[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On transport-level policy enforcement (was Re: RFC 2401...)
--- Stephen Kent <kent@bbn.com> wrote:
> Andrew,
>
> >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.
>
> I think there is an opportunity for folks to work on optimizing the
> decorrelation algorithm for dynamic addition/deletion operations.
> Deletion should not be a problem; back pointers to the decorrelated
> entries will enable one to remove them. Addition may be a bit harder.
>
> Steve
Addition is even easier, if you assume that dynamic SPD entries will be
session specific (i.e, no regular expressions) and will only need exact
match. In such a case, each new SPD entry can simply be prepended at the
start of the SPD list (de-correlated, cached SPD).
Assuming that the order is no longer important, it is quite reasonable to
seperate individual session specific entries from the regular expression
based entries and list them in that order.
cheers,
suresh
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Follow-Ups:
References: