Subject: [tcpinc] draft-bittau-tcpinc-tcpeno-02

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 20 Sep 2015 16:06:30 +0000

I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems related to other TCP modifications. Below are a couple of comments; some could be more major than others. Disclaimer: I don't have much cycles to look into tcpinc, i.e., I apologize if some aspects been discussed already. 

* Abstract, page 1: The abstract confuses me. Should the sentence "The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems" imply that this document shall finally also specify the encryption within the transport layer, being the second problem? Why doesn't the abstract simply focus on negotiation and mention that it specifies an option limited to the TCP three-way-handshake to solve the negotiation problem?

* Section 2, page 3: To me, the whole text on page 2 includes too much hand-having. Some examples: The relation between this document and EDO is unclear and not further detailed later. The socket interface is not owned by the IETF, and RFC 3493 is an informational document for IPv6 only. It is not clear how TFO (RFC 7413) would be used together with this option, and, if so, if stack vendors would be interested in deploying both options together. Basically, I think page 2 could be removed entirely without affecting the content of the document.

* Section 2, page 4: "Provide signaling through which applications can better take advantage of TCP-level encryption (for instance by improving authentication mechanisms in the presence of TCP-level encryption)." Since authentication is listed here: How does this option interact with TCP-AO? For instance, I think this document could perhaps discuss what a receiver may do if a SYN segment both with TCP-ENO and TCP-AO options is received. This is a question much closer to the SYN handshake negotiation mechanics than various other sections of the document.

* Section 3, page 5: Regarding the sentence "Encryption specs MAY include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST ignore them." and Figure 2: I suggest to keep this document entirely self-contained, which to me means something like: "If a non-SYN options contains extra bytes, TCP-ENO itself MUST ignore them." If a protocol negotiated by TCP-ENO indeed needs further TCP option space, this should be documented in the corresponding protocol specification.

* Section 3.2, page 7: I am confused by some RFC 2119 language in this section. Examples:

  - "More precisely, for negotiation to succeed, the TCP-ENO option MUST be present in the SYN segment sent by each host" => lower-capital  or (better) reword to required implementation behavior

  - "Additionally, the ENO option MUST be present in the first ACK segment sent by each host, so as to indicate that no
   middlebox stripped the ENO option from the ACKed SYN." => lower-capital or (better) reword to required implementation behavior

  - ... (several further examples of the same form)

* Section 3.2, page 7: "An active opener begins with a SYN-only segment, and hence must send two segments containing ENO options." That "must" would be a candidate for RFC 2119, but in fact I think the sentence is actually even wrong, given that an active opener "must" only send ENO options in the first segment for the fallback case.

* Section 3.2, page 7: The protocol specification has to correctly specify the behavior for retransmitted segments with SYN flag. The requirement stated on page 12 probably belongs here.

* Section 3.2, page 9: "... and MUST NOT present raw TCP payload data to the application." Please specify the behavior for payload data in SYN segments, or explicitly mark it as in-scope of a protocol specification using this option. TFO (RFC 7413) could be relevant in this context.

* Section 3.3, page 10: Protocol stacks on top of TCP can be complex and consist of multiple layers, libraries, etc. "application" is not well-defined in this case, and whether an application indeed can be aware of TCP stack internals, or not, is a relatively complex question. The concept of "application-awareness" in a multi-layer stack seems fuzzy to me, with lots of open questions. As a simple remedy, instead of "application-aware", the document could perhaps use a term like "upper layer protocol aware".

* Section 4: I don't understand why any of the content in the whole section 4 is needed for interoperable implementations of a TCP option in SYNs. Specifically:

  - Requirement list: In the IETF, requirement lists are typically useful during WG operation, but they can easily become outdated, e.g., by trends in the market. There has always been lots of research innovation in TCP, and I could imagine that the TCP-ENO negotiation option could find future interesting use outside of what is known today.

  - Session ID: To me, the definition of session IDs, if at all, has to be done in specification of the encryption spec. I don't understand why this section is needed for building interoperable implementations of TCP-ENO, in particular, if not even the length is defined (and that length definition does not belong in this document, IMHO). 

  - Option kind sharing: For this spec, it is sufficient to specify how the option is used within this specification. This section can thus be removed entirely.

* Section 5: So far, the IETF has only rather limited credibility in specifying TCP API extensions, at least in my experience. Given that, this section could e.g. be moved to an appendix (see e.g. RFC 7413).

* Section 6: Further topics to be considered here:

  - Considerations of the space limitation in SYNs. Since this document allows in principle an arbitrarily long TCP option, discussion and guidance on that seems useful.

  - Compatibility with other TCP extensions. Unless sorted out in this document, potential interactions and/or incompatibility with TCP-AO, MPTCP, TCP Fast Open, etc. should at least be mentioned as open issue.

* Section 8: The IANA registration procedure for "cs" values has to be specified, and I could imagine different variants, which should probably be discussed relatively early.

* Section 8: Why does TCP-ENO not allocate an TCP Experimental Option Experiment Identifier according to RFC 6994? That would be an easy solution to enable experiments with multiple interoperable implementations over the Internet, prior to assignment of a TCP option kind number. Keep in mind that an experimental document requires an explicit IESG action for TCP option kind assignment. In the past, TSV has asked for this IESG action several times. In those cases, there has been very strong consensus in the corresponding working group regarding the codepoint assignment, backed by reasonable interest by TCP stack vendors in the protocol.

Michael

---

From: David Mazieres <[email-masked]>
Date: Sun, 20 Sep 2015 12:58:17 -0700

"Scharf, Michael (Michael)" <[email-masked]> writes:

> I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems
> related to other TCP modifications. Below are a couple of comments;
> some could be more major than others. Disclaimer: I don't have much
> cycles to look into tcpinc, i.e., I apologize if some aspects been
> discussed already.

Thanks for the detailed feedback.  I believe we can address many of your
comments pretty easily.  Most of the others would depend on WG
consensus, but the draft could be adopted either way.  There's only one
suggestion I think would be problematic to adopt, which is in your
comments on section 4.  I'll go through each point.

> * Abstract, page 1: The abstract confuses me. Should the sentence "The
> TCP Encryption Negotiation Option (TCP-ENO) addresses both of these
> problems" imply that this document shall finally also specify the
> encryption within the transport layer, being the second problem? Why
> doesn't the abstract simply focus on negotiation and mention that it
> specifies an option limited to the TCP three-way-handshake to solve
> the negotiation problem?

The abstract here is just trying to give motivation.  So by addresses we
didn't mean solves.  TCP-ENO does not solve either of those problems
without an encryption spec, but is motivated by both.  Would it help if
instead of "addresses" we said "is motivated by"?

> * Section 2, page 3: To me, the whole text on page 2 includes too much
> hand-having. Some examples: The relation between this document and EDO
> is unclear and not further detailed later. The socket interface is not
> owned by the IETF, and RFC 3493 is an informational document for IPv6
> only. It is not clear how TFO (RFC 7413) would be used together with
> this option, and, if so, if stack vendors would be interested in
> deploying both options together. Basically, I think page 2 could be
> removed entirely without affecting the content of the document.

Removing this text seems fine.  It's partly there just to provide some
context/motivation for the working group, so perhaps this is the sort of
thing we could remove after adoption.  There's a longer argument to be
made for each of these points, but it doesn't really belong in the
TCP-ENO document itself, so killing the text might be a reasonable way
forward.

> * Section 2, page 4: "Provide signaling through which applications can
> better take advantage of TCP-level encryption (for instance by
> improving authentication mechanisms in the presence of TCP-level
> encryption)." Since authentication is listed here: How does this
> option interact with TCP-AO? For instance, I think this document could
> perhaps discuss what a receiver may do if a SYN segment both with
> TCP-ENO and TCP-AO options is received. This is a question much closer
> to the SYN handshake negotiation mechanics than various other sections
> of the document.

The higher-layer authentication taking advantage of TCP-level encryption
is at a higher layer than TCP-AO.  In particular, it would take place by
exchanging bytes over the TCP connection itself.  Hence, I see only one
reasonable approach:  First check TCP-AO.  If TCP-AO discards the
packet, then TCP-ENO is irrelevant.  Otherwise, proceed as usual with
TCP-ENO.

Does that make sense to you?  And is it worth detailing in the document?

> * Section 3, page 5: Regarding the sentence "Encryption specs MAY
> include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST
> ignore them." and Figure 2: I suggest to keep this document entirely
> self-contained, which to me means something like: "If a non-SYN
> options contains extra bytes, TCP-ENO itself MUST ignore them." If a
> protocol negotiated by TCP-ENO indeed needs further TCP option space,
> this should be documented in the corresponding protocol specification.

I'm going to lump this together with your next comment.

>   - Option kind sharing: For this spec, it is sufficient to specify
>   how the option is used within this specification. This section can
>   thus be removed entirely.

I agree that how to do option kind sharing is a property of encryption
specs, not TCP-ENO.  However, the fact that TCP-ENO is amenable to such
sharing is an attractive property.  So it seemed useful somewhere to
record the fact that this property isn't just an accident.  If someday
somebody proposes an encryption spec that shares ENO's option kind, we
don't want them to meet resistance on the grounds that they are
squatting on a different RFC's option kind.

So basically the intent of section 4.2 is A) to serve as a reminder not
to mess up this sharability property as we edit the draft, B) to avoid
resistance for specs that do such sharing, and C) to serve as a strong
suggestion to any future TCP-ENO revisions to confine themselves to SYN
segments.  Would you be happier if we moved it to an appendix?  Or maybe
we could leave it in as a reminder while the document is being edited,
and then take it out at the last minute?

>   - "More precisely, for negotiation to succeed, the TCP-ENO option
>   MUST be present in the SYN segment sent by each host" =>
>   lower-capital or (better) reword to required implementation behavior
>

I see.  Is the issue that the MUST isn't really associated with an
action on the part of an endpoint?  So would an informal description
("TCP-ENO can't work unless A, B, C"), followed be a more active
"implementations MUST disable encryption if..." be better?

> * Section 3.2, page 7: "An active opener begins with a SYN-only
> segment, and hence must send two segments containing ENO options."
> That "must" would be a candidate for RFC 2119, but in fact I think the
> sentence is actually even wrong, given that an active opener "must"
> only send ENO options in the first segment for the fallback case.

Indeed, good catch.

> * Section 3.2, page 7: The protocol specification has to correctly
> specify the behavior for retransmitted segments with SYN flag. The
> requirement stated on page 12 probably belongs here.

That should be pretty easy to address.

> * Section 3.2, page 9: "... and MUST NOT present raw TCP payload data
> to the application." Please specify the behavior for payload data in
> SYN segments, or explicitly mark it as in-scope of a protocol
> specification using this option. TFO (RFC 7413) could be relevant in
> this context.

Really the point is just that you want to make sure you don't end up
with one side encrypting, and the other side not encrypting.  What we
mean to say is that receiving an ACK segment with an ENO option is the
point of no return.  That implies that whatever is in TCP's payload
isn't what the application is writing.  But I agree talking about key
agreement and such may be too specific here.  It would probably be
clearer just to talk this in terms of enabled/disabled encryption.

> * Section 3.3, page 10: Protocol stacks on top of TCP can be complex
> and consist of multiple layers, libraries, etc. "application" is not
> well-defined in this case, and whether an application indeed can be
> aware of TCP stack internals, or not, is a relatively complex
> question. The concept of "application-awareness" in a multi-layer
> stack seems fuzzy to me, with lots of open questions. As a simple
> remedy, instead of "application-aware", the document could perhaps use
> a term like "upper layer protocol aware".

Yup, that sounds like a good suggestion.  (In fact, the companion
tcpinc-api informational document tries to shed some light on this, and
the suggested API changes are right on top of the socket layer, so very
low level.)

> * Section 4: I don't understand why any of the content in the whole
> section 4 is needed for interoperable implementations of a TCP option
> in SYNs. Specifically:
>
>   - Requirement list: In the IETF, requirement lists are typically
>   useful during WG operation, but they can easily become outdated,
>   e.g., by trends in the market. There has always been lots of
>   research innovation in TCP, and I could imagine that the TCP-ENO
>   negotiation option could find future interesting use outside of what
>   is known today.
>
>   - Session ID: To me, the definition of session IDs, if at all, has
>   to be done in specification of the encryption spec. I don't
>   understand why this section is needed for building interoperable
>   implementations of TCP-ENO, in particular, if not even the length is
>   defined (and that length definition does not belong in this
>   document, IMHO).

I think this is the one area where it would be harder to incorporate
your feedback.  The reason is that the main value of TCP-ENO is that it
can abstract away the differences between different TCP-layer encryption
schemes for applications.  So if I write an application that uses TCPINC
today, and tomorrow there's some new spec that takes advantage of TFO or
something, my application should still work unmodified TCP with the new
encryption spec.  This is only possible if there are certain standards
for how a TCP-ENO spec behaves.

To make this concrete, suppose a spec behaves as currently described in
the TCP-ENO draft, and an application starts digitally signing the
Session ID to authenticate the client to the server.  That's a perfectly
reasonable use of Session IDs as we envision them.  Now say a later spec
allows the client to determine the session ID.  That means all these
signed messages from past authentications are now effectively "blank
checks" that servers can use to impersonate clients to other servers.

> * Section 5: So far, the IETF has only rather limited credibility in
> specifying TCP API extensions, at least in my experience. Given that,
> this section could e.g. be moved to an appendix (see e.g. RFC 7413).

Well, RFC7413 actually specifies the API changes in the appendix.  In
our case, following the TCPINC charter, we don't even want to put the
suggested changes in the experimental RFC, but rather an informational
one.  We've proposed a draft for that informational document here:

        https://tools.ietf.org/html/draft-bittau-tcpinc-api-00

So given that there will exist a separate informational document with an
example API, a reasonable question would be whether to mention this at
all in the ENO spec.  I think it's nice to remind implementers that they
SHOULD provide some sort of API (even if not the example one), but I
don't feel very strongly about it.  My preference might be to leave it
in, but if the WG wants to remove it, then that's fine, too.  It's just
a couple of sentences that won't otherwise affect anything the draft.

>   - Considerations of the space limitation in SYNs. Since this
>   document allows in principle an arbitrarily long TCP option,
>   discussion and guidance on that seems useful.
>
>   - Compatibility with other TCP extensions. Unless sorted out in this
>   document, potential interactions and/or incompatibility with TCP-AO,
>   MPTCP, TCP Fast Open, etc. should at least be mentioned as open
>   issue.

These are good points to mention.

> * Section 8: The IANA registration procedure for "cs" values has to be
> specified, and I could imagine different variants, which should
> probably be discussed relatively early.

Any suggestions or examples of other RFCs whose lead you think TCP-ENO
should follow?

> * Section 8: Why does TCP-ENO not allocate an TCP Experimental Option
> Experiment Identifier according to RFC 6994? That would be an easy
> solution to enable experiments with multiple interoperable
> implementations over the Internet, prior to assignment of a TCP option
> kind number. Keep in mind that an experimental document requires an
> explicit IESG action for TCP option kind assignment. In the past, TSV
> has asked for this IESG action several times. In those cases, there
> has been very strong consensus in the corresponding working group
> regarding the codepoint assignment, backed by reasonable interest by
> TCP stack vendors in the protocol.

The WG has debated this point before, and there didn't seem to be
consensus.  Some favor experimental option kinds.  Others believe this
will cause problems when we switch from experimental to regular.  (If I
recall, an example of that problem was NAT-T.)

The reality is that we've been using option kinds 69 and 70 in the wild
for encryption for many years, in software that's available for several
OS distros.  Before that, options 16 and 17 were allocated to encryption
and could safely be reused given that the old encryption scheme is no
longer or was never in use.  IANA has marked 69-70 as "Reserved (known
unauthorized use without proper IANA assignment)."  Realistically, at
this point the main danger is that our use of 69-70 annoys people, not
that we collide with other users in the wild.  (Plus, TCP-ENO's option
kind sharing means only one kind is required, not two.)

I hope that the lack of consensus on this this point doesn't stand in
the way of adopting the draft.  We could certainly adapt TCP-ENO either
way.

David

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 21 Sep 2015 21:04:06 +0000

I provide some further explanation inline, but I don't have bandwidth for detailed tcpinc discussions. TCP stack vendors would have to speak up for some of these questions, IMHO.

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of David
> Mazieres
> Sent: Sunday, September 20, 2015 9:58 PM
> To: Scharf, Michael (Michael); tcpinc
> Subject: Re: [tcpinc] draft-bittau-tcpinc-tcpeno-02
> 

There is actually a very simple solution for section 4. As none of this content seems to be required for an interoperable specification of the TCP option, just move all content in Section 4 to one or more other drafts. KISS principle.

For instance, the session ID could just be a short draft of its own. To me, that would be a much more future-proof concept, e.g., if it should turn out that the session ID format has to be changed in future, but the SYN option format can stay as it is. Or the other way round. Many IETF solutions are specified in more than one document, to have a modular solution.

> instead of "addresses" we said "is motivated by"?

My point is to have an abstract that focuses on what this document seems to be about. As far as I can see, this document seems to specify a TCP option during the 3-way handshake that enables negotiation of encryption. Why don't you just write that in the first or second sentence so that the reader can find the key message fast?
 
> Does that make sense to you?  And is it worth detailing in the

Whether any specific processing belongs into the document has to be decided by the WG. Personally, I'd also be fine with mentioning TCP-AO as a topic for further experimentation.

> squatting on a different RFC's option kind.

I cannot follow. Every protocol designer knows that a protocol can be extended if a protocol does not make use of certain messages, and this does not require explanation. Also, the IETF can update the document any time in future if those bytes are required.

Sorry, if your motivation is to have this section as a means to bypass the IETF process in future, then having these statements is not acceptable *AT ALL*.

Apart from that, it could happen that an enhanced version of TCP-ENO (e.g., a follow-up spec on standards track) needs some option space e.g. in the first ACK for some more advanced negotiation, right? If so, it is not clear whether that extra byte space is completely available to TCPINC encryption specs, or whether TCP-ENO may need it itself in future. Thus, to me the statement in the current draft is not even future-proof for TCP-ENO alone.

The usual way the IETF deals with this is a sentence like "Extra bytes in non-SYN are reserved for future use, and TCP-ENO itself MUST ignore them". What prevents you from writing that?

> > * Section 3.2, page 7: I am confused by some RFC 2119 language in
> this
> > section. Examples:
> >
> >   - "Additionally, the ENO option MUST be present in the first ACK
> segment sent by each host, so as to indicate that no
> >    middlebox stripped the ENO option from the ACKed SYN." => lower-
> capital or (better) reword to required implementation behavior
> >

Yes, I suggest to rephrase those sentences to describe required active behavior of a protocol implementation.

> clearer just to talk this in terms of enabled/disabled encryption.

My comment is not about key agreement, but about the fact that data in SYNs is allowed by the TCP protocol specification. Specifically, a receiver could receive a SYN with an ENO option and payload data. Now, the question is what the receiver shall do with that payload. I think this document has to comment on that. Note that - without TFO - the recipient can delay the delivery of that data to the app until the hand-shake completes, i.e., at first sight the receiver knows whether a TCPINC protocol is indeed enabled or not before it has to decide what to do with SYN payload. Thus, I guess this situation can be sorted out even for fallback, with some additional wording in the spec. With TFO, the situation may be more complex.

This document could leave the combination of TCP-ENO and TFO as a topic for further experimentation. But personally I'd be concerned if the IETF specifies more and more TCP options being mutually exclusive.

> for how a TCP-ENO spec behaves.

I cannot follow. To me, this mixes up TCPINC and TCP-ENO specs. As far as I understand, a TCPINC protocol has two interfaces, and TCP-ENO is only one of them. To me, TCP-ENO seems to be about a simple TCP option during the three-way handshake, and one or more TCPINC protocols have to allocate code-point(s) to enable negotiation and implement the SYN processing according to the spec. But whether different TCPINC encryption specs implementations on different OS indeed have the same user interface, e.g. on Linux and Windows, does not matter for their implementation of the TCP-ENO option, as long as they are compatible in the SYN. This is about two completely separate interfaces that affect different parts of the operating system, which also have separate innovation cycles. For instance, at some point in time TCP-ENO SYN handling may want to be implemented inside TCP hardware offload engines. Updating that is a completely separate question from updating an OS kernel, a user space library, etc. And if Windows and Linux provide a different application interface, you can still sort that out in an OS-independent middleware. That is not possible for TCP SYN options.

My suggestion is to limit this document to what is needed to have interoperable implementations of the TCP option during 3-way handshake. This is core IETF business and a relatively straightforward document. KISS.

Application interfaces can be discussed in separate documents (provided that operating system vendors back corresponding standardization in the IETF).

> checks" that servers can use to impersonate clients to other servers.

I don't question the potential value of session IDs. I just suggest to move them into a separate document, which can possibly refer to the TCP-ENO option spec.

If the draft that specifies a session ID was only a short 5-page I-D, this would even be better. KISS, as I said. 

> a couple of sentences that won't otherwise affect anything the draft.

I've not read draft-bittau-tcpinc-api-00. Whether TCP stack vendors would indeed care about such IETF specifications has to be sorted out. As an author of RFC 6897, I had to learn myself some lessons in that space, but this was in another WG. 

> Any suggestions or examples of other RFCs whose lead you think TCP-ENO

See RFC 5226

My own experience as document shepherd is that IANA sections are rather carefully reviewed by the IESG, with interesting outcomes. Therefore I leave it up to people more familiar with IANA procedures to suggest something.

But based on my own experience it makes sense for a WG to consider this question at *very* early stage.

> kind sharing means only one kind is required, not two.)

I'll not comment on these statements on TCP option code-point squatting, even if I probably should.

As a side note, it is perfectly possible that the IESG will neither allocate 16, 17, 69, nor 70 to TCP-ENO, and this may even be appropriate given the prior code-point squatting. And anyway any IETF-compliant protocol spec of TCP-ENO may have to be updated at some point in time, after an IESG decision. My understanding is that many TCP stacks can be updated within weeks as part of the normal OS updates, i.e., there are probably solutions to this in the market.

I'll just state again that the IETF has published RFC 6994 in order to offer a simple solution to avoid TCP option kind code-point squatting. This solution was designed for experiments with interoperable implementations of a protocol spec prior to an IESG decision. For instance, TFO used this process. As far as I understood, the TCPINC working group currently asks for experiments with running code. I don't know how independent implementations of the TCP-ENO spec should interoperate without some guidance on the option code-point, and RFC 6994 would be a simple solution to that. In some sense, the current IANA section text seems like a guideline towards non-interoperable implementations and code-point squatting. This is not acceptable in my point of view.

Michael

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Sep 2015 14:58:18 -0700

On 9/20/2015 9:06 AM, Scharf, Michael (Michael) wrote:
...
> * Section 2, page 4: "Provide signaling through which applications 
> can better take advantage of TCP-level encryption (for instance by
> option interact with TCP-AO? For instance, I think this document
> could perhaps discuss what a receiver may do if a SYN segment both
> with TCP-ENO and TCP-AO options is received. This is a question much
> closer to the SYN handshake negotiation mechanics than various other
> sections of the document.

FWIW, TCP-AO must precede TCP-ENO processing. If you have a TCP-AO key,
it might be preferable to just encrypt using that key (as per
draft-touch-tcp-ao-encrypt).

...
> * Section 8: Why does TCP-ENO not allocate an TCP Experimental 
> Option Experiment Identifier according to RFC 6994?

+1

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Sep 2015 15:08:51 -0700

...
> is at a higher layer than TCP-AO. 

This is very confusing to me. There are four layers in a TCP segment:

	- link (e.g., WiFi WEP)
	- network (e.g., IPsec)
	- transport (e.g., TCP-AO or TCP-ENO-negotiated protection)
	- application (e.g., SSL)

> In particular, it would take place by

See my other message.

Also note that TCP-AO covers the TCP options only as a choice; it should
be made clear whether leaving that choice open is compatible with
TCP-ENO. See Section 9 of RFC5925.

Even though it is experimental, interaction with TCP-AO-NAT should
probably also be addressed (RFC6978).

...
> unauthorized use without proper IANA assignment)." 

IANA marked *all* unused TCP option kind codepoints as RESERVED. The
only thing different about some of the code points is that they are also
marked as having at least one known, unauthorized use.

You're assuming that you're the only ones who used that codepoint.

Given how you squatted on them without permission or coordination, I
find that amusing.

Joe