Subject: [Ipsec] Technical change needed to IKEv2 before publication

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Feb 2005 16:25:57 -0800

Greetings again. During the IKEv2 bakeoff last week, a technical 
mistake was found in the current IKEv2 Internet Draft. This is not 
something that simply needs to be clarified; it needs an actual fix 
to the document because, without it, interoperability is literally 
impossible.

(FWIW, the bakeoff also led to about 25 clarifications that will be 
sent to the list soon. These are all clarifications to areas that one 
or more bakeoff participant felt was unclear. They are only 
clarifications, not technical changes.)

After discussing this briefly with Russ Housley, our AD, we decided 
to poll the Working Group on how to fix the problem. If we can reach 
consensus soon (such as within a week from today), it may not delay 
the publication of the IKEv2 RFC. Russ will want to hear from the WG 
co-chairs as to our consensus.

-------------------

Issue: If a receiver doesn't support ESN, they require the sender
to send an ESN transform

Some systems know that they don't support ESN, and therefore they
require the other side to actively say they won't expect it. The only
way for the other side to do so is for it to send a Transform Type
5 with a value of 0. However, there is no way for the responder to
say that to the initiator, so interoperability is not possible.

This is a technical error in the IKEv2 spec. There are three simple
possible ways to change this:

SUGGESTION A:
The last sentence of 3.3.2 says:
           If Transform Type 5 is not included in a proposal, use of
           Extended Sequence Numbers is assumed.
Replace this with:
           If Transform Type 5 is not included in a proposal, it is
           assumed that the sending party does not support Extended
           Sequence Numbers.

SUGGESTION B:
Create a new response notification that says "I can't do ESN, start
again and include a 'no ESN' transform."

SUGGESTION C:
Change the places that says Transform Type 5 is optional to say
it is mandatory.

-------------------

The people I spoke with at the bakeoff agreed that suggestions A and 
C would both work and be easy to implement. Personally, I think 
suggestion C is better because having defaults tends to lead to 
interoperability issues down the line when new implementers don't 
read all the defaults. It's only a few extra bytes per proposal to 
always be explicit.

Please respond on the list soon so that the WG co-chairs can advise 
the ADs of the WG consensus on this and prevent a delay in the 
document's publication.

--Paul Hoffman, Director
--VPN Consortium

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