Subject: [tcpm] draft-ietf-tcpm-experimental-options

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Fri, 22 Feb 2013 20:54:05 +0000

I have reviewed this proposed draft.  I don't believe that commercial vendors who have TCP option needs would view this as changing the current landscape at all.  If your intent is to provide a new alternative that "cooperating protocol designers" could use, in my opinion this is not meeting the need.

(If your intent is just to make it safer and easier to use the experimental TCP options for actual experiments, you can ignore the rest of this email.)

The draft claims that experimental TCP options are
          "intended to be used both in controlled environments and in are allowed in public deployments (when not enabled as default) [RFC3962]"
(Side note:  typo "in", and the citation is wrong, it should be 3692.)

However, that goes against other documentation - for example these statements in 3692:

"Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes" (i.e. not for production use)

"They are not intended to be used in general deployments or be enabled by default in products or other general releases."  (my reading of that has always been, "not intended for use in the public Internet")

And, on the IANA assigned numbers:

"RFC3692-style Experiment 1 (also improperly used for shipping products)" - clearly implying these are not intended for use in commercial products.

Finally, the draft itself implies the experimental option usage is still intended to be temporary in the discussion "Migration to Assigned Options".
(Another side note:  I'd have concerns about implementing the proposed migration mechanism in practice due to the creation of extra connections which would just be dropped.)

In the absence of a better solution, a vendor may find using an experimental option to be preferable to squatting somewhere else in the option space, but this draft in its current form does not really appear to change any of the underlying rules which suggest experimental options are not intended for this type of use.

One other suggestion for the draft:  it might merit a word or two in the security considerations how this draft might affect the firewall processing of TCP options 253 and 254.  Having the IANA registry suggested elsewhere in the thread would actually help firewalls to have better visibility into the contents of these options to be more selective about what to allow.

--Jamshid

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Feb 2013 13:33:07 -0800

Hi, Jamshid,

On 2/22/2013 12:54 PM, Mahdavi, Jamshid wrote:
...
>            “intended to be used both in controlled environments and in
> are allowed in public deployments (when not enabled as default) [RFC3962]”
>
> (Side note:  typo “in”, and the citation is wrong, it should be 3692.)

Those are part of pending updates.

> However, that goes against other documentation – for example these
> statements in 3692:
>
> “Mutually consenting devices could use these numbers for whatever
> purposes they desire, but under the understanding that they are reserved
> for generic testing purposes” (i.e. not for production use)
>
> “They are not intended to be used in general deployments or be enabled
> by default in products or other general releases.”  (my reading of that
> has always been, “not intended for use in the public Internet”)

The key is the term "default". I.e., they are allowed in general 
releases if not enabled by default.

> “RFC3692-style Experiment 1 (also improperly used for shipping
> products)” – clearly implying these are not intended for use in
> commercial products.

Not by default. But having them available where users can turn them on 
causes the same problem.

> Finally, the draft itself implies the experimental option usage is still
> intended to be temporary in the discussion “Migration to Assigned Options”.

That's correct. The goal would be for experiments with sufficient 
experience that are sufficiently warranted to justify assignment of 
permanent TCP option codepoints.

> (Another side note:  I’d have concerns about implementing the proposed
> migration mechanism in practice due to the creation of extra connections
> which would just be dropped.)
>
> In the absence of a better solution, a vendor may find using an
> experimental option to be preferable to squatting somewhere else in the
> option space, but this draft in its current form does not really appear
> to change any of the underlying rules which suggest experimental options
> are not intended for this type of use.
>
> One other suggestion for the draft:  it might merit a word or two in the
> security considerations how this draft might affect the firewall
> processing of TCP options 253 and 254.

I can add that.

> Having the IANA registry
> suggested elsewhere in the thread would actually help firewalls to have
> better visibility into the contents of these options to be more
> selective about what to allow.

The IANA registry would help firewalls only if they parsed inside TCP 
options; is that remotely likely?

Joe

>
> --Jamshid
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Fri, 22 Feb 2013 23:41:58 +0000

> > Having the IANA registry
> > suggested elsewhere in the thread would actually help firewalls to 
> > have better visibility into the contents of these options to be more 

> The IANA registry would help firewalls only if they parsed inside TCP options; is that remotely likely?

I don't know if it is likely, but I know that some firewalls do parse the option numbers themselves and give control to block or allow specific option numbers.  If the data were available it seems at least plausible that some would try to take advantage of that.

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Feb 2013 15:45:01 -0800

> I don't know if it is likely, but I know that some firewalls do parse the option numbers themselves and give control to block or allow specific option numbers.  If the data were available it seems…

Yes, but I suspect it would be prudent to block experimental options 
completely, rather than to parse them for various experiments.

Joe

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Sat, 23 Feb 2013 00:04:10 +0000

> Yes, but I suspect it would be prudent to block experimental options completely, rather than to parse them for various experiments.

Fair enough, but that reiterates my main point -- if you are trying to provide a solution for vendors who have needs around TCP Options, this draft is not really going to provide that any better than the current scheme does.

--J

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Feb 2013 16:11:46 -0800

> Fair enough, but that reiterates my main point -- if you are trying to provide a solution for vendors who have needs around TCP Options, this draft is not really going to provide that any better th…

Vendors ought to go through the process and get their stuff approved by 
the IETF - or be mocked publicly for not doing so.

We're talking about TCP here. If you play with an option as a test, you 
ought to call it a test and be happy with that, even if it means the 
system isn't yet commercially viable.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 27 Feb 2013 10:12:17 +0100

Jamshid, 

> I have reviewed this proposed draft.  I don't believe that 
> commercial vendors who have TCP option needs would view this 
> as changing the current landscape at all.  If your intent is 
> to provide a new alternative that "cooperating protocol 
> designers" could use, in my opinion this is not meeting the need.

We've always explicitly stated that the existing process for getting a dedicated TCP option codepoint does not change.

Personally, I think that this should be the prefered solution, e. g., because it doesn't waste TCP SYN bytes.

But an IANA-assigned codepoint indeed requires some "cooperation" of the protocol designer with the IETF (and preferably TCPM).

Michael

---

From: Kevin Lahey <[email-masked]>
Date: Thu, 28 Feb 2013 09:03:08 -0800

> Personally, I think that this should be the prefered solution, e. g., because it doesn't waste TCP SYN bytes.

I have no objection to the publication of this document (aside from a nit that I sent in a different message), but it does seem like we're optimizing the wrong value.  We have only 40 octets of TCP option space on a SYN, and we've seen proposals that are pushing up against that.  We have used something like 35 of the available TCP option values in the 32 years since RFC 793 was published, and it doesn't seem like there will be a big run on TCP options in the near future.  Yet here we're burning precious option space to save option values.

I'd really prefer that we loosen our standards for assigning TCP options.  Given a choice between even reasonably responsible parties[*] squatting on values or passing out a few more options and documenting the use, I'll take the documentation.

Kevin
[email-masked]

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 28 Feb 2013 11:47:06 -0800

Hear, hear!

Andrew

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Feb 2013 12:53:13 -0800

Hi, all,

The bar for TCP options is passing a standards-track RFC. That's the 
same bar as for many other limited resources, including system TCP and 
UDP ports.

Some of the current squatters fall into the following categories:

	- in the process of developing a standards-track option,
	some parties were impatient and disagreed with the process,
	and squatted on the experimental ports (for TCP-AO precursors)

	- some parties want to develop extensions that they explicitly
	don't want to participate in the IETF process (tcp-ct)

	- some parties developed a prototype that squatted on
	numbers before they even brought it to the IETF; when they did,
	there were concerns with the approach expressed
	(tcp-crypt)

So, FWIW, "lowering the bar" to issuing option numbers means TCPM accepting:
	a) multiple competing standards in early development stages
	b) proposals that don't even want to be vetted by the WG
	c) proposals that the WG has already expressed concerns about

In part, the bar could be lowered by the WG being more accepting of 
proposals, but even then is it appropriate to burn multiple codepoints 
on one option? Or to allow standards based on non-WG drafts (how does 
that occur?) or to assign codepoints to competing standards while under 
active WG debate?

There's no easy solution here, but it's clear that there's no way to 
"lower the bar" that is compatible with IETF processes AFAICT.

Joe

On 2/28/2013 11:47 AM, Andrew Knutsen wrote:
>>> We've always explicitly stated that the existing process for getting
>>> a dedicated TCP option codepoint does not change.
>>>
>> I have no objection to the publication of this document (aside from a
>> nit that I sent in a different message), but it does seem like we're
>> optimizing the wrong value.  We have only 40 octets of TCP option
>> space on a SYN, and we've seen proposals that are pushing up against
>> that.  We have used something like 35 of the available TCP option
>> values in the 32 years since RFC 793 was published, and it doesn't
>> seem like there will be a big run on TCP options in the near future.
>> Yet here we're burning precious option space to save option values.
>>
>> I'd really prefer that we loosen our standards for assigning TCP
>> options.  Given a choice between even reasonably responsible
>> parties[*] squatting on values or passing out a few more options and
>> documenting the use, I'll take the documentation.
>>
>> Kevin
>> [email-masked]
>>
>>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 1 Mar 2013 00:05:47 +0100

I think that the bar is actually a little bit lower. For instance, the IETF allocated in the last years codepoints to experimental protocols as well (Quick-Start, MPTCP). Also, TCPM currently has one active working group draft that asks for assignment of a dedicated option number.

I do believe that we have enough remaining TCP option codepoints so that implementors of Internet-scale TCP extensions can get dedicated codepoints. But obviously not bypassing the IETF process.

Michael

________________________________________
Von: [email-masked] [[email-masked]] im Auftrag von Joe Touch [[email-masked]]
Gesendet: Donnerstag, 28. Februar 2013 21:53
An: Andrew Knutsen
Cc: [email-masked]
Betreff: Re: [tcpm] draft-ietf-tcpm-experimental-options

Hi, all,

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 28 Feb 2013 15:06:28 -0800

The problems arise when "IETF processes" cause longstanding problems 
in the field.  A bit analogous to what's going on in Congress today, it 
seems to me.  Several of the largest "squatters" (widely deployed, 
multivendor technology, none listed below) tried to get "over the bar" a 
couple years ago, and found it unreasonably high.  So, we're all still 
squatting (and shipping lots of units ;-).

    To repeat Kevin's point again, so it doesn't get lost in the 
verbiage: TCP option *size* seems to be a more limited resource than the 
"kinds"/codepoints.  This is the *Engineering* task force; we should be 
making *engineering* decisions.  Trading off one resource for another is 
a classic engineering decision.

Andrew

PS Yes this is a sore point for me.
AK

On 2/28/2013 12:53 PM, Joe Touch wrote:
> that occur?) or to assign codepoints to competing standards while 
> under active WG debate?
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Feb 2013 15:16:06 -0800

> squatting (and shipping lots of units ;-).

It either means the bar is too high or they can't jump.

Whether we ought to lower the bar depends on that decision. We shouldn't 
just assume we should lower the bar solely to avoid circumnavigation.

> a classic engineering decision.

I agree that space is a big issue, but wouldn't opening the gates to 
wider standardized usage similarly compromise that space?

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 28 Feb 2013 16:24:54 -0800

I think what you're saying is that if we allow more options, its 
more likely the 40 bytes sometimes won't be enough.

    The key here is that we standardize on working code.  That means, 
any new option functions with the other options needed for it to work.  
If a new option causes problems with other relevant options, that should 
be part of the decision, as it has in the past.  If it doesn't, it 
shouldn't.

Andrew

PS the joke about not jumping isn't funny to all of us.
AK

On 2/28/2013 3:16 PM, Joe Touch wrote:
> Whether we ought to lower the bar depends on that decision. We 
> shouldn't just assume we should lower the bar solely to avoid 
> circumnavigation.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Feb 2013 17:21:04 -0800

> more likely the 40 bytes sometimes won't be enough.

Yes, that sometimes is (and has been) a deciding issue.

> be part of the decision, as it has in the past.  If it doesn't, it

Agreed.

> PS the joke about not jumping isn't funny to all of us.

It wasn't a joke; it was an extension of the euphemism of "over the bar" 
- which you brought up. I'm fine with not using euphemisms if you prefer.

Joe

---

From: Kevin Lahey <[email-masked]>
Date: Thu, 28 Feb 2013 19:05:08 -0800

On Feb 28, 2013, at 12:53 PM, Joe Touch wrote:

> The bar for TCP options is passing a standards-track RFC. That's the same bar as for many other limited resources, including system TCP and UDP ports.

Well, it's actually Standards Action or IESG Approval, right?  I had naively assumed that we could squeeze in a slightly more relaxed process via IESG Approval, but RFC 5226 suggests that this is intended for exceptional cases.

My concern is that, as an implementor and occasional deployer of boxes, I don't want to see an option show up in a packet trace (or in a crash dump or even a log file) that I haven't seen before and that I can't identify.  If I do see something weird, I'd really like to be able to look it up and make an informed decision about how to deal with it.

I also would like to have enough options around in case I someday have a need for one, so I understand why we don't want them to be handed out without any controls at all.  I'd like it if really awful options weren't deployed, but I suspect that there's really not much I can do if a widely deployed system decides to implement something (hence our squatted values).

> In part, the bar could be lowered by the WG being more accepting of proposals, but even then is it appropriate to burn multiple codepoints on one option? Or to allow standards based on non-WG drafts (how does that occur?) or to assign codepoints to competing standards while under active WG debate?

Of the options in RFC 5226, I'd prefer to use Specification Required (or RFC Required with Expert Review) to allocate TCP Option Kinds.  There's obviously a balance to be had between carefully protecting a limited resource and throwing open a registry to all comers.  Given the small number of assigned TCP Option Kinds and the squatting situation, it seems like the current balance is tilted too far towards conservation and not far enough towards serving the community.

Speaking for myself,

Kevin
[email-masked]