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

Christoph Paasch <cpaasch@apple.com> Wed, 29 March 2017 15:39 UTC

Return-Path: <cpaasch@apple.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 10802126557 for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 08:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 CQyxtk92YUO3 for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 08:39:03 -0700 (PDT)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6B0126DC2 for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 08:39:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490801942; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kQVM6iHN/BWAyg+LvVNSjOfGPlQKlDlSFlg2JUczKrM=; b=K65FnkeBb/0p40Y4IunPLa6BpZ3d2rPo8+1behdlGCmkk/ExWCu/vt8C19vU0KTe c1MOLR8EySKORL3hoepA3GRth0qCtFfDoR61Ro2P6ahp/gS/WonHgxolvIh6ZrvG CAnH1rSfC+iuA49QH+znLgVFpeKCZ2+1c5DT9QcFNN76JFCIK2xfZubkdbonSiNh qryL4b5Th6nRu8oxbcm9VzWnwDbS+PxzUvJyWGORWpVA8/+LdZcFYpXfB4frj9h+ 1CwSIklITNLCNhl0puiUAh8F8CJqz9aBfJCZxTh3SRchg9aMOUu4Udwr2TIwiQLn jP1hkoP8HXEW4VugVwjzVQ==;
Received: from relay27.apple.com (relay27.apple.com [17.171.128.108]) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 7C.BA.09505.615DBD85; Wed, 29 Mar 2017 08:39:02 -0700 (PDT)
X-AuditID: 11ab0219-dc2b19a000002521-64-58dbd5166af1
Received: from ma1-mmpp-sz10.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay27.apple.com (Apple SCV relay) with SMTP id 62.D7.01638.615DBD85; Wed, 29 Mar 2017 11:39:02 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=iso-8859-1
Received: from localhost ([17.168.191.252]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONL00C7L252KY60@ma1-mmpp-sz10.apple.com>; Wed, 29 Mar 2017 08:39:02 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Wed, 29 Mar 2017 10:39:01 -0500
From: Christoph Paasch <cpaasch@apple.com>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
Cc: "philip.eardley@bt.com" <philip.eardley@bt.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Message-id: <20170329153901.GF2779@dhcp-8507.meeting.ietf.org>
References: <70EAECD3-22A6-420A-B84C-04B0673020DF@nokia.com>
In-reply-to: <70EAECD3-22A6-420A-B84C-04B0673020DF@nokia.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUiuLohR1fs6u0Ig0tLzCwOv33KbvF59XU2 i2VrVzBaTPq9icWBxaPty2QmjyVLfjJ53L11icmj5dlJtgCWKC6blNSczLLUIn27BK6Mnatm MRU8VK9Y8WcGUwPjM6kuRk4OCQETiY8HpjF3MXJxCAkcZJT4dfQNK0xiefs6RhBbSOAso8TO qaUgNq+AoMSPyfdYuhg5OJgF5CWOXMoGCTMLSEs8+juDHcLWkej9/g1qZhOTROvndWAJYQFJ ie47d5hBbBYBVYmuthNgu9gEtCTe3m4Hs0UEXCWu7FkO1swssJxR4vSZmawQze4SH4/0s4Es 5hWwk3i4JRfiNhuJFe/mgs3kFLCVODbjNNguUQFlib+HQe4E+WULm8SFWcITGEVmIXlhFsIL s5C8MAvJCwsYWVYxCucmZuboZuYZmeolFhTkpOol5+duYgRHDJPkDsavrw0PMQpwMCrx8Cqs vh0hxJpYVlyZe4hRmoNFSZx3375bEUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY+13ZVqYe k+te8ktge5tEduPOFcd/9hXU/b9XamsRON1L6+Pr3szeu/014vs7/woeeNh8rsP8lUXUabYX u7mTcq68Vp3wf7LMlqdL52qwcRwJExSo3jK3lOt2OPd51tN5TT3L/zpMz05QSMuQN+rYs/34 LI1WU6PrR64d/9EiUW7Ctku57fwPJZbijERDLeai4kQAh0LNCHkCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUiuLqBVVfs6u0Ig/XPVCwOv33KbvF59XU2 i2VrVzBaTPq9icWBxaPty2QmjyVLfjJ53L11icmj5dlJtgCWKC6blNSczLLUIn27BK6Mnatm MRU8VK9Y8WcGUwPjM6kuRk4OCQETieXt6xhBbCGBs4wSO6eWgti8AoISPybfY+li5OBgFpCX OHIpGyTMLCAt8ejvDHYIW0ei9/s35i5GLqDWJiaJ1s/rwBLCApIS3XfuMIPYLAKqEl1tJ1hB bDYBLYm3t9vBbBEBV4kre5aDNTMLLGeUOH1mJitEs7vExyP9bCCLeQXsJB5uyYW4zUZixbu5 YDM5BWwljs04DbZLVEBZ4u/heywTGAVnITl7FsLZs5CcPQvJ2QsYWVYxChal5iRWGpnrJRYU 5KTqJefnbmKEhHjODsY7N80OMQpwMCrx8Cqsvh0hxJpYVlyZe4hRgoNZSYTX7RRQiDclsbIq tSg/vqg0J7X4EKM0B4uSOO9ee6CUQHpiSWp2ampBahFMlomDU6qB0WeT+6372w9LzzzHc3P6 gmseD+6yT5mRy37E2kzp5sO42wff8c2skz8tHLJhYfaOX4cOXlxxK5Pp7vWftxP2f9kZ9sl/ 5izlzbksj/4I3bh99ceGHMNjX04Ive86ouT+JaAstV8rcc7C719TZbuu6pcKT1CecV5jl7P7 maMHT7BeSS+z3a0nJF2oxFKckWioxVxUnAgAjtEY3m0CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/uOn6o5G97Nb5qtvYtajLZvvIS5Q>
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 15:39:06 -0000

Hello Wim,

inline:

On 29/03/17 - 15:29:04, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
> Phil, you will be a bit more optimal but not a lot as you can see or you end up changing the SOCKs protocol. Even if you do this MP_CONVERT IE will always be the most optimal and hence this is what we propose for doing this proxy function.
> 
> On 29/03/2017, 10:12, "multipathtcp on behalf of philip.eardley@bt.com" <multipathtcp-bounces@ietf.org on behalf of philip.eardley@bt.com> wrote:
> 
>     By non-chatty, I meant a version that didn't do all the authentication messages. After all, the home gateway and network proxy can be expected to know about each other already - at least don't need to do for every new TCP connection from devices behind home gateway
>     
>     -----Original Message-----
>     From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
>     Sent: 29 March 2017 06:30
>     To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>om>; multipathtcp@ietf.org
>     Subject: RE: Two proxy scenario (network proxy off path)
>     
>     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) ->

you would of course use TFO with SOCKS, so that you gain one RTT.

If then in addition to that you remove the authentication part of SOCKS, and
you can even put the payload right after the SOCKS Connection Request inside
the SYN-payload, then you are effectively also at a 0-RTT connection
establishment.


Christoph


>                        <-    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
>     
>     _______________________________________________
>     multipathtcp mailing list
>     multipathtcp@ietf.org
>     https://www.ietf.org/mailman/listinfo/multipathtcp
>     
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp