Re: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] 
> Envoyé : mardi 28 février 2012 17:01
> À : [e-mail]; [e-mail]; BOUCADAIR Mohamed 
> OLNC/NAD/TIP; [e-mail]; [e-mail]
> Cc : [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
>