Subject: [tcpinc] Encryption of TCP Options

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 27 Apr 2016 08:50:28 +0200

Hi all,

I briefly brought this up in the last meeting and would like to start the discussion on the mailing list now. The working group decided that tcpinc will not encrypt the TCP header for good reasons. However, it would still be possible to encrypt TCP options. This could help keeping confidentiality and would avoid that a middle could alter information in a option or strip it. Not sure if there is a case where some options should be encrypted and some not but I guess that would be possible as well. Any thoughts?

Mirja

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Apr 2016 16:56:40 +1000

> I briefly brought this up in the last meeting and would like to start the discussion on the mailing list now. The working group decided that tcpinc will not encrypt the TCP header for good reasons.…

Why not encrypt on an ad-hoc basis?  You could have new options
encrypted, and define encrypted variants of existing options.  It's a
little tricky to get this stuff right though.  See for example
https://tools.ietf.org/html/rfc6904

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 27 Apr 2016 07:38:17 +0000

I think this could be done for non-SYN options that do not modify the semantics of the key TCP header fields. But there are not to many of those options and putting them inside TCPINC gets relatively close to developing a new shim layer transport inside a "TCPINC tunnel".

As far as I understand, encrypting MSS, WS, and SACK would be very challenging. Encrypting TS may be possible in some use case, but e.g. there have been TCPM discussions regarding leveraging TS in CG-NATs, so what would be the value? Fast open seems challenging as it is a SYN option. Regarding other options, MD5 and TCP-AO may typically not be used in combination with TCPINC.

So, what options could realistically be encrypted? MPTCP?

Michael

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of EXT Mirja Kühlewind
Sent: Wednesday, April 27, 2016 8:50 AM
To: tcpinc
Subject: [tcpinc] Encryption of TCP Options

Hi all,

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

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 27 Apr 2016 17:45:21 +0100

On Wed, Apr 27, 2016 at 07:38:17am +0000, Scharf, Michael (Nokia - DE) wrote:
> As far as I understand, encrypting MSS, WS, and SACK would be very challenging.

Well,  for MSS I'd want to be able to alter it in a middle box, despite the
DOS (slow down) attack this yields - simply because of the existance of MSS
clamping features in various routers, firewalls and NATs.

Commonly used to cope with the impact of PPPoE.

DF

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Apr 2016 10:50:14 -0700

Hi, all,

TCPINC decided not to include any protection for the TCP header.

TCP options are part of the TCP header.

Sorry, but I have absolutely no idea why they would be asking now for a
way to protect part of the TCP header when they've already so clearly
decided otherwise.

If you're not protecting things like IP addresses, ports, or - more to
the point -the TCP header length field, I have no idea what it even
means to claim you're protecting options.

Joe

---

From: David Mazieres <[email-masked]>
Date: Wed, 27 Apr 2016 11:24:11 -0700

Mirja Kühlewind <[email-masked]> writes:

> Hi all,
>
> I briefly brought this up in the last meeting and would like to start
> the discussion on the mailing list now. The working group decided that
> tcpinc will not encrypt the TCP header for good reasons. However, it
> would still be possible to encrypt TCP options. This could help
> keeping confidentiality and would avoid that a middle could alter
> information in a option or strip it. Not sure if there is a case where
> some options should be encrypted and some not but I guess that would
> be possible as well. Any thoughts?

Encrypting existing TCP options strikes me as a bit complex, especially
since at that point you might to authenticate them.

That said, there's a related point which is that tcpcrypt, given its TLV
structure, could easily offer some sort of side channel.  In BA, Jana
suggested there might be good uses for something like this.  For
example, suppose you want to collect information on what middleboxes are
doing.  You could transmit an advisory copy of the options in a special
tcpcrypt frame and compare them at the receiving end.

We are definitely open to accommodating such scenarios for the simple
reason that it would be extremely simple.  In fact, we currently have 6
unused bits in the flags field of a frame.  We could easily say that the
high bit means this is a control message and implementations MUST skip
over control messages they don't understand.  (Or partition the space
using the other bits into some MANDATORY and a bunch of OPTIONAL
skippable ones.)

What do people think?

David

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Apr 2016 11:07:18 +0200

Hi Michael,

see below.

> As far as I understand, encrypting MSS, WS, and SACK would be very challenging.

Can you further explain why?

> Encrypting TS may be possible in some use case, but e.g. there have been TCPM discussions regarding leveraging TS in CG-NATs, so what would be the value?

I agree that there might be value to not encrypt TS, however, using this 
information in a middlebox is architecturally very unclear and a pity that we 
have too...

> Fast open seems challenging as it is a SYN option. Regarding other options, MD5 and TCP-AO may typically not be used in combination with TCPINC.
>

Yes, I was actually thinking about some MPTCP options as they might reveal 
privacy-sensitive information that allows the network to identify that two 
connections/two IP addresses belong to the same endpoint. I was really only 
talking about encryption, not authentication. I don't think there is a 
middlebox out there yet that would miss this information or block the traffic 
if it could be encrypted, at least I hope that's not the case.

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Apr 2016 11:10:54 +0200

Hi Joe,

> way to protect part of the TCP header when they've already so clearly

To my understanding the reason to not encrypt the header was that some of the 
header information is need to pass middleboxes, such as for sure the ports 
but also some of the flags and maybe even the seq#. However, I think options 
or at least some of the options are less critical.

> means to claim you're protecting options.

The main reason is to avoid (easy) leakage of privacy-sensitive information 
that could be used to identify different connections or different IP 
addresses that belong to the same host.

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Apr 2016 11:14:21 +0200

Hi all,

another idea would be to provide some side channel to transport additional 
information such as potentially options instead of encrypting the actual 
options. In this case we would probably rather need a length field than a 
single bit (and then we could use the same semantics as used for options to 
fill this field...). Just an idea... probably need to further think about it.

Mirja

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 28 Apr 2016 10:28:11 +0000

MSS, WS, SACK, and TS are part of the standard TCP header. Moving these options elsewhere would change not only the TCP header but affect the fundamental TCP/IP protocol architecture. This would have to be brought up at least in TCPM, IMHO.

I do not deal with middleboxes but I think the following has been discussed in the IETF in the last decades:

* MSS option: As already mentioned, this is often modified e.g. in xDSL networks (MSS clamping)

* WS: SYN only option, i.e. hard to encrypt, has to be read by Wireshark, stateful firewalls, etc. to determine whether a TCP segment is in-window, also has to be understood by TCP PEPs that reduce RWND (e.g., to prevent congestion on a last hop)

* SACK: May perhaps be used by transparent TCP caches that transparently retransmit segments (e.g., in SATCOM environments), probably also read by anomaly detection systems, stateful firewalls, packet loss estimation in network analytics, etc.

* TS: Probably used for RTT estimation in network analytics, possibly also some CG-NAT use, etc.

And I am pretty sure this list is not comprehensive in particular regarding network analytics and dynamic traffic engineering. TCPM contributors may know more.

For measurement purposes any application protocol running on top of TCP could copy the content of TCP options into an application layer protocol structure. Unless I miss something, I think measurement is completely orthogonal to encryption. 

Michael

-----Original Message-----
From: EXT Mirja Kühlewind [mailto:[email-masked]] 
Sent: Thursday, April 28, 2016 11:07 AM
To: Scharf, Michael (Nokia - DE); tcpinc
Subject: Re: [tcpinc] Encryption of TCP Options

Hi Michael,

see below.

> Encrypting TS may be possible in some use case, but e.g. there have been TCPM discussions regarding leveraging TS in CG-NATs, so what would be the value?

I agree that there might be value to not encrypt TS, however, using this information in a middlebox is architecturally very unclear and a pity that we have too...

> So, what options could realistically be encrypted? MPTCP?

Yes, I was actually thinking about some MPTCP options as they might reveal privacy-sensitive information that allows the network to identify that two connections/two IP addresses belong to the same endpoint. I was really only talking about encryption, not authentication. I don't think there is a middlebox out there yet that would miss this information or block the traffic if it could be encrypted, at least I hope that's not the case.

Mirja

---

From: Brian Trammell <[email-masked]>
Date: Thu, 28 Apr 2016 12:33:02 +0200

Of these, I think TS is the only one with clear privacy tradeoffs:

> On 28 Apr 2016, at 12:28, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 

Definitely used for RTT estimation in network analytics. :) Timestamp sequencing can be used to identify devices behind a NAT, and clock skew provides a few bits of entropy in fingerprinting devices regardless of NATs. Not clear that there's much benefit to TCPINC encryption of this option, though, because a more comprehensive solution to fingerprinting is to disable transmission of TS.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 28 Apr 2016 12:36:42 +0200

hi Mirja, all,

Briefly, inline,

> On 28 Apr 2016, at 11:14, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> another idea would be to provide some side channel to transport additional information such as potentially options instead of encrypting the actual options. In this case we would probably rather need a length field than a single bit (and then we could use the same semantics as used for options to fill this field...). Just an idea... probably need to further think about it.

Yep. I think the main win here, as David says below, would be protecting something a la HICCUPS, where hash information about the packet header would be tcpcrypt-protected, to allow endpoint detection of header manipulation.

>> using the other bits into some MANDATORY and a bunch of OPTIONAL

As an author of the SPUD requirements draft, this seems to me like a useful general purpose facility to have...

Cheers,

Brian

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Apr 2016 12:47:06 +0200

Just one minor comment: Other than the TCP header itself, all this 
information is optional, so a middlebox can never be sure that this 
information will be available anyway.

Further I didn't propose to encrypt all option by default but maybe rather 
give the endpoint the opportunity to encrypt them (or some of them) if needed.

And finally, I agree that there is probably no need to encrypt the option 
below (except TS maybe).

Mirja

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 09:26:49 -0700

On 4/28/2016 2:10 AM, Mirja Kühlewind wrote:
> To my understanding the reason to not encrypt the header 

Encrypt yes; include in the encryption pass, which would have protected
it against modification, no.

> was that some of the header information is need to pass middleboxes,
> such as for sure the ports but also some of the flags and maybe even
> the seq#. However, I think options or at least some of the options are
> less critical.

I guarantee someone will show us a middlebox that NEEDS to modify every
option we currently have and every option we will ever create.

However, regardless, the logic for the middlebox and the base TCP header
are exactly the same. I prefer to protect both, but if you're not
protecting the base it is nonsense to protect the options.

> The main reason is to avoid (easy) leakage of privacy-sensitive
> information that could be used to identify different connections or
> different IP addresses that belong to the same host.

All of that logic applies to the contents of the base TCP header as
well. The only option that would really need to be protected by
encryption this way would be a host-identity option - but that would
need to be inherently protected anyway and would not need TCPINC to do
that for it.

>>> I briefly brought this up in the last meeting and would like to
>>> start the discussion on the mailing list now. The working group
>>> decided that tcpinc will not encrypt the TCP header for good
>>> reasons. However, it would still be possible to encrypt TCP options.
>>> This could help keeping confidentiality and would avoid that a
>>> middle could alter information in a option or strip it. Not sure if
>>> there is a case where some options should be encrypted and some not
>>> but I guess that would be possible as well. Any thoughts?
>>>
>>> Mirja

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 09:32:35 -0700

TCP options define how a TCP segment and its header are interpreted.

If you put them somewhere else, you need a synchronization mechanism to
tie them back together.

I.e., you're defeating the idea of the header as a control channel for TCP.

This is a very bad idea.

Joe

On 4/28/2016 2:14 AM, Mirja Kühlewind wrote:
> Hi all,
>
> another idea would be to provide some side channel to transport
> additional information such as potentially options instead of
> encrypting the actual options. In this case we would probably rather
> need a length field than a single bit (and then we could use the same
> semantics as used for options to fill this field...). Just an idea...
> probably need to further think about it.
>
> Mirja
>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 09:39:24 -0700

> information will be available anyway.

However, it will interpret it as in-the-clear and modify it, regardless
of whether you want it to or not.

And if you make it look like it's "unknown", it will drop, split/copy,
or coalesce/drop it, regardless of whether you want it to or not.

The whole motivation for TCPINC - which is effectively TLS inside the OS
on the TCP payload, even if that exact variant isn't what we ended up
with - was to provide TLS-like protection without needing application
involvement. If you want to protect the TCP header too, use TCP-AO, If
you want to encrypt the TCP header and/or options, use TCP-AO-ENC. If
you want to include the IP header in all of this, use IPsec.

Don't get me wrong - I still think TCPINC is a mistake and that we ought
to push back on the nonsense that many middleboxes create, but there's
simply no valid reason for TCPINC to claim that the header isn't
involved but the options are.

To repeat more simply - "TCP options ARE part of the header". They're
not this separate thing that you get to include in other ways on a
per-option basis.

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 28 Apr 2016 10:00:08 -0700

> means to claim you're protecting options.

So my understanding of the sidechannel is that it could be used for
things like measurement studies.  It's obviously not going to be 100%
right, since packets might get resegmented, etc.  But it's also a fairly
small change to make to tcpcrypt, so a small numerator makes the
cost/benefit analysis is probably favorable.

I think the high-level point is that doing anything that consumes option
space and risks middlebox problems should be considered a large cost.
So at that point we really need to maximize the benefit, which was
already what we tried to do with the original version of tcpcrypt before
the working group required TLV.

Actually, there's one more thing we never showed the working group,
which was an authenticated encryption mode that is robust to middlebox
resegmentation, basically using cumulative authentication.  We came up
with that in response to objections about middlebox resegmentation, but
it was too late as the working group had already gone to TLV and no
header protection.  That vastly complicates implementation but is by
construction robust to pretty much any layer 4 or lower middlebox
shenanigans.

Of course, the advantage of ENO is that it doesn't completely shut the
door on revisiting these decisions even after tcpcrypt is deployed, but
I won't be holding my breath.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 10:16:53 -0700

> cost/benefit analysis is probably favorable.

If the sidechannel measures the overall flow by essentially random
sampling, sure.

But, as you note, there's no guarantee that the sidechannel would
correlate to a specific TCP segment or its header (including options).

> ...

You can layer anything you want on top of TCP, including TCP.
Ultimately, the only way to get around middlebox behavior is to do this,
but then we'll end up with middleboxes that parse the inner packet and
reassemble them.

We've already seen this escalation with IP option use and tunnels and
V6OPS is finally starting to pushback, saying that we need to hold the
ground that routers may be required to deal with hop-by-hop IP options
(silly me - I thought this was a requirement of RFC2460).

Ultimately, as I've said there, until the ISOC creates a compliance
mechanism, we have to do the best we can, which sometimes means
interoperating and sometimes means pushing back.

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 28 Apr 2016 10:18:57 -0700

> or at least some of the options are less critical.

First, the problem here is as much the authentication as the encryption,
assuming we are using some sort of authenticated encryption.  The
original tcpcrypt design actually addressed most of the fields.  For
example, even though middleboxes manipulate seq# and ack#, we used
64-bit offsets from the ISN, which is robust to middleboxes.  In fact,
tcpcrypt even subsumed timestamp and could potentially save option space
for things like RFC1323 PAWS.

However, the working group was concerned that middleboxes might reorder
options.  Hence, any authentication must be robust to such
manipulation.  I think that leaves two possible approaches:

  1. Encrypt each option separately with authenticated encryption.

  2. Stuff all the options into a giant, new "encrypted option option".
     Probably this would be the ENO option in non-SYN packets.

#1 is problematic because each individual option is going to require an
authentication tag (say 8 bytes), very likely blowing out the option
space.  Moreover, middleboxes attempting to parse the options may flip
out when the options don't match their length.

#2 is I think a better approach, but not perfect.  Many options depend
on a SYN exchange to make sure both sides (and all middleboxes) support
the option.  So we need to keep that negotiation robust.  Of course,
long-term if ENO takes off there may be significant gains in SYN option
space to be had.  For example if the encrypted option option enjoyed
widespread use, we could define a new ENO code point that uses a bitmask
in SYN segments to disclose supported options, so a single byte could
negotiate timestamp, SACK, etc.  Or later encryption specs could even
subsume some of those options if they are universally supported.

> addresses that belong to the same host.

It might help to consider options on a case by case basis.  Some
options, such as timestamp, can potentially be handled unilaterally.
For example OpenBSD's NAT code has been modulating timestamps for years.
Another approach here would be to make it easy for other RFC authors to
leverage tcpcrypt to protect the privacy of there options.  For any
options that are tied to data, moving them in-band to special TLV frames
might make the most sense.

David

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 28 Apr 2016 20:09:34 +0000

> might make the most sense.

Formally, that would require a proposed standard specification of TCPINC because only then it can be used in standards produced by other working groups such TCPM. And I believe we are here discussing a mechanism that may have to update RFC 793, which is an Internet Standard that is ubiquitously deployed in the Internet.

Also, I think this mechanism is not required for payload protection and should thus be moved into a separate document separated from the base TCPINC protocol. 

Furthermore, at least the MPTCP WG had a past consensus call against using options inside TLV frames, even for option data tied to payload. There can be subtle challenges when moving TCP options to a TLV structure and this has been discussed extensively in MPTCP (in 2010/2011). So, it could make sense to first sync with implementers of other TCP options whether there is actually interest in this sort of mechanism, and what the actual requirements would be. Again, this is an indication that such a mechanism should be separated from a base protocol.

Finally, I believe it is not appropriate for this WG to further discuss any mechanism that affects RFC 793, which defines the handling of options in TCP. Such a discussion belongs to the TCPM list.

Michael

---

From: David Mazieres <[email-masked]>
Date: Thu, 28 Apr 2016 13:34:14 -0700

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

> Formally, that would require a proposed standard specification of
> TCPINC because only then it can be used in standards produced by other
> working groups such TCPM. And I believe we are here discussing a
> mechanism that may have to update RFC 793, which is an Internet
> Standard that is ubiquitously deployed in the Internet.

First, I'm fine with not further discussing as you suggest.  However,
IANA does assign TCP option kinds to experimental RFCs (e.g., RFC6824,
with option kind 30 for multipath TCP, and I hope one day TCP-ENO as
well).  So I hope it's not completely unreasonable to imagine future
experimental RFCs that use TCP options to say something about tcpcrypt.

Second, I want to clarify that by "make it easy for other RFC authors to
leverage tcpcrypt," I wasn't at all suggesting describing some alternate
TCP option mechanism in any TCPINC document.  Rather, I just meant
giving some consideration to future side channel mechanisms, for
instance by explicitly having a bunch of reserved frame types along with
language about how implementations MUST skip over those frames if they
don't understand them.

David

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 28 Apr 2016 21:24:56 +0000

> experimental RFCs that use TCP options to say something about tcpcrypt.

In this context, I want to mention once again that in my point of view the TCP-ENO specification should use RFC 6994 right now:

https://www.ietf.org/mail-archive/web/tcpinc/current/msg00815.html

https://www.ietf.org/mail-archive/web/tcpinc/current/msg00817.html

I'd like to explicitly thank for ignoring my feedback.
 
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 16:07:33 -0700

+1

Experiments like ENO are exactly what that mechanism is defined for. 

> On Apr 28, 2016, at 2:24 PM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
>

---

From: David Mazieres <[email-masked]>
Date: Thu, 28 Apr 2016 16:35:06 -0700

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

>> IANA does assign TCP option kinds to experimental RFCs (e.g.,
>> RFC6824, with option kind 30 for multipath TCP, and I hope one day
>> TCP-ENO as well).  So I hope it's not completely unreasonable to
>> imagine future experimental RFCs that use TCP options to say
>> something about tcpcrypt.
>

First, believe it or not RFC6994 is actually standards track, so not
necessarily relevant in this context (namely the question of what RFCs
can cite ENO).

Second, I thank you for your feedback.  We certainly did not ignore it,
as evidenced by some of my replies to your messages.  On the specific
point of switching to option kind 253 or 254, there are good points on
both sides.  Squatting no doubt involves risk.  However, RFC3692 also
prohibits use of 253/254 in shipping products like tcpcrypt, so we're
kind of in a catch-22.

In the absence of working group consensus, we decided to maintain the
status quo and keep squatting.  Since IANA tacitly acknowledges and
documents option squatting, it's reasonable to hope that no one else
will concurrently squat on 69 (or any of the other 8 numbers with known
unauthorized use) before we get an RFC.

At any rate, I hope the point becomes moot when IANA allocates a
dedicated option kind number to the TCP-ENO RFC.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 17:24:22 -0700

> necessarily relevant in this context (namely the question of what RFCs

I'm fairly sure that both Michael and I are citing 6994 the other way
around (that ENO would use 6994). Just like you almost do below...

> prohibits use of 253/254 in shipping products like tcpcrypt, so we're

Please read RFC6994.

> documents option squatting,
 
Got an RFC for that? IANA recognizes that it happens but it's not
endorsed and not typically considered in applications (e.g., see RFC6335
in the impact of squatting on port assignments).

I cannot understand how a WG item is using a squatted number. This point
was raised a LONG time ago.

>  it's reasonable to hope that no one else

Given RFC6994, it's not clear why an experimental TCP option should ever
be allocated a separate option kind number until it becomes standards-track.

Joe

---

From: David Mazieres <[email-masked]>
Date: Thu, 28 Apr 2016 18:38:39 -0700

> was raised a LONG time ago.

IANA claims 253/254 are already being "improperly used for shipping
products", presumably in violation of RFC6994.
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1

Until we get an official option kind, this is just a lose-lose
situation.

But also, note that the WG documents are not actually using a squatted
number.  For now the number is symbolic in the actual document.  So
technically you can criticize our pre-RFC deployment, but the working
group itself isn't necessarily guilty of anything.

> be allocated a separate option kind number until it becomes standards-track.

It may not be clear why, but it happens (as evidenced by RFC7413, an
experimental RFC, moving from option kind 254 to 34).

Look, I don't have anything against RFC6994, which seems like a good
idea.  But all else equal, I'd rather not lose 2 more bytes of option
space or risk colliding with whoever is squatting on 253/4 without a
valid ExId.

More importantly, I don't want to keep re-litigating this point.  If
you'd formed working group consensus around getting an ExID, we would
have switched to RFC6994.  At this point, we're on the home stretch for
an RFC and have a bunch of deployed code out there, so our efforts are
better spent finishing the existing document.

The good news is that at least ENO is a bit like RFC6994 in allowing use
by multiple protocols.  So if we are going to consume another short
option kind for an experimental RFC, assigning it to ENO will not be
wasteful.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2016 20:03:44 -0700

I recall making this point for tcpcrypt but I gave up on most of what happens here long ago. I'm not surprised the group insists on making the same mistake twice. 

Please at least don't break the rest of tcp in the process. 

Jie

> On Apr 28, 2016, at 6:38 PM, David Mazieres <[email-masked]> wrote:
> 
> have switched to RFC6994.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 29 Apr 2016 07:29:40 +0000

> More importantly, I don't want to keep re-litigating this point.  If you'd formed working group consensus around getting an ExID, we would have switched to RFC6994.  At this point, we're on the home
> stretch for an RFC and have a bunch of deployed code out there, so our efforts are better spent finishing the existing document.

As co-chair of TCPM: Many thanks for letting me know that a proposed standard RFC published by the TCPM working group, which represents IETF consensus, is not considered appropriate in this community. I believe this decision should be recorded in the shepherd write-up for the TCP-ENO document, so that it can be discussed during IETF last call.

As individual contributor: I have not asked for changes in running code. But in my understanding new experiments with TCP-ENO could use RFC 6994 and would thus follow the process that the IETF offers for such experiments. Given that the TCP-ENO specification has changed over time I would assume that new experiments fully complying to the TCP-ENO specification would require other code changes as well and TCP-ENO implementations could thus move to RFC 6994 for further experimentation. The value of experimentation with running code is well-known and RFC 6994 has successfully be used in such cases.

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 29 Apr 2016 10:06:38 +0000

> But more to the point, what is your concrete proposal? 

1. Get an ExId from IANA. I think filling out http://www.iana.org/form/protocol-assignment can be done in 5min. This can be done by anybody interested in experimenting with TCP options, because it is clear that there is a need to experiment with TCP extensions prior to an official TCP option kind assignment by IANA. RFC 6994 was written for that.

2. Note down in the TCP-ENO document how TCP-ENO uses the ExID according to RFC 6994. In the simplest case, this may only affect the IANA section. For full interoperability between different TCP-ENO experiments, indeed, you might have to specify in the ID whether to use 253 or 254 or both. IANA allocates the ExID for both options.

3. Assuming that the TCP-ENO spec will be move forward soon, assuming the TCPINC WG will formally ask IESG for an exceptional assignment of a new TCP option kind number, and assuming that IESG will finally approve this exception, you could perhaps just reuse some wording from the IANA considerations of RFC 7413 without changing the rest of the protocol spec.

Under the mentioned assumptions I do not believe that this would create major migration problems as the transient period might be short in the best case. It is up to the TCPINC community to decide on whether to discuss potential migration strategy for pre-standard protocols possibly using codepoints not approved by IANA. Of course, it is up to the IESG to decide whether to indeed assign a TCP option kind number to an experimental protocol. 

Alternatively, you could just decide to specify the use of codepoints 253 or 254 without an ExID value for TCP-ENO prior to the IANA assignment. That would have been the method prior to RFC 6994. 

And I guess the document could stay as it is right now if this is only a conceptual proposal and there is really no plan to implement the TCP-ENO mechanism any time soon. That would be a bit strange but if the TCPINC community concludes that there will be no implementation of the TCP-ENO prior to an IANA option kind allocation, indeed, there may be no need to explain how the protocol could be implemented. Formally this could perhaps be achieved by a statement in the I-D such as "This protocol specification MUST NOT be implemented prior to assignment of a TCP option kind number" or something like that.

Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 29 Apr 2016 15:30:50 +0000

> On Apr 28, 2016, at 9:26 AM, [email-masked] wrote:
> 

I'd put it the other way around. The fact that middleware *can* get to something lets someone find a use for doing so. That's not an argument for it, it's an observation of fact.

Frankly, the only option I'm aware of people actively modifying is the MSS. In a world in which ICMP is filtered and RFC 4821 isn't widely implemented, having a VPN Tunnel Endpoint or other middleware reduce the MSS to some value is a PMTU solution that mostly works. My preference would be RFC 4821 or something like it. But that's not where we are.

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Apr 2016 10:18:46 -0700

Excepts for those who have (still) not yet read RFC6994 (and some
corrections on misconceptions) below.

Joe

> 1. Get an ExId from IANA. I think filling out http://www.iana.org/form/protocol-assignment can be done in 5min. This can be done by anybody interested in experimenting with TCP options, because it…

"ExIDs are registered with IANA using "first come, first served" (FCFS)
priority based on the first two bytes."

There is no requirement for an RFC, a particular development track in
the IETF, or anything else to request an ExID.

> 2. Note down in the TCP-ENO document how TCP-ENO uses the ExID according to RFC 6994. In the simplest case, this may only affect the IANA section. For full interoperability between different TCP-EN…
"ExIDs are registered for use with both of the TCP experimental option
codepoints, i.e., with TCP options with values of 253 and 254."

There's no requirement that they be used with both codepoints; that's up
to the protocol designer.
> Alternatively, you could just decide to specify the use of codepoints 253 or 254 without an ExID value for TCP-ENO prior to the IANA assignment. That would have been the method prior to RFC 6994. 
That's counter to the recommendation in RFC6994:

" >> All protocols using the TCP experimental option codepoints (253,
254), even those deployed in controlled environments, SHOULD use ExIDs
as described in this document."

> And I guess the document could stay as it is right now if this is only a conceptual proposal and there is really no plan to implement the TCP-ENO mechanism any time soon. That would be a bit strang…
IMO, that would be a good idea as well. Also, RFC6994 Section 5
discusses issues with transitioning to assigned option codepoints.

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:29:41 +0000

> I'd put it the other way around. The fact that middleware *can* get to
> something lets someone find a use for doing so. That's not an argument
> for it, it's an observation of fact.
> 
> Frankly, the only option I'm aware of people actively modifying is the
> MSS. In a world in which ICMP is filtered and RFC 4821 isn't widely
> implemented, having a VPN Tunnel Endpoint or other middleware reduce
> the MSS to some value is a PMTU solution that mostly works. My
> preference would be RFC 4821 or something like it. But that's not where
> we are.

In TCPM there have been reports about sequence-number randomizing firewalls:

https://www.ietf.org/proceedings/87/slides/slides-87-tcpm-11.pdf

>From slide 2: 'Firewalls "fixed" it by randomizing TCP sequence numbers - But some of them forgot SACK'

Encryption the SACK option would result in the same issues like this entirely broken firewall.

Yet, this shows that there may be cases in which *not* modifying the SACK option creates problems. 

(I'll obviously not argue in favor of this sort of firewall, as a modern high-end TCP stack should have sufficient sequence number randomization.)

Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:31:32 +0000

True, but that's not in an option.

> On Apr 29, 2016, at 11:29 AM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 29 Apr 2016 18:32:37 +0000

oops, missed your observation re SACK. Yes, that firewall would get pretty well screwed by an encrypted SACK option.