Subject: [Ipsec] Proposed Straw Poll

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

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

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.  

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

_______________________________________________
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: "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: [email-masked]
Date: Fri, 4 Mar 2005 13:47:04 +0200

> PROPOSAL D: 

I think the current spec does not need any technical changes,
and a clarification is enough. So, I support D.

(But the correct phrasing would be something like "If the initiator 
is willing to accept either the use of extended sequence numbers or 
not, the initiator will include two ESN transforms in its proposals,
one with value 0 and another with value 1."

I don't support D_1 or D_2.

Best regards,
Pasi