Re: [tcpinc] TCP-ENO draft 04 posted

[Joe Touch <[e-mail]>]

On 7/29/2016 4:11 PM, David Mazieres wrote:
> 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.

Fair enough, but then you really need to re-implement the bulk of what
TFO does if you intend to act on previous state as if it were known for
future connections.

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

TCP is a reliable transport protocol. That reliability is not predicated
on "likeliness".

>
>> 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?
IMO, it is incomplete.

The first goal should be correct TCP behavior in all cases.

A secondary goal can be optimization, but only when it does not
interfere with the first goal at all.

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

I appreciate the desire to avoid TFO with ENO, but then you need to
stick to non-TFO semantics.

That means that previous connection state can be used only as a hint,
and that the connection MUST be able to undo 100% of that hint when (not
if) it is wrong.

In that case, you have only two options:

   1) require that ENO never *send* SYN data

    2) require that failed ENO negotiation MUST result in a dropped
connection

In the case of #2, the question is what to do next. I don't see a good
way to make an *option* require a TCP retry. That's why I suggested #1,
unless - of course - you build some sort of TFO-like way to ensure that
you're not just talking to the same IP you spoke to before, but the same
endpoint stack.

Joe