Re: [tcpinc] TCP-ENO draft 04 posted

[Joe Touch <[e-mail]>]

On 7/29/2016 5:24 PM, David Mazieres wrote:
> Joe Touch <[e-mail]> writes:
>
>> 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.
> Yes, except the reimplementation may turn out to be simplified by the
> fact that A) TEPs have a cryptographically strong way to check data
> integrity at their disposal, and B) there may be extrinsic information
> about the server-side SYN handling. 
Sure, but TFO achieves a way to rely on safe early use of SYN data that
doesn't change. That's what you get with a TFO-like solution.

...
>  E.g., if TCPINC ever integrates
> with DANE, there could be a DNS record promising that a server always
> implements some TEP and is always willing to engage in some server
> authentication pre-protocol.  In that case, the client can count on the
> server observing ENO's requirement to discard unexpected SYN data.
DNS hints can tell you what might succeed, but can't guarantee it. You
don't know if TCP will be preceded by a DNS lookup - it's not integrated
inside TCP.


>
>>>   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.
> I don't understand.  Don't we already have RFC793 and the whole IETF
> process to ensure correct TCP behavior? 
If everyone follows it...(and that's the trick here)

>  I'm not saying TCP-ENO should
> advocate incorrect behavior, 
That's where we disagree - if you intend on sending SYN data that
changes if not ACKd, I do.

> just that A) most correctness requirements
> are implicit (or by normative citation of RFC793), and B) from
> time to time the IETF sees value in deviating from RFC793 (e.g., TFO).
Certainly - e.g., the meaning of the URG pointer changed too. But in all
cases there's a strong expectation that these changes do not affect
legacy TCP. In the case of URG, it was because we all believed strongly
that this was compliant with all known implementations and that the
failure mode was relatively gentle to TCP semantics.

> There's no reason to write the spec in such a way as to complicate or
> redundantly prohibit future TFO-like things *if* the IETF wants to
> pursue them.
Agreed. But I'm still not sure that's what's going on here..

>> I appreciate the desire to avoid TFO with ENO, but then you need to
>> stick to non-TFO semantics.
> Unless a TEP specifies TFO-like semantics, right? 

Yes, but that means success of TFO-like gives you permission to do more
with the SYN-data (or do it earlier). Even TFO doesn't give permission
to change data that hasn't yet been ACKd.

>  There may be value in
> having a TEP replicate or incorporate TFO, but for backwards
> compatibility A) it should do so without including option 34, and B)
> older versions of the TEP should ignore the SYN data.
And legacy TCP cannot be required to discard the SYN-data. You cannot
control the server side if it's legacy.

>
>> 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 could see going with #2 if that's the sentiment of the working group,
I've noted my concern there... (see the end of this message for more on
that)


> but my preference would be to leave it up to the individual TEP, 

Do you mean that you would let the TEP indicate which of the two above
is selected for a given endpoint? That's fine, as long as both work
(again, see the end of this thread)...

> for two
> reasons.  First, we don't have any empirical evidence about SYN data
> buffering, 
Agreed...

> and it does seem like something that can be probed for or
> annouced at a different layer of abstraction.
On a per-connection basis, yes. As a persistent endpoint property, no -
for the same reason as the fact that you can't use ENO state from past
connections.

>   Second, as things evolve,
> who's to say some future TEP won't have a better workaround for the
> problem?

RFC793, until this issue is locked down in a different way, IMO.
>
> As a compromise, how about making #2 a SHOULD, so as to minimize the
> chances of TEP accidentally messing this up without closing the door on
> intentional deviations?

#1 is a MUST unless you can guarantee that a given TCP stack will
automatically retry with different connection parameters (#2). Otherwise
you've made your TCP brittle by turning on ENO. I don't mind if you want
to shoot yourself in the foot that way, but I suspect few users of ENO
capability would want that.

(i.e., there's no room here for a SHOULD, unless you want to say "SHOULD
do #2 if the TCP stack implements automatic retry" -- however, you're
now hurting all connections that make the mistake of using ENO to a
legacy endpoint. That might be OK, if you think the hints you're using
are usually correct, though).

Joe