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

From: [email-masked]
Date: Tue, 1 Mar 2005 13:55:23 +0200

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
> 

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 01 Mar 2005 07:56:34 -0500

> problem is.

I wasn't at the bakeoff, either, but I think I see what it is.
I have this odd feeling that we are reinventing ethernet capability
negotiation, badly.

> ESNs, it will reply with NO_PROPOSAL_CHOSEN.

.. and bits don't move.

I'm not sure how proposals "A" and "C" help interoperability.
It looks to me more like a disagreement on the default.

There is this bit in section 3.3.3:

    ... "A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE."

which is inconsistent with the ESN default defined in the immediately
previous section.

Aside from fixing the above, to I'd think we'd need to codify one of:

 - if you can do ESN, double your fun: when in doubt, always include 
both ESN and non-ESN variants in your proposals.

 - psychic retry logic ("maybe I should try again with ESN turned off").

Option "B", or a richer variant ("I can {always, never, sometimes} do ESN with {AH, ESP}" would help both variants:
  1) it lets the peer trim out proposals which it knows would be rejected
  2) requires less psychic ability in the initiator

That said, there is this bit in the next section:

3.3.3 Valid Transform Types by Protocol
    ... "A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE."

which is inconsistent with the ESN default defined in the immediately
previous section.

					- Bill

---

From: Paul Koning <[email-masked]>
Date: Tue, 1 Mar 2005 10:29:29 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

 Bill> I'm not sure how proposals "A" and "C" help interoperability.
 Bill> It looks to me more like a disagreement on the default.

Perhaps, but so what?  I'm wondering the same thing as Pasi mentioned.

All things being equal, it seems reasonable to make the ESN transform
type code mandatory rather than optional.  But unless I'm missing
something, that doesn't affect the original issue at all.

I believe the original problem statement was:

a. Sender insists on ESN
b. Responder doesn't support ESN

Clearly "no proposal chosen" is the expected and correct outcome
then.  If the sender actually wanted to allow ESN either on or off, it
should have proposed that.

Right now, the sender can express "I insist on ESN" two ways (by
sending ESN(1) or by not sending ESN at all).  But the semantics are
the same either way.  Yes, the encoding rule for ESN is inconsistent
with other rules, and yes, it would be reasonable to clean that up,
but that won't affect the outcome of the negotiation in the case under
discussion.

 Bill> - if you can do ESN, double your fun: when in doubt, always
 Bill> include both ESN and non-ESN variants in your proposals.

 Bill> - psychic retry logic ("maybe I should try again with ESN
 Bill> turned off").

Right.  That's just a specific case of this general observation: If
you propose lots of things, something may end up being chosen.  If you
propose few things, you may get "no proposal chosen" at which point
you're either out of luck or you have to make some guesses about what
to do next.  I prefer the former, but either is permitted.

       paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Mar 2005 07:47:53 -0800

>proposal, use of Extended Sequence Numbers is assumed.")

Correct; there was no disagreement there.

>these alternatives is fine with me, you choose".

Right.

>ESNs, it will reply with NO_PROPOSAL_CHOSEN.

Exactly. There is no way to say *why* no proposal was chosen, so that 
the initiator, if they actually want a tunnel up, has to randomly 
guess the reason. That leads to lack of interop, which we saw at the 
bakeoff.

>is fine with me, you choose".)

The major conceptual difference is that ESNs have *nothing* to do 
with either traffic flow or cryptography; they are simply a 
housekeeping feature that each side has.

>I have this odd feeling that we are reinventing ethernet capability

s/are reinventing/have reinvented/ It is too late to change them now.

If you look through the negotiation and announcement mechanisms we 
use in IKEv2, you see that some are done with transform proposals for 
which there is no response other than yes or no, others are through 
transform proposals for which there is an informative hint that can 
be attached to a failure, some are just through notifications, and 
some are through vendor-ids.

>It looks to me more like a disagreement on the default.

"A" (change the default) helps in the currently-common case where the 
recipient hasn't implemented ESNs; it hurts in the long-run case when 
most systems will have implemented ESNs. "C" (make the transform 
mandatory) helps all the time: it says exactly what the initiator is 
willing to do (ESN, no ESN, or either). Without sending the 
transform, it is not clear whether the initiator is insisting on ESN 
or simply preferring it. (This part is murky for all proposals, of 
course.)

>which is inconsistent with the ESN default defined in the immediately

...and probably inconsistent with what "NONE" means.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Mar 2005 07:52:27 -0800

A different way to view this, one which does *not* require us to 
change the current IKEv2 spec, would be to make this a clarification. 
We could simply write a clarification (that would go into Pasi's 
clarification document) that would add a sentence to the end of 
Section 3.3.2 that says "Note that if the initiator is willing to 
accept either the use of extended sequence numbers or not, the 
initiator SHOULD send this transform in its proposals."

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 01 Mar 2005 11:25:08 -0500

> b. Responder doesn't support ESN

I'm questioning the utility of (a) in real-world networks.

What actual problems are solved by failing to move bits unless
the responder supports ESN?  

The fix needs to include recommendations to implementors regarding how to
avoid this little "wings-stay-on / wings-fall-off" option trap.

						- Bill

---

From: Tom Stiemerling <[email-masked]>
Date: Tue, 1 Mar 2005 11:27:34 -0500

The problem that was found at the bake-off is that some vendors
implementations (correctly) insisted that the ESN(off)
transform was included in all proposals, since they did not support ESN,
and not including the ESN transform meant
ESN was on (as specified in the draft). Therefore to interoperate with all
responders - without knowing whether they supported
ESN or not - the initiator always has to include either ESN(off) if it does
not support ESN, or ESN(off) | ESN(on) if the responder
does support ESN. So the ESN transform is then not really optional any
more, and it was decided to make this explicit
in the draft.

Cheers, Tom