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.