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

[Joe Touch <[e-mail]>]

On 3/7/2017 10:12 PM, David Mazieres expires 2017-06-05 PDT wrote:
> Joe Touch <[e-mail]> writes:
>
>> 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.
> 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