Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<> Wed, 26 April 2017 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A2AB126BF6 for <>; Wed, 26 Apr 2017 00:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H5myISHbk3cU for <>; Wed, 26 Apr 2017 00:11:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58FDA131948 for <>; Wed, 26 Apr 2017 00:11:32 -0700 (PDT)
Received: from (unknown [xx.xx.xx.68]) by (ESMTP service) with ESMTP id E509A20255; Wed, 26 Apr 2017 09:11:30 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by (ESMTP service) with ESMTP id 89B254006B; Wed, 26 Apr 2017 09:11:30 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 09:11:30 +0200
To: Joe Touch <>
CC: "" <>, "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSvleZFYN3Pf6Ey0Kw29UUSw2QvaHXM+ww
Date: Wed, 26 Apr 2017 07:11:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corpo! rate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E539A3OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2017 07:11:38 -0000

Hi Joe,

Please see inline.


De : Joe Touch []
Envoyé : mercredi 26 avril 2017 08:38
Cc :;
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On Apr 25, 2017, at 11:11 PM, <<>> <<>> wrote:
Hi Touch,

Please see inline.


-----Message d'origine-----
De : Joe Touch []
Envoyé : lundi 24 avril 2017 17:23
Cc :<>;<>
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/24/2017 8:03 AM,<> wrote:

Do you consider a NAT implementation as part of your first category or
the second one?
A NAT is part of the second one. You'll notice that there are no
IETF-endorsed NAT solutions

[Med] I disagree, Joe. The IETF published "Standards Track" documents about NAT TCP state machines:,, and many other RFCs about NAT TCP behavior itself (RFC5382) or RFC6888. All these RFCs are implemented and deployed in real networks.
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.
[Med] NAT64 (RFC6146) is not a patch AFAIK.

The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

Can you clarify where you see split TCP in RFC1928,
[Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see “split TCP” in the plain-mode draft.

I though you are making the same analysis, you have done for the MPTCP proxy, for SOCKS too: i.e., mix implementations-specific design choices with the base specification itself. FWIW, the typical exchanges that are observed when MPTCP is used with a SOCKS implementation is as follows:

(MP Client) ->    TCP SYN    ->  (MCP)
                   <- TCP SYN/ACK <-
                   ->    TCP ACK    ->
                   -> SOCKS Method Request ->
                   <-    TCP ACK   <-
                    <- SOCKS Method Response  <-
                    ->   TCP ACK   ->
                    -> SOCKS Authentication Request ->
                    <-    TCP ACK     <-
                    <- SOCKS Auth. Response <-
                    ->   TCP ACK   ->
                    -> SOCKS Connection Request  -> (MCP)
                    <-   TCP ACK                   <- (MCP)
                                                      (MCP)  -> TCP SYN  -> (Server)
                                                      (MCP)  <- SYN/ACK  <- (Server)
                    <- SOCKS Connection Response   <-(MCP) -> TCP ACK -> (Server)
                    ->   TCP ACK  ->

or are you confusing it with this, which adds split TCP to a SOCKS proxy:

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.

The same is true when you try to reinvent ways to interpret SYN data
before the MPTCP 3WHS completes - reinventing TFO without TFO's

[Med] I don't accept this argument. The only protection in TFO is a server-supplied "cookie". The proxy work has sufficient protections to interpret data inserted in a SYN in a safe manner.

- TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. We support a variety of authentication/authorization methods; Please refer to slide 29 of

Can you confirm that your approach has the same level of protection as TFO cookies?
[Med] Yes, I confirm.

- TFO specification acknowledges the following: “COOKIES ARE NOT NECESSARY if the server has application-level protection or is immune to these attacks” (cookie-less Fast Open) and “the server may choose to generate a TRIVIAL or even a ZERO-LENGTH COOKIE to improve performance by avoiding the cookie generation and verification”. Cached cookies are not required to supply data in 3WHS if the server if protection is in place. This is the case for the MPTCP proxy target case.
Please explain your application level protection or why you think this approach is immune to cookieless attacks. Or are you just embracing the result of those attacks as valid?

- TFO server-supplied cookies are used to prevent SYNs with spoofed IP addresses attacks: Providers' networks are enabled with anti-spoofing filters.

In order to avoid any confusion: the data we are talking about is not user/application supplied data but a proxy-supplied data that won't never reach the ultimate destination. We are not cloning TFO functionality.

That might actually be OK.