Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 04 Mar 2005 14:36:35 -0500

OK, we haven't had anyone complaining about the proposed alternatives or
how they have been worded (except for four people who jumped the gun :-), 
so let's actually conduct the actual straw poll.

Please reply to this message with your preference for dealing with this
issues as described below, selecting one of proposals A, B, C, D.  If
proposal D is selected, please note if you support none, one, or both of
sub-choices D_1 or D_2.  

The straw poll will close at 5pm EST on Monday, March 7th.

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

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.

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

Change the places that says Transform Type 5 is optional to say
it is mandatory.

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.  

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 4 Mar 2005 12:03:54 -0800

Proposal C

Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Theodore Ts'o
Sent: Friday, March 04, 2005 11:37 AM
To: [email-masked]
Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop
issuein IKEv2

							- Ted

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

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

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

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

	PROPOSAL D_1:
	-------------

	PROPOSAL D_2:
	-------------

---

From: Kevin Li <[email-masked]>
Date: Fri, 04 Mar 2005 12:28:33 -0800

PROPOSAL A.

If I don't send an optional transform, means that it is not supported. It reduces the software complexity and packet overhead. In another word, for all the optional parameters, if I don't support it, there is no reason to go through all the trouble to compose the payload and send it. IMHO.

Thanks.

Kevin

---

From: "Geoffrey Huang" <[email-masked]>
Date: Fri, 4 Mar 2005 14:05:14 -0800

I prefer C.

-g 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Theodore Ts'o
> Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation 
> interop issuein IKEv2
> 
> 
> OK, we haven't had anyone complaining about the proposed 
> alternatives or how they have been worded (except for four 
> people who jumped the gun :-), so let's actually conduct the 
> actual straw poll.
> 
> Please reply to this message with your preference for dealing 
> with this issues as described below, selecting one of 
> proposals A, B, C, D.  If proposal D is selected, please note 
> if you support none, one, or both of sub-choices D_1 or D_2.  
> 
> 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.
> 
> 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:
> -----------
> 
> Change the places that says Transform Type 5 is optional to 
> say it is mandatory.
> 
> PROPOSAL D: 
> -----------
> 
> 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:
> 	-------------