[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DataStructure for Storing SPD,SA Entries



I think removing the requirement on policy ordering works only if your
system supports one security modeul for all peers, e.g. the `friendly' model,
i.e., if it's not specified secured in the SPD bypass the traffic.  It will
not work if you need to support both the friendly model and the opposite (discard
by default).  The policies still need to be ordered, somewhere and somehow,
but may not be globally.

--Wei Jen Yeh

William Dixon wrote:
> 
> 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

-- 
Wei-Jen Yeh
weijyeh@nortelnetworks.com	Nortel, RTP, NC
Office Phone: (919) 991-2707,	ESN: 35-12707
Fax: (919) 991-8073


References: