[email protected] writes: > I agree that rekeying is currently not very easy to understand. But > e.g. early drafts of ikev2-clarifications (-00 and -01) included some > text wondering about what exactly N(REKEY_SA) means (that is, what is > different when you do/don't include REKEY_SA in CREATE_CHILD_SA > exchange), and all of those reasons (which I think you also > commented back then) would IMHO allow the new SA to be narrower > than the old (even when N(REKEY_SA) is included)...
I originally also tought so, i.e. that is the reason this issue is here in the first place. I.e. if the narrower traffic selectors are allowed, then we MUST also have traffic selectors from the triggering packet. Then other people convinced me that if there would be reason for the rekeyed SA to have narrower traffic selectors that are currently used, then the SA would have been already deleted because it would have been against policy, thus such situation cannot ever happen. Check the original ticket description (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=1#L1). I do not really have strong opinion which way to go, but we either needs to make sure there is the triggering packet traffic selectors (which might be problematic if SA was rekeyed because of time) and the rekey can narrow down traffic selectors. Or we assume that narrowing case cannot happen, as the SAs were already deleted before they were rekeyed in such situations, and we can say that traffic selectors MUST NOT narrow down. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
