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

[<[e-mail]>]

Hello Mohamed,

> 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.

Thank you for picking up the text.

It would be helpful for the Security Area to double-check it - I've cc:'d Sean Turner (SEC AD) in the hope that he or one of the IPsec experts in the Security Directorate can quickly check this 1-paragraph proposed text change, as in addition to this draft, I will need to file the result as errata against RFC 4966.

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

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, February 29, 2012 4:37 AM
> To: Black, David; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Gen-ART review of draft-ietf-behave-64-analysis-06
> 
> 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]
> > ----------------------------------------------------
> >
> >