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

Tero Kivinen <kivinen@iki.fi> Mon, 08 March 2010 15:08 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 27A723A69C5; Mon, 8 Mar 2010 07:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 cw6HaQh0s6Uy; Mon, 8 Mar 2010 07:08:02 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 661D73A69C0; Mon, 8 Mar 2010 07:08:02 -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 o28F84CJ018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:08:04 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28F83Pl009239; Mon, 8 Mar 2010 17:08:03 +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.4819.856265.175704@fireball.kivinen.iki.fi>
Date: Mon, 08 Mar 2010 17:08:03 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Pasi.Eronen@nokia.com
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <p06240810c7b8ad71932e@[10.20.30.158]> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 8 min
Cc: ipsec@ietf.org, paul.hoffman@vpnc.org, 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:08:04 -0000

Pasi.Eronen@nokia.com writes:
> Paul Hoffman wrote:
> 
> > >- One of the changes is listed in Section 1.7 twice. I'd suggest
> > >combining
> > >
> > >   In section 1.3.2, changed "The KEi payload SHOULD be included" to
> > >   be "The KEi payload MUST be included".  This also led to changes in
> > >   section 2.18.
> > >
> > >and
> > >
> > >   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
> > >   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
> > >   Hellman exchange was optional, but this was not useful (or
> > >   appropriate) when rekeying the IKE_SA.
> > >
> > >as follows:
> > >
> > >   This document requires doing a Diffie-Hellman exchange when
> > >   rekeying the IKE_SA (and thus requires including the KEi/KEr
> > >   payloads).  In theory, RFC 4306 allowed a policy where the
> > >   Diffie-Hellman exchange was optional (and KEi/KEr payloads could be
> > >   omitted), this was not useful (or appropriate) when rekeying the
> > >   IKE_SA.
> > 
> > Disagree. Where possible, I tried to list the actual sections where
> > changes were made, and your proposed rewording loses the two places.
> > The current text is more explicit than the proposed change.
> 
> 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...

I agree with you that it should be listing actual clarifications and
changes, not just textual changes. For implementor it does not really
matter what paragraphs were changed, he is interested what changes he
need to do for his implementation and for that the text saying that
Diffie-Hellman is now mandatory when rekeying IKE SA is much more
important than the fact that this changed text in section 1.3.2 and
2.18.

I proposed multiple such changes (including the one you pointed out)
in my email
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05766.html) but
Paul didn't want to make those changes
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05769.html). As
nobody else seemed to care, I didn't continue complaining about the
issue.
-- 
kivinen@iki.fi