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

[<[e-mail]>]

Hi Vladimir,

Please see inline.

Cheers,
Med

De : Vladimir Olteanu [mailto:[e-mail]]
Envoyé : mercredi 5 juillet 2017 18:39
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : [e-mail]; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft


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]<mailto:[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]<mailto:[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).
[Med] TFO is not required. We are in the explicit mode where the proxy is provisioned by the provider to the client/CPE. That proxy is prepared to receive data in the first SYN of an MPTCP connection. In order to detect misbehaving proxies, the content of CONVERT is echoed in SYN-ACK. Absent that information, the client/CPE will avoid using that proxy for subsequent network-assisted MPTCP exchanged till a timer is expired or a new proxy is configured.

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.
[Med] Yes.


 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.
[Med] Agree. BTW, this is one of the advices made by Joe. This is now part of the CONVERT design.


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.
[Med] In the plain mode, there is no such limitation because we are leveraging on PCP (RFC6887).



·         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.
[Med] I'm not sure to understand your answer here. Let's consider that your host is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How the solution would work?


·         Use MPTCP in the leg between the proxy and server
Yes.
[Med] Good.



·         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.
[Med] Agree. That's aligned with the plain mode.


·         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.

[Med] Agree.

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.
[Med] I'm not sure I would go that way.



·         IPv6 source address/prefix preservation

I'm not sure what you mean by that.
[Med] Please see slide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf