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

Christoph,

If you remove the initial TCP connection,
If you remove the authentication negotiation,
If you include the payload of the original SYN as part of the NEW SOCKS request

You are just cloning the MP_CONVERT behavior by overloading SOCKS semantic without providing an extra feature compared to the MP_CONVERT.

For the particular case of IPv6 when source address/prefix preservation is required, I don't see how this can be supported by SOCKS. Of course, you can modify the SOCKS command to clone MP_CONVERT :) 

Cheers,
Med

> -----Message d'origine-----
> De : cpaasch@apple.com [mailto:cpaasch@apple.com]
> Envoyé : mercredi 29 mars 2017 10:47
> À : Henderickx, Wim (Nokia - BE/Antwerp)
> Cc : philip.eardley@bt.com; BOUCADAIR Mohamed IMT/OLN;
> multipathtcp@ietf.org
> Objet : Re: [multipathtcp] Two proxy scenario (network proxy off path)
> 
> On 29/03/17 - 15:42:59, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
> > Christoph, yes but again it something new and less optimal from the
> proposed MP_CONVERT IE in the SYN.
> 
> No, that's what I wrote below. It's not less optimal. It's exactly the
> same in
> terms of performance as MP_CONVERT IE in the SYN!
> 
> 
> Christoph
> 
> 
> >
> > On 29/03/2017, 10:39, "cpaasch@apple.com on behalf of Christoph Paasch"
> <cpaasch@apple.com> wrote:
> >
> >     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>;
> 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
> >
> >