David: Has an errata been entered against RFC 3948?
On Feb 28, 2012, at 11:01 AM, <[email protected]> <[email protected]> wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd or > AD before posting a new version of the draft. > > Document: draft-ietf-behave-64-analysis-06 > Reviewer: David L. Black > Review Date: February 28, 2012 > IETF LC End Date: February 20, 2012 > IESG Telechat Date: March 1, 2012 > > Summary: > > This draft is on the right track but has open issues, described in the review. > > Comments: > > This draft summarizes the improvements of stateful 64 techniques over the > now-historic > NAT-PT techniques for communication between IPv4 and IPv6 networks. The > draft does a > nice job of summarizing the current situation in a fashion that avoids the > reader > having to go through the plethora of details in the cited references. The > draft is > clearly written and reads well. > > There is one open issue that's almost a nit - unfortunately, the IPsec > discussion in > item 6 of Section 3.2 is wrong, even though it was copied from RFC 4966 > (FWIW, it's > wrong there, also): > > 6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic > using IPsec AH (Authentication Header), in transport and tunnel > mode, and IPsec ESP (Encapsulating Security Payload), in > transport mode, is unable to be carried through NAT-PT without > terminating the security associations on the NAT-PT, due to their > usage of cryptographic integrity protection (Section 4.5 of > [RFC4966]). > > There are four problems with that explanation: > > (1) AH cannot be UDP-encapsulated. RFC 3948 says: > > Because the protection of the outer IP addresses in IPsec AH is > inherently incompatible with NAT, the IPsec AH was left out of the > scope of this protocol specification. > > (2) The reasons for use of UDP encapsulation with ESP do not include ESP's > "usage of cryptographic integrity protection." because ESP's cryptographic > integrity protection does not include any IP header fields. The actual > reasons > are considerably more subtle and involved (e.g., traffic selector issues and > NAT implementations that did not work correctly with IKE), see RFC 3715. > > (3) Nit: The correct RFC 4966 reference is Section 2.1, not 4.5. > > (4) A number of additional references are needed, starting with RFC 3715. > > Here's an attempt to propose a text change: > > OLD > 6. Unless UDP encapsulation is used for IPsec [RFC3948], traffic > using IPsec AH (Authentication Header), in transport and tunnel > mode, and IPsec ESP (Encapsulating Security Payload), in > transport mode, is unable to be carried through NAT-PT without > terminating the security associations on the NAT-PT, due to their > usage of cryptographic integrity protection (Section 4.5 of > [RFC4966]). > NEW > 6. IPsec traffic using AH (Authentication Header) [RFC4302] in > both transport and tunnel modes cannot be carried through NAT-PT > without terminating the security associations on the NAT-PT, due > to the inclusion of IP header fields in the scope of AH's cryptographic > integrity protection [RFC3715] (Section 2.1 of [RFC4966]). In > addition, IPsec traffic using ESP (Encapsulating Security Payload) > [RFC4303] in transport mode generally uses UDP encapsulation [RFC3948] > for NAT traversal (including NAT-PT traversal) in order to avoid the > problems described in [RFC3715] (Section 2.1 of [RFC 4966]). > END > > The Security Area should review the above proposed text change. > > idnits 2.12.13 noted that RFC 2766 was obsoleted by RFC 4966 - this is > fine, as RFC 2766 does need to be cited. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [email protected] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
