> 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
