Subject: RE: [Ipsec] First draft of IKEv2.1

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Dec 2005 16:58:30 -0800

At 3:18 PM -0800 12/29/05, Charlie Kaufman wrote:
>If this document is limited to clarifications and truly minor revisions,

It is not. There are many places where the 2.0 spec was unclear, 
leaving implementers with multiple ways to attempt to do something; 
the version 2.1 spec says exactly how to do them, often with 
MUST-level language.

>  then it should not change the version number from 2.0 to 2.1. The 
>semantics of such a change are defined in the v2.0 document.

Correct. It says:

    The minor
    version number indicates new capabilities, and MUST be ignored by a
    node with a smaller minor version number, but used for informational
    purposes by the node with the larger minor version number.

Adding new MUST-level methods is a new capability.

>Changing to 2.1 implies that the recipient should do something 
>differently when seeing the 2.1 than when seeing the 2.0. If there 
>is such a change, it should be carefully documented (e.g. if there 
>were some new notification types that should only be sent to someone 
>who agreed to speak version 2.1).

All of the changes are fairly clearly labelled in the document. The 
labelling makes it a bit harder to read, and thus may change in a 
later draft, but right now it is fairly easy to find every 
non-trivial change by searching for "{{".

>A related concern is that if there are going to be changes that are 
>likely to affect interoperability, I would not expect we could sneak 
>this through without re-forming a working group to review it. Some 
>of your SHOULD vs. MUST changes were hard fought at the time (and I 
>believe in some cases I wanted to make some of the changes you 
>propose and was told not to by the working group).

It is up to the ADs if they want to re-form the WG. Many other 
protocols have continued to develop after their WGs shut down, while 
some have had the WG started up.

Given that this mailing list is still alive and active, and given 
that there are many active developers and a fair amount of 
interoperability testing going on, there may not be much need to form 
a WG.

>It would be good to have a new base document for the next round of 
>substantive changes to IKE and for that document to include the 
>explanation of minor version number negotiation, but I wouldn't 
>expect such a document to move forward any time soon. It would also 
>be good to have a document that merges the original IKEv2 document 
>with your clarifications - possibly as annotations, or possibly as 
>integrated text. But we are still early in deployment, and I would 
>expect that document would be updated frequently over the next few 
>years.

The IKEv2 implementers have shaken out the unclear parts fairly well 
so far. For example, after the first IKEv2 bakeoff, there was a slew 
of additions to the clarifications document; after the second 
bakeoff, there were almost none. We have gotten almost no new input 
to the clarifications document in the past few months.

It does not benefit the users to have a version hanging in limbo for 
years if the version is fairly complete. On the other hand, if my 
opening version 2.1 brings out a lot more additions and changes to 
the core IKEv2 protocol, we should work on them until it is complete. 
But those may not be likely, given the past six months of relative 
quiet.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Dec 2005 12:21:40 +0200

> the version 2.1 spec says exactly how to do them, often with 

If the 2.0 spec was written so that no interoperable versions can be
written using that text, then adding MUST or SHOULDs to make it able
to write interoperable versions isn't really a change, but
clarification.

I think the question is:

Do the v2.1 implementation do something differently when he notices
other end is v2.0 or not?

If the answer is no, v2.1 does not need to do anything differently
when other end is v2.0 or whether it is v2.1 version then I do not
think we need to update the version number. 

>     purposes by the node with the larger minor version number.

So in what places the v2.1 version needs to act differently when the
other end is v2.0 version?

> Adding new MUST-level methods is a new capability.

Adding MUST level to the sending part but still allowing other options
when receiving (i.e. say you MUST send xxx, but MUST also accept yyy
when receiving). 

> >who agreed to speak version 2.1).

Actually new notification types do NOT need version number change.
There is already text in the document saying that unknown notification
types are ignored, and we normally use them as one way notifications,
and things are agreed only when we see the other end sending such
notification back (for example when both ends have sent and received
USE_TRANSPRORT_MODE).

Just adding new notification type does not normally require updating
version number.

> non-trivial change by searching for "{{".

Good, need to check that document soon. 

> interoperability testing going on, there may not be much need to form 

I think the question is do we want to do separate interoperability
tests for v2.1?

Or do we simply assume that we do IKEv2 interoperability tests, and
that can be done with both v2.0 and v2.1 implementations.

I myself would like to see only v2.0 versions out there, and this
document only as a clarification explaining and modifying only things
that were non-interoperable with base RFC4306 spec. If there is no
need for the other end to know whether the other end support v2.1 or
v2.0, then I would leave that thing out.

Leaving the version number to 2.0 would also make it clear that no new
features are allowed, and no bits on the wire can be changed. Also we
cannot allow something that was forbidden and working by RFC4306. On
the other hand if something was so there was no way to make
interoperable version based on the RFC4306, then it really does not
matter if we change that, as we cannot break interoperable versions. 

> to the clarifications document in the past few months.

One reason for that is that we are through the basic tests, but there
are still cases which will cause changes when we start testing more
complicated things. Things like the thread here in the list few weeks
ago about the delete payloads to unknown SPIs and what error message
to send back and so on. 

> But those may not be likely, given the past six months of relative 

I still think we should keep the version number 2.0 if we can do that,
i.e. is there something now in the document that did work with base
RFC4306 spec in interoperable way, but which is done differently on
your draft?

I do not care about cases which you could not make interoperable
versions based on RFC4306. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Dec 2005 09:49:49 -0800

>to write interoperable versions isn't really a change, but

Do other implementers agree with this assessment? If so, it would be 
fine to keep the 2.0 numbering. Before answering, *please* read the 
actual document (ahem) and look at each change.

If we don't change the minor version number, some implementations 
will be going by RFC 4306 SHOULD/MUST rules (which were confusing in 
many cases), and other implementations will be going by the new 
SHOULD/MUST rules, and there will be no indication which is which. If 
there is a MUST in the new document where there was a SHOULD in the 
old document, there is essentially no point to making the MUST to 
increase interoperability.

If what people want is just the clarifications rolled in with no 
actual increased interoperability, that's fine and easy to do, but 
that is not what I heard from many implementers. Maybe seeing all the 
changes in one place will help that decision.

--Paul Hoffman, Director
--VPN Consortium