[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-ike-ext-meth-01.txt
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.