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

[<[e-mail]>]

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[e-mail]]
Envoyé : jeudi 27 avril 2017 19:09
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work


Med,

On 4/26/2017 11:53 PM, [e-mail]<mailto:[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.
[Med] Hmm…a router does not act on port numbers.


MPTCP is not a router. It is a transport protocol stack.
[Med] Same as a NAT that relies on transport ports to demux connections. This is why we have TCP/UDP BEHAVE RFCs.

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.
[Med] We are not changing the TCP state machine, we are relying on the one defined in standards track IETF documents.




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.
[Med] The external behavior is that a received SYN will trigger an outgoing SYN. What happens inside the proxy itself is implementation-specific.

"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?
[Med] It extracts the address/port of the remote server and sends a SYN to that address/port.

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.
[Med] The proxy can (1) complete the 3WHS to the client; the document says the following:

   “Conceptually, the MCP acts as a relay between an upstream MPTCP
   connection and a downstream TCP connection.”


   “The MCP maps an upstream MPTCP connection (and its associated
   subflows) onto a downstream TCP connection.”


   “At this point, there are two established connections.  The endpoints
  of the upstream Multipath TCP connection are the Multipath TCP Client
   and the MCP.  The endpoints of the downstream TCP connection are the
   MCP and the Server.  These two connections are bound by the MCP.”

or (2) can proceed a la NAT (e.g., Fig 5).

We have trade-offs: if we complete the 3WHS before an answer is received from the server, we lose the following feature that we would like to offer:

   Whether an MCP must be maintained in the processing of an MPTCP
   connection that involve MPTCP-capable clients and server is a
   configurable parameter.

Whether we need to have both or recommend one approach is be worked out once we have a WG document.
The specification is not frozen and your suggestions/comments will be taken into account.


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?
[Med] We are achieving 0-RTT MPTCP proxying because :

·         We don’t have out of band signaling to communicate with the proxy (for the record, there are +10 TCP messages when SOCKSv5 is in use).

·         The initial SYN includes the information about the ultimate server; that server will be contacted immediately.

For example, because we are leveraging on BEHAVE RFCs, a proxied MPTCP connections will experience the same delay as a TCP connection that goes through a CGN/NAT64.


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.
[Med] OK, thanks. It is not different.



-   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.
[Med] They are different things but achieve the same purpose: preserve the server from misuse/abuse/DoS. Whether MPTCP proxy has to check new/old connections is deployment-specific.

 ...


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.
[Med] Can you provide an example of attack you have in mind for the MPTCP proxy?


Joe