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

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 1 Mar 2005 05:16:06 -0800

Hi Pasi,

I do not understand IKE well, however the place where I think
clarification is needed is: -

     "If a transform is optional and the initiator
      wishes to propose that the transform be omitted, no transform
      of the given type is included in the proposal."

from the above I assume it means that the responder should not have the
transform in the response.

however
          If Transform Type 5 is not included in a proposal, use of
          Extended Sequence Numbers is assumed.

The simpler solution could be to respond with ESN (0). Does it make
sense?

I had another doubt about transform Id 0 being used for transform type
5. Is it ok to use a transform ID of 0(as I think it holds a special
meaning)?

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, March 01, 2005 5:25 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication

Hi,

I wasn't at the bakeoff, but I don't quite see what the 
problem is..

My reading of the spec was that a proposal with no ESN transform 
means exactly the same thing as the same proposal + ESN transform 
containing value 1. ("If Transform Type 5 is not included in a 
proposal, use of Extended Sequence Numbers is assumed.")

Thus, a proposal with ESN(0) means "don't use ESNs", a proposal 
with ESN(1) or no ESN transform at all means "use ESNs", and a 
proposal containing both ESN(0) and ESN(1) means "either of 
these alternatives is fine with me, you choose".

So, if the initiator does not include the ESN transform at all,
it really means "using normal sequence numbers is not acceptable
according to my policy", so if the responder does not support
ESNs, it will reply with NO_PROPOSAL_CHOSEN.

(This would be consistent with how other transform types work;
e.g., if initiator includes only ENCR(AES_CBC) it means that
other choices are not acceptable, while including both
both ENCR(3DES) and ENCR(AES_CBC) means "either of these 
is fine with me, you choose".)

(Or is there some non-obvious problem with this approach
that I missed?)

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Paul Hoffman
> Sent: Tuesday, March 01, 2005 2:26 AM
> 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:
> 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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2005 16:10:50 +0200

On Mar 1, 2005, at 3:16 PM, Vishwas Manral wrote:
<snip
> 5. Is it ok to use a transform ID of 0(as I think it holds a special

The problem is that yes(1) and no(0) are the two valid values for the 
ESN transform type.  Any IPsec SA uses this transform (with either a 
yes or no value) and any proposal includes it either explicitly or 
implicitly by omission.  If the initiator proposed ESN(1), the 
responder cannot answer ESN(0) because the zero value was not proposed 
by the initiator.  It's the same as if the initiator proposed 
ENCR(3DES) and the responder answered ENCR(AES_128).

Another option would have been to have 1 as the only valid value, and 
then omission would be the same as saying that ESN is not supported, 
but in that case, how could the transform be optional?

I also don't like Bill's idea of having a richer variant of "B".  This 
makes for repeated exchanges with slightly differing proposals until 
something works.  This is fine for Ethernet or PPP where you can have 
multiple such exchanges in a second, but on the Internet where packets 
may take a full second or more to make a round trip, this would make 
the setting up of tunnels very long.  It would be nice to have an 
explanation accompanying the "NO PROPOSAL CHOSEN", so that 
administrators can better configure their VPN, but as it stands, making 
the specification mandatory is the best way out.