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

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 29 Mar 2017 15:29:04 +0000

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 [email-masked]" <[email-masked] on behalf of [email-masked]> 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: [email-masked] [mailto:[email-masked]] 
    Sent: 29 March 2017 06:30
    To: Eardley,PL,Philip,TUB8 R <[email-masked]>; [email-masked]
    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) ->
                       <-    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:[email-masked]] De la part de 
    > [email-masked] Envoyé : mardi 28 mars 2017 20:24 À : 
    > [email-masked] 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
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/multipathtcp
    
    _______________________________________________
    multipathtcp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 29 Mar 2017 10:39:01 -0500

Hello Wim,

inline:

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

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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 29 Mar 2017 15:42:59 +0000

Christoph, yes but again it something new and less optimal from the proposed MP_CONVERT IE in the SYN.

On 29/03/2017, 10:39, "[email-masked] on behalf of Christoph Paasch" <[email-masked]> wrote:

    Hello Wim,
    
    inline:

    

    Christoph

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 29 Mar 2017 10:46:52 -0500

> 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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 29 Mar 2017 16:07:01 +0000

Christoph, understood now, but does SOCKS have Src.ip, src.port, etc  which we need for some use cases?
So, whatever we say here we will need to extend something and as such we believe the current proposal with the MP-CONVERT IE is the most optimal way to support this.

On 29/03/2017, 10:46, "[email-masked] on behalf of Christoph Paasch" <[email-masked]> wrote:

    Christoph

---

From: <[email-masked]>
Date: Wed, 29 Mar 2017 16:13:18 +0000

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

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mercredi 29 mars 2017 10:47
> À : Henderickx, Wim (Nokia - BE/Antwerp)
> Cc : [email-masked]; BOUCADAIR Mohamed IMT/OLN;
> [email-masked]
> Objet : Re: [multipathtcp] Two proxy scenario (network proxy off path)
> 
> >     > 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
> [email-masked]" <[email-masked] on behalf of
> [email-masked]> 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
> >     >
> >     >     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.
> >     >
> >     >                         <-   TCP ACK (j)                   <-
> (MCP)

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 29 Mar 2017 11:23:27 -0500

> 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…

The point is that we should try to do something that is architecturally clean,
without being closely linked to MPTCP.

Just imagine, if you deploy a proxy that enables the use of TCP-BBR, a
congestion-control that is much better than what servers/clients currently
use. This would also need a 0-RTT proxying solution (even if it is not
using MPTCP).

The point I am trying to make is that a 0-RTT proxying solution is not
something that the MPTCP working-group should be in charge of. There are
other places in the IETF that are probably more appropriate for this.

Christoph

---

From: <[email-masked]>
Date: Wed, 29 Mar 2017 16:32:45 +0000

Re,

Please see inline.

Cheers,
Med

> Envoyé : mercredi 29 mars 2017 11:23
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Henderickx, Wim (Nokia - BE/Antwerp); [email-masked];
> [email-masked]
> > 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 :)
> 

[Med] MP_CONVERT is defined as an Information Element; not an MPTCP option. The documents we are discussing in MPTCP are specifying the use of this IE for MPTCP proxying purposes. This is the only case we have today for it.

> use. This would also need a 0-RTT proxying solution (even if it is not

[Med] I agree. MP_CONVERT can be used in that context. Interested parties can edit a document to describe the MP_CONVERT IE applicability for that use case. This is not precluded if there is interest.
 
> other places in the IETF that are probably more appropriate for this.
[Med] MPTCP is the place where **MPTCP** proxy is to be specified. 0-RTT is a concern for all transport protocol designs. Endorsing an MPTCP proxy design that increases the delay of establishing proxyied connections by several tens of ms is a no starter. 

> > > > On 29/03/2017, 10:39, "[email-masked] on behalf of Christoph
> Paasch"
> > > <[email-masked]> wrote:
> > > >
> > > >     Hello Wim,
> > > >
> > > >     inline:
> > > >
> > > >     >     Below an excerpt of signaling messages observed to create
> an
> > > initial subflow using SOCKSv5:
> > > >     >
> > > >     >     ==============
> > > >     If then in addition to that you remove the authentication part
> of
> > > SOCKS, and
> > > >     >                         <- SOCKS Connection Response (n) (6)
> <-
> > > (MCP) -> TCP ACK (m) -> (Server)
> > > >     >                         ->   TCP ACK (o)  ->
> > > >     >     =================
> > > >     >
> > > >     >     > De : multipathtcp [mailto:[email-masked]]
> De
> > > la part de
> > > >     >     > 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
> > > >     >     > 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.
> > > >     >     > home gateway and network proxy are already
> authenticated. So
> > > a

---

From: <[email-masked]>
Date: Wed, 29 Mar 2017 16:38:23 +0000

<< The point I am trying to make is that a 0-RTT proxying solution is not something that the MPTCP working-group should be in charge of. There are other places in the IETF that are probably more appropriate for this.>>
If possible the WG can discuss a solution for a while without worrying about this - at least to get to a protocol model that we like. then we (or rather Mirja & IESG) can worry about Whether this needs a re-charter, another wg involved etc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 29 March 2017 11:23
To: [email-masked]
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Eardley,PL,Philip,TUB8 R <[email-masked]>; [email-masked]
Subject: Re: [multipathtcp] Two proxy scenario (network proxy off path)

On 29/03/17 - 16:13:18, [email-masked] wrote:
> 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
> 
> 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 
> :)

The point is that we should try to do something that is architecturally clean, without being closely linked to MPTCP.

Just imagine, if you deploy a proxy that enables the use of TCP-BBR, a congestion-control that is much better than what servers/clients currently use. This would also need a 0-RTT proxying solution (even if it is not using MPTCP).

The point I am trying to make is that a 0-RTT proxying solution is not something that the MPTCP working-group should be in charge of. There are other places in the IETF that are probably more appropriate for this.

Christoph

> > De : [email-masked] [mailto:[email-masked]] Envoyé : mercredi 
> > 29 mars 2017 10:47 À : Henderickx, Wim (Nokia - BE/Antwerp) Cc : 
> > [email-masked]; BOUCADAIR Mohamed IMT/OLN; 
> > [email-masked] Objet : Re: [multipathtcp] Two proxy scenario 
> > (network proxy off path)
> > 
> > > 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
> > 
> > 
> > >
> > 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.
> > >     >
> > 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
> > >     >
> > the number of messages that are required before sending actual 
> > traffic when SOCKSv5 is used.
> > >     >

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 29 Mar 2017 19:38:40 +0200

> If possible the WG can discuss a solution for a while without worrying about this - at least to get to a protocol model that we like. then we (or rather Mirja & IESG) can worry about Whether this n…

I agree that there could be other use cases than MPTCP and that the main 
objective is to have 0-RTT proxying solution. Several members of this 
group have worked on MPTCP proxies and there is sufficient demand from 
various network operators to justify a specification that ensures that 
different implementations are interoperable. Given the experience that 
we have in this group with MPTCP proxies, it would make sense to discuss 
here first. There are already deployments and operators expect to have 
interoperablt solutions soon.

Olivier

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 29 Mar 2017 21:07:48 +0000

On 29/03/2017, 12:38, "Olivier Bonaventure" <[email-masked]> wrote:

WH> agreed, lets focus on MPTCP for this proposal and lets get interoperability.
    
    Olivier