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

[Vladimir Olteanu <[e-mail]>]

Hi Med,

As per usual, inline.

Cheers,
Vlad

On 7/7/2017 11:17 AM, [e-mail] wrote:
>
> Hi Vlad,
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :*Vladimir Olteanu [mailto:[e-mail]]
> *Envoyé :* vendredi 7 juillet 2017 09:19
> *À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
> *Cc :* [e-mail]; multipathtcp
> *Objet :* Re: [Int-area] SOCKS 6 Draft
>
> 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.
>
> [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.
>
> 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
>
>          +----------+
>
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, [e-mail] 
> <mailto:[e-mail]>wrote:
>
>     *De :*Vladimir Olteanu [mailto:[e-mail]]
>     *Envoyé :* mercredi 5 juillet 2017 18:39
>     *À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
>     *Cc :* [e-mail] <mailto:[e-mail]>; multipathtcp
>     *Objet :* Re: [Int-area] SOCKS 6 Draft
>
>      <SNIP>
>
>     On 7/5/2017 9:00 AM, [e-mail]
>     <mailto:[e-mail]> wrote:
>
>         <SNIP>
>
>         *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
>
>         <SNIP>
>
>     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?
>
>
>     <SNIP>
>
>
>     ·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
>
>