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

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2005 13:45:43 +0200

I'd go with suggestion C

On Mar 1, 2005, at 2:25 AM, Paul Hoffman wrote:

> 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

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

---

From: "Geoffrey Huang" <[email-masked]>
Date: Tue, 1 Mar 2005 08:41:46 -0800

I prefer C.

-g 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Hoffman
> Sent: Monday, February 28, 2005 4:26 PM
> To: IPsec WG
> Cc: Theodore Y. Ts'o; Russ Housley; Barbara Fraser
> Subject: [Ipsec] Technical change needed to IKEv2 before publication
> 
> 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:
> 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
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Mar 2005 13:29:42 +0200

> Change the places that says Transform Type 5 is optional to say

I think C is best, as it will also work with versions implemented
using old version. I.e. if you always say that DO ESN and/or DONT ESN
then there is no question which one is the default.

For implementations which do not support ESN they can simply always
add DONT ESN in the proposal and return no proposal chosen in case the
other end proposes only DO ESN. For implementations doing both (and
allowing both) will then send both values.
-- 
[email-masked]