Re: [tcpinc] TCP-ENO draft 04 posted

[David Mazieres <[e-mail]>]

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

>>   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?  I'm not saying TCP-ENO should
advocate incorrect behavior, 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).
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.

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

> 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,
but my preference would be to leave it up to the individual TEP, for two
reasons.  First, we don't have any empirical evidence about SYN data
buffering, and it does seem like something that can be probed for or
annouced at a different layer of abstraction.  Second, as things evolve,
who's to say some future TEP won't have a better workaround for the
problem?

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?

David