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

tuexen@fh-muenster.de Sun, 30 May 2021 13:45 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B3B3A3CE9 for <tcpm@ietfa.amsl.com>; Sun, 30 May 2021 06:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level:
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAHbiRh0v1AL for <tcpm@ietfa.amsl.com>; Sun, 30 May 2021 06:45:50 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566263A3CE8 for <tcpm@ietf.org>; Sun, 30 May 2021 06:45:49 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:b56c:3c9:75d0:af31]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8DEDE7220BFAB; Sun, 30 May 2021 15:45:44 +0200 (CEST)
From: tuexen@fh-muenster.de
Message-Id: <F96CC7BF-7E5C-4FFE-8877-CEACCC798221@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_C145E47D-998F-40B4-8F1E-E5BB452950B5"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Sun, 30 May 2021 15:45:44 +0200
In-Reply-To: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
To: "Scheffenegger, Richard" <rs.ietf@gmx.at>
References: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_YOyvtNc9punldtF86G-G6AvMvY>
Subject: Re: [tcpm] <SYN,FIN> in SYN-SENT (793bis)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 May 2021 13:45:55 -0000

> On 30. May 2021, at 13:00, Scheffenegger, Richard <rs.ietf@gmx.at> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm