Re: [multipathtcp] [Int-area] SOCKS 6 Draft

[Vladimir Olteanu <[e-mail]>]

Hi Mohamed,

It's great to talk this through. I've inlined my answers.

Cheers,

Vlad


On 7/5/2017 9:00 AM, [e-mail] wrote:
>
> Hi Valdimir,
>
> Thank you for your answer.
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :*Vladimir Olteanu [mailto:[e-mail]]
> *Envoyé :* mercredi 5 juillet 2017 01:35
> *À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
> *Cc :* [e-mail]; multipathtcp
> *Objet :* Re: [Int-area] SOCKS 6 Draft
>
> Hi Mohamed,
>
> No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as 
> inspiration for SOCKS 6.
>
> When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 
> 0-RTT overhead.
>
> [Med] Glad to see that we are pursuing the same goal. That’s said I’m 
> not sure about the 0-RTT in the current proposal given this text that 
> puts a dependency on the server side:
>
>    In the fast case, when authentication is properly set up, the proxy
>
>    attempts to create the socket immediately after the receipt of the
>
>    request, thus achieving an operational conection in one RTT (provided
>
>    TFO functionality is available at the client, proxy, and server).
>
>                                              ^^^^^^^^
>
Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP 
OK).
>
>  It can also be stacked as many times as desired for arbitrarily long 
> proxy chains. However:
>  * We avoid using the SYN's payload as extra option space (which, I 
> think, goes against TCP's core philosophy).
>
> [Med] This is also true for MP_CONVERT Information Element which is 
> not a TCP option, but a data supplied for proxy purposes in the SYN 
> payload.
>
Fair enough, but this is not a purely layer 5+ protocol. It seems that 
you are strongly tied to TFO (between the client and the proxy). 
MP_CONVERT must be part of the SYN's payload, because the following 
SYN+ACK depends on the contents of MP_CONVERT and signals that the 
remote server has accepted your connection.
>
>  The magic number at the start of the MP_CONVERT element implies that 
> if any MPTCP stream happens to start with 0xFAA8FAA8, the client 
> should not use TFO.
>
> [Med] This can be fixed by registering a service port for the proxy 
> service because, after all, the ultimate destination port is conveyed 
> in the MP_CONVERT.
>
I think this is more sensible.
>
> I think moving up the protocol stack is a more desirable alternative.
>  * We support authentication. Connections to the proxy can also be 
> initiated from networks outside of the operator's control (e.g. home 
> WiFis).
>
> [Med] Authentication/authorization can be supported by various means. 
> This depends on the deployment scheme.
>
>
>  * SOCKS 6 is easier to extend. If the client needs to request some 
> special behavior from the proxy (e.g. what packet scheduler to use), 
> all we have to do is define (and standardize) a new SOCKS option.
>
> [Med] That’s also true for MP_CONVERT Information Element. You can 
> define new “Types” if needed.
>
> Can you please let me know if the proposal supports the following 
> features:
>
> ·Support incoming connections (Proxy<---Remote Host): That is the 
> proxy intercept a TCP connection that it transforms into an MPTCP one.
>
Yes. See section 7.2. The client makes a request and then has to keep 
the connection to the proxy open. When the proxy accepts a connection 
from a remote host, it informs the client of the remote host's address 
and starts relaying data. SOCKS 5 has the exact same feature. You are 
limited to one incoming connection per request, though.
>
> ·If such feature is supported, how a host located behind a CPE 
> (Host----CPE-----Proxy----Remote Host) can instruct dynamically the 
> CPE so that it can forward appropriately incoming connections?
>
It does not have to. The connection on the host-proxy leg is initiated 
by the client.
>
> ·Use MPTCP in the leg between the proxy and server
>
Yes.
>
> ·Notify the client that the server is also MPTCP-capable (so that the 
> proxy can be withdrawn from the communication)
>
It depends on the implementation. A basic implementation just listens 
for a connection from the client and then opens a socket to the server 
using the vanilla socket API. It can't do any fancy stuff.

A smarter implementation (the one we're aiming for) can mirror the 
keys/tokens/DSS sequence numbers (also taking the DSS delta(s) incurred 
by the request/auth. reply/operation reply into account) and advertise 
the server's real address(es) via ADD_ADDR. We plan to go a step further 
in -01 and add an option in the operation reply that hints that the main 
subflow (the one going through the proxy) should be closed once other 
subflows are established.
>
> ·Relay untouched the set of TCP options supplied by the client/server 
> without any alteration from the proxy
>
Yes-ish. In both SOCKS 6 and MPTCP Plain mode, when you strip away the 
initial exchange between the client and the proxy, you end up with the 
actual data that has to be relayed, so I would argue that both solutions 
are similar and suffer from roughly the same issues.

As long as there is a 1:1 mapping between client-proxy and proxy-server 
subflows, I don't think there are many issues. In case you have TFO on 
the client-proxy leg, but not on the server, you have to transmit the 
SYN's payload in a subsequent packet.

When you have to convert between MPTCP and regular TCP, you can no 
longer translate everything packet-by-packet and let end-to-end 
congestion control do the work for you (and you can't relay ECN, 
either). Further:
  * In MPTCP, different subflows may send the same data using different 
options and/or DSCP.
  * You can't freely mix TCP timestamps from different subflows. (The 
only guarantee is that timestamps are numbers that increase 
monotonically for each individual subflow.)

I would go even further and say that, on principle, a proxy should not 
relay unknown TCP options, but rather strip them.
>
> ·IPv6 source address/prefix preservation
>
>
I'm not sure what you mean by that.
>
> (I've also CCed the MPTCP WG).
>
> [Med] Thanks.
>
>
>
> Cheers,
> Vlad
>
> On 07/04/2017 12:09 PM, [e-mail] 
> <mailto:[e-mail]> wrote:
>
>     Hi Vladimir, all,
>
>     (focusing only on this part of the message).
>
>     I do fully agree that shortening MPTCP connections setup is key.
>     Having 0-RTT is an important requirement for this effort.
>     Achieving it without out-of-band signaling would be even ideal.
>
>     Can you please elaborate on the benefits of your proposal compared
>     to
>     https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
>     which allows to achieve 0-RTT proxying.
>
>     Thank you.
>
>     Cheers,
>
>     Med
>
>     *De :*Int-area [mailto:[e-mail]] *De la part de*
>     Vladimir Olteanu
>     *Envoyé :* vendredi 30 juin 2017 23:37
>     *À :* David Schinazi
>     *Cc :* [e-mail] <mailto:[e-mail]>
>     *Objet :* Re: [Int-area] SOCKS 6 Draft
>
>     Hi David,
>
>         */[/*SNIP]
>
>
>         - Out of curiosity, what specific use case are you using this
>         protocol for?
>
>         We are looking into using MPTCP on mobile devices to "bind"
>         4G/LTE and WiFi. Mobile data networks have high latency, hence
>         the drive to shave off as many RTTs as possible and to take
>         advantage of TFO, at least on the client-proxy leg.
>
>     Cheers,
>     Vlad
>