Subject: [tcpm] On TCP option codepoints

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 8 Oct 2013 12:49:53 +0000

Hi all,

I've performed today a small and very nonscientific experiment:

For all TCP option codepoints N marked as "Reserved" on http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml, I entered the term "tcp option N" in a major Internet search engine and applied a special, human ranking by post-processing the first 5 results for the exact match, if available. To ensure that only the data analysis tool is proprietary and biased, but not in the data source, I also verified the key result in a second major search engine, and I used hex values for N as well ;)

The result of this small experiment resulted in two surprising news (well, that was actually to be expected, but I wasn't aware of it):
 
- For N= 38 (0x26), there are several links to official product documentation

- For N= 101 (0x65), there are several product-related links, but no official product documentation

There is also a single hit for N= 171 (0xab), but the sample size seems too small even for an entirely nonscientific method ;) Also, note that I cannot verify the quality and correctness of the two data sources. The method does not work well for N= 64 and N= 128.
 
The good news is that the two data sources didn't find any exact match for most other values of N...

Michael

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 08 Oct 2013 11:14:14 -0400

On 10/8/2013 8:49 AM, Scharf, Michael (Michael) wrote:
> For all TCP option codepoints N marked as "Reserved" on
> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml,
> I entered the term "tcp option N" in a major Internet search engine
> and applied a special, human ranking by post-processing the first 5
> results for the exact match, if available. To ensure that only the
> data analysis tool is proprietary and biased, but not in the data
> source, I also verified the key result in a second major search
> engine, and I used hex values for N as well ;)

Nice idea; thanks for doing this!

> - For N= 38 (0x26), there are several links to official product

In at least this case, where there is evidence that deployed products
have stolen the codepoint, there should be an indication on the IANA
webpage, similar to the existing ones.  I think it's best if the
responsible AD for TCPM handles this (sorry Martin!) though.

In my personal opinion, the number of codepoint thefts is significant
enough (and showing no signs of stopping) that instead of the generic
statement about unauthorized use on all of them, we should specifically
mention the vendors and products known to be abusing them.  That way,
if at some point those products go away and become obsolete, then the
codepoints can be reaped back for legitimate use.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Oct 2013 10:25:48 -0700

FWIW, the IANA page already indicates some of these as known 
unauthorized uses;

http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

AFAICT, IANA doesn't point to details on those unauthorized uses, to 
avoid implicitly endorsing them.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Oct 2013 10:30:20 -0700

> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

Correction - some of these were known, but didn't seem to make it as
tagged as "known unauthorized use" yet. That should be updated.

However, mention in a web page doesn't necessarily mean actual use. The 
other known unauthorized uses have been confirmed.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 08 Oct 2013 14:29:09 -0400

> avoid implicitly endorsing them.

I think saying "unauthorized use by company X's product Y and Z" would
not be mistaken as an endorsement.

I think identifying parties is useful in order to prevent serial abuse
by the same companies and in tracking down specific oddities that
someone might observe in packet traces or otherwise.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Oct 2013 11:35:54 -0700

> not be mistaken as an endorsement.

To us, no, but I have already seen explicit mention of the specific 
company being used as a precedent for TCP and UDP ports.

> someone might observe in packet traces or otherwise.

It doesn't matter to the companies that do it. I don't think that the 
information IANA provides is intended for debugging; it's intended to 
indicate who is authorized, and when asking for an assignment might 
cause problems to the assignee.

It might be useful for the ISOC to put up a website of shame - e.g., on 
the same site that includes information on what products pass our rigid 
compliance tests.

(hint: since we don't endorse those who comply, it's not clear we should 
be listing those who don't)

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 08 Oct 2013 14:36:33 -0400

In general I am not adverse to naming and shaming.  And, I agree with

> not be mistaken as an endorsement.

I would also say the above could be amended with ", but fixed in version
V" or something like that.  I.e., flagging the problems is fair, but I
also think it'd be fair to indicate the problems have been taken care
of.

allman

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 9 Oct 2013 16:56:52 +0000

> > not be mistaken as an endorsement.

I guess shaming is not IETF's core business. But the IANA page could probably link to IETF contributions if available (such as draft-ananth-middisc-tcpopt). Some of the Web pages I found originate from admins that observe an option in a trace, go to the IANA page, and wonder why the codepoint is not mentioned there...

However, I was not aware of any IETF "disclosure" for the two codepoints identified by my small Web search. 

> also think it'd be fair to indicate the problems have been taken care

Naming products could be difficult. Products may exist with various versions and different releases, and without detailed insight it is probably impossible to figure out if a codepoint is indeed used, or not. Also, company X might actually not be only user of the codepoint. For instance, in case of a security vulnerability, some malware might try use the codepoint as well... Taking care of this class of users is non-trivial ;)

Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Oct 2013 10:04:52 -0700

On 10/9/2013 9:56 AM, Scharf, Michael (Michael) wrote:
> I guess shaming is not IETF's core business. But the IANA page could
> probably link to IETF contributions if available (such as
> draft-ananth-middisc-tcpopt).

That information is similarly not necessarily validated; it's easy to 
claim that a number might be in unauthorized use, but pointing the 
finger can result in complications.

> Some of the Web pages I found originate
> from admins that observe an option in a trace, go to the IANA page, and
> wonder why the codepoint is not mentioned there...

"unauthorized use" ought to be more than enough information at that point.

Joe