Russ, I think the errata would be needed against RFC 4966 (not 3948), and there is no errata on this topic, yet. I can enter one after the final text for this draft is approved.
Thanks, --David > -----Original Message----- > From: Russ Housley [mailto:[email protected]] > Sent: Tuesday, February 28, 2012 3:44 PM > To: Black, David > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; gen- > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06 > > 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
