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

[Joe Touch <[e-mail]>]

On 7/29/2016 12:41 PM, Kyle Rose wrote:
> On Fri, Jul 29, 2016 at 2:46 PM, Joe Touch <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     ...
>     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.
>
>
> Right, I get that for interoperability with ENO-unaware stacks there
> is no way to change data presented in the SYN.
Then you're basically stuck between the semantics of ENO (which
presumably are: deliver encrypted data if possible or unencrypted if
not) and TCP (never undo data).

I.e., as long as ENO is silently backward compatible, then ENO SYNs MUST
NOT include data.

> In the case where both ends understand ENO but the server is not
> negotiating it,

I have no idea what that means. TCP only *knows* what is assumed for all
endpoints (the specs) and what it negotiates. Everything else is wrong
unless verified (e.g., as with a cookie like in TFO).

> we can define TCP SYN payload semantics differently: essentially, when
> there is an ENO option in the SYN, an ENO-aware server will do one of
> two things:
>
> (1) If it is negotiating ENO, it will hand the data off to the chosen
> TEP, which will then indicate back to ENO whether to ACK the data or not.
>
> (2) If it is not negotiating ENO, it will not ACK the data, and will
> in fact throw it away and explicitly permit transmission of
> *different* data for the same sequence number range.
>
> This seems fine to me: since we're defining it in this case, we get to
> choose the behavior.

Agreed, though I really think redefining the TCP data plane for control
is a bad idea...

> The problem is with interoperability with servers that don't
> understand ENO, because they can't make an informed decision here, and
> don't all throw away SYN data.

Exactly.

>> (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...
> Allow the client to assume that a particular server supports ENO, and
> so choose to send SYN data knowing a priori that the server will be
> able to make the choice I outlined above. If you run a service on a
> particular version of Linux that supports ENO, and distribute a phone
> app that contacts only that service, it seems perfectly fine to tell
> your app to assume the server knows ENO.

Clients have no business telling TCP where to put data IMO. They also
have no way of knowing when this *assumption* is wrong.

If you want this sort of "knowledge", you need to build in persistent
cross-connection state at the TCP layer.

TCP isn't "best effort".

Joe