Re: [multipathtcp] q about on-path proxy

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 22 March 2017 09:35 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 8F8221296B0 for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 02:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 bstRYUouuBbm for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 02:35:22 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5161296B4 for <multipathtcp@ietf.org>; Wed, 22 Mar 2017 02:35:21 -0700 (PDT)
Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ED8F867DDDF; Wed, 22 Mar 2017 10:35:06 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be ED8F867DDDF
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1490175307; bh=LH0GpogqnnV42FKC+4xkwQlA2r7l5Vdc8wFRSPGxVbU=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=ATVhaPcJj7/0CdS2zGK6PNXlgjhx0/LQ4FtZbSQAnc2o6FsgVMcYW5nFtAQXyXU9x Ql87pAkQ5pLRQ66oWQfcw/MNyr7aCDxJ5UcmknXbaSOaI7hgqIFKFhgkzCo6ewNmw4 w7XJgt1VLdpIACVhG7XIxM9zccCzXNZETfJEtg4o=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5
Reply-To: Olivier.Bonaventure@uclouvain.be
References: <CAO249ydsuoAUn0y6yo62OM8mdp_AfyS1cA+patgQ84ata5piXw@mail.gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <a5ae92e4-c0c9-96c6-a575-f23891189087@uclouvain.be>
Date: Wed, 22 Mar 2017 10:35:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAO249ydsuoAUn0y6yo62OM8mdp_AfyS1cA+patgQ84ata5piXw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: ED8F867DDDF.A5CF5
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/u82u2KATnyZDMp1C539WVxL0eKA>
Subject: Re: [multipathtcp] q about on-path proxy
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, 22 Mar 2017 09:35:24 -0000

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


There are several techniques that can be deployed by operators to ensure 
that the transparent MCP is on-path for the initial subflow. All these 
techniques operate in the network layer or below and are thus 
transparent for TCP. Let me give an example based on source routing that 
does not match an actual deployment but would illustrate the main 
principle. With source routing, one can add inside the IP header a loose 
hop.


        +------- R4 ---- R5 --------+
C --- uMCP ---- R1 ---- R2 ------ dMCP ---- R6 --- R7 --- S

Consider a TCP connection created by client C towards server S. The uMCP 
is the first hop router for C. It intercepts the connection and 
transparently terminates it, acting as S. It then initiates a Multipath 
TCP connection towards S, acting as C. The packets for this connection 
are sent as IP packet that contain the IP address of the downstream MCP 
as a loose source routing hop. The dMCP removes the source routing 
option, transparently terminates the Multipath TCP connection and then 
initiates a connection towards S, acting as C.

Three connections exist to transfer data from C et S and vice-versa.

C<->uMCP  (source address C, destination address S)
uMCP<->dMCP (source address C, destination address S, using source 
routing to ensure that all downstream packets pass through dMCP, for 
upstream packets, source routing is usually not required because there 
is only one path to the uMCP that advertises C to R1 only )
dMCP<-> S (source address C, destination address S)

For the Multipath TCP connection between uMCP and dMCP, the second 
subflow is used without relying on source routing. The uMCP and the dMCP 
have addresses on the R4/R5 network and use the ADD_ADDR option to 
advertise those addresses and create the required subflows.

> The MCP splits the connection between two nodes and send forged packets
> to the sender?

Yes

> Also, in the two proxy scenario, does the downstream MCP have to be
> on-path?

If the downstream MCP is on path, then it does not have to include any 
NAT function which is beneficial from an operational viewpoint.


Olivier