Re: [IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996)
Hi David, Thanks for detecting this glitch. I don't think this is worth an erratum, given that we are republishing the document. Thanks, Yaron On 05/19/2014 05:09 AM, Black, David wrote: In looking for something else, I ran across a minor thinko in the rfc5996bis draft that was inherited from RFC 5996. Section 3.14, Encrypted Payload, 4th paragraph: When an authenticated encryption algorithm is used to protect the IKE SA, the construction of the Encrypted payload is different than what is described here. See [AEAD] for more information on authenticated encryption algorithms and their use in ESP. [AEAD] is a reference to RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. Hence, a change is in order at the end of the paragraph: ESP - IKEv2 In the unlikely event that the IESG finds nothing else to change in the draft :-), an RFC Editor Note ought to suffice to handle this. Should I also file an erratum against RFC 5996? Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.comMobile: +1 (978) 394-7754 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996)
Black, David writes: In looking for something else, I ran across a minor thinko in the rfc5996bis draft that was inherited from RFC 5996. Section 3.14, Encrypted Payload, 4th paragraph: When an authenticated encryption algorithm is used to protect the IKE SA, the construction of the Encrypted payload is different than what is described here. See [AEAD] for more information on authenticated encryption algorithms and their use in ESP. [AEAD] is a reference to RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. Hence, a change is in order at the end of the paragraph: ESP - IKEv2 In the unlikely event that the IESG finds nothing else to change in the draft :-), an RFC Editor Note ought to suffice to handle this. Thanks. I made the change in the current xml file, i.e. so next time I make new version this change will be there. Should I also file an erratum against RFC 5996? I do not think we want to do that, as then I would have to publish new version immediately, as the draft-kivinen-ipsecme-ikev2-rfc5996bis says it has fixes for all errata... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996)
In looking for something else, I ran across a minor thinko in the rfc5996bis draft that was inherited from RFC 5996. Section 3.14, Encrypted Payload, 4th paragraph: When an authenticated encryption algorithm is used to protect the IKE SA, the construction of the Encrypted payload is different than what is described here. See [AEAD] for more information on authenticated encryption algorithms and their use in ESP. [AEAD] is a reference to RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. Hence, a change is in order at the end of the paragraph: ESP - IKEv2 In the unlikely event that the IESG finds nothing else to change in the draft :-), an RFC Editor Note ought to suffice to handle this. Should I also file an erratum against RFC 5996? Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
