Dear David, Thank you for the review.
I adopted in my local copy the text you proposed to describe the IPsec issue. I can even shorten the text to something like "IPsec complications with NAT-PT (Section 2.1 of [RFC4966])" but I prefer your text because it provides more RFC pointers. Cheers, Med > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] > Envoyé : mardi 28 février 2012 17:01 > À : [email protected]; [email protected]; BOUCADAIR Mohamed > OLNC/NAD/TIP; [email protected]; [email protected] > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > Objet : Gen-ART review of draft-ietf-behave-64-analysis-06 > > 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
