Hi, David, This seems reasonable to me. Thanks for taking the time to work through this issue.
Joe On 8/4/2016 6:21 PM, David Mazieres wrote: > Okay, guys. Thanks for the feedback. Here's yet another attempt at > revamping the section. I made sure each SHOULD is followed by an > exception. Note I made one other change, which is to allow SYN-form ENO > options with no suboptions. Before that didn't make sense, but now it > does as a way of saying "I don't want to encrypt, but I threw away your > SYN data." > > Once we converge on this I will release yet another draft... > > Thanks, > 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 host sending a SYN+ENO segment MUST NOT include data in the segment > unless the SYN TEP's specification defines the use of such data. > Furthermore, to avoid conflicting interpretations of SYN data, a > SYN+ENO option MUST NOT include a non-empty TCP Fast Open (TFO) > option [RFC7413]. > > Because a host can send SYN data before knowing which if any TEP will > govern a connection, hosts implementing ENO are REQUIRED to discard > data from SYN+ENO segments when the SYN TEP does not govern the > connection or when there is any ambiguity over the meaning of the SYN > data. This requirement applies to hosts that implement ENO even when > ENO has been disabled by configuration. However, note that > discarding SYN data is already common practice [RFC4987] and the new > requirement applies only to segments with ENO options. > > More specifically, a host that implements ENO MUST discard the data > in a received SYN+ENO segment if any of the following applies: > > o ENO fails and TEP-indicated encryption is disabled for the > connection, > > 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. > > A host discarding SYN data in compliance with the above requirement > MUST NOT acknowledge the sequence number of the discarded data, but > rather MUST acknowledge other host's initial sequence number as if > the received SYN segment contained no data. Furthermore, after > discarding SYN data, such a host MUST NOT assume the SYN data will be > identically retransmitted, and MUST process data only from non-SYN > segments. > > If a host sends a SYN+ENO segment with data and receives > acknowledgment for the data, but the SYN TEP governing the data is > not the negotiated TEP (either because a different TEP was negotiated > or because ENO failed to negotiate encryption), then the host MUST > reset the TCP connection. Proceeding in any other fashion risks > misinterpreted SYN data. > > If a host sends a SYN-only SYN+ENO segment bearing data and > subsequently receives a SYN-ACK segment without an ENO option, that > host SHOULD reset the connection even if the SYN-ACK segment does not > acknowledge the SYN data. The issue is that unacknowledged data may > nonetheless have been cached by the receiver; later retransmissions > intended to supersede this unacknowledged data could fail to do so if > the receiver gives precedence to the cached original data. > Connection resets are potentially avoidable if SYN data caching is > empirically found not to occur, or in response to an API command (for > cases where a higher-layer integrity check would anyway terminate a > garbled connection). > > To avoid unexpected connection resets, ENO implementations MUST > disable the use of data in SYN-only segments by default. Such data > MAY be enabled by an API command. In particular, implementations MAY > provide a per-connection mandatory encryption mode that automatically > resets a connection if ENO fails, and MAY enable SYN data in this > mode. > > To satisfy the requirement of the previous paragraph, all TEPs SHOULD > support a normal mode of operation that avoids data in SYN-only > segments. An exception is TEPs intended to be disabled by default. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
