IETF Logo Mail Archive

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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Sun, 30 May 2021 11:00 UTC

Return-Path: <rs.ietf@gmx.at>
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 F13FA3A386C for <tcpm@ietfa.amsl.com>; Sun, 30 May 2021 04:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 p0JbSFEbMTyf for <tcpm@ietfa.amsl.com>; Sun, 30 May 2021 04:00:31 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3462A3A386A for <tcpm@ietf.org>; Sun, 30 May 2021 04:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622372427; bh=uKnOUX98g6ZEJXkWsZXVfpgmIhonIh0QxRyZYHtPddQ=; h=X-UI-Sender-Class:To:From:Subject:Date; b=JHziFFrdav0MfaTZcjeqwyHSaaX/T3YAnHY2fATiTCQOVDXV1yJDoNR8UQbVELy7y f4qiPhHZyv+D01+CtCv6Dyr4/xvk42+QZ/6qERm8GJrpd9P6KP0QFigqantVNSg8O1 QvToIwFN2K7Mu50/KprgAIqO399JgXigrXWtel+I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUZ4-1l4JKZ056q-00pqo8 for <tcpm@ietf.org>; Sun, 30 May 2021 13:00:27 +0200
To: "tcpm@ietf.org" <tcpm@ietf.org>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at>
Date: Sun, 30 May 2021 13:00:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:JGfRO6WPxf/pyXnPIdMfeDh99QDR7Jv8sQ+f+zNobuP2HIe5hzF SKqz+7hpXDbIuq2egj+wLGw5b3Sv4y+lzFV6k/xTX7/2+dwnH+HRFAT5tOaaZTPNQ3Eb7Zy TklqDSZeWNFAmctyGon1b4tts4qHLwFmSGelPxJRHaU4ek14NeUZDNEzsgj0ovXncRYbEcB 7WOsQX4MFtMm12O6coZkQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kIyxc+QIq6Q=:1Yh2OUoQGI7m4ray/9+vjb eB5p8hAnp1n7hEWEV2AO+NZVC8V43Eylk5UK1pfZ+J/QHpvth8krgd2HFsFECBPA/He5ep1zP h6rMWm5cwQueNaANo0ruGRVyCOwaWlqDPOFNux6uG8vZ8+3yjTrgONBYADqjWOJGqanLA0PRz Zf+2CxTAYQbCxoVOgO58IKTJEplv+jUqissaO+MLg+F5/Eq4Nh9HgXPkjrd1Ka6n+ErUiGJSI QbsSFArckXTHQvDkfFxYKDPw8OHVnSbLb+0bI3qYkGXviwmv1fT7IduawWrKgwWDijlUFQzuO lBUaPF/C1k6M1mH235tgR9Ul3o4PbndVqFx5oy1SpTIDE7XSsCiSxWpmZ8xfMpEQF/9ywLW/n Xh3Upa/knxbDf3tguAiUYVI5P89q5GNOqtCqH+sGxQ4Gv5BE6Ipsk4pIYqpC2PytMY0WSMkWI wwtsyFZ1vTv2+qsybdHSsXfwIZn3X/M/7HbTTOyGXU3grjBavhC1Au1UbbV5MOcTG0nnRqL9W HuYgfXNjRiyE7fJu8tKwoAbfKekWTmDDYlE4O/dCg8X5NYb6MqFBuzSlrYgxKLW5cInpGvw2Y DVQm9daAsE+fEIyiHqKT/4pwk2NCtiJCCykuX/4m7hWKb15L9Z81yLpO79eKjnhc1X84EGq6U 1Q+qBdrxJznUvGCxZp2qQLaTiqEKEhkoQ8cJAv7XFoe/LR4IHTwsLyccreCHr3MAz6DkK6cc9 SuFc9CRg+ULSdE03RZvDw41FnjCf05elK0GGWTwgWe1UxwlIUNNnnC8waZW90J+d8eAKwxS7C BgueoGvodUVwnc4VGx04l897HMW4ytL8shhzKAVzmp4X6B+4Xg9U2ZZSgg8pR+NAY9Ua45W3N rlEtumidDUNuZb9q+xZ07NitKh1TvPocPA9PoKt9l4LGLFKLe6oo4t+vaz4I6l6T4QsfQqOTV sYC16GDNANwzSohKtwdznOBgQlXUsbEGmNJjaWv1RlgiKnrSHxm7zsWsP9VCXZLQ3OBZcYRgr bs2f1CIMUdmc/d66rWpzgUf+EUBPUXAFlh8oWVnIISTBeRfZtbDe1GcMpC7HODcmM47C90u57 n8lk3bAvgm4WaGv9/rbDN9/HyoCKCyDQa1BDJFpkgs2pZYEs/qFZJ4Bu+9wYH3q23vyiBDZF1 tWP5lndgLV87MEcwsrRwIh2IvU5BfJA0dMReKgWgTDcx3ullb+Ns39qqjMyZAtLJ5eS4s=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/IAAAhY3WSm-py_DtlfNj8j8PPlM>
Subject: [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 11:00:34 -0000

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


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?

(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

v2.23.0 | Report a Bug | By Email