On 7/31/2016 11:10 PM, David Mazieres expires 2016-10-29 PDT wrote: > Oops, I failed to notice that you had in-line comments as well. Please > read this instead of the previous version. > > Sorry, > David > > > 4.7. Data in SYN segments > > TEPs MAY specify the use of data in SYN segments so as to reduce the > number of round trips required for connection setup. The meaning of > data in a SYN segment with an ENO option (a SYN+ENO segment) is > determined by the last TEP identifier in the ENO option, which we > term the segment's _SYN TEP_. > > A SYN+ENO segment MUST NOT include data unless the SYN TEP's > specification defines the use of such data. Furthermore, a SYN+ENO > option MUST NOT include a non-empty TCP Fast Open (TFO) option > [RFC7413]. > > A host implementing ENO, even if ENO has been disabled by > configuration, MUST discard the data in a received SYN+ENO segment if > any of the following applies: > > o Encryption is disabled for the connection,
You should be specific that this applies only to TEP-indicated encryption. There are other encryptions that do not involve ENO (e.g., TCP-AO-ENC). > o The received segment's SYN TEP is not the negotiated TEP, > > o The negotiated TEP does not define the use of SYN data, or > > o The SYN segment contains a non-empty TFO option or any other TCP > option implying a conflicting definition of SYN data. Again, this needs to be specific to TEP-protected associations. I doubt you want to (or should) disable TFO just for all connections at an ENO-capable endpoint even when ENO isn't intended for a give connection. > A host MUST NOT acknowledge the sequence number of any discarded SYN Again, "TEP-protected host"... > data, but rather MUST acknowledge the other host's initial sequence > number as if the received SYN segment contained no data. > Furthermore, a host MUST NOT assume discarded SYN data will be that host (or again "TEP-protected host") > identically retransmitted. If later non-SYN segments contain > different data for the same sequence numbers as SYN data, the host again "that host" or "TEP-protected host" > MUST process only data from non-SYN segments. > > If a host receives acknowledgment for data in a SYN+ENO segment but again "that host" or "TEP-protected host" > the SYN TEP governing that data is not the negotiated TEP (either > because a different TEP was negotiated, or because encryption is > disabled), then the host that sent the SYN+ENO segment MUST reset the again "that host" or "TEP-protected host" > TCP connection. Proceeding in any other fashion risks misinterpreted > SYN data. > > If a host sends data in a SYN-only SYN+ENO segment and subsequently again "that host" or "TEP-protected host" > receives a SYN-ACK segment without an ENO option, the host SHOULD again "that host" or "TEP-protected host", but would say MUST here because... > reset the connection even if the SYN-ACK segment does not acknowledge > the SYN data. The reason is that a host sending a SYN-ACK segment > without an ENO option does not necessarily follow the requirements of > this section, and in particular could buffer SYN data and later > process it instead of the contents of non-SYN segments with the same > sequence numbers. Barring empirical evidence against the existence > of such buffering, it is not safe to assume unacknowledged SYN data > has been discarded. The issue is that the data may have been cached but not ACKd, and the later resend of the changed SYN data might not overwrite the cached data, because TCP does not guarantee that overlapping segment data will overwrite old data. It might be useful to clarify that. > To avoid unexpected connection resets, TEPs SHOULD support a normal > mode of operation that does not make use of data in SYN-only > segments. Moreover, implementations SHOULD enable data in SYN-only > segments only if explicitly requested by the application This seems odd to me - IMO, you should refer to an API command that might result in SYN data, not to the application directly controlling this protocol event. That command might be "eager start" or something... > or in cases > where such use is unlikely to cause connection failure. > Implementations MAY provide a per-connection mandatory encryption > mode that automatically resets a connection if ENO fails. For TEPs > that support it, an implementation MAY default to using SYN data when > in mandatory encryption mode. at the expense of connection failure to endpoints whose TEP capabilities have changed. I.e., you now have a brittle TCP, and you should state that. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
