[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-ike-ext-meth-01.txt
Valery Smyslov writes:
> > 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:
True, but the document is more concerned about the IKE extensibility
than ISAKMP. Also I am not sure if the text is at all acceptable when
somebody defines other key exchange method than IKE, and it is very
hard to think about that before you see the other protocol. After
somebody does that, this document propably needs to be updated
anyways...
> > 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.
Perhaps I should be more clear to say that every time we change minor
or major version it is really ISAKMP modification not IKE
modifications. The end effect is same, the ISAKMP version number is
going to go up every time we make bigger changes to IKE.
The document isolates the modifications which need changes to the
version numbers (flags, new use of reserved, and maybe new payload
types), and they are strictly speaking ISAKMP modifications not IKE
modifications.
> 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?
It still defines the packet format of the system. Even if the IKE has
added some flags or new use for reserved fields (the criticality flag
for payloads) thus causing the new minor version number (== new ISAKMP
version), it does not necessary mean that other KE protocols must use
that version they can be using the old 1.0 version if the want to.
If the other KE protocol also wants to modify the ISAKMP packet
structure (lets say they want to add another flag), then they have to
take the latests version of ISAKMP, including the changes done because
of the IKE update and update from there.
Note, that there is no changes in the will bump up the ISAKMP version
number without the packet format also changing at the same time.
> What meaning shall it have if two (or more) different KE protocols
> (different transform identifiers) are proposed by initiator?
Good question. Currently I don't think you can do it, because for
example the KE payload etc might be completely different depending on
the KE protocol. So you cannot really do that in general case.
For some limeted use you might be able to do it, for example if you
are using the main mode you could do it (only SA payload in the first
payload), but unfortunately IKE rfc says that you can have only
"single proposal payload in a single SA payload", so if you offer two
proposal the other end is propably going to fail immediately.
I didn't like that restriction when it was added, and I still dont
like it, but it is there.
> 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).
Yes, you are right that, that order of checking applies also for
generic ISAKMP packets, but it also applies to IKE packets... The
document is still named "IKE Extensions Methods", because that is
where the intrest of this document really is. In most cases where
there is a string "IKE" you can change to to say "ISAKMP" and you
still get things right.
> > 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.
There might be limitiations in mixing the version numbers, but in
general I would say they it should be allowed. If we redefine SKEYID
in phase 1, then that SKEYID is used for later exchanges also, and in
that case mixing the versions is not allowed. When somebody makes that
kind of modification then they have to disallow that in their
document.
BTW changing the SKEYID doesn't cause minor number to updated, but
that is just one of those limited things you can do by changing the
transform id.
> > 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.
Thats why this two cases are the only ones that requires the ISAKMP
minor version number to be updated.
The current document is written mostly from the IKE standpoint, and it
quite often considers IKE and ISAKMP same. It could be quite easily to
be exanded it to generic ISAKMP extension method documents, but then I
would have to use more time think cases which are not relevant for
IKE (which I am not sure if it is going to be that usefull, because I
will propably get them all wrong...)
I could update it for the next version so that I change almost all
instances of "IKE" to "ISAKMP" and add still some more text about IKE
transform id, and remove that one paragraph talking about ISAKMP and
IKE version numbers.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: