Hi David, This looks good, although I think this "SHOULD" requirement ought to be a "MUST":
> > 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. and I would clearly characterize the following as suggestions for future work: > > 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). This leaves specification of circumstances in which it's ok not to reset the connection to a future draft that explains why that's ok. Thanks, --David > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, August 05, 2016 5:16 PM > To: David Mazieres expires 2016-11-02 PDT; Black, David; tcpinc > Subject: Re: [tcpinc] TCP's treatment of data in SYN packets > > 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
