Re: [tcpm] <SYN,FIN> in SYN-SENT (793bis)

[[e-mail]]

> On 30. May 2021, at 13:00, Scheffenegger, Richard <[e-mail]> wrote:
> 
> Hi,
> 
> I would like to gather some feedback around a recently observed
> modification in one TCP stack:
> 
> The 793(bis) TCP FSM does not have any direct state-transition from
> SYN-SENT to CLOSE-WAIT or FIN_WAIT_1, which would be the expected
> logical transition, if a <SYN,FIN> is received in that state.
> 
> Rather, the 793bis prescribes, that the FSM transitions only to
> SYN-RECEIVED (or ESTABLISHED), acking on the SYN-bit, but is silent on
> how to treat a FIN bit observed in this state...
Well, it states (and is therefore not silent):

Otherwise enter SYN-RECEIVED, form a SYN,ACK segment

  <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>

and send it.  Set the variables:

  SND.WND <- SEG.WND
  SND.WL1 <- SEG.SEQ
  SND.WL2 <- SEG.ACK

If there are other controls or text in the segment, queue
them for processing after the ESTABLISHED state has been
reached, return.

However, I think the queuing of the test is not needed. Since the SYN-ACK
does not acknowledge the FIN, I would expect the peer to finish the
three way handshake by sending a FIN ACK.

I guess the following should happen (expressed in a packetdrill script):

 0.00 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0.00 fcntl(3, F_GETFL) = 0x02 (flags O_RDWR)
+0.00 fcntl(3, F_SETFL, O_RDWR | O_NONBLOCK) = 0
+0.00 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], [4]) = 0
+0.00 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.00 > S  0:0(0)       win 65535 <mss 1460,nop,wscale 6,sackOK,TS val 100 ecr 0>
+0.00 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], [4]) = 0
+0.00 %{ assert tcpi_state == TCPI_SYN_SENT }%
+0.10 < SF 0:0(0)       win 32767 <mss 1460,sackOK,eol,eol>
+0.00 > S. 0:0(0) ack 1 win 65535 <mss 1460,sackOK,eol,eol>
+0.00 %{ assert tcpi_state == TCPI_SYN_RECEIVED }%
+0.00 < F. 1:1(0) ack 1 win 32767
+0.00 >  . 1:1(0) ack 2 win 65535
+0.00 %{ assert tcpi_state == TCPI_CLOSE_WAIT }%
+0.00 close(3) = 0
+0.00 > F. 1:1(0) ack 2 win 65535
+0.00 <  . 2:2(0) ack 2 win 32767


> 
> 
> Logically, the receipt of a <SYN,FIN> could be broken into the SYN
> processing (first) and FIN processing second.
> 
> Any thoughts if such an additional, explicit direct state transition /
> FIN processing in SYN-SENT should be added to 793bis?
This would mean that the endpoint in a synchronized state without
its SYN being ACKed. I don't think this is a good idea.

Best regards
Michael

> 
> (only ACKing the SYN bit should cause the other end to retransmit the
> FIN in a subsequent segment, ending in either of the two states
> mentioned above - depending if the ACK bit is set too).
> 
> Best regards,
>  Richard
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm