Re: [multipathtcp] rfc6824bis - RST after MP_FASTCLOSE retransmission

Christoph Paasch <cpaasch@apple.com> Wed, 24 May 2017 05:05 UTC

Return-Path: <cpaasch@apple.com>
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 6C92812778D for <multipathtcp@ietfa.amsl.com>; Tue, 23 May 2017 22:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level:
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 m8fPKRhzbbqe for <multipathtcp@ietfa.amsl.com>; Tue, 23 May 2017 22:05:27 -0700 (PDT)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 AE213126B72 for <multipathtcp@ietf.org>; Tue, 23 May 2017 22:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1495602327; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=txOMoWqHCUZSrYyJXyN0VeToCI3e8YqHZ7xXCTYYPF4=; b=IwUVIzIsU3NE6FVViHw1LbD5rhprdymWKDAOa+WTSv10qHnbWdwDYUjM0WFZQcuI 8e8EvV+/lyQg3mxSNwLapWN+ya0o3sWB5NjOs2tgeG0fxWIxv4fZuF7f2afvBlvH Oog5UISHxFoBRR/3SHjP5+UBKHTiRTg1RQrV1jfVJVjlv6tp2epeOaie6+xRfZd3 I2tR2cleM0U16uB8KDgJ+R3ObIPueQSYj7kYeeuUZVVkM/V/I2qX9Gi5eWstikz4 ofE970WCWqdnXDVzuPkLq/jh5DP68uxbPYaCVHopVWWF1YGPZPjbmeZ1PuAgQGfb 7lOaHlfMZISQ9beTHiPIMA==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A3.96.01595.79415295; Tue, 23 May 2017 22:05:27 -0700 (PDT)
X-AuditID: 11973e13-caa429a00000063b-36-592514975f15
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay3.apple.com (Apple SCV relay) with SMTP id B8.02.15148.79415295; Tue, 23 May 2017 22:05:27 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=iso-8859-1
Received: from localhost ([17.149.229.108]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQF00GIHY53H820@nwk-mmpp-sz09.apple.com>; Tue, 23 May 2017 22:05:27 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Tue, 23 May 2017 22:05:27 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: =?iso-8859-1?Q?Fran=E7ois?= Finfe <francois.finfe@tessares.net>
Cc: multipathtcp@ietf.org
Message-id: <20170524050527.GH5506@da0602a-dhcp165.apple.com>
References: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net>
In-reply-to: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYrDtdRDXSYMZRZYutEzYxWXxefZ3N gcljyZKfTB53mqYzBzBFcdmkpOZklqUW6dslcGU0L7jKWnDUoOLN03vMDYxPZboYOTkkBEwk rk/tZeli5OIQEljNJNG6bgkjTOLIxtnsEImDjBKvV/SygiR4BQQlfky+B9TBwcEsIC9x5FI2 SJhZQFri0d8Z7BC2jkTv92/MEL1NTBJnl+0FGyosICnRfecOM0gvi4CqRMtyL5Awm4CWxNvb 7WDjRQScJdYsfs8KMUdSYsXfT6wQrX4Sm2YegTrBVmLd+t1gtpCAvcTVjt9gezkFHCQO3JwO ZosKKEv8PXwP7DEJgS1sEj1bG5gmMIrMQvLCLIQXZiF5YRaSFxYwsqxiFMpNzMzRzcwz1Uss KMhJ1UvOz93ECIqE6XbCOxhPr7I6xCjAwajEw5vgoBIpxJpYVlyZe4hRmoNFSZy3Mh4oJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgVHsq9f0b5d22oV4WdUn7T28YuOJxZFn2Hee6C7QOSPL Wth/w7j6YfK1tx8rlx72cf+5zi4jc7Hv77Q7FQ8s4u58CTPXldrNeGX+QqsHnhtaz+xomvR6 W+reSo8j8/rEKvdJvUrf+eLxq+mePpuu3D5tKq+YNEk15+MWt6C01NOabmL5cd0zNuxUYinO SDTUYi4qTgQAYXR6FWUCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUi2FAcoDtdRDXSYMIMaYutEzYxWXxefZ3N gcljyZKfTB53mqYzBzBFcdmkpOZklqUW6dslcGU0L7jKWnDUoOLN03vMDYxPZboYOTkkBEwk jmyczd7FyMUhJHCQUeL1il5WkASvgKDEj8n3WLoYOTiYBeQljlzKBgkzC0hLPPo7gx3C1pHo /f6NGaK3iUni7LK9jCAJYQFJie47d5hBelkEVCValnuBhNkEtCTe3m4HGy8i4CyxZvF7Vog5 khIr/n5ihWj1k9g08wjUCbYS69bvBrOFBOwlrnb8BtvLKeAgceDmdDBbVEBZ4u/heywTGAVn Ibl6FsLVs5BcPQvJ1QsYWVYxChSl5iRWGuslFhTkpOol5+duYgQHbmHwDsY/y6wOMQpwMCrx 8CY4qEQKsSaWFVfmHmKU4GBWEuE9JqQaKcSbklhZlVqUH19UmpNafIixCujdicxSosn5wKjK K4k3NDExMDE2NjM2Njcxp4qwkjhvRgLQMQLpiSWp2ampBalFMMuZODilGhib3TLY8vN5TS4a nnfMFpzfM6v09KuiqbNWtaiu27ZjhfW7c/F2Olf3bRLL8ZuyufeC8TYnX4PGLfossde1i4Qi 3ao93Zw5bs6LVeQ1ypI5nOckYuy+d7t0RNJ3o72qRybX6UxpDBYsO3Rf1O/aWZeH9lZlZZP0 Kt69q//ClD8lc+FikY26D5RYijMSDbWYi4oTAWG8U6a3AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/-uTxk3MrX6yrVuSveKIanCUQ_Cw>
Subject: Re: [multipathtcp] rfc6824bis - RST after MP_FASTCLOSE retransmission
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, 24 May 2017 05:05:29 -0000

Hello Francois,

On 23/05/17 - 10:55:32, François Finfe wrote:
> Hello,
> 
> I encountered an issue with MP_FASTCLOSE and a stateful firewall.
> 
> Let's explain it with the following scenario. See figure 1.
> Firewalls M and N are stateful firewall which don't analyse MPTCP
> options and ignore them.
> 
> - An MPTCP connection has been established between host A and host B.
> - Host A sends a ACK with the MP_FASTCLOSE option.
> - Firewall M forwards the packet to host firewall N.
> - Firewall N forwards the packet to host B.
> - Host B receives the MP_FASTCLOSE and replies with a TCP RST.
> - Firewall N forwards the TCP RST packet to firewall M.
>   Due to the TCP RST, the stateful firewall removes the connection
>   state.
> - The TCP RST is lost due to a lossy link, network congestion, etc.
> 
> - As host A didn't receive the expected TCP RST packet, a timeout fires
>   a MP_FASTCLOSE retransmission.
> - Firewall M forwards the packet to firewall N.
> - For firewall N, this connection no more exists. It sees the
>   MP_FASTCLOSE as an TCP ACK packet without any related connection.
>   Firewall N drops the packet.
> - MP_FASTCLOSE are retransmitted until the limit of MP_FASTCLOSE
>   retransmission is reached.
> - If nothing is done, firewall M will retain the connection state for
>   some time until a connection tracking timeout occurs.
>   In a production environment, with a lot of simultaneous connection,
>   this kind of entries (erroneous connection state for an already closed
>   connection) can accumulate in the firewall.
>   Due to ressources limitation, this might lead to performance issue
>   where new connections might be rejected.
> 
> 
> To mitigate this issue, here is a proposal for rfc6824bis:
> - When the limit of MP_FASTCLOSE retransmission is reached, a TCP RST
>   could be sent by host A.
> - In this scenario, firewall M forwards the TCP RST packet and removes
>   the connection state.
> 
> This TCP RST packet could contain the MP_FASTCLOSE option.

wouldn't this exact same scenario happen with regular TCP as well?

For example, host A is sending data while host B at one point decides to
drop the connection with a TCP RST. This TCP RST gets lost between firewall
N and M. A will keep on retransmitting its data until it gives up and
signals an ETIMEDOUT to the application upon which the socket gets silently
closed.

If we deem the problem severe enough in MPTCP to address it for the
MP_FASTCLOSE scenario, then I think it should in general be considered for
TCP that when a connection times out it must be closed with a TCP RST.


Christoph

> 
> 
> 
>   Host A                                                          Host B
>    |                 Firewall M             Firewall N                |
>    |                      |                      |                    |
>    |  ACK(MP_FASTCLOSE)   |  ACK(MP_FASTCLOSE)   | ACK(MP_FASTCLOSE)  |
>    |--------------------->|--------------------->|------------------->|
>    |                      |             TCP RST  | TCP RST            |
>    |                      |           x----------|<-------------------|
>    |                      |                      |                    |
>    |                      |                      |                    |
>    |                      |                      |                    |
>    |  ACK(MP_FASTCLOSE)   |  ACK(MP_FASTCLOSE)   |                    |
>    |--------------------->|--------------------->x                    |
>    |                      |                      |                    |
>    |                      |                      |                    |
>    |  ACK(MP_FASTCLOSE)   |  ACK(MP_FASTCLOSE)   |                    |
>    |--------------------->|--------------------->x                    |
>    |                      |                      |                    |
>    :                      :                      :                    :
>    :                                                                  :
>    :  Multiple MP_FASTCLOSE retransmissions until limit is reached    :
>    :                                                                  :
>    :                      :                      :                    :
>    :                      :                      :                    :
>    :                      :                      :                    :
>    |  Last retransmission |                      |                    |
>    |                      |                      |                    |
>    |  ACK(MP_FASTCLOSE)   |  ACK(MP_FASTCLOSE)   |                    |
>    |--------------------->|--------------------->x                    |
>    |                      |                      |                    |
>    | (timeout)            |                      |                    |
>    |  RST(MP_FASTCLOSE)   |  RST(MP_FASTCLOSE)   |                    |
>    |--------------------->|--------------------->x                    |
>    |                      |                      |                    |
> 
>    Figure 1
> 
> 
> Best regards,
> 
> 
> François Finfe
> 
> -- 
> 
> ------------------------------
> 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.
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp