Greetings again. During discussion with the other authors of IKEv2bis, we discovered some problems with the proposed resolution to issue #12 about traffic selectors when rekeying. The text I proposed to put in the document was this: ----- 2.9.2 Traffic Selectors in Rekeying
Rekeying is used to replace an existing Child SA with another. If the new SA were allowed to have a narrower set of selectors than the original, traffic that was allowed on the old SA would be dropped in the new SA, thus violating the idea of "replacing". Thus, the new SA MUST NOT have narrower selectors than the original. If the rekeyed SA would ever need to have narrower scope than currently used SA, that would mean that the policy was changed in a way that the currently used SAs are against the policy. In that case, the SA should have been already deleted after the policy change took effect. When the initiator attemepts to rekey the Child SA, the proposed traffic selectors SHOULD be either the same as, or a superset of, the traffic selectors used in the old Child SA. That is, they would be the same as, or a superset of, the currently active (decorrelated) policy. The responder MUST NOT narrow down the traffic selectors narrower than the scope currently in use. Because a rekeyed SA can never have narrower scope than the one currently in use, there is no need for the selectors from the packet, so those selectors SHOULD NOT be sent. ----- It was pointed out that (a) this is a new MUST and (b) this also assumes that the encryption algorithm and so on will be the same. So, how does the WG want to proceed here? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
