Telechat Review of draft-ietf-behave-64-analysis-
review-ietf-behave-64-analysis-genart-telechat-black-2012-02-29-00

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
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------