[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: