Hi Med,
As per usual, inline.
Cheers,
Vlad
On 7/7/2017 11:17 AM, [email protected] wrote:
Hi Vlad,
Please see inline.
Cheers,
Med
*De :*Vladimir Olteanu [mailto:[email protected]]
*Envoyé :* vendredi 7 juillet 2017 09:19
*À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
*Cc :* [email protected]; 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, [email protected]
<mailto:[email protected]>wrote:
*De :*Vladimir Olteanu [mailto:[email protected]]
*Envoyé :* mercredi 5 juillet 2017 18:39
*À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
*Cc :* [email protected] <mailto:[email protected]>; multipathtcp
*Objet :* Re: [Int-area] SOCKS 6 Draft
<SNIP>
On 7/5/2017 9:00 AM, [email protected]
<mailto:[email protected]> wrote:
<SNIP>
*De :*Vladimir Olteanu [mailto:[email protected]]
*Envoyé :* mercredi 5 juillet 2017 01:35
*À :* BOUCADAIR Mohamed IMT/OLN; David Schinazi
*Cc :* [email protected] <mailto:[email protected]>; 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
