Scott C Moonen writes: > Tero, the existence of RFC 4304 represents an even more direct way in which > ESPv3 and AHv3 have leaked into IKEv1.
True. On the other hand that is feature that is explictly negotiated in the IKEv1, which only enables the one specific feature of the ESPv3 to the IKEv1 and IPsec-v2. If you use that option, I do not expect that you are allowed to use traffic flow confidentiality even if you send that option. And we did make our mind when we decided to have the current wording on the RFC6071. > I'm inclined to take your option 1, though I would quibble with "nobody > uses." :) Considering both ESN and combined-mode algorithms, it seems that > in practice we have general agreement that it is legitimate for two IKEv1 > implementations to mutually agree to use ESPv3 and AHv3 without importing > all of IPsec-v3. Which features of IPsec-v3 is imported? Do using any of the features from the ESPv3 mean that all features of ESPv3 are available. Do we take any changes from the RFC4301 too? Perhaps we have 4th option, i.e. just add note saying that this is not really feature which should be used here as it is only defined for ESPv3. Or at least mark those ciphers separately which require (and perhaps imply) ESPv3. But do to that I would really need more text than what would be useful in the IANA footnote, and having new RFC for obsolete IKEv1 would be quite useless... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
