[IPsec] RFC5996bis section 3.1 comment

Tero Kivinen <kivinen@iki.fi> Fri, 25 April 2014 12:43 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B4F1A04B8 for <ipsec@ietfa.amsl.com>; Fri, 25 Apr 2014 05:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level:
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2AkRwszvKHl for <ipsec@ietfa.amsl.com>; Fri, 25 Apr 2014 05:43:40 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 933E11A04B7 for <ipsec@ietf.org>; Fri, 25 Apr 2014 05:43:39 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3PChSAE015095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Apr 2014 15:43:28 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3PChRTp007762; Fri, 25 Apr 2014 15:43:27 +0300 (EEST)
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: <21338.22639.519882.711032@fireball.kivinen.iki.fi>
Date: Fri, 25 Apr 2014 15:43:27 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@cypherpunks.ca>
In-Reply-To: <alpine.LFD.2.10.1311131536150.9256@bofh.nohats.ca>
References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1311131536150.9256@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 3 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LK6rDT2JprO_mNr2ckyE_8HTGLU
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: [IPsec] RFC5996bis section 3.1 comment
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 25 Apr 2014 12:43:42 -0000

I am making new version of the rfc5996bis, so going through old emails
too... 

Paul Wouters writes:
> On Thu, 17 Oct 2013, Tero Kivinen wrote:
> 
> [forgive me if already reported]
> 
> Section 3.1 states:
> 
>     o  Major Version (4 bits) - Indicates the major version of the IKE
>        protocol in use.  Implementations based on this version of IKE
>        MUST set the major version to 2.  Implementations based on
>        previous versions of IKE and ISAKMP MUST set the major version to
> -->   1.  Implementations based on this version of IKE MUST reject or
>        ignore messages containing a version number greater than 2 with an
>        INVALID_MAJOR_VERSION notification message as described in Section
>        2.5.
> 
> The reading of "this version" on the line marked "-->" is a little
> unclear. Does it refer to the previous sentence's version (version 1)
> or this version as in "this document's" version (version 2). I suggest
> replacing "this version" with "this document's version"

Changed to:

Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE MUST set
the major version to 2. Implementations based on previous versions of
IKE and ISAKMP MUST set the major version to 1. Implementations based
on this document's version (version 2) of IKE MUST reject or ignore
messages containing a version number greater than 2 with an
INVALID_MAJOR_VERSION notification message as described in Section
2.5.

>     o  Minor Version (4 bits) - Indicates the minor version of the IKE
>        protocol in use.  Implementations based on this version of IKE
>        MUST set the minor version to 0.  They MUST ignore the minor
>        version number of received messages.
> 
> For the Major we tell what IKEv1 implementations should do. Why don't we
> do that for the Minor as well? Suggested addition:
> 
>  	Implementations based on the previous major version of IKE and
>  	ISAKMP MUST set the minor version to 0 and reject or ignore
>  	messages containing a minor version number greater than 0 with
>  	an INVALID_MINOR_VERSION  notification message.

I do not think we want to specify how IKEv1 implementations needs to
work. This is IKEv2, and as IKEv2 will ignore the minor version
number, it does not matter what IKEv1 implementations do it, or how
they sent it. The Major version number text was needed as
implementations need to know how to differentiate IKEv1 and IKEv2,
minor version number handling of IKEv1 does not matter for IKEv2
implementations. 
-- 
kivinen@iki.fi