[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DataStructure for Storing SPD,SA Entries
Deconflicting overlapping policy (e.g. port ranges, subnets, all TCP to
Any IP vs. All traffic to 1.1.1.1) was the main point why RFC 2401 says
filters must be manually ordered.
However, I'll posit that, when talking about IP packet filters that are
matched only at the IP level (or below), manual ordering is enforceable
only if your policy comes from one source. Clearly if policy comes from
two sources, and if it overlaps, it would be impossible to guarantee the
outcome of each original manual ordering. If your run-time effective
policy comes from a static policy definition, then enhanced from a local
command line, possibly enhanced by local service or application API
calls to protect their traffic, and perhaps filters are generated by a
default response policy (accept whatever is proposed by the initiator)
when nothing else matches inbound IKE QM requests, then you must have an
automatic, total ordering, decorrelation algorithm.
With many new IETF protocols specifying their traffic to be protected by
IPsec, and some like iFCP in the IP Storage group requiring tunneling
mode instead of transport mode, enforcing strict admin manual ordering
of filters in the static policy he applied last week does not appear to
be feasible for an end-system.
To the extent possible, I've encouraged other protocols to request IPSec
transport mode 5-tuple specific IPsec SA pairs. This is how L2TP
requests IKE quick mode to establish an SA pair for src me, dst gw, UDP,
src <specific>, dst 1701.
However, many people have argued that they want an IPSec SA established
for TCP src <any>, dst <their port>, so they don't get additional
overhead of QM's & IPSec SA pairs per new connection. I see their
point. However, different source ports could imply different
applications or even identities connecting to the same service port at
the destination IP. In L2TP's case, a new UDP source port connecting to
the same destination port could mean a new L2TP tunnel (L2TP can do new
tunnel sessions across the same port pair with session IDs). The IKE
identity used is that of the machine, thus it could have requested src
<any>, dst 1701 in QM. We just had to decide, and chose the "safer"
full 5-tuple. L2TP itself identifies the user for each tunnel in it's
PPP negotiation completely independent of IPsec.
Anyway, decorrelation ordering based on most specific seems reasonable,
since IP will see a full 5-tuple outbound and inbound. Just hope the
other guy implements the same ordering, so the return traffic doesn't
use a different IPSec SA than the pair you initially established...
-----Original Message-----
From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
Sent: Thursday, October 18, 2001 5:25 AM
To: Puja Puri
Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; ranjeet
barve
Subject: Re: DataStructure for Storing SPD,SA Entries
I use three tries in my implementation -- but it really isn't the
relevant issue here. It sounds to me like you are really glossing over
the issue of overlapping policy. If you do not implement a
decorrelation algorithm, you are probably going to cause yourself some
major problems down the road. Are you going to be hardcoding the policy
values in yourself, or are you going to be selling a product that will
have the policies loaded by a system administrator after the sale?
Assuming the latter case is correct, and you insist on using a hash
lookup, then you really should guarantee that your product will not
overlap the policies ever -- don't blame the system administrators for
not using the product correctly if the initial design is not robust and
able to separate the policies dynamically in the field.
Steve
"Puja Puri"
<puja.puri@cdac.ern To: "ranjeet barve"
<ranjeet_barve@yahoo.co.in>
et.in> cc:
<ipsec@lists.tislabs.com>
Sent by: Subject: Re:
DataStructure for Storing SPD,SA Entries
owner-ipsec@lists.t
islabs.com
10/18/01 01:13 AM
hi
Its true that finding an efficient hash function seems to be a major
problem but then once that is done, hash tables prove to be efficient.
Rajesh, I suggest u to do some r&d on hash function to find a suitable
one for you. For instance the hi/fn toolkit for IPSec uses hash tables.
But unfortunately such implementations don't mention about their hash
functions.
The selectors do contain a number of fields but remember that according
to RFC 2401 u can use one or more fields from selectors to map to ur
policies. This makes life simpler.
The queries with wildcards do create some problem but that can be sorted
out with the way u implement.
As far as tries are concerned, I have no idea whether any
implementations use it or not.
I hope Rajesh that atleast i have tried answering all your queries.
regds
puja
----- Original Message -----
From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
To: "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, October 18, 2001 9:51 AM
Subject: Re: DataStructure for Storing SPD,SA Entries
> hi,
> With Hash Table finding an efficient hash function
> seems to be a major Problem. Also as the Selector
> contains of a number of fields, it would make the task
> even complicated. Which Implementations are using Hash
> Tables for storing SPD and SAD? What kind of hash
> functions do they use??
>
> Also does the range queries with wild cards not create
> a major problem in formulating a Hash Function??
> Does any implementation use Tries for Storing SPD,SAD?
>
> Please help me with the above queries,
>
> Regards,
> Ranjeet Barve,
> M.Tech IIT Bombay.
>
>
>
> --- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> > Hash tables seem to be good for SPD n SAD, since
> > search is faster than many
> > other data structures. It is used by many toolkits
> > which implement IPSec.
> >
> > Just need to take care that policies don't overlap
> > Correct me anybody if I am wrong.
> > regds
> > puja
> > ----- Original Message -----
> > From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> > To: <ipsec@lists.tislabs.com>
> > Sent: Friday, October 12, 2001 8:10 PM
> > Subject: DataStructure for Storing SPD,SA Entries
> >
> >
> > > hi,
> > > I had a quesiton on the Data Structure to use for Security Policy
> > > Database and Security Association Entries.
> > > Which would be the most efficient Data Structure
> > for
> > > Storing SPD and SA entries ??
> > > Which Data-Structure is Most Commonly used?
> > > (I apologise if this question is already answered
> > in
> > > the mailing list.)
> > >
> > > Please let me know.
> > >
> > > Regards,
> > > Ranjeet Barve,
> > > M.Tech IIT Bombay.
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________
> > > Do You Yahoo!?
> > > Send a newsletter, share photos & files, conduct
> > polls, organize chat
> > events. Visit http://in.groups.yahoo.com
> >
>
> ____________________________________________________________
> *NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
Follow-Ups: