Subject: [tcpm] unallocated TCP options in-use

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 23 Dec 2009 16:06:43 -0600

In the IETF's TCPM working group, there's been a revelation that several
TCP Options Numbers, not listed as allocated in IANA's registry, are in
use on the Internet.

I think IANA is in the best position to decide how to deal with this, but
it's been proposed that they be added to your registry for TCP options:
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

The values to add are:
0x21 - Cisco middlebox discovery
0x4C - Riverbed middlebox discovery
0x4E - Riverbed middlebox discovery

One suggestion was to label these as "inappropriate use" so that the
practice is discouraged to some extent.

It may also be a good idea to make even more clear (if possible) that the
two numbers reserved for experimental use are not to be used in shipping
products as defaults.  The current footnote that says this shows up above
the table rather than below where most people would expect to find it, I
think.

--
Wes Eddy
MTI Systems

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 28 Dec 2009 12:25:13 +0100

--- Original Message -----
From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Sent: Wednesday, December 23, 2009 11:06 PM

> I think IANA is in the best position to decide how to deal with this, but

Disagree.

I think that the IETF at large is the body that should decide this, so the
discussion should be on the main IETF list.  That would need a chair to call
rough consensus - perhaps one of our ADs would oblige.

Tom Petch

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Dec 2009 11:05:23 -0800

> rough consensus - perhaps one of our ADs would oblige.

What are the possible alternatives other than noting that these options
are being used without being allocated, and are thus their use in the
public Internet is inappropriate?

Joe

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 31 Dec 2009 14:49:15 +0100

----- Original Message -----
From: "Joe Touch" <[email-masked]>
Sent: Monday, December 28, 2009 8:05 PM
> public Internet is inappropriate?

The policy could take several forms.

Do nothing
Document them privately
Document them publicly but in a format that expresses disapproval
Document them publicly without disapproval but noting that there is no RFC to
endorse their use

'One suggestion was to label these as "inappropriate use" so that the
practice is discouraged to some extent.'  Some might think this too
mild.

Doubtless others will think of other options.

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Dec 2009 10:35:34 -0800

> practice is discouraged to some extent.'  Some might think this too

Of the 4 options above, labeling them is option 3.

Of the 4 options above, options 1,2 do nothing to discourage squatting,
thus they implicitly endorse it, which defeats the purpose of IANA in
managing that space.

Option 4 explicitly endorses squatting.

That's why it seems to me that option 3 is IANA's only reasonable way
forward, esp. as it mirrors what is done for ports.

> Doubtless others will think of other options.

It'd be interesting to hear if there are any that aren't the above, and
how they specifically address IANA's management of the space.

Joe

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 31 Dec 2009 13:59:22 -0500

> how they specifically address IANA's management of the space.
The route that I chose a couple of months ago was to fill out the IANA
form....  After all, IANA already has a way to handle these non-working
group related assignments:

   http://iana.org/protocols/apply/

BTW, I'm using:

   31 (0x1f) TCP Cookie Transactions
   32 (0x20) 64-bit Timestamps

Make a note of it.

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Dec 2009 12:25:39 -0800

>   32 (0x20) 64-bit Timestamps

IANA also has requirements for assignments - for TCP options, they are
IESG approval or standards action.

Has either gone through either process? If not, then these too would be
unauthorized use.

Joe

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 31 Dec 2009 18:52:06 -0500

For some odd reason, my previous message was assigned a number, so I'm
including it in the subject.  Presumably, all the rest of you also had
some number assigned, too.

> Has either gone through either process? If not, then these too would be
You asked about a 5th option, I'm merely pointing you to the current
process (which wasn't covered in the 4 options given).

Since it is IANA's process, I'm assuming that when we fill out their
form, they send the assignment along to IESG for pro forma approval.
IANA is a collector of information, not an "authorizer" per se.

As to the latter, this thread is about non-working-group actions, thus
not standards action (by definition).

If having been informed, IANA fails to handle the processing, then
that's not my problem (nor Cisco's nor anybody else).  Does anybody know
whether Cisco bothered to submit the assignment form?

I do remember MicroSoft, during their embrace and extend days, refused
to even inform IANA or anybody about protocol numbers they were
self-assigning.  That lead to conflicts.

My only interest is avoiding assignment conflicts.
--
Happy New Year

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Dec 2009 19:52:13 -0800

Fixing a nonassigned number to make it assigned is an option, but not  
a very easy one. One presumes the IESG doesn't rubberstamp such  
applications.

Joe

Sent from my iPhone

On Dec 31, 2009, at 3:52 PM, William Allen Simpson <[email-masked] 
 > wrote: