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

Joe Touch <> Wed, 26 April 2017 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 466DE13185B for <>; Tue, 25 Apr 2017 23:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g5zJuRoY29kZ for <>; Tue, 25 Apr 2017 23:38:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0968013185D for <>; Tue, 25 Apr 2017 23:38:49 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v3Q6bfdJ001787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Apr 2017 23:37:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-CBACD639-45A1-4252-9CDE-1E78D1279E35"
Mime-Version: 1.0 (1.0)
From: Joe Touch <>
X-Mailer: iPad Mail (14E304)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5390A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Tue, 25 Apr 2017 23:37:40 -0700
Cc: "" <>, "" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
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>
X-ISI-4-43-8-MailScanner: Found to be clean
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 06:38:51 -0000

> On Apr 25, 2017, at 11:11 PM, <> <> wrote:
> Hi Touch, 
> Please see inline. 
> Cheers,
> Med
>> -----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:
>>> Re-,
>>> 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.

> 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, or are you confusing it with this, which adds split TCP to a SOCKS proxy:

>> The same is true when you try to reinvent ways to interpret SYN data
>> before the MPTCP 3WHS completes - reinventing TFO without TFO's
>> protections.
> [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? 

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