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

<david.black@emc.com> Tue, 28 February 2012 16:01 UTC

Return-Path: <david.black@emc.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC31121F857A for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 08:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.695
X-Spam-Level:
X-Spam-Status: No, score=-109.695 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6vuiOP2BxRA for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 08:01:36 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5687A21F8576 for <gen-art@ietf.org>; Tue, 28 Feb 2012 08:01:36 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1SG1HWm011424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 11:01:32 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 28 Feb 2012 11:01:06 -0500
Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1SG0xa9002130; Tue, 28 Feb 2012 11:01:05 -0500
Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Tue, 28 Feb 2012 11:01:04 -0500
From: david.black@emc.com
To: rpenno@juniper.net, tasaxena@cisco.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, gen-art@ietf.org
Date: Tue, 28 Feb 2012 11:01:02 -0500
Thread-Topic: Gen-ART review of draft-ietf-behave-64-analysis-06
Thread-Index: Acz2Mith6bPDej4wTwiRs+mM/3oLzg==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: ietfdbh@comcast.net, dthaler@microsoft.com, dwing@cisco.com, Martin.Stiemerling@neclab.eu
Subject: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2012 16:01:37 -0000

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