The traffic selectors in the REKEY exchange are not currently specified. If were designing IKEv2 from scratch, I would be in favor of removing traffic selectors altogether from REKEY exchanges - I don't think it should be called a "rekey" if you get a totally different SA. This does raise the question (that has been asked before) of why do we really need REKEY_SA exchanges as opposed to regular exchanges.
As it is, I think the initiator of the rekey (not necessarily the same as the initiator of the old SA) should keep the selectors in the old SA, and the responder should either accept of reject, but I don't think we need to capitalize the SHOULD. In some implementations, the REKEY is generated because of traffic passing the IPsec stack when little time remains before the child SA expiration. It may be much more convenient to rekey with the narrowed selectors rather than locating an SPD entry which is a superset of the SPD cache entry that matches this SA. I think the rekey initiator SHOULD propose any superset of the current selectors, which can be the current selectors, or anything that matches its policy. I don't think we should recommend doing one or the other. We can and should, however, require the responder to not expect the traffic selectors in a rekey-SA to exactly match those of the current SA. Tero Kivinen wrote: > That is one change that is needed, but in addition I think we > need to say that the TSi and TSr should be the original > traffic selectors from the policy, not the already narrowed > down ones that the current child SA is using. > > I.e. if initiator originally offered TSi as > 10.0.0.0-10.0.255.255 and included specific packet of > 10.0.0.5 TCP port 25 by sending following TSi entries: > > TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) > > and then the responder narrowed it down to per host basic, i.e. > returned TSi as: > > TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) > > now when the initiator starts to rekey that SA after > receiving TCP packet going to that SA (otherwise he would not > be rekeying this SA), and lets say the packet is 10.0.0.5 TCP > port 80, so he should send TSi when rekeying as follows: > > TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) > > Note, that the second entry is still the whole 10.0.0.0 - > 10.0.255.255 range as specified by the policy, not the > already narrowed down range of 10.0.0.5 - 10.0.0.5 which the > current child SA is using. > > If the responders policy is still same it will still return same TSi: > > TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) > > > If the responders policy has been changed so that port host > SAs are no longer required it can instead rekey the old SA to > have TSi which would cover the new range, i.e. widen up the > traffic selectors from what they used to be. > > If this is not done, then this kind of widening is not > possible, meaning that even if the policy is fixed the > original more narrow policy is still used. > > I have seen implementations where the traffic selectors are > sent out (and narrowed to) based on the traffic selectors > used in the child SA now, not what is specified in the > policy. The traffic selectors used in the child SA can always > be only more narrow than what is in the policy (if child SA > would have more wider traffic selectors than what is allowed > by policy it would be violating the policy, and it would be deleted). > > I would like to have text saying that the original traffic > selectors from the policy SHOULD be used. > -- > kivi...@iki.fi Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
