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

[[e-mail]]

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