[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
- [IPsec] Updated version of RFC5996bis Tero Kivinen
- Re: [IPsec] Updated version of RFC5996bis Paul Wouters
- Re: [IPsec] Updated version of RFC5996bis Yaron Sheffer
- Re: [IPsec] Updated version of RFC5996bis Yoav Nir
- Re: [IPsec] Updated version of RFC5996bis Paul Wouters
- Re: [IPsec] Updated version of RFC5996bis Tero Kivinen
- [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Yoav Nir
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- Re: [IPsec] Editorial changes to RFC5996 Valery Smyslov
- Re: [IPsec] Editorial changes to RFC5996 Yaron Sheffer
- [IPsec] One more editorial issue in RFC5996 Valery Smyslov
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- Re: [IPsec] RFC5996bis editorial change in sectio… Yaron Sheffer
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- Re: [IPsec] RFC5996bis editorial change in sectio… Valery Smyslov
- Re: [IPsec] RFC5996bis editorial change in sectio… Yaron Sheffer
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 1.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 2.… Tero Kivinen
- [IPsec] RFC5996bis editorial change in section 3.… Tero Kivinen
- [IPsec] RFC5996bis section 3.1 comment Paul Wouters
- [IPsec] RFC5996bis section 3.1 comment Tero Kivinen