Re: [tcpinc] TCP's treatment of data in SYN packets

[Joe Touch <[e-mail]>]

On 7/28/2016 3:31 PM, Kyle Rose wrote:
> On Thu, Jul 28, 2016 at 6:07 PM, Joe Touch <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 7/28/2016 3:01 PM, Kyle Rose wrote:
>     > I still don't have a good feel for what folks like Joe are
>     > recommending re: dealing with a B that doesn't understand ENO.
>     If B is
>     > suddenly not ENO-aware,
>     Not suddenly. During the SYN exchange.
>
>
> Sorry, by "suddenly" I mean that an IP that formerly negotiated ENO
> gets swapped out for one that doesn't understand ENO: this could for
> example be the result of a load balancer sending the request to a
> machine with an older kernel.

Or a different connection. For all you know, there are multiple stacks
within the kernel (e.g., FreeBSD supports this) or per-connection settings.

IMO, it isn't a good idea to build a protocol around the default
assumption that past connections predict future ones. It's OK to guess,
but that guess has to be "unrollable". Which leads me to the concern
below...
>
> Note that it must be the case that the stack in question doesn't
> understand ENO, not just that it is now unwilling to negotiate ENO. If
> it knows about ENO but just doesn't want to negotiate it, it knows
> enough to throw away the SYN data.

The thing about TCP is that it doesn't say what to do with data that is
retransmitted.

E.g., let's say you send SYN-abc, and I ACK only the SYN (not the data
"abc").

Then you send "def". I ACK the data *at the position of 3*. There's
nothing that indicates which "position of 3" data I'm ACKing. For all
you know, I cached the data in the SYN but did not ACK It, but when the
new data came in I didn't overwrite it.

Although I know this is unusual behavior, I'm not entirely positive it's
prohibited by the spec. TCP doesn't say what happens to data that is
sent more than once at a given position - there's no rule that it MUST
be the variant seen in the most recently received segment.

So I can easily imagine compliant implementations that might end up
doing something you didn't want.

That's why, IMO, if you send ENO, you need to make sure the SENDER
doesn't put anything in the SYN data that has to be *changed*. Re-sent
is fine. But CHANGED is not.

...
To your point:

> I see four main options:
>
> (1) Don't ever send data in the SYN. This is easiest, but sacrifices
> ENO support for SYN data forever for the sake of full interoperability
> with legacy TCP stacks, even with hosts a user knows a priori support
> ENO. This is not my preference.
It is known safe, though.

> (2) Retain knowledge of ENO support for an IP and assume it on
> resumption attempts, throwing that state away if ENO is not
> negotiated. This case means accepting that we'll have to retry the
> connection in cases when a server supporting ENO and one knowing
> nothing about ENO share an IP.
This is safe only if you kill off the connection where you try ENO with
data and it fails.

> (3) Require signaling from the server on a previous connection. This
> case is a more explicit form of (2), and carries the same dangers, but
> puts the configuration burden on the server administrator to assert
> that, yes, all servers responding for this IP support ENO.

Dangerous. TCP shares state explicitly only within a single connection.
Across connections, you can share hints that you can undo (ala RFC2140),
but nothing that changes the semantics of TCP or can't be unrolled
completely.

> (4) Require signaling from the client application. This allows a
> client to decide whether to support SYN data based on a priori
> knowledge of the server's support for ENO.

I'm not sure what you mean here...

Joe