Re: [tcpinc] TCP-ENO draft 04 posted

[David Mazieres <[e-mail]>]

Joe Touch <[e-mail]> writes:

> Hi, all,
>
> I'm very confused by the new SYN data text.
>
> First, if you really want state based on previous connections that
> allows early use of SYN data  before the 3WHS, that seems to be the very
> definition of TFO. So declaring that this solution is valid only where
> TFO isn't used seems the opposite of what I would expect.

TFO requires sending plaintext.  ENO explicitly prohibits it.  Either or
both options could get munged by a middlebox.  Hence, it is much safer
to say that ENO specs can do something TFO-like than to allow ENO specs
to modify the semantics of TFO.

The principle here is that it is far more likely for a middlebox to
remove a TCP option than it is for a middlebox to add a TCP option
created out of thin air.

> Second, the text doesn't cover the case where the endpoint abilities
> have changed. Unless you use TFO cookies to verify that ability, you
> should not assume you know it. Which means you can easily be sending
> data you need to unroll - and the only safe way to do that (if the
> endpoint turns out to be non-ENO even if you assumed otherwise) is to
> terminate the connection.

Quite possibly.  However, the goal of section 4.7 is not to prevent TEPs
from doing "bad" things.  Rather, the goal is to impose the minimum
restrictions such that if different TEPs say different things about SYN
data, then it is always unambiguous which TEP specification governs a
particular SYN segment.  A secondary goal is to ensure that TEPs can
later be amended to take advantage of SYN data (because initial TEP
implementations MUST discard SYN data whose usage the old specification
did not define).

Questions about when to reset a connection (or whether to allow some
really weird behavior when the application has explicitly requested it)
should be deferred to the point at which a TEP actually wants to use SYN
data.  If you foresee problems with the current wording (as opposed to
what future TEPs might hypothetically do), then it would help to discuss
two questions separately:

  1. Is the current section 4.7 setting the right goals?
  2. Is the current section 4.7 achieving its goals?

> Third, the claim that "Using data in SYNs deviates..." is incorrect.
> Data in the SYN is valid for TCP. Did you mean "acting on received data
> in the SYN before the 3WHS in the absence of TFO deviates..."?

I originally had "consuming" instead of "using," but thought that read
kind of weird.  Would you prefer "consuming"?  And yes I definitely
meant in the absence of TFO, since the absence of TFO is required.  (TFO
itself already claims to deviate from standard TCP semantics.)

David