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

<david.black@emc.com> Tue, 28 February 2012 20:50 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 3D74021E8056 for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 12:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.702
X-Spam-Level:
X-Spam-Status: No, score=-109.702 tagged_above=-999 required=5 tests=[AWL=0.897, 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 O2tPGPiS7Etu for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 12:50:04 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD8F21E8054 for <gen-art@ietf.org>; Tue, 28 Feb 2012 12:50:04 -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 q1SKnwCM027173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 15:49:59 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 28 Feb 2012 15:49:50 -0500
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1SKnnRx015299; Tue, 28 Feb 2012 15:49:50 -0500
Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 28 Feb 2012 15:49:49 -0500
From: <david.black@emc.com>
To: <housley@vigilsec.com>
Date: Tue, 28 Feb 2012 15:49:47 -0500
Thread-Topic: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06
Thread-Index: Acz2WdCswU2U/45JTxCRSwL3yq/sbAAABlog
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C7A8@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com> <D2B84A7F-BF4D-4E97-B3E8-EDAC64F76836@vigilsec.com>
In-Reply-To: <D2B84A7F-BF4D-4E97-B3E8-EDAC64F76836@vigilsec.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: tasaxena@cisco.com, mohamed.boucadair@orange.com, gen-art@ietf.org, rpenno@juniper.net, ssenthil@cisco.com, 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: Tue, 28 Feb 2012 20:50:06 -0000

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:housley@vigilsec.com]
> Sent: Tuesday, February 28, 2012 3:44 PM
> To: Black, David
> Cc: rpenno@juniper.net; tasaxena@cisco.com; mohamed.boucadair@orange.com; ssenthil@cisco.com; gen-
> art@ietf.org; ietfdbh@comcast.net; dthaler@microsoft.com; dwing@cisco.com;
> Martin.Stiemerling@neclab.eu
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-behave-64-analysis-06
> 
> David:
> 
> Has an errata been entered against RFC 3948?
> 
> 
> On Feb 28, 2012, at 11:01 AM, <david.black@emc.com> <david.black@emc.com> wrote:
> 
> > 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
> > ----------------------------------------------------
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
>