IETF Logo Mail Archive

Re: [multipathtcp] Two proxy scenario (network proxy off path)

<mohamed.boucadair@orange.com> Wed, 29 March 2017 11:30 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 E6590129407 for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 04:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ekxK7QjNkoVK for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 04:30:29 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5801242F7 for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 04:30:28 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 116471805E6 for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 13:30:27 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id D988A20066; Wed, 29 Mar 2017 13:30:26 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 13:30:26 +0200
From: mohamed.boucadair@orange.com
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: Two proxy scenario (network proxy off path)
Thread-Index: AdKoJ5zQqp6DxGj1TeSb3FIu9At16gADSQSA
Date: Wed, 29 Mar 2017 11:30:25 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E42A2F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <6284b86cf96445548c88452da0daf225@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <6284b86cf96445548c88452da0daf225@rew09926dag03b.domain1.systemhost.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/P_Fy8CmIesZd9rz5z2PSIi5Wa4g>
Subject: Re: [multipathtcp] Two proxy scenario (network proxy off path)
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, 29 Mar 2017 11:30:31 -0000

Hi Phil, 

Can you please clarify what you mean by a "non-chatty version"? version of what?

You can refer to Section 3 of RFC1928 to have an idea about the number of messages that are required before sending actual traffic when SOCKSv5 is used. 

Below an excerpt of signaling messages observed to create an initial subflow using SOCKSv5:

==============
(MP Client) ->    TCP SYN    ->  (MCP)
                   <- TCP SYN/ACK <- 
                   ->    TCP ACK    ->
                   -> SOCKS Method Request (1)(a) ->
                   <-    TCP ACK (b)   <-
                    <- SOCKS Method Response (2)(c) <-
                    ->   TCP ACK (d)   ->
                    -> SOCKS Authentication Request (3)(e) ->
                    <-    TCP ACK (f)    <-
                    <- SOCKS Auth. Response (4)(g) <-
                    ->   TCP ACK (h)   ->
                    -> SOCKS Connection Request (5)(i) -> (MCP)
                    <-   TCP ACK (j)                   <- (MCP)
                                                          (MCP)  -> TCP SYN (k) -> (Server)
                                                          (MCP)  <- SYN/ACK (l) <- (Server)
                    <- SOCKS Connection Response (n) (6) <-(MCP) -> TCP ACK (m) -> (Server)
                    ->   TCP ACK (o)  ->
=================

I let you compare it with the 0-RTT and 0-extra signaling approach with MP_CONVERT IE. 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> philip.eardley@bt.com
> Envoyé : mardi 28 mars 2017 20:24
> À : multipathtcp@ietf.org
> Objet : [multipathtcp] Two proxy scenario (network proxy off path)
> 
> Hi,
> 
> I'm now thinking about the scenario where there are two proxies, one in
> the home gateway or Customer Premises Equipment and one in the network,
> both under the control of the operator. And looking at the 'explicit mode'
> scenario, which - if I get it right - means that the network proxy is not
> on the default path. (It's safe to assume that the home gateway proxy is
> on the default path)
> 
> Thinking about the use of SOCKS in this context.
> 
> Earlier Olivier said (in the context of the smartphone scenario -  sorry
> if your comments don't apply to this scenario and I'm just creating
> confusion) that there are different variants of SOCKS that can be used,
> which mainly depend on the number of messages that are used to
> authenticate.
> In the two proxy scenario, it's probably reasonable to assume that the
> home gateway and network proxy are already authenticated. So a non-chatty
> version would be ok.
> 
> Is that right?
> 
> Thanks
> phil
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

v2.27.6 | Report a Bug | By Email | System Status