[multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing

François Finfe <francois.finfe@tessares.net> Wed, 13 September 2017 13:39 UTC

Return-Path: <francois.finfe@tessares.net>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71225133041 for <multipathtcp@ietfa.amsl.com>; Wed, 13 Sep 2017 06:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com
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 UlJ701nQsW9u for <multipathtcp@ietfa.amsl.com>; Wed, 13 Sep 2017 06:39:24 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEEE132D44 for <multipathtcp@ietf.org>; Wed, 13 Sep 2017 06:39:24 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id i189so7092303wmf.1 for <multipathtcp@ietf.org>; Wed, 13 Sep 2017 06:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=rqZpCkfC818TX1tWPCKT1MIiiwRBtdzvAhW+ovsVdc4=; b=1Lo2geIW0eWcRQc8Z4fhLjV3fNG/nCWez9MWXQCWySErMCnolAcD16ky1pNk69gF9c w9y7mqVrwXBF2ulaCVoBU+79BHxfSlTN5PqxL/8iMvE/P4a1r1nrylJXl778BMySlgW4 05lrgh0j78Filaay2YytR4iEcZ+mH2ZiZ2LJh9HnXDj7nWV7X+Dl97I4+FhdZLURZOdw sOZEk7BrP8s1LvGAikCKYK+Mkbjad+N0Tb+WnuFVaRpkF3W7PFzIfdIGvPvHY1k5l0wF /q1K2hUavNgrsrILKVChpamNsxQzvFCbmsyZkIx10Gds5905HuAh9aMi8tEwcgMOVKeh 2BHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=rqZpCkfC818TX1tWPCKT1MIiiwRBtdzvAhW+ovsVdc4=; b=TzZQfvIpgxZNrAL9ww+9uw+KY+c+J/LP61pKs2boFkzkws0CM/V/5JuZMFDuZM8Hz4 QmLLrla4uel8HtVe4+VxNxKpV3JVM+AhEUNqQkx9fkVBTSx9tMmfAvO11F9oF7g8lof6 F5nLVdc2UvuAbxoWqfCj6C/RWrhgpurpDwSYm+kDN0mfXQmn7JKHsv1hA5HO42NI4vPy Px8Bt4CBN3TXztY2cyLhnbSaqlJ0SdSAKWZwpIzinmSgDSyzbXIp7QmJ3dwwFTWL0nyL OaTQWVSYkJHBuwSj030qyXA3k7z1sTMdBFn511p5I2X/CWcQig2L51ThHsjDP+/bfr/0 d58w==
X-Gm-Message-State: AHPjjUjhCQiVPC5K4aqX1vih5Rm43TrE2sg5ckZEo/MkHSxe+Egxxf8j 1+H7kAv5w5SDxnd9B+2ZIPYRfZilWoadMxrJ8/8X48YVL2XAIh3/Gokbdrhutj4bw/DBuSTRKKA cPqxF
X-Google-Smtp-Source: ADKCNb5MYsMPGx31Q7IBHKFlULsmRyi6tgdfzDuqlKvO5j+8Bp0zohceoB35iw2mNKsOBEQ/cPps+Q==
X-Received: by 10.80.147.193 with SMTP id o59mr7063152eda.88.1505309962868; Wed, 13 Sep 2017 06:39:22 -0700 (PDT)
Received: from [192.168.2.2] ([87.66.241.164]) by smtp.gmail.com with ESMTPSA id r13sm6768299edk.40.2017.09.13.06.39.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 06:39:22 -0700 (PDT)
From: =?UTF-8?Q?Fran=c3=a7ois_Finfe?= <francois.finfe@tessares.net>
To: multipathtcp@ietf.org
Cc: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Message-ID: <b3968dc9-0500-5907-4e13-8aa350d12f11@tessares.net>
Date: Wed, 13 Sep 2017 15:39:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/XFlFywyHWUnwmpL8YsHSGsJHRFM>
Subject: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 13:39:27 -0000

Hi,


RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a
Multipath TCP connection. The motivation for the procedure defined in
section 3.5 is to enable a host to quickly terminate a Multipath TCP
connection without being forced to send DATA_FINs.

The current procedure defined in section 3.5 is that the host that
wishes to abruptly terminate a connection must send a RST on all
subflows except one where it sends an ACK with the FAST_CLOSE option and
waits for a RST before closing the Multipath TCP connection. The
FAST_CLOSE option includes the receiver’s key to authenticate the abrupt
release of the subflow. This prevents attacks where a remote attacker
could send spoofed packets that would terminate the Multipath TCP
connection.

Unfortunately, the procedure defined in section 3.5 has a very important
drawback. Although the host wants to abruptly close the Multipath TCP
connection, it needs to maintain state for this connection until the
other host has confirmed (with a RST) the termination of the connection.
This goes against the idea of abruptly closing connections due to lack
of ressources for example. We have faced some issues with applications
using SO_LINGER set to zero that were expecting the socket to have
disappeared after an abrupt release while it did not disappear.

It would make sense to reconsider the abrupt connection termination
procedure defined in section 3.5 to enable a host to immediately
terminate a Multipath TCP connection and release the associated data
structures. One possibility would be to work as follows.

Consider a Multipath TCP connection established between a client and a
server. There are two subflows, A and B. The server wants to abruptly
close the connection. For this, we propose to continue to use the
FAST_CLOSE option, but place it inside the RST packet sent over all
subflows. By using a RST instead of an ACK as in section 3.5, the server
does not need to maintain any state and can remove the data structures
associated with the closed connection immediately. If one of the RST
packets reaches the client, it will know that the entire connection has
been closed by the server.

The only issue with this new approach is when none of the RST packets
sent by the server reach the client. We would be in a situation where
the client considers that the Multipath TCP is active while it does not
exist anymore on the server. After some time, the client will send a
packet to the server over one of the subflows. Since the Multipath TCP
connection does not exist anymore on the server, it will reply with a
RST packet that will close this subflow. The client will receive the
same RST over all the established subflows. When all subflows have been
closed, the client should try to establish a new subflow to the server
by sending a SYN with MP_JOIN. Upon reception of this SYN, the server
will try to match the connection token with the established Multipath
TCP connection and will find that there is no matching connection.
According to RFC6824, the server should reply with a RST packet to close
the subflow. We could add to this RST packet a new MP_TCPRST option
indicating that the server could not match the received token with an
existing connection. Upon reception of a RST carrying this option, the
client would know that the corresponding connection has been closed by
the server and would close it itself.

We believe that this approach is simpler on the server side while still
allowing clients to detect closed Multipath TCP connections. The abrupt
closing (e.g. socket option SO_LINGER with zero timeout) is also
properly implemented. In contrast with the current approach, it places
the burden on the client instead of on the server, but we believe this
is beneficial for servers that often need to abruptly close connections.


François

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.