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

[Derek Fawcus <[e-mail]>]

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.

So for some scenario's:
 a) connecting to my home machines from my parents network - I know I will
    have an unadulterated connection between machines I control.
 b) connecting to my home machines from my office - I have a NAT'ed
    connection with known characteristics.
 c) connecting so my home machine from say an airport lounge - I almost
    certainly have a NAT'ed connection,  and with unknown characteristics.

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.

> >  and in particular *if* the application intends to abort an
> > unencrypted connection anyway, 
> TCP needs to be the one making that decision, because an "app" that
> doesn't make that decision could be experiencing TCP semantics that are
> incorrect.
> 
> > *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.

[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.

However,  other than strictly legalistic reading,  I can't see a valid objection.
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?  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 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;  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.  As to if the stack should then attempt
an automatic retry w/o ENO,  I've not given enough though.

DF