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

<> Fri, 21 April 2017 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C8341294A3 for <>; Fri, 21 Apr 2017 05:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9_kpl6NWDpUi for <>; Fri, 21 Apr 2017 05:27:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E044112949D for <>; Fri, 21 Apr 2017 05:27:53 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) by (ESMTP service) with ESMTP id 589DA2043D; Fri, 21 Apr 2017 14:27:52 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by (ESMTP service) with ESMTP id 2277C1A0064; Fri, 21 Apr 2017 14:27:52 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 14:27:51 +0200
To: Joe Touch <>, Yoshifumi Nishida <>
CC: multipathtcp <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSufr4FYN3Pf6Ey0Kw29UUSw2QvaHPsxBg
Date: Fri, 21 Apr 2017 12:27:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5204E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.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_787AE7BB302AE849A7480A190F8B933009E5204EOPEXCLILMA3corp_"
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: Fri, 21 Apr 2017 12:27:56 -0000


Please see inline.


De : Joe Touch []
Envoyé : jeudi 20 avril 2017 19:25
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work


On 4/19/2017 10:50 PM,<> wrote:
Hi Joe,

I don’t understand your comments here:

·         The use of a 32-bit magic number is meant to distinguish application-supplied data from the one inserted by the proxy. There are other fields in the MP_CONVERT information element that help in that aim too (validation of the TLV, M-bit, for example).

·         Both entities that supply and process the data are under the control of the same operator.

·         The network-located proxy is explicitly configured on the CPE. The destination IP address of the packet is an address of that proxy, not the address of a legacy node.

·         The proxy must echo supplied data in a SYN/ACK. If a mismatch is detected by the CPE, that proxy WON’t be used for subsequent connections till a new proxy is configured, TTL expires, etc.

To sum:

·         We are acting on one single SYN of an MPTCP connection.

·         If a mismatch is detected for one single SYN of a given connection, all subsequent connections (with any remote server) won’t be relayed to that proxy.

How is this “hazardous”?

TCPM archives are full of discussions on why TFO only works for subsequent connections to the same endpoint, due to cached cookies that allow the SYN data to be safely interpreted *before* the end of the 3WHS.
[Med] if having a “cookie” is the guarantee to “allow the SYN data to be safely interpreted *before* the end of the 3WHS”, I’d like to confirm that are conforming to that rationale:

·         TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. In our case, all MPTCP connections that include MP_CONVERT are always between the same nodes. The proxy relies upon other means to authenticate/authorize a CPE. Please refer to slide 29 of

·         TFO server-supplied cookies are used to prevent SYNs with spoofed IP addresses attacks: Spoofed IP addresses is not a problem in a provider network because anti-spoofing filters are in place (at access nodes, typically).

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

·         Last, the use of TFO cookies is not 100% safe. SYN flooding with valid cookies is still a valid threat.

MPTCP archives are full of discussions on why the data plane is not a good place to put option information.
[Med] Hmm, EDO does already that. But…more important:

·         we are not putting option information in the payload.

·         I guess you are referring to the reliable delivery of the extended option space in a SYN. This would be a valid point if we are sending data to ANY host on the Internet but we are not doing that. We are supplying data to ONE single node that is configured explicitly to a host/CPE. The provider, who configures that proxy to a host/CPE by means of DHCP, ensures that proxy complies with the specification. As a guard, the solution supports a mechanism to detect misbehaving proxies.

It's not practical to repeat those arguments in one email. The point is that you're reinventing the wheel in ways that this group and other groups already know are hazardous.
[Med] I don’t think there is a precedent of the 0-RTT proxying work. I don’t see what we are reinventing here.  I still don’t see what is “hazardous” here.


Thank you.


De : Joe Touch []
Envoyé : mercredi 19 avril 2017 20:12
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/18/2017 10:46 PM,<> wrote:
Using the SYN data as control information is the hazardous part.
[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.

The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics.

Putting data in the SYN of TFO is permitted only because of previous state.

MPTCP doesn't have that state and so it is hazardous to put data in the SYN.

I.e., if you want TFO-like performance, figure out how to use TFO. Period.