Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

[Joe Touch <[e-mail]>]

On 3/7/2017 9:45 PM, [e-mail] wrote:
> Wesley Eddy <[e-mail]> 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.

>    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.

Joe