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
- [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy Olivier Bonaventure
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy mohamed.boucadair
- Re: [multipathtcp] q about on-path proxy philip.eardley
- Re: [multipathtcp] q about on-path proxy Yoshifumi Nishida
- Re: [multipathtcp] q about on-path proxy Henderickx, Wim (Nokia - BE/Antwerp)