Re: [IPsec] Bis issue #11: Clarify which traffic selectors
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPsec] Bis issue #11: Clarify which traffic selectors
[[ Changed the subject line because Tero didn't. No other changes. ]]
At 2:34 PM +0200 2/5/09, Tero Kivinen wrote:
> > IKEv2-bis
>> Issue #11: Clarify which traffic selectors to use in rekeying.
>> Paul: [unclear]. Tero: if you have SAs that violate the new
>> policy, you either delete them or you rekey. Prefers a rekey,
>> even if this is narrowing the SA. Mostly useful for decorrelated
>> policies, but people are not doing that yet [general agreement by
>> silence]. Gives an example of a specific connection moving from
>> one SA to another, which he says is a policy change that requires
>> a rekey, but only if you're doing decorrelated policy.
>
>The example I gave was that we have IPsec SA between two hosts (or
>subnets) and then someone adds new SPD rule which has higher
>precedence and which says that port 80 between those hosts should be
>put on separate SA. This effectively creates hole to the old IPsec SA,
>thus the old IPsec SA now covers traffic selectors which it should
>not.
>
>> Paul: if no-one is doing decorrelated policies, then they
>> wouldn't have thought of this issue. Tero: some user
>> interfaces may eliminate the need to support this feature
>> altogether.
>
>There is three ways to do this:
>
>1) Forbid overlapping selectors (i.e. make user interface so that you
> cannot enter overlapping traffic selectors, and require
> adminstrator to "decorrelate" traffic selectors manually).
>
>2) Go through SPD entries in the precedence order and do not use any
> kind of caching. This requires linear scan through SPD for every
> single packet.
>
>3) Do the decorrelation properly and then you can use effective
> datastuctures to find the correct SPD entry, i.e. no linear scan is
> needed as you know that there cannot be any overlapping SPD entries
> in the decorrelated policy.
>--
>kivinen at iki.fi
>_______________________________________________
>IPsec mailing list
>IPsec at ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.