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

From: <[email-masked]>
Date: Tue, 28 Feb 2012 11:01:02 -0500

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Feb 2012 15:43:53 -0500

David:

Has an errata been entered against RFC 3948?

On Feb 28, 2012, at 11:01 AM, <[email-masked]> <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Tue, 28 Feb 2012 15:49:47 -0500

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-masked]]
> Sent: Tuesday, February 28, 2012 3:44 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; gen-
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06
> 
> David:
>

---

From: <[email-masked]>
Date: Wed, 29 Feb 2012 10:37:00 +0100

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-masked] [mailto:[email-masked]] 
> Envoyé : mardi 28 février 2012 17:01
> À : [email-masked]; [email-masked]; BOUCADAIR Mohamed 
> OLNC/NAD/TIP; [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Objet : Gen-ART review of draft-ietf-behave-64-analysis-06
>

---

From: <[email-masked]>
Date: Wed, 29 Feb 2012 09:46:30 -0500

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

Thanks,
--David

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