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

From: Vladimir Olteanu <[email-masked]>
Date: Wed, 5 Jul 2017 02:35:12 +0300

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. 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). 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. 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).
  * 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.

(I've also CCed the MPTCP WG).

Cheers,
Vlad

On 07/04/2017 12:09 PM, [email-masked] 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:[email-masked]] *De la part de* 
> Vladimir Olteanu
> *Envoyé :* vendredi 30 juin 2017 23:37
> *À :* David Schinazi
> *Cc :* [email-masked]
> *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
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Jul 2017 21:43:41 -0700

> On Jul 4, 2017, at 4:35 PM, Vladimir Olteanu <[email-masked]> wrote:
> 
>  * We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy).

It's not philosophy - it's a requirement for backward compatibility as required for receivers not supporting new options in the SYN. 

See https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06

Issues are discussed in detail in sec 8 of https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-06

Joe

---

From: <[email-masked]>
Date: Wed, 5 Jul 2017 06:00:54 +0000

Hi Valdimir,

Thank you for your answer.

Please see inline.

Cheers,
Med

De : Vladimir Olteanu [mailto:[email-masked]]
Envoyé : mercredi 5 juillet 2017 01:35
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : [email-masked]; 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).
                                                            ^^^^^^^^
 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.
 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 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.

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

·         Use MPTCP in the leg between the proxy and server

·         Notify the client that the server is also MPTCP-capable (so that the proxy can be withdrawn from the communication)

·         Relay untouched the set of TCP options supplied by the client/server without any alteration from the proxy

·         IPv6 source address/prefix preservation

[Med] Thanks.

Cheers,
Vlad
On 07/04/2017 12:09 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi Vladimir, all,

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:[email-masked]] De la part de Vladimir Olteanu
Envoyé : vendredi 30 juin 2017 23:37
À : David Schinazi
Cc : [email-masked]<mailto:[email-masked]>
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

---

From: Vladimir Olteanu <[email-masked]>
Date: Wed, 5 Jul 2017 19:39:07 +0300

Hi Mohamed,

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

Cheers,

Vlad

On 7/5/2017 9:00 AM, [email-masked] wrote:
> *De :*Vladimir Olteanu [mailto:[email-masked]]
> *Envoyé :* mercredi 5 juillet 2017 01:35
> *À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
> *Cc :* [email-masked]; multipathtcp
> [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:
>
Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP 
OK).
> 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.
> 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.
>
> ·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.
> On 07/04/2017 12:09 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
>
>     Hi Vladimir, all,
>
>     Having 0-RTT is an important requirement for this effort.
>     Achieving it without out-of-band signaling would be even ideal.
>
>     *Cc :* [email-masked] <mailto:[email-masked]>
>         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
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Jul 2017 09:59:03 -0700

> remote server has accepted your connection.

The biggest impact of including non-data information in the SYN payload
area is that it completely defeats graceful fallback for SYN receivers
that don't support the option. As you note, it can be *more* safe when
tied to out-of-band context (e.g., prior TFO support), but TCP has NO
requirement that such context is absolutely maintained across different
connections. You might be speaking to a different stack or demuxed off
to a different virtual host behind a load balancer.

Ultimately, putting any non-data info in the SYN payload violates the
requirement that TCP options can be ignored by receivers that don't
support them *without* impacting the ability of *that* connection
attempt to succeed.

Joe

---

From: Dragoș Niculescu <[email-masked]>
Date: Thu, 6 Jul 2017 11:41:15 +0300 (EEST)

----- On Jul 5, 2017, at 7:59 PM, Joe Touch [email-masked] wrote:

> [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 biggest impact of including non-data information in the SYN payload area is
> that it completely defeats graceful fallback for SYN receivers that don't
> support the option. As you note, it can be *more* safe when tied to out-of-band
> context (e.g., prior TFO support), but TCP has NO requirement that such context
> is absolutely maintained across different connections. You might be speaking to
> a different stack or demuxed off to a different virtual host behind a load
> balancer.
> 
> requirement that TCP options can be ignored by receivers that don't support
> them *without* impacting the ability of *that* connection attempt to succeed.
> 
> Joe

SOCKSv6 proposal makes use of extra data in the SYN (SOCKS data, and user data), but 
its correctness and backward compatibility does not depend on TFO, only its RTT performance. 
In fact, when TFO is not available neither between client and proxy, nor between proxy and 
server the SOCKSv6 RTT is still lower than SOCKSv4 and SOCKSv5. But TFO is likely to be the most 
common case in the future - Linux kernel has TFO client side on by default since 3.12 
(November 2013)[1], and it seems to be the default in all Android phones and default 
Linux installs.  

-- 
Dragoș

[1] https://github.com/torvalds/linux/commit/0d41cca490c274352211efac50e9598d39a9dc80

---

From: <[email-masked]>
Date: Thu, 6 Jul 2017 12:56:04 +0000

Hi Vladimir,

Please see inline.

Cheers,
Med

Envoyé : mercredi 5 juillet 2017 18:39

Hi Mohamed,

Cheers,

Vlad

On 7/5/2017 9:00 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Valdimir,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; multipathtcp

Hi Mohamed,

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.

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

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

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

---

From: <[email-masked]>
Date: Thu, 6 Jul 2017 13:02:32 +0000

Hi Joe,

Please see inline.

Cheers,
Med

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

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 biggest impact of including non-data information in the SYN payload area is that it completely defeats graceful fallback for SYN receivers that don't support the option. As you note, it can be *more* safe when tied to out-of-band context (e.g., prior TFO support), but TCP has NO requirement that such context is absolutely maintained across different connections. You might be speaking to a different stack or demuxed off to a different virtual host behind a load balancer.

Ultimately, putting any non-data info in the SYN payload violates the requirement that TCP options can be ignored by receivers that don't support them *without* impacting the ability of *that* connection attempt to succeed.
[Med] You are right... if we are talking about TCP options that are inserted in the payload of the SYN to every remote peer. This is not the case for the MPTCP proxy case: this is about proxy-supplied data that is sent to the proxy, which is provisioned by the provider. Proxy-supplied data is not received by the remote peer.

Joe

---

From: Vladimir Olteanu <[email-masked]>
Date: Fri, 7 Jul 2017 10:18:58 +0300

Hi Mohamed,

I'm replying specifically to the parts quoted below.

SOCKS is used by explicit proxies; anything related to transparent 
proxies is beyond its scope. It does not preclude the deployment of 
anything transparent. In other words, I merely propose it as an 
alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc. makes no 
sense in this context.

Cheers,
Vlad

On 7/6/2017 3:56 PM, [email-masked] wrote:
> *Envoyé :* mercredi 5 juillet 2017 18:39
>  <SNIP>
> On 7/5/2017 9:00 AM, [email-masked] 
>     <SNIP>
>     *Cc :* [email-masked] <mailto:[email-masked]>; multipathtcp
>     <SNIP>
> [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?
>
> <SNIP>
>
> [Med] Please see slide 18 of

---

From: <[email-masked]>
Date: Fri, 7 Jul 2017 08:17:00 +0000

Hi Vlad,

Please see inline.

Cheers,
Med

Envoyé : vendredi 7 juillet 2017 09:19

Hi Mohamed,

SOCKS is used by explicit proxies; anything related to transparent proxies is beyond its scope.
[Med] The definition we had so far is that "explicit proxy" means that the client is aware about the presence of the proxy and such packets are sent explicitly to that proxy. An explicit proxy can therefore behave either as transparent or non-transparent. I understand, that the current design assumes non-transparent mode.
 It does not preclude the deployment of anything transparent. In other words, I merely propose it as an alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc. makes no sense in this context.
[Med] I disagree. The support of incoming connections is one of the requirements of the MPTCP WG: "A session can be initiated from either end".
This is why I'm wondering how this typical flow can be achieved with SOCKS.

H<=====CPE<----------proxy<===RM
         +----------+

Cheers,
Vlad

On 7/6/2017 3:56 PM, [email-masked]<mailto:[email-masked]> wrote:

*         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?

<SNIP>

*         IPv6 source address/prefix preservation

---

From: Vladimir Olteanu <[email-masked]>
Date: Fri, 7 Jul 2017 14:23:45 +0300

Hi Med,

As per usual, inline.

Cheers,
Vlad

On 7/7/2017 11:17 AM, [email-masked] wrote:
> *Envoyé :* vendredi 7 juillet 2017 09:19
> proxies is beyond its scope.
>
> [Med] The definition we had so far is that “explicit proxy” means that 
> the client is aware about the presence of the proxy and such packets 
> are sent explicitly to that proxy. An explicit proxy can therefore 
> behave either as transparent or non-transparent. I understand, that 
> the current design assumes non-transparent mode.
>
Yes, what I meant was "non-transparent".
>
>  It does not preclude the deployment of anything transparent. In other 
> words, I merely propose it as an alternative to MP_CONVERT.
>
> [Med] I disagree. The support of incoming connections is one of the 
> requirements of the MPTCP WG:"A session can be initiated from either end”.
>
> This is why I’m wondering how this typical flow can be achieved with 
> SOCKS.
>
> H<=====CPEß--------proxy<===RM
>
>          +----------+
>
My point was that if you want any transparent functionality, you have to 
use something other than SOCKS, but now I see what you mean.

Currently, SOCKS 6 has the same limited support for this scenario that 
v5 has. The client opens a connection to the server and asks it to 
listen for an incoming connection. When a remote host connects to the 
proxy, the server sends  a reply (v5)/operation reply (v6) to the client 
(via the connection that the client initiated) containing the remote 
host's address and starts relaying data back and forth.

I think adequately handling this use case would mean adding a reverse 
mode to SOCKS 6:
  * The client informs the proxy on which port it is listening. (It's 
the client's job to set up port forwarding etc.)
  * For each incoming connection, the proxy opens a connection to the 
client, sends an operation reply containing the remote host's IP and 
port, and then relays data.
>
>
> Cheers,
> Vlad
>
> On 7/6/2017 3:56 PM, [email-masked] 
> <mailto:[email-masked]>wrote:
>
>     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.
>
>     (Host----CPE-----Proxy----Remote Host) can instruct dynamically
>     the CPE so that it can forward appropriately incoming connections?
>
>     [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?
>
>
>     <SNIP>
>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 10 Jul 2017 00:00:07 -0700

Hi Vlad and Dragos,

I really appreciate you for preparing the draft and brought it to here.
As you might know, we have been exploring solutions for proxying mptcp
sessions.
We've had lots of discussions on plain mode and other solutions, but
because we didn't have concrete proposals other than plain mode, it was
difficult to compare the pros and the cons properly. But, now I believe we
have a good chance to advance this.

BTW, as I'm curious about this approach to use with mptcp, I have some
questions for a certain scenario. In the WG, one use case we discuss is
using two proxies like below.

          client ---- proxy1 ============= proxy2 ---- server

In this scenario, we presume using TCP for client-proxy1 and proxy2-server,
while using mptcp for proxy1-proxy2.
The draft says it supports TFO, but I still think it takes some RTTs with
approach although I miss something. It would be great if you could clarify
the following points.

1:  How will the connection between proxy1 and proxy2 set up? Does proxy1
need to negotiate proxy2 for authentication, etc? If so, it might add
another delays before clients can send data.

2: Do clients need to wait a response for CONNECT request? If not, how it
handles an error case?

Thanks,
--
Yoshi

On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu <
[email-masked]> wrote:

> Hello,
>
> We have submitted a draft describing a new version of the SOCKS protocol,
> which could help in the deployment of MPTCP. You can find the abstract and
> a link to the draft below.
>
> Best,
> Vlad and Dragoș
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
> Date: Wed, 28 Jun 2017 22:01:16 -0700
> From: [email-masked]
> To: Vladimir Olteanu <[email-masked]>
> <[email-masked]>, Dragos Niculescu
> <[email-masked]> <[email-masked]>
>
> A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
> has been successfully submitted by Vladimir Olteanu and posted to the
> IETF repository.
>
> Name:		draft-olteanu-intarea-socks-6
> Revision:	00
> Title:		SOCKS Protocol Version 6
> Document date:	2017-06-28
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
> Htmlized:       https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00
>
>
> Abstract:
>    The SOCKS protocol is used primarily to proxy TCP connections to
>    arbitrary destinations via the use of a proxy server.  Under the
>    latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
>    authentication is used) before data can flow between the client and
>    the server.
>
>    This memo proposes SOCKS version 6, which reduces the number of RTTs
>    used, takes full advantage of TCP Fast Open, and adds support for
>    0-RTT authentication.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

---

From: Vladimir Olteanu <[email-masked]>
Date: Tue, 11 Jul 2017 02:19:28 +0300

Hi Yoshi,

As a response to question 2, the client can send some initial data as 
part of the request. It does have to wait for a reply to send any more 
data, though. As such, the client can get a data response from the 
server in 1 RTT, same as when contacting the server directly with TFO, if:
  * Everyone uses TFO (otherwise, RTTs are incurred only on the segments 
where TFO is not available).
  * Authentication is not required, or 0-RTT authentication succeeds. 
(Otherwise, some extra RTTs are incurred, same as above.)

If nobody uses TFO, but authentication is not an issue (either it's not 
needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP 
(2 RTTs for a data response).

As for the use case, there are two possible ways in which it can be handled:
  * The client knows about both proxies.
  * The client knows only about proxy1, but proxy1 is configured to go 
via proxy2 when contacting the server.

Assuming the client knows about both of them, it can speak SOCKS 6 over 
SOCKS 6. The relevant messages are:
C->P1 request(P2, auth data 1, initial data(request(S, auth data 2, 
initial data(application data))))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

If proxy1 is configured to use proxy2:
C->P1 request(S, auth data 1, initial data(application data))
P1->P2 request(S, auth data 2, initial data(application data))
P2->S application data

Cheers,
Vlad

On 07/10/2017 10:00 AM, Yoshifumi Nishida wrote:
> because we didn't have concrete proposals other than plain mode, it 
> was difficult to compare the pros and the cons properly. But, now I 
> believe we have a good chance to advance this.
>
> questions for a certain scenario. In the WG, one use case we discuss 
> is using two proxies like below.
>
> In this scenario, we presume using TCP for client-proxy1 and 
> proxy2-server, while using mptcp for proxy1-proxy2.
> The draft says it supports TFO, but I still think it takes some RTTs 
> with approach although I miss something. It would be great if you 
> could clarify the following points.
>
> 1:  How will the connection between proxy1 and proxy2 set up? Does 
> proxy1 need to negotiate proxy2 for authentication, etc? If so, it 
> might add another delays before clients can send data.
>
> 2: Do clients need to wait a response for CONNECT request? If not, how 
> it handles an error case?
>
> Thanks,
> --
> Yoshi
>
>
> On Thu, Jun 29, 2017 at 5:02 AM, Vladimir Olteanu 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     We have submitted a draft describing a new version of the SOCKS
>     protocol, which could help in the deployment of MPTCP. You can
>     find the abstract and a link to the draft below.
>
>     Best,
>     Vlad and Dragoș
>
>
>
>     From: 	[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>, Dragos Niculescu
>     <[email-masked]> <mailto:[email-masked]>
>
>
>
>     URL:https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt
>     <https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt>
>     Status:https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
>     <https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/>
>     Htmlized:https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
>     <https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00>
>     Htmlized:https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00
>     <https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00>
>
>
>     Abstract:
>     until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/multipathtcp>
>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 12 Jul 2017 00:51:42 -0700

Hi Vlad,

Thanks for the response.

On Mon, Jul 10, 2017 at 4:19 PM, Vladimir Olteanu <
[email-masked]> wrote:

> Hi Yoshi,
>
> As a response to question 2, the client can send some initial data as part
> of the request. It does have to wait for a reply to send any more data,
> though. As such, the client can get a data response from the server in 1
> RTT, same as when contacting the server directly with TFO, if:

> needed or done in 0 RTTs), then SOCKS 6 does no worse than regular TCP (2
> RTTs for a data response).
>
>  * The client knows only about proxy1, but proxy1 is configured to go via
> proxy2 when contacting the server.
>

> P1->P2 request(S, auth data 2, initial data(application data))
Thanks for the clarification.
So, in both cases, if C piggy-backs all requests (authentication, connect,
etc if any) and application data in SYN payload with TFO, P1 can forward it
as soon as it receives and P2 can do the same thing? (We might presume no
authentication or 0-rtt authentication here, though.)
--
Yoshi

---

From: Vladimir Olteanu <[email-masked]>
Date: Wed, 12 Jul 2017 17:15:27 +0300

Hi Yoshi,

On 07/12/2017 10:51 AM, Yoshifumi Nishida wrote:
> Hi Vlad,
>
> Thanks for the response.
>
> On Mon, Jul 10, 2017 at 4:19 PM, Vladimir Olteanu 
>     As a response to question 2, the client can send some initial data
>     as part of the request. It does have to wait for a reply to send
>     any more data, though. As such, the client can get a data response
>     from the server in 1 RTT, same as when contacting the server
>     directly with TFO, if:
>      * Everyone uses TFO (otherwise, RTTs are incurred only on the
>     segments where TFO is not available).
>      * Authentication is not required, or 0-RTT authentication
>     succeeds. (Otherwise, some extra RTTs are incurred, same as above.)
>
>
>     If nobody uses TFO, but authentication is not an issue (either
>     it's not needed or done in 0 RTTs), then SOCKS 6 does no worse
>     than regular TCP (2 RTTs for a data response).
>
>      * The client knows only about proxy1, but proxy1 is configured to
>     go via proxy2 when contacting the server.
>
>
>     Assuming the client knows about both of them, it can speak SOCKS 6
>     over SOCKS 6. The relevant messages are:
>     C->P1 request(P2, auth data 1, initial data(request(S, auth data
>     2, initial data(application data))))
> So, in both cases, if C piggy-backs all requests (authentication, 
> connect, etc if any) and application data in SYN payload with TFO, P1 
> can forward it as soon as it receives and P2 can do the same thing? 
> (We might presume no authentication or 0-rtt authentication here, though.)
>
Yes, that is the case.

Vlad

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2017 10:07:09 -0700

> (November 2013)[1], and it seems to be the default in all Android phones and default 
What happens with a legacy receiver?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2017 10:09:50 -0700

On 7/6/2017 6:02 AM, [email-masked] wrote:
> [Med] You are right… if we are talking about TCP options that are
> inserted in the payload of the SYN to every remote peer. This is not
> the case for the MPTCP proxy case: this is about proxy-supplied data
> that is sent to the proxy, which is provisioned by the provider.
> Proxy-supplied data is not received by the remote peer.  
>
You have not considered what happens when the remote peer changes or
disappears.

In that case, your E2E TCP connection is no longer falling back safely
and correctly, based on the principle that all unknown options can be
ignored - as is required by RFC793.

Further, I have no idea what you think is happening above, but at *best*
it's TCP between the proxies, perhaps triggered by packets between the
endpoints. However, it's no longer a TCP "connection" in any sense of
any IETF standard of which I am familiar.

Joe

---

From: Dragoș Niculescu <[email-masked]>
Date: Fri, 14 Jul 2017 10:44:10 +0300 (EEST)

> What happens with a legacy receiver?
Legacy receiver will use plain TCP. Proxies (SOCKS and others) are routinely used to bridge new options to legacy receivers. In this case, TFO will work between client and proxy, but not between proxy and legacy server. 

-- 
Dragoș

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 11:26:18 -0700

On 7/14/2017 12:44 AM, Dragoș Niculescu wrote:
> Legacy receiver will use plain TCP. 

No - a legacy receiver will interpret the SYN information as user data,
which there is no way to "undo".

You can't know that you're not talking to a legacy receiver until you
receive the SYN-ACK. Even if you cache TFO availability, you could be
wrong - the endpoint could reboot or be replaced with a new endpoint, etc.

Ultimately, the onus is on you to NEVER poison a TCP connection that
could be to a legacy receiver. That's a requirement in RFC793.
Joe

---

From: Vladimir Olteanu <[email-masked]>
Date: Wed, 19 Jul 2017 22:23:17 +0300

On 07/19/2017 09:26 PM, Joe Touch wrote:
> No - a legacy receiver will interpret the SYN information as user 
> data, which there is no way to "undo".
>
I think there's a misunderstanding here. SOCKSv6 runs strictly on top of 
TCP. The "user data" to which we're referring is data meant to be 
relayed by the proxy to the server. The SYN's payload (both SOCKS 
request and said user data) is irrevocably part of the client-proxy data 
stream and we do not change it retroactively after learning that the 
proxy does not support TFO.

Vlad

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:40:44 -0700

On 7/19/2017 12:23 PM, Vladimir Olteanu wrote:
> I think there's a misunderstanding here. SOCKSv6 runs strictly on top
> of TCP. 
OK, so to clarify - TCP is between the two SOCKS endpoints.
The user data travels over SOCKS.
Can you confirm that's correct?

> The "user data" to which we're referring is data meant to be relayed
> by the proxy to the server. The SYN's payload (both SOCKS request and
> said user data) is irrevocably part of the client-proxy data stream
> and we do not change it retroactively after learning that the proxy
> does not support TFO.
If the above is correct, then it would be useful to NEVER speak of
"putting data in the SYN payload". You simply don't have that control.
The interface to TCP *allows* pending "user" (as in TCP user, which in
this case is the SOCKS layer) data to be placed in the SYN, but never
requires it.

So you can talk about putting information in the SOCKS stream, but
shouldn't be referring to individual TCP segments.

Joe

---

From: Vladimir Olteanu <[email-masked]>
Date: Thu, 20 Jul 2017 03:32:30 +0300

Yes.
> this case is the SOCKS layer) data to be placed in the SYN, but never
We're perfectly aware of that. We were only talking about putting data 
in the SYN for the sake of brevity, because said data is very likely to 
actually make it into the SYN under typical circumstances.

However, you do have a point, especially given that MPTCP-PM and O-RTT 
converters are being actively discussed and they do require data to be 
placed in the SYN.
> shouldn't be referring to individual TCP segments.
If we were not discussing performance, I would agree with you. However, 
it's impractical (and not useful, either) to reason about the RTT 
overhead without making some assumptions about what data goes into which 
segment. SOCKS 6 is is designed to take advantage of how the stack is 
likely to split the data into segments in typical use cases.

Cheers,
Vlad

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 17:40:46 -0700

On 7/19/2017 5:32 PM, Vladimir Olteanu wrote:
> in the SYN for the sake of brevity, because said data is very likely
> to actually make it into the SYN under typical circumstances.
>

And those would fall under the category of attack devices, IMO.

I.e., if you're speaking of just an application proxy, then the doc
needs to be very clear of that goal AND use only the required TCP "user"
API -- which does not have any indication of an arriving SYN (it would
only indicate when the connection was established, e.g., after the TWHS
completes).

If you're speaking of something that rewrites TCP segments directly,
then you need to be clear that this is what you intend (and I cannot see
how you can do that and be compliant with TCP).

> If we were not discussing performance, I would agree with you.
> However, it's impractical (and not useful, either) to reason about the
> RTT overhead without making some assumptions about what data goes into
> which segment. SOCKS 6 is is designed to take advantage of how the
> stack is likely to split the data into segments in typical use cases. 

You can make some *assumptions* about what might happen, and even talk
about ways to configure the outgoing TCP to encourage its putting data
in the SYN (e.g., by writing before connecting). However, if we're
talking about an application layer proxy, you cannot assume availability
of the incoming SYN data unless you also assume TFO - and at best, it's
an assumption (your application would never know).

I.e., if you do everything right, you MIGHT end up looking "LIKE" you
rewrote the TCP SYN as it "passes through", but speaking of that as the
actual mechanism violates TCP.

So at best, there is need for a significant revision to clear this all up.

Joe

---

From: Dragoș Niculescu <[email-masked]>
Date: Thu, 20 Jul 2017 10:22:23 +0300 (EEST)

> only indicate when the connection was established, e.g., after the TWHS

SOCKSv6 is an application proxy, just as SOCKSv4 and SOCKSv5. 
This means you can use it with standard TCP API. But it also understands TFO, and if one client wishes lower RTT, he needs to use TFO API. I think this is pretty clear from the figures in the slides [1], and is the way we are currently implementing it [2].

 I think the discussion here is not different from discussions when TFO was adopted: everything works as before with standard API, but you need setsockopt and connect with data if you have idempotent data and want lower RTT.       

> how you can do that and be compliant with TCP).

We are not talking about this in SOCKSv6. 

> an assumption (your application would never know).

There are two points here. First, the application NEEDS TO know, because it needs to decide whether to use TFO API, or classic API(legacy apps will be classic API, of course). Second, for SOCKS (v4, v5, or v6), there is the request data which can be put in SYN, even if the user uses classic API, but this is a proxy implementation issue, and our current specification does not preclude or force this.  

> actual mechanism violates TCP.

It looks like that IF the client has idempotent data, and IF the client uses TFO API, and IF the proxy enables TFO as a client and as a server, and IF the actual server supports TFO. So, there are a lot of IFs to get that kind of performance, but as shown in slide 9 of the presentation [1], it does work with standard API, only twice as slow.  

-- 
Dragoș

[1] https://www.ietf.org/proceedings/99/slides/slides-99-intarea-socks6-00.pdf
[2] https://github.com/45G/shadowsocks-libev

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 10:31:12 -0700

> It looks like that IF the client has idempotent data, and IF the client uses TFO API, and IF the proxy enables TFO as a client and as a server, and IF the actual server supports TFO. So, there are…
Agreed, but the text could be much more clear that this is the goal and
expected outcome.

Joe