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

From: "Michael Roe" <[email-masked]>
Date: Wed, 2 Mar 2005 12:49:35 -0000

As far as I can see, the specification as currently written
works, but the default value isn't very sensible.

As the spec is currently written:

  An initiator that is willing to negotiate either ESN off or ESN on
  should explicitly encode both options in a Transform Type 5
  (because the default is to demand ESN on, which is not a good idea).

  An initiator that only supports ESN off should explicitly encode
  this in a Transform type 5.

  A responder that selects ESN off should explicitly encode this
  in a Transform type 5.

  A responder that selects ESN on may encode this in a Transform
  type 5, but doesn't need to, because this is the default.

This all works, but the default value adds code complexity for
little benefit.

I'd suggest option C below, or leaving things as they are.

Mike

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

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

---

From: Paul Koning <[email-masked]>
Date: Wed, 2 Mar 2005 08:03:12 -0500

>>>>> "Michael" == Michael Roe <[email-masked]> writes:

 Michael> As far as I can see, the specification as currently written
 Michael> works, but the default value isn't very sensible.

I would agree, but it really doesn't matter much what the default
values are.  They are merely an encoding shorthand, nothing more.
They add no new capabilities to the protocol.

 Michael> As the spec is currently written:

 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.

 Michael> This all works, but the default value adds code complexity
 Michael> for little benefit.

True.  Things would be simpler if all the defaults were taken out and
everything had to be stated explicitly.

	   paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Mar 2005 07:14:19 -0800

>They add no new capabilities to the protocol.

Me three (or five, by my count). At this point, I don't think a 
technical change is needed, just a clarification.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 19:20:14 +0200

> be encoded either by explicitly saying ESN on, or by omitting ESN from

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]

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 3 Mar 2005 12:25:55 -0500

A number of people have suggested just doing a clarification, although
there were also a number of people who suggested making ESN's
mandatory (Suggestion C).  Some of these discussions were done while
the discussion was still going on, however, so I'd like for us to do a
quick straw poll so that people can clearly register their
preferences.

At this point, I believe this is would be a correct description of the
question at hand.  Do people agree this is the proper way to pose the
question before we start the straw poll?

						- Ted

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

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.

There are four ways that have been discussed to resolve this issue:

PROPOSAL A:
-----------

PROPOSAL B:
-----------

Create a new response notification that says "I can't do ESN, start
again and include a 'no ESN' transform."  [Note during the discussion
on the mailig list, little or no support was seen for this
alternative.

PROPOSAL C:
-----------

PROPOSAL D: 
-----------

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

	PROPOSAL D_1:
	-------------
	Do suggestion D above, but place the clarification in IKEv2.

	PROPOSAL D_2:
	-------------
	Do Suggestion D_1 only if it can be done without delaying the
	publication of IKEv2.  

Please select one of proposals A, B, C, D.  If proposal D is selected,
please note if you support D_1 or D_2.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 Mar 2005 09:50:42 -0800

>document)

(I don't support D_1 or D_2 because there are literally at least two 
dozen other clarifications that are as important as this one; we 
can't even think of holding up the publication for them.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 21:52:18 +0200

> quick straw poll so that people can clearly register their

I still think the C is the best one. 

> PROPOSAL D: 

I do not think that clarification helps at all. It does not really
clarify the situation at all. Making the option mandatory fixes the
problem as there is no default value after that, and it can also be
made in the backward compatible way (i.e. if no value then assume ESN
is enabled).
-- 
[email-masked]

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 3 Mar 2005 23:22:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tero Kivinen
> Sent: Thursday, March 03, 2005 11:52 AM
> To: Theodore Ts'o
> Cc: [email-masked]; Paul Hoffman
> Subject: [Ipsec] Proposed Straw Poll
> 
> Theodore Ts'o writes:

I agree that C is the best one as well.  I don't like implicit values.

> made in the backward compatible way (i.e. if no value then assume ESN

I don't understand.  If we made the transform mandatory, then wouldn't the
omission of it be an error?  If no value meant we should assume ESN is
enabled, how would that differ from what we have now?

-g

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Mar 2005 17:07:53 +0200

Geoffrey Huang writes:
> omission of it be an error?

Yes if the old version is initiating. If the new version is initiating
then everything will work. If the old version is initiating and
responder notices there is no ESN types at all, it can either reject
the proposal as incorrect, or it can try to do backward compatibility
code and assume there was ESN option included. 

> If no value meant we should assume ESN is

That would mean that as most implementations will send that ESN type,
then people will pay attention to it, and the normal proposal
selection works there properly. Most likely the backward compatibility
is not really needed, as there might not be any released versions with
old version. 
-- 
[email-masked]