Jeremy Harris <[email protected]> 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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
