draft-ietf-ipsec-ike-ext-meth-01.txt
"Valery Smyslov" <svan@trustworks.com> Mon, 28 June 1999 14:39 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26347; Mon, 28 Jun 1999 07:39:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03691 Mon, 28 Jun 1999 08:36:54 -0400 (EDT)
Message-Id: <199906281236.QAA03140@relay1.trustworks.com>
Comments: Authenticated sender is <svan@ss10>
From: Valery Smyslov <svan@trustworks.com>
Organization: TWS
To: Tero Kivinen <kivinen@ssh.fi>
Date: Mon, 28 Jun 1999 16:36:00 +0004
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: draft-ietf-ipsec-ike-ext-meth-01.txt
CC: ipsec@lists.tislabs.com
X-mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Tero, please, see some comments below. > 5. Order of Checking > > The order of checks performed for IKE datagram SHOULD be following: This is true not only for IKE datagrams, but for generic ISAKMP datagram also. So, the wording should probably be: "The order of checks performed for ISAKMP datagram SHOULD be following:" > 6. ISAKMP Major and Minor Version Numbers > > All IKE datagrams contain version numbers, which describe the major and Again, "All ISAKMP datagrams..." > There are no separate major and minor version numbers for ISAKMP and > IKE, so they both share one major/minor version number. Because the > ISAKMP document describes the generic packet formats etc, changes in the > ISAKMP part will propably cause major version number to be incremented. > On the other hand changes in the IKE part propably will keep the generic > packet formats intact, thus only minor version number might need to be > incremented. Tero, I've been still under impression, that mixing IKE and ISAKMP versions number is not a good thing. Let us leave ISAKMP major and minor versions for changes in ISAKMP and encode future IKE versions as new transform identifiers. Otherwise we will have difficulties in case an alternative KE protocol will be defined within ISAKMP framework. What meaning shall minor ISAKMP number have in this case? What meaning shall it have if two (or more) different KE protocols (different transform identifiers) are proposed by initiator? Moreover, by mixing ISAKMP minor version number with IKE version you seem to contradict with section 5 of your own draft (order of checking), because you require to check minor version number before you even get know that it is really an IKE datagram, not general ISAKMP datagram. So, you implicitly assume that all ISAKMP datagrams are IKE datagrams, that is not true (at least in theory). > Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 > negotiation that creates ISAKMP SA may use version X, and phase 2 > negotiation done over that ISAKMP SA may use version Y. I don't think this is right, especially with your intention to use minor ISAKMP version number as IKE version number. Future IKE versions may completely redefine internal cryptographic variables, so mixing old and new versions may become problematic (consider the situation when future IKE version will use not SKEYID, but, say, two variables). I think that negotiated during phase 1 IKE and ISAKMP versions must be used for all subsequent negotiations under this ISAKMP SA. > 6.1. ISAKMP Major Version Number > > If an old version receives a datagram with a major version number larger > than its own, it SHOULD send the INVALID-MAJOR-VERSION notification > back. It MUST put its own version number inside the notification > datagram. This gives the other end the opportunity to obtain the version > number supported by the sender of the notification. The received IKE > datagram MUST then be discarded (the old version cannot parse anything Again, "ISAKMP datagram" - you don't know at this point whether this is IKE or something else. > 6.2. ISAKMP Minor Version number > > If an old version receives a datagram with a minor version newer than > its own, it > > o SHOULD continue processing the datagram, or it > > o MAY discard the IKE datagram. In that case it SHOULD send the Again, "ISAKMP datagram". > 7. Phase 1 Transform Identifier > > Phase 1 SA payload contains a transform identifier that currently > specifies the key exchange method used. It can be used to negotiate key > exchange method used, but it cannot really be used as a version number > of the IKE protocol. IKE protocol defines also other exchanges > (notifications, deletes) that do not contain SA payload. Its use is Yes, but all of them can take place only after phase 1, when you already know what IKE version you use. If you prohibit using different IKE versions for subsequent exchanges under given ISAKMP SA, you will always know what KE protocol of which version does any exchange belongs to (even if its message doesn't contain SA payload) - this information can be saved in ISAKMP SA state. Those exchanges that can take place before phase 1 must be ISAKMP specific, not IKE or some other KE protocol specific. > There may be a need to add a criticality flag in the generic payload > header in the next version of IKE [RFC-2409]. This allows an old version I think this is probably an ISAKMP issue, not IKE's. > 13. Reserved Fields > > Lots of payloads in the IKE contain RESERVED fields that are defined to They are defined in ISAKMP, not in the IKE. Regards, Valery.
- draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen