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

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 1 Mar 2005 03:57:13 -0800

Hi Paul,

I am ok with C too.

Besides I had raised some text requiring minor clarifications, which
could be included too.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Hoffman
Sent: Tuesday, March 01, 2005 5:56 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: [email-masked]
Date: Tue, 1 Mar 2005 17:12:18 +0200

Bill Sommerfeld writes:

> > 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.
> 
> .. and bits don't move.

Yes (which is exactly what should happen, since doing otherwise
would violate the initiator's policy -- not that such a policy
would be very common or sensible, though).

> 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.

Hmm... this depends on whether you consider ESN something that
can be omitted (just like you can omit integrity protection for
ESP), or whether sequence numbers is something that you always
have, and we currently have two different "algorithms" for
handling them.

>From the latter viewpoint, the choices are "normal" and
"extended" (there is no value "NONE"), and the current text is
(mostly) consistent. It would also imply that initiators that
support ESN will almost always include both ESN(0=normal) and
ESN(1=extended) in their proposals.

But if you like the former viewpoint better, then the current
text is inconsistent (at least the text you quoted from 3.3.3).
It seems that suggestion A from Paul's email (no ESN transform
in the proposal means no ESNs) would make it consistent, though.
It would still imply that an initiator who supports ESNs but
accepts also normal sequence numbers has to include both
ESN(0) and ESN(1) transforms in proposals.

A third alternative would be to adopt option A, but in addition
change the negotiation logic so that including ESN(1) also
implies that ESN(0) is acceptable. I don't think we should do
this, since it's not consistent with how other transforms are
negotiated (e.g., proposing ENCR(AES) does not mean that you're
willing to accept ENCR(NONE)).

Any which way, I don't see any need for new notification 
payloads here. 

Best regards,
Pasi

---

From: [email-masked]
Date: Tue, 1 Mar 2005 18:18:22 +0200

Paul Hoffman writes:
> 
> At 1:55 PM +0200 3/1/05, [email-masked] wrote:
>> 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.")
> 
> Correct; there was no disagreement there.
> 
>> 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".
> 
> Right.

Except I guess here some people were interpreting a proposal 
with only ESN(1) to mean "I support ESNs, but normal sequence 
numbers are also fine"...?

> >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.
> 
> 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.

Well, it does not lead to (unnecessary) lack of interop if both 
parties agree  that omitting ESN transform means "normal sequence 
numbers are not acceptable".

Presumably a sensible initiator would not have such a policy 
in the first place. And if it has, the protocol can't do much 
about it: if the policies are fundamentally incompatible, they 
can't be no interop.

(I think this is not really that different from the situation where 
the initiator's policy requires some FOOBAR encryption algorithm 
(and nothing else is acceptable) which the responder does not 
support: there's no way to say why no proposal was chosen in this 
case, either.)

>> (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".)
> 
> 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.

Right. But they're still using the same negotiation mechanisms, 
and that leads to some complications. In hindsight, perhaps
having something like IPCOMP_SUPPORTED notification would
have been better, but it's too late to change that now...

Best regards,
Pasi

---

From: "Tero Kivinen" <[email-masked]>
Date: Thu, 3 Mar 2005 09:20:14 -0800

Paul Koning writes:
>  Michael> An initiator that is willing to negotiate either ESN off or
>  Michael> ESN on should explicitly encode both options in a Transform
>  Michael> Type 5 (because the default is to demand ESN on, which is
>  Michael> not a good idea).
> 
> I don't think so -- such an initiator would have to send two
> proposals, one with ESN on, one with ESN off.  The one with ESN on can
> be encoded either by explicitly saying ESN on, or by omitting ESN from
> that proposal.

No he does not need to send two proposals, in fact there are mostly no
reason ever to include multiple proposals. He should include two
transform with identical transform type, and different transform ID.

The only reason to include multiple proposals if you do not want to
allow mix and match, meaning that you want to say that AES and ESN, or
3DES and NO ESN, but do not want to allow AES and NO ESN.

There is no reason to do things in the complicated IKEv1 way of having
multiple proposals. Actually if you follow rfc2401bis and IKEv2 the SA
payload can always have exactly one proposal substructure, which will
then have multiple transform substructures.

I.e. there will not even be multiple protocols when using rfc2401bis,
as it creates AH + ESP as routing the packets back to the IPsec
instead of creating SA bundle with multiple protocols.

The IKEv2 document still have some text saying that you could create
AH + ESP using one exchange, and that can be used for non rfc2401bis
or extended rfc2401bis implementations, but base rfc2401bis does not
require you to support that.

All this means that most implementations can simply use the first
proposal substructure and only check the other proposal structures to
check that if there is multiple protocols then they need to return
error (but they do not need to really parse them etc). 
-- 
[email-masked]