[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On transport-level policy enforcement (was Re: RFC 2401...)
> 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.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> Sent: Monday, November 27, 2000 4:18 PM
> To: Dan McDonald
> Cc: ipsec@lists.tislabs.com
> Subject: Re: On transport-level policy enforcement (was Re:
> RFC 2401...)
>
>
> Dan,
>
> I was away for a week, and terribly far behind, so this reply is way
> of out order, but ...
>
> Your analysis of how to do the checking is fine for a native host
> implementation where per-connection state is already available. In a
> security gateway, the problem is a bit different. 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. We can also divide
> the discussion into SG vs. native host environments, to simplify
> matters.
>
> Steve
>