Re: [multipathtcp] towards a potential work item on two-ended proxy

Alan Ford <> Wed, 03 August 2016 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F85812D985 for <>; Wed, 3 Aug 2016 00:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iJGl4dVNNdHN for <>; Wed, 3 Aug 2016 00:20:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F06F12D504 for <>; Wed, 3 Aug 2016 00:20:43 -0700 (PDT)
Received: by with SMTP id q128so436256369wma.1 for <>; Wed, 03 Aug 2016 00:20:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8UlG9U4K8Fptvsv8t+wXdefaQ+pmxaAzmtICLKAiJ0s=; b=FXK/jmuiFmxDSlyWjz4BHlqsviR9IhuYgh3Ua3m0aMtLcS0ch0Ss+GCl+PWU4l1nh5 qlf2zBv+RbpFfxRKK7M2Clf/EAhjqRNAG/LVgOg/TP9ij6hdk+ofnT/XYJtV2eEuzbk+ lOEOmEPKeCrAxUE+oi8zVKoNRHrNzvtA/o1hwm9UlWf+/+au4rA69BjoR+Z79rwYe446 ZofByOEengxKlusnfEZkLaTuSEtb9HS7wYh0Ul1HsXKoQPierxZN6EA/VuBGehrHbtnx iMp0XaoBBrobAqap0s9gBCfIAhdcsBYfWAPECH12vZX/S8ajA0ZSTF8qEO5UYC3xSide C+yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8UlG9U4K8Fptvsv8t+wXdefaQ+pmxaAzmtICLKAiJ0s=; b=mCb2/sgFUOIkhn5OJ6RBoRg0tsVgTKYQsMgMiCJynp44taYpYn2fd9bLdE6F31HIfU aTsJWwl92HUv3UO2z6y6WPakBaZDaI/eEzuzASCFB/+3dE2PsTDAV34diWOkt3xhv0l2 ZDyHzlfBK8GxaFmh6vSXfIpwJRNfUJkVwPpo3IFWnavgph01jZ6BWoNYKIfNeIPJ38zw Izhrc54JnqES4LnSi1DaoXMhA7kdsyqgob3WDKuSpj1+DwpUx+xGgRWXFQ2pygt0Xvj9 O2mtwLNZRsTxRUsMi9TmtDzu2V5f+VR4vEHewIz/mEAGTCF+2U7WRZSVMd5Qs64M+fT1 QLog==
X-Gm-Message-State: AEkoouscDtzxSKoOysYhHiuZ2UbtyfZt2gMe3xFBFLA/swTt/xZAK23YufrwQJfmRbwA2w==
X-Received: by with SMTP id tz17mr67271012wjb.64.1470208841771; Wed, 03 Aug 2016 00:20:41 -0700 (PDT)
Received: from alans-mbp.lan ( []) by with ESMTPSA id b186sm6572374wmg.23.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Aug 2016 00:20:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2A38FF38-5C73-4A1C-AB53-4EBC4639E71F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Wed, 3 Aug 2016 08:20:26 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: "Henderickx, Wim (Nokia - BE)" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Aug 2016 07:20:45 -0000

Hi Wim, all,

Comment inline...

> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <> wrote:
> On 02/08/16 15:52, "Alan Ford" < <>> wrote:
>> I’m trying to distinguish the various use cases; can we confirm this is correct?
>> Transparent Mode
>> - Source address = real source address
> WH> not always since NAT can be in the path
>> - Destination address = real destination address
>> - Transparent proxies create MPTCP functionality in the stream, adding and removing the MPTCP headers, mapping seq numa, etc
>> - Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it
> WH> indeed or not intercept it based on the indication
>> Plain Mode
>> - Source address = real source
> WH> could also be NATed in some use cases
>> - Destination address = proxy destination address
>> - Signalling protocol inside indicates real destination address
> WH> or SRC address
>> So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?
> WH> the main difference is mainly DST IP is changed to get explicit routing to the proxy versus being implicit in the transparent case

OK, so my understanding appears correct here.

>> The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Proxy from Operator A, but in fact is picked up by Operator B.
> WH> the network assisted proxy is mainly targeting single operator/controlled operator use cases to avoid these issues.
>> As I’ve said before, the plain mode option is not MPTCP-specific and is simple a signal that says “everything that follows is actually targeted for IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could know where to find a proxy (e.g. a well-known anycast address) then addresses could be rewritten and packets forwarded, with no need for any MPTCP protocol changes.
> WH> you would still need to know the original destination IP@ that the application wanted to go to.

Which is the point of the signalling protocol - the proposed “plain mode option” which is actually carried in the payload. My issue with this is that this is _not MPTCP-specific_. This is simply a signal above the transport layer to inform a proxy what the real destination is.