Subject: Re: [tcpm] Extending TCP option space

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 1 Sep 2011 09:14:11 +0200

> In a nutshell:
> 
> 	- extending option space after then TWHS is trivial
> 		define a new option, confirm it with a SYN exchange,
> 		and either the SYN gets dropped (some midboxes),
> 		the option is dropped (others), or it works.
> 
> 		if the SYN is retransmitted, retransmit without the
> 		option and tell the user it failed ;-(

And, just to mention an obvious alternative: Unless one needs reliable
transport one can always piggyback options <=40B individually to empty
ACKs.

And if one needs options >40B after SYNs: Maybe we could just run TCP
with MSS=40B inside the option channel ;)

Michael

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 01 Sep 2011 09:12:36 -0400

On 9/1/2011 3:14 AM, SCHARF, Michael wrote:
> transport one can always piggyback options<=40B individually to empty
> ACKs.
>
> And if one needs options>40B after SYNs: Maybe we could just run TCP

I don't have a better reference, but that's essentially what these
guys did for the "in-band, secondary data channel" mentioned on slide
9 of this presentation:
http://www.saloits.com/papers/SIW-ETA2004.pdf
I'm not sure if there was IPR or not.

-- 
Wes Eddy
MTI Systems

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Sep 2011 10:22:59 -0400

On 8/31/11 8:52 PM, Fernando Gont wrote:
> On 08/31/2011 12:58 PM, Joe Touch wrote:
>> Options are exchanged reliably only during connection establishment.
>> There is no TWHS after that. So starting a new option after the
>> connection starts seems difficult at best -
>
> Stick the option to a given SEQ. Whenever you retransmit that SEQ, you
> retransmit the option. And when that SEQ is ACKed, that means the option
> arrived to the other end (assuming no packet scrubber stripped the
> option, obviously).
>
Of course, this is the technique used by TCPCT [RFC-6013], although
slightly more liberally.

Any option can be sent by either peer at *any* time, simply by
inclusion after (Extend part) the TCP Timestamps Extended Option.

If the option wasn't in a data-bearing segment, it is retransmitted
with every successive packet and doesn't take effect until a data Ack
is received.

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 01 Sep 2011 11:12:49 -0400

Farther up the thread a bit:

On 8/31/11 11:58 AM, Joe Touch wrote:
> .... My recollection is that we've dragged this dog around the block every few years, and realize the same thing:
>
> TCP SYN option space cannot be extended
>
I'm certainly in agreement.

> Option negotiation on subsequent packets needs to build in enough of a state machine to consider what happens when packets are replayed or come out of order. The TWHS already handles that, but there doesn't appear to be a good way to do that once a
> connection is established.
>
Or design it to be entirely relative, as we did with TCPCT [RFC-6013],
obviating the need for any state machine revision.

The monster under the bed that folks keep forgetting, that Joe forgot to
mention in his list, and that keeps getting swept under the rug: no
matter how elegant the design, it has to function with dropped packets
and changes in the routing path.

A simple SYN-option to extend the option space on later packets is
utterly useless after the path changes to pass through a different
middlebox.  The extension option might be dropped or munged or
re-segmented into oblivion.

The only solution is security.  TCPCT provides a modicum of security.
That's the reason I combined the baker's dozen features into:

              One Kind to aid them all, One Kind to find them,
           One Kind to hold them all and in the header bind them.

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Sep 2011 08:28:01 -0700

> Farther up the thread a bit:
...
> and changes in the routing path.

Thanks for noting this; I am in complete agreement.

That means that any rewriting middlebox cannot be traversed with an 
option extension it doesn't understand.

...
> The only solution is security.

Security helps you know when it works or not, but doesn't force it to work.

The only way to force it to work through rewriting middleboxes is 
essentially a tunnel over vanilla TCP.

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 1 Sep 2011 21:54:22 +0300

Thanks, all, for responses! So...

* Extending option space after the SYN is trivial, and for example the LO option in Wes' draft would do the trick.

* Reliably extending space for the first SYN is difficult, if not impossible, but extending the SYN option negotiation could be supported with some trick, such as the SLO option in the above mentioned draft.

I don't see why it would be a big problem if some options are introduced later than at SYN time (even without the IAMACAHYAT option), when possible for the purpose of the option (e.g., not window scaling). There are some risks with middleboxes or possibly crashing hosts, but the available measurements seem to suggest that such risks are pretty small. So even just the LO option could be quite helpful, and I think it would be useful to see that idea go forward, with discussion of the possible risks or shortcomings.

People may have ideas of cool new extensions they would like to play with, and it would be nice to be able to try these out in an IETF-approved manner, without having to disable the earlier standardized options first to make room in the header.

- Pasi

On Aug 31, 2011, at 6:58 PM, Joe Touch wrote:

> 
> 
> On 8/31/2011 7:26 AM, Tim Shepard wrote:
>> 
>> 
>> Several years ago, I posted to the TCPM list a ha-ha-only-serious
>> proposal that what we need is a single new minimal size option called
>> IAMACAHYAT which could be exchanged on the SYN and SYN-ACK packets.
>> 
>> This would be used to allow both ends to signal to each other that
>> they are fully prepared to negotiate further options on later
>> segments.
> 
> Whether this works or not - as per middlebox interactions - is less important than it not solving the problem.
> 
> In a nutshell:
> 
> 	- extending the SYN option space is the real issue anyway
> 		- put in an option and extend the options right then
> 			this breaks under 'ignore unknown options',
> 			since the end of the options will be mis-
> 			read as data
> 
> 		- put in an option and use the data in the SYN
> 			this breaks under 'ignore unknown options',
> 			since the option-as-data will be mis-
> 			read as data
> 
> 		- put in something that breaks if unknown
> 			this is the same as using a new transport
> 			protocol number, and won't pass through NATs
> 
> If anyone sees a way around #2, please speak up. My recollection is that we've dragged this dog around the block every few years, and realize the same thing:
> 
> There may be use to extending the space after the SYNs (someone can propose that), but doing it in the SYNs doesn't appear to be possible.
> 
> NOTE:
> 
>> There was a belief at least among some that unexpected options on
>> anything other than the SYN are dangerous because there might be
>> stacks out there that handle them badly, like crashing.  So we seemed
>> to be stuck requiring all new options to somehow fit in the
>> SYN/SYN-ACK exchange.
> 
> Options are exchanged reliably only during connection establishment. There is no TWHS after that. So starting a new option after the connection starts seems difficult at best - however, it fails to solve the key issue:
> 
> 	- starting after the SYN has no real use given you can
> 	start the option during the SYN with 2 bytes
> 
> 	- extending the SYN option space isn't helped by starting
> 	after the SYN
> 
> Another suggestion was to set an option that can affect future TCP connections, but this is a problem because:
> 	a) hosts that restart could use new stacks that don't
> 	support the option, and have no way to safely ignore it
> 	b) IP addrs can be/are shared among endpoints (behind NATs,
> 	or via L2 muxing)
> 
>> And now that I think of it, perhaps it would have been good if MPTCP
>> had not filled up most all of the remaining option space on the SYN
>> with its new options but had instead required use of the IAMACAHYAT
>> option on the initial SYN/SYN-ACK exchange, and then did its
>> own option negotiation on later packets.
> 
> Option negotiation on subsequent packets needs to build in enough of a state machine to consider what happens when packets are replayed or come out of order. The TWHS already handles that, but there doesn't appear to be a good way to do that once a connection is established.
> 
> Joe