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

[Joe Touch <[e-mail]>]

On 7/31/2016 2:26 PM, Derek Fawcus wrote:
> On Sat, Jul 30, 2016 at 08:02:03PM -0700, Joe Touch wrote:
>> On 7/30/2016 4:26 PM, David Mazieres expires 2016-10-28 PDT wrote:
>>> No, I'm saying *if* the application knows the other end of a connection
>>> supports ENO,
>> It doesn't until the SYN-ACK.
>>
>> Let me put it this way - if you know the other end supports ENO, then
>> you clearly don't need to negotiate it in the SYN. Is that what you do?
> If I am contacting a server I control from some arbitrary point within the
> internet, then I do know what the far end supports.  It may well be that
> a middlebox interfers with the connection,  but I can know a priori how
> the other end would respond assuming no interfering middleboxes.

If you know as much as you claim, then you could avoid sending ENO
option completely.

...

> So I can know the box I am connecting to should have a known set of capabilities.
> As to why ENO still needs to be negotiated,  well because the box connecting
> to my home machine may well be from one which does not support ENO.

That considers only the case where the call originator does not support
ENO. TCP extensions need to support all cases of interactions between
upgraded and legacy endpoints.

> ...
>>> *then* it probably makes sense for the
>>> application to send data in a SYN segment.
>> An app doesn't make that decision - it can do things to prevent it from
>> happening (i.e., waiting for the connection to be open before writing
>> data), but it can't force this behavior. It's not in the user interface
>> defined in RFC793, so you can't assume it (unless you're creating this
>> definition solely for ENO, which seems far out of scope to me).
> I don't really view the model APIs mentioned in RFCs as perscriptive,
> rather the over the wire formats are.  So if something can be sent over
> the wire,  a user interface can be created to exercise it.
Protocols are defined by the following entire set:
- messages on the wire
- state at the endpoints
- the interface above (for TCP, that's called the "application" interface)
- the interface below (for TCP, that's IPv4 or IPv6 and its upper-layer
interface)
- timers
- the rules that describe the relationship between the items above as a FSM

The idea that  "if something can be sent on the wire, then the API needs
to be able to control it" fails to consider that upper layer behaviors
act on the FSM and the FSM generates the wire messages.

An API isn't simply a way to write packets. That would be true only for
a degenerate protocol whose FSM is the identity function (and that's not
TCP, in particular).

> [snip]
>
>> Then there's the part about non-compliant hosts - actually, "using" data
>> in the SYN violates the semantics of TCP for *compliant* hosts.
> Well RFC793 implies that,  I've closest I/ come to spotting the bit stating
> that is the text saying data in the syn is handled in the established state.
It's there in the "SEGMENT ARRIVES" processing.

> However,  other than strictly legalistic reading,  I can't see a valid objection.
Protocol specifications aren't suggestions. They are there exactly for
this sort of legalistic reason.

The objection is simple - TCP ensures reliable delivery. Acting on SYN
data before the end of the 3WHS violates that reliability requirement.

TFO gets around this by using the establishment of a cookie from the
previous connection as a sort of "pending" new connection, thus the SYN
data in TFO is considered in the context of the end of this partially
completed handshake, rather than as the start of a completely new handshake.

> A syn can contain data.  A syn-act can contain data.  The syn-ack data could be
> perceived to be a function of the syn data,  but how does it harm any third party
> if it is or is not? 

Because an endpoint that follows RFC793 would NEVER make the SYN-ACK
data depend on the SYN data.

> The worst that can happen (in this case) would seem to be
> a failure to establish an connection,  and a wasted RTT (or two).

The worst thing would be acting on data that has not been reliably
transmitted, which means you have TCP but it no longer is reliable.
That's no longer TCP.

>
>> The answer is simple - if the receiver (ENO or otherwise) uses the
>> information in the SYN data (i.e., it changes its behavior in any way
>> based on that content), then it MUST happen after TFO only (at this
>> point) or a true equivalent. There is *no* aspect of ENO that currently
>> supports that level of equivalence - i.e., *validated* by a SYN cookie.
>> You don't get to make that assumption based on any "belief" of the other
>> end's state
> But one does based upon knowledge of the other ends state;
I'll try not to repeat this too much, but you KNOW NOTHING until the end
of the 3WHS or if you use TFO. Everything else you think you know can -
and will - be wrong.

>  so it won't
> necessarily be available for opportunistic cases,  but for some cases
> connecting to know end nodes it will.
>
>>>  You also did not answer my question
>>> about whether you would support a sentence saying active openers SHOULD
>>> abort non-ENO connections if they have sent SYN data (though at this
>>> point I think such a sentence would be good). 
>> MUST, and it MUST occur inside TCP. You can't assume that happens at the
>> application (user) layer.
>>
>> Note that I already said this when I gave you two choices:
>> a) never send anything you can't retract in the SYN-ACK
>> or
>> b) always abort - inside TCP - a connection where you would have needed
>> to do that retraction
> So in the scenario I give above,  if the host one know's about does not
> support ENO,  then there is a MITM messing with things,  and I'd suggest
> one should abort the connection. 
It's not just MITM - the endpoint has a right to change (rollback its
OS, etc.).

But yes, aborting the connection *inside TCP* is the only correct
behavior if you send SYN data that turns out to be incorrect.

>  As to if the stack should then attempt
> an automatic retry w/o ENO,  I've not given enough though.

That would determine whether your solution is robust or not. Do you
really want to be the one to blame when (not if) this sort of thing happens?

Joe