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

Russ Housley <housley@vigilsec.com> Tue, 28 February 2012 20:43 UTC

Return-Path: <housley@vigilsec.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 729DB21F86D0 for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 12:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level:
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 FSWxm+YcPRar for <gen-art@ietfa.amsl.com>; Tue, 28 Feb 2012 12:43:54 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63B21F86C7 for <gen-art@ietf.org>; Tue, 28 Feb 2012 12:43:54 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 509F99A472A; Tue, 28 Feb 2012 15:44:10 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id QiKR35SNhQJy; Tue, 28 Feb 2012 15:43:48 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D7C169A4727; Tue, 28 Feb 2012 15:44:09 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com>
Date: Tue, 28 Feb 2012 15:43:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2B84A7F-BF4D-4E97-B3E8-EDAC64F76836@vigilsec.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8C63C@MX14A.corp.emc.com>
To: <david.black@emc.com> <david.black@emc.com>
X-Mailer: Apple Mail (2.1084)
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:43:56 -0000

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