Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

Tero Kivinen <kivinen@iki.fi> Mon, 08 March 2010 15:43 UTC

Return-Path: <kivinen@iki.fi>
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 689DB3A6A24; Mon, 8 Mar 2010 07:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
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 toUTtJZWCRLN; Mon, 8 Mar 2010 07:43:13 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF743A6A1F; Mon, 8 Mar 2010 07:43:12 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o28FhCNI000387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:43:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28FhBfB015673; Mon, 8 Mar 2010 17:43:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19349.6926.978794.772035@fireball.kivinen.iki.fi>
Date: Mon, 08 Mar 2010 17:43:10 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240803c7bac47aaf65@[10.20.30.158]>
References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <p06240810c7b8ad71932e@[10.20.30.158]> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> <p06240803c7bac47aaf65@[10.20.30.158]>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, ietf@ietf.org
Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
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: Mon, 08 Mar 2010 15:43:14 -0000

Paul Hoffman writes:
> At 8:16 AM +0100 3/8/10, <Pasi.Eronen@nokia.com> wrote:
> >Well, this depends on whether you think Section 1.7 should list
> >textual changes in the document, or clarification/changes to the
> >protocol.
> >
> >IMHO, it should be the latter, but I see that currently it's really
> >listing the textual changes (even when they clearly don't have any
> >impact on the protocol); so perhaps listing these separately is
> >consistent with that...
> 
> The problem with making this list more conceptual (as both you and
> Tero have requested) is that doing so may help future implementers
> but can miss context that is important to a current implementer who
> needs to change their implementation.

As an implementor I disagree with you on that. 

> In this particular example, we have one change that affects two very
> different parts of the document, and someone who implemented by
> reading RFC 4306 (instead of knowing it instinctively like you and
> Tero) might really need to see exactly which bits *of the spec* are
> changing to decide which bits of their code is changing.

Yes that change changes two locations of the text, but only one
location in the implementation. Thus for someone who is doing this
change for their implementation it would be important to understand
that this change is actually just one code change, not two. Also the
change is most likely going to be in the policy enforing part than in
the actual exchange handling code (1.3.2) or the SKEYSEED calculation
part. The implementation simply needs to enforce the IKE SA rekey
policy so that Diffie-Hellman is not optional and that is only change
they need to do in the code. They already have to calculate the
SKEYSEED (most likely with or without the g^ir (new)), and they
already have the code to parse KEi and KEr (generic code). 

> I will try to come up with a way to cover the conceptual change as
> well, but really am loath to remove the section references in the
> change description. 
-- 
kivinen@iki.fi