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

<david.black@emc.com> Wed, 29 February 2012 14:47 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 3EBBD21F86F6 for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 06:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.708
X-Spam-Level:
X-Spam-Status: No, score=-109.708 tagged_above=-999 required=5 tests=[AWL=0.891, 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 Ims8oAi0iifZ for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 06:47:01 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5206921F86EF for <gen-art@ietf.org>; Wed, 29 Feb 2012 06:46:57 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1TEkksF024900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 09:46:52 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 29 Feb 2012 09:46:35 -0500
Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1TEkVa0020663; Wed, 29 Feb 2012 09:46:34 -0500
Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Wed, 29 Feb 2012 09:46:31 -0500
From: <david.black@emc.com>
To: <mohamed.boucadair@orange.com>, <rpenno@juniper.net>, <tasaxena@cisco.com>, <ssenthil@cisco.com>, <gen-art@ietf.org>
Date: Wed, 29 Feb 2012 09:46:30 -0500
Thread-Topic: Gen-ART review of draft-ietf-behave-64-analysis-06
Thread-Index: Acz2Mith6bPDej4wTwiRs+mM/3oLzgAkSCQAAAqGX+A=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C94C@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com> <94C682931C08B048B7A8645303FDC9F35D88B262B7@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F35D88B262B7@PUEXCB1B.nanterre.francetelecom.fr>
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: dthaler@microsoft.com, dwing@cisco.com, Martin.Stiemerling@neclab.eu, ietfdbh@comcast.net
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 14:47:03 -0000

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: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
> Sent: Wednesday, February 29, 2012 4:37 AM
> To: Black, David; rpenno@juniper.net; tasaxena@cisco.com; ssenthil@cisco.com; gen-art@ietf.org
> Cc: dwing@cisco.com; dthaler@microsoft.com; ietfdbh@comcast.net; Martin.Stiemerling@neclab.eu
> 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 : 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
> > ----------------------------------------------------
> >
> >