Tero Kivinen wrote: > Paul Hoffman writes: > > It was pointed out that (a) this is a new MUST and > > Yes, but it can mostly be already deducted from the requirement that > end node cannot violate its own policy, meaning it needs to delete > Child SA which are not following his policy. If that is already done, > there is no point for the new SA having narrower scope than old SA > had, and making this MUST makes it simplier for implementations (i.e. > they do not need to think what to do for the traffic which do not fit > the rekeyed SA, and we do not need to add the traffic selectors from > the packet parts). > > > (b) this also > > assumes that the encryption algorithm and so on will be the same. > > No it does not. I do not see any text there saying anything about > encryption algorithms. Those are negotiated as normally and again if > policy has been changed so that the original algorithms are not valid > anymore, then the child SA should have been deleted already.
Hmm... narrowing and algorithm negotiation can interact. Consider the following situation: Alice's SPD: traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred) Bob's SPD: traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred) traffic on UDP ports 1500-1999 MUST use ESP w/AES The old SA (OK to both Alice and Bob): UDP ports 1000-1999, AES Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this SA, proposing algorithms AES and 3DES, and traffic selectors for UDP ports 1000-1999. Bob prefers 3DES, and picks that. But now Bob cannot meet the requirement "new SA MUST NOT be narrower than the old one", because it would violate his policy. So, I think the current text in 2.9.2 *does* assume that encryption algorithm negotiation behaves differently when rekeying (and IMHO this requirement is not in RFC 4306). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
