[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-kivinen-ike-ext-meth-00.txt
Valery Smyslov writes:
> >There are no separate 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 needs to be incremented.
> Well, what about situations when ISAKMP is used not with IKE, but with
> some other KE protocol?
When somebody starts using it that way, they have to define what do
they mean. The current situation is that there is only one major and
minor version number, and we are stuck with that, until we revise the
protocol specification.
> Or, even worse, when ISAKMP SA contains multiple transforms with
> different KE protocols in each? To which of them will you apply
> minor version number?
Can you give me example how that can be done? The SA payload contains
only one DOI, so I think you have to use it for only one KE protocol
at a time. So if you want to support multiple KE protocols you
propably have to allocate DOI numbers for each of them, thus you can
only use one of the in one negotiation.
> I think that new IKE versions should be encoded as a totally new transform
> identifiers. Now we have only KEY_IKE; when new version appear we will
> have, say, KEY_IKE and KEY_IKE_v2.
The problem is that if we redefine some fields in the generic payload
structure (like adding the criticality flag) for IKE, then we cannot
parse the SA payload to find out that transform identifier. But you
are right in any case that, I should add something about that KEY_IKE
transform number also in the draft. I completely forgot it...
> >Each party MUST NOT change the version number it is sending during one
> >negotiation, i.e if negotiation was started using version number 1.1, it
> >MUST be used during the whole negotiation. Separate negotiations MAY
> >have different version numbers, i.e newer version may restart
> >negotiation with older version number.
> >
>
>
> [...]
>
> >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
> > INVALID-MINOR-VERSION notification back.
> >
> >In any case the old version MUST respond with a datagram containing the
> >local minor version number so that a new version can get the older
> >version number and fall back to same version if necessary.
>
> Does it means (in conjunction with previously quoted paragraph, that
> prohibits version number changing during negotiating), that it is
> possible for ISAKMP headers of initiator and responder to contain
> _different_ minor version numbers during negotiating (if responder
> desides to continue negotiating)?
Yes. There is nothing in the current RFC set to say against that.
> In this case initiator must keep in mind two minor version numbers
> during negotiating - one (highest), that it puts into outgoing
> ISAKMP datagrams, and the other (lowest), that it process both
> incoming and outgoing datagrams according with. Is it right?
Yes.
> Note, that if it is the case, initiator's datagrams will contain one
> minor version number, but will be formatted according to other
> (lower) minor version number.
Not really. It sends packet out just as if the other end would be
using same version number. It can disable itself to use of some
extensions that it knows would cause problems in the other end, but it
should still continue sending packets that conform its own version
number. If it detects it cannot do that (because it would need to use
extension that the other end will not understand), it should fall back
to the previous version and start the negotiation from the start.
All this really depends on what kind of extensions the next version of
ISAKMP/IKE defines. Remember that this document is mainly for the
current implementators. The basic idea is that if they follow the
basic rules in the document and those who define next version of
protocol or add new extension does the same, then the old versions
can work with the newer versions. Those who define next version of
protocol or add new extension MUST define in the document what new
version should do if the other end doesn't support the feature.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/