Re: [multipathtcp] Consensus call on potential MPTCP proxy work

[Joe Touch <[e-mail]>]

Med,


On 4/26/2017 11:53 PM, [e-mail] wrote:
> ...
>
> IMO, it is - it's a patch to help support the deprecation of IPv4 in
> the global Internet. I don't see that as the role for an MPTCP proxy.
>
> [Med] The main point Joe is that the IETF has standard track documents
> that specify a TCP state machine when NAT is used. We are leveraging
> that state machine for the MPTCP proxy work.
>

A NAT is - at best - a variant of a router.

MPTCP is not a router. It is a transport protocol stack.

You're not changing the TCP state machine - you're claiming that two TCP
connections are somehow tied together inside the TCP stack - that's a
fundamental change to the definition of TCP that is far outside the
scope of this WG.


>
>
>
> The IETF has also a "Standards Track" document called SOCKSv5
> (RFC1928) that is splitting the TCP connection. We are adhering to the
> logic of that RFC but without the drawbacks of SOCKS.
>
>  
>
> Can you clarify where you see split TCP in RFC1928,
>
> [Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see
> “split TCP” in the plain-mode draft.
>
> Nothing in RFC1929 talks about translating SYNs
>
> [Med] I guess you meant RFC1928. Translating packets is not explicited
> in the text, but it is hinted. For example, the text says the following:
>
>  
>
>    When a TCP-based client wishes to establish a connection to an object
>
>    that is reachable only via a firewall (such determination is left up
>
>    to the implementation), it must open a TCP connection to the
>
>    appropriate SOCKS port on the SOCKS server system.
>
>  
>
> How a connection from a client to a server with DST@=SOCKS_Proxy will
> be relayed to that remote server without gluing connections in both
> sides?
>
It's called a conventional proxy. The 3WHS completes to the SOCKS
server, then the SOCKS server opens a new connection.

"open a TCP connection" means finishing the 3WHS.

> That “glue” can be seen as translating packets by means of SNAT/DNAT.
>
>  
>
> (side note: I’m sure that RFC1928 will never be published as it is in
> 2017. I hear from here people that will argue that RFC1928 is
> underspecified) 
>

They can update that RFC if they want. However, that RFC specifies a
conventional application layer proxy - see Section 3.

>  
>
> - it doesn't even mention specific TCP segments at all, but refers
> only to the standard TCP API, where user data would be available only
> after the 3WHS between the client and the SOCKS proxy.
>
> [Med] That’s also the case for the MPTCP proxy. The user data will be
> available ONLY once the 3WHS is completed.
>

So a SYN arrives at the MPTCP proxy from the client. What happens next?

If the answer isn't "complete the 3WHS to the client", it's wrong. But
that's not what FIg 5 in your doc shows.

>
> Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN
> generating an outgoing SYN before the client SYN/ACK is returned. You
> don't mention split-TCP (and it has taken more than too long to figure
> out that's what's going on here), but that is what you show.
>
> or are you confusing it with this, which adds split TCP to a SOCKS proxy:
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf
>
>  
>
> [Med] Bingo. That is exactly my point. We need to avoid mixing
> implementation details with base specifications. That is exactly the
> reason why I said earlier that mptcp proxy documents only describe the
> external behavior.
>
> OK, so keep ALL discussions of SYN (or any segment translation) out of
> this document - including the figures.
>
> [Med] I’m personally fine with your proposal, but I’m sure we will
> have a lot of comments asking for more details. Figures are not
> normative; they are provided for illustration purposes.
>
> If you can explain this using the existing TCP API, e.g.,
> OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.
>

How do you achieve zero-delay E2E otherwise? Or are you assuming
zero-delay only within the MPTCP connection?

>
> But nowhere in that API does TCP tell you when a SYN arrives *before*
> sending a SYN-ACK.
>
> -----
> As to your TFO argument, the problem is this:
>
>     - what happens to the first MPTCP connection from proxy to proxy?
>
> [Med] Do you mean the first MPTCP connection that is proxied?
>
Yes.

> Or the first subflow of a proxied MPTCP connection?
>
>
>             why do you treat this differently than a typical MPTCP,
> and what information lets you do so?
>
> [Med] Can you please explicit your question? Are you referring to a
> multipath client, multipath server, or proxy?
>

I'm asking how the MPTCP connection between the two proxies is different
from a typical MPTCP connection as currently specified.

> -    No change is required for MPTCP-unaware clients and servers.
>
> -    MPTCP processing at the MPTCP-aware server follows the base MPTCP
> specification.
>
> -    MPTCP processing at the MPTCP-aware client in the dual-proxy case
> follows the base MPTCP specification.
>
> -    MPTCP processing at the MPTCP-aware client in the single-proxy
> case will require to supply the MP_CONVERT in the initial subflow. A
> part from that, it follows the base MPTCP specification.
>
> -   MPTCP processing at the proxy will require to process the
> MP_CONVERT information in order to create a forwarding state for that
> MPTCP connection. A part from that, it follows the base MPTCP
> specification.
>
I'm less interested in the details of the MPTCP options than in how the
API changes.

The current MPTCP API opens initial connections only in response to user
calls to OPEN. That doesn't appear to be the case here.

>
> I don't see anything in this doc that qualifies as what TFO calls
> either a cookie between sessions or any substitute based on
> authentication or authorization.
>
> [Med] I already provided a pointer to the slides where this is
> discussed. You can also refer to
> draft-nam-mptcp-deployment-considerations-01#section-5.3
> <https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-5.3>:
>
>
>  
>
>    The Network Provider that manages the various network attachments
>
>    (including the MCPs) may enforce authentication and authorization
>
>    policies using appropriate mechanisms.  For example, a non-exhaustive
>
>    list of methods to achieve authorization is provided hereafter:
>

You're talking about authorizations of users and access control. TFO is
authorizing connections in order to decide if they're new or old.
They're different things.

>  ...
>
>
>
> I agree that you're not strictly cloning TFO - IMO, you're trying to
> reinvent TFO without leveraging the experience the community has
> developed in that process, and IMO you're repeating some of the
> mistakes on that journey.
>
> [Med] I strongly disagree with this. We are leveraging on the guards
> as discussed in TFO specification:
>
> -    Anti-spoofing filters are in place in the access segment.
>
> -   TFO specification describes a cookie-less scheme if the server is
> immune.
>

And I disagree that you have proven your server to be immune.

Joe