[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On transport-level policy enforcement (was Re: RFC 2401...)
Steve,
Thanks for clarifying this. I only asked because we had heard of earlier
suggestions for caching SPD rules where the requirement that the
decorrelated database be fully precalculated was not stated. I agree that it
makes sense to store the database in this format. Yes, the SPD will be
larger, but I am willing to bet that the scaling will be better than O(n).
This seems like an implementation detail, and an implementation doing it
this way today wouldn't really be non-compliant, since it is merely an
optimization of an ordered database. But it's worth mentioning in the RFC
anyway...
One potential complication is dynamic SPD rules. An application will need to
be able to add and delete rules dynamically without having to rebuild the
entire database.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, April 03, 2001 7:21 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: On transport-level policy enforcement (was Re:
> RFC 2401...)
>
>
> Andrew,
>
> > > We wrote the
> >> generic checking description we didn't know how to cache
> SPD rules in
> >> such circumstances. We now have ways of doing that which do not
> >> violate the SPD ordering assumption. The next rev of 2401
> will update
> >> the inbound processing discussion accordingly.
> >
> >Steve,
> >
> >If you'd like to discuss how this will be done, either on
> the list or at the
> >meeting, I think several of us would be interested. My
> instinct tells me
> >that this is going to require some extra rules that limit
> the ways in which
> >policy can be expressed, and I'm wondering what they are.
>
> Whoops! I lost this one in my inbox for quite a while!
> Sorry about that.
>
> During some work for DARPA on security policy management in complex
> security domain topologies, some BBN researchers came across the idea
> of decorrelating the entries in the SPD, i.e., processing them so
> that no two entries overlap. This increases the size of the SPD, but
> the resulting database no longer needs to be ordered. since any
> packet will match at most one entry. So, I propose adopting a model
> that shows the SPD as a decorrelated database, and adding an SPD
> cache to the model. When an SA is established, one looks into the SPD
> and finds a match, then moves the entry to the SPD cache, where all
> future searches for outbound packets take place. Only if you have a
> miss on this cache for an outbound packet do you go back to search
> the SPD, e.g., as would occur if an SG encountered a new traffic
> stream.
>
> I think will make the explanation much clearer, and if one chooses
> to mimic it in an implementation (which is not required, of course)
> the lookup time for outbound traffic generally would be faster too.
>
>
> As for your concern re policy, I don't see a problem, since the
> decorrleation process transforms the original, ordered SPD into an
> unordered, but equivalent database.
>
> Steve
>
Follow-Ups:
References: