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

From: [email-masked]
Date: Tue, 07 Mar 2017 21:45:37 -0800

Wesley Eddy <[email-masked]> 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
   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.

I would ideally like to use RFC793 as much as possible as a
"subroutine," because your suggestion of specifying exactly what must be
in the RST segment risks contradicting RFC793.  Hence, my idea that you
can transition to CLOSED and pretend you were closed when you got the
segment.  By maybe I should say "CLOSED or LISTEN" (in keeping with
RFC793), or maybe this is a bad idea for some other reason, so I'd
appreciate some feedback from the list on how best to do this.  Any
feedback helps, but specific wording suggestions are even better...

Thanks,
David

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 21:52:05 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 22:23:29 -0800

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 Mar 2017 08:29:44 -0800

FWIW, you might add "and not attempt to open the connection with
different parameters (e.g., the same socket pair with ENO off, a
different socket pair with ENO off)."

The former is not safe and the latter changes the semantics of the TCP
API incorrectly.

Joe

On 3/7/2017 10:38 PM, David Mazieres expires 2017-06-05 PDT wrote:
> Perfect, that's exactly what I needed.  Thank you.
>
> David