On 3/7/2017 10:12 PM, David Mazieres expires 2017-06-05 PDT wrote: > Joe Touch <to...@isi.edu> writes: > >> On 3/7/2017 9:45 PM, dm-list-tcpcr...@scs.stanford.edu wrote: >>> Wesley Eddy <w...@mti-systems.com> writes: >>> >>>>> 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 MUST reset the connection even if the SYN-ACK segment >>>>> does not acknowledge the SYN data... >>>> Saying "reset the connection" is interesting to me, because technically >>>> there is not yet any connection (there are TCBs at each side, but >>>> neither has entered ESTABLISHED state). The reset that's sent should >>>> probably *not* acknowledge any data that may have been on the SYN-ACK, >>>> which seems important to state. That way, if some application's >>>> transaction erroneously started due to data on the SYN, any response >>>> piggybacking the SYN-ACK would not be acknowledged, and the RST should >>>> cause the application transaction to fail. >>> I'm trying to tie up loose ends here, and think this is the only >>> relevant point from the mailing list that we may have not yet have >>> satisfactorily addressed in our working draft. Several points in >>> section 4.7 use the term "reset the connection." I've now attempted to >>> define the term more pedantically the first time I use it. Here's the >>> new language: >>> >>> 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 >> FWIW, I would just jump right to the following, which avoids giving >> unnecessary detail: >> >> abort the connection. Proceeding in any other fashion risks >> misinterpreted SYN data. > Thanks, that's how we had it before (well, "reset the connection" was > what we had before). But Wesley made me worry that the phrase "reset > the connection" might not be specific enough. Is "abort" better than > "reset"? Per RFC793:
Abort is an event that the TCP API implements (and can be called by users, the OS, etc.). Reset is a message that TCP issues/receives, and happens within the protocol in reaction to message receipt, timer expiration, or API events. This is why "reset the connection" is imprecise, whereas "abort the connection" is not. ;-) >>> reset the TCP connection by transitioning to TCP's CLOSED state and >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> responding to the acknowledgment with a reset segment as if the >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> connection had never existed. Proceeding in any other fashion risks >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> misinterpreted SYN data. >> If you do say which state to end up in, I would think you would want to >> transition to TIME-WAIT, otherwise the connection could reopen using the >> same socket pair and you may have a hazard condition. >> >> See: T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its >> Effect on Busy Servers <http://www.isi.edu/touch/pubs/infocomm99/>,” in >> /Proc. IEEE Infocom/, 1999, pp. 1573-1583. > Right, this is exactly why I'm worried about getting too specific. What > I want to say is something like "abort the connection" with an implicit > reference to best current practice. If most people think "abort the > connection" or "reset the connection" is unambiguous, then I'll go with > that. > > Is there a reason you said "abort" rather than "reset"? I was thinking > reset might be better because of reset generation, but would defer to > you on which word is better. There is. See above. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
