Re: [multipathtcp] q about on-path proxy

<> Wed, 22 March 2017 09:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21C3213162E for <>; Wed, 22 Mar 2017 02:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.395
X-Spam-Status: No, score=-5.395 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.796, 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 TOVpjT3fhazb for <>; Wed, 22 Mar 2017 02:40:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC5F2131605 for <>; Wed, 22 Mar 2017 02:40:33 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 558F8402A4; Wed, 22 Mar 2017 10:40:32 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by (ESMTP service) with ESMTP id 1E6BF12008A; Wed, 22 Mar 2017 10:40:32 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Wed, 22 Mar 2017 10:40:31 +0100
To: Yoshifumi Nishida <>, multipathtcp <>
Thread-Topic: [multipathtcp] q about on-path proxy
Thread-Index: AQHSoutDjy0a9GTR1U+84LKyZFSQtaGgldHw
Date: Wed, 22 Mar 2017 09:40:31 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E37563@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E37563OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] q about on-path proxy
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, 22 Mar 2017 09:40:36 -0000

Hi Yoshi,

Please see inline.


De : multipathtcp [] De la part de Yoshifumi Nishida
Envoyé : mercredi 22 mars 2017 10:04
À : multipathtcp
Objet : [multipathtcp] q about on-path proxy


I am trying to understand on-path proxy scenarios.
(BTW, I'm referring draft-nam-mptcp-deployment-considerations-01 and draft-boucadair-mptcp-plain-mode-10)

In case of on-path proxy (implicit mode),the dest of the primary subflow will be the receiver. It's not very clear to me how MCP intercepts the packets in this subflow.
[Med] In this mode, the MCP is placed on a default forwarding path. It will inspect TCP traffic it sees to determine the MPTCP one that needs to be proxied.

The draft says:

   Unlike the explicit mode, the implicit mode assumes that the MCP is
   located on a default forwarding path (primary path).  As such, the
   first subflow must always be placed over that primary path so that
   the MCP can intercept MPTCP flows.  Once intercepted, the MCP
   advertises its reachability information by means of MPTCP signals

The text does not specify which hook is used locally to inspect the traffic because this is implementation-specific.

The MCP splits the connection between two nodes and send forged packets to the sender?
[Med] Yes, the MCP splits the connection only if there is a MP_PREFER_PROXY signal received from the sender; forged packets are sent to the sender. draft-nam-mptcp-deployment-considerations also describes a deployment case where the MCP supports a configuration parameter to be removed from the connection if the destination is also MPTCP-capable. An example is shown in this figure:

   +----+                     +-----+                     +--+

   | H1 |                     | MCP |                     |RM|

   +----+                     +-----+                     +--+

   h1@h2@                       mcp@                       rm@

    | |                          |                          |

    | |src:h1             dst:rm@|src:h1             dst:rm@|

    | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>|

    | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===|

    | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>|

    | | __________________________________________________  |

    | |/            Secondary subflow                      \|

    | |=====================SYN+MP_JOIN====================>|

    | |<===================SYN/ACK(MPJOIN)==================|

    | |=====================ACK(MP_JOIN)===================>|

    | |                       ...                           |

Also, in the two proxy scenario, does the downstream MCP have to be on-path?
[Med] Yes, the same considerations apply for both case (single proxy, dual proxy).