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

[David Mazieres <[e-mail]>]

Jeremy Harris <[e-mail]> writes:

> On 29/07/16 20:41, Kyle Rose wrote:
>> Right, I get that for interoperability with ENO-unaware stacks there is no
>> way to change data presented in the SYN. In the case where both ends
>> understand ENO but the server is not negotiating it, we can define TCP SYN
>> payload semantics differently: essentially, when there is an ENO option in
>> the SYN, an ENO-aware server will do one of two things:
> [...]
>> (2) If it is not negotiating ENO, it will not ACK the data, and will in
>> fact throw it away and explicitly permit transmission of *different* data
>> for the same sequence number range.
>
> I don't think so.  Whatever the client is, if the server is not showing
> support for different behaviour then the client must assume a standards
> TCP-implementing server, meaning that any data sent cannot be altered
> in a retransmission.  That applies whether or not the _initial_ ack for
> a SYN-with-data acks that data; even if it did not, a later one might.
>
> Unless you're dividing signalling of ENO-aware from ENO-negotiating?

No one is suggesting sending data in a SYN segment to a server that does
not support ENO.  In fact, no one is even suggesting sending data in a
SYN segment.  All we want is a minimum specification of what you do if
you receive such data, so that people can capitalize on it in the
future.  The proposal currently on the table is that you do whatever the
data TEP/negotiated TEP says, and if that TEP doesn't say anything, then
you discard the data and don't ACK it.  Moreover, we are saying that
even TEPs that support SYN data shouldn't send any unless requested to
do so by the application or unless they know it won't lead to connection
failure (through some future mechanism we don't currently anticipate).

The long-term plan here is to secure 100% of TCP traffic that isn't
secured by some other protocol such as TLS or SSH.  To get better than
opportunistic encryption, there needs to be logic in applications or
middleware to abort TCP connections that are not properly authenticated.
That logic may well want to permit SYN data, since it will scuttle a
non-ENO connection anyway.  Yes, this is very, very far in the future.
But if the TCPINC working group is successful, then the documents we are
working on today could be relevant in 10-20 years.  So without doing
anything to break TCP today, we want to ease the path to a more secure
Internet without trying to predict the future.  And mandating no
buffering of discarded SYN data is a good way to do that...

Incidentally, this discussion makes me think we need a section of the
non-normative rationale section on SYN data as well...

David