Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

"Frankel, Sheila E." <sheila.frankel@nist.gov> Wed, 21 October 2009 20:08 UTC

Return-Path: <sheila.frankel@nist.gov>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AA93A690C for <ipsec@core3.amsl.com>; Wed, 21 Oct 2009 13:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.227
X-Spam-Level:
X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvsWxXSZqAZ8 for <ipsec@core3.amsl.com>; Wed, 21 Oct 2009 13:08:39 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id B4EFC3A68D0 for <ipsec@ietf.org>; Wed, 21 Oct 2009 13:08:38 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9LK8BpP024542; Wed, 21 Oct 2009 16:08:13 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 21 Oct 2009 16:08:12 -0400
From: "Frankel, Sheila E." <sheila.frankel@nist.gov>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: Wed, 21 Oct 2009 16:08:10 -0400
Thread-Topic: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
Thread-Index: AcpSh9E1R5spaP+uSDemfdD8Gxx7nAAAZNyO
Message-ID: <D7A0423E5E193F40BE6E94126930C4930789878B68@MBCLUSTER.xchange.nist.gov>
References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> <D7A0423E5E193F40BE6E94126930C4930789878B5E@MBCLUSTER.xchange.nist.gov>, <p06240807c70514f45089@[10.20.30.158]>
In-Reply-To: <p06240807c70514f45089@[10.20.30.158]>
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-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: sheila.frankel@nist.gov
Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2009 20:08:39 -0000

If that's the case, we'll remove the offending statements in the roadmap.

Just 2 more questions: even if this was a sloppy document, why is there a separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms? Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either?

Sheila
________________________________________
From: Paul Hoffman [paul.hoffman@vpnc.org]
Sent: Wednesday, October 21, 2009 3:50 PM
To: Frankel, Sheila E.; Tero Kivinen; ipsec@ietf.org
Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

Looking through the archives for the IPsec WG (the predecessor to this one), Tero's interpretation is probably closer to what happened than Sheila's. It is unfortunately that both Sheila and Tero use the word "clearly" when talking about RFC 4307; the archive would strongly indicate that it is inappropriate to use that word when discussion RFC 4307.

We need to remember that the flight of documents coming out of the original WG included both RFC 4305 and RFC 4307. There was some sloppy cross-over of requirements due to a poor split late in the process. However, the WG seems to have wanted to have two different sets of requirements, one for IKEv2 crypto, and one for AH/ESP crypto. This is what makes me think that Tero's interpretation is closer to what happened, regardless of what words were (possibly inappropriately) left in RFC 4307 at the point that the WG became exhausted.

--Paul Hoffman, Director
--VPN Consortium