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

<mohamed.boucadair@orange.com> Wed, 29 February 2012 09:37 UTC

Return-Path: <mohamed.boucadair@orange.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 525EC21F8879 for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 01:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level:
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
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 1L9r49uu11Ke for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 01:37:09 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4191721F8876 for <gen-art@ietf.org>; Wed, 29 Feb 2012 01:37:03 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B39E52DC3CA; Wed, 29 Feb 2012 10:37:01 +0100 (CET)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8E27627C054; Wed, 29 Feb 2012 10:37:01 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 29 Feb 2012 10:37:01 +0100
From: <mohamed.boucadair@orange.com>
To: "david.black@emc.com" <david.black@emc.com>, "rpenno@juniper.net" <rpenno@juniper.net>, "tasaxena@cisco.com" <tasaxena@cisco.com>, "ssenthil@cisco.com" <ssenthil@cisco.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Date: Wed, 29 Feb 2012 10:37:00 +0100
Thread-Topic: Gen-ART review of draft-ietf-behave-64-analysis-06
Thread-Index: Acz2Mith6bPDej4wTwiRs+mM/3oLzgAkSCQA
Message-ID: <94C682931C08B048B7A8645303FDC9F35D88B262B7@PUEXCB1B.nanterre.francetelecom.fr>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.29.81216
X-Mailman-Approved-At: Wed, 29 Feb 2012 04:49:19 -0800
Cc: "ietfdbh@comcast.net" <ietfdbh@comcast.net>, "dthaler@microsoft.com" <dthaler@microsoft.com>, "dwing@cisco.com" <dwing@cisco.com>, "Martin.Stiemerling@neclab.eu" <Martin.Stiemerling@neclab.eu>
Subject: Re: [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: Wed, 29 Feb 2012 09:37:10 -0000

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 : david.black@emc.com [mailto:david.black@emc.com] 
> Envoyé : mardi 28 février 2012 17:01
> À : rpenno@juniper.net; tasaxena@cisco.com; BOUCADAIR Mohamed 
> OLNC/NAD/TIP; ssenthil@cisco.com; gen-art@ietf.org
> Cc : david.black@emc.com; dwing@cisco.com; 
> dthaler@microsoft.com; ietfdbh@comcast.net; 
> Martin.Stiemerling@neclab.eu
> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
>