[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On transport-level policy enforcement (was Re: RFC 2401...)
Surseh,
>--- 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).
yes, if dynamic entries are fully specified (no wildcards) then it
should be easy to add a cache entry.
>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.
Order is still important in the uncorrelated (base) SPD, but adding
fully qualified entries is independent of order.
Steve
References: