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é : mercredi 26 avril 2017 19:34
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work


Med,

On 4/26/2017 12:11 AM, [e-mail]<mailto:[e-mail]> wrote:
...
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.
[Med] NAT64 (RFC6146) is not a patch AFAIK.
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.



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

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

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.

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

-    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 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:

   o  The network provider may enforce a policy based on the
      International Mobile Subscriber Identity (IMSI) to verify that a
      user is allowed to benefit from the aggregation service.  If that
      authorization fails, the Packet Data Protocol (PDP) context
      /bearer will not be mounted.  This method does not require any
      interaction with the MCP.

   o  The network provider may enforce a policy based upon Access
      Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
      to control the CPEs that are authorized to communicate with an
      MCP.  These ACLs may be installed as a result of RADIUS exchanges,
      for instance ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]).  This method does not
      require any interaction with the MCP.

   o  The MCP may implement an Ident interface [RFC1413<https://tools.ietf.org/html/rfc1413>] to retrieve an
      identifier that will be used to assess whether that client is
      entitled to make use of the aggregation service.  Ident exchanges
      will take place only when receiving the first subflow from a given
      source IP address.

   o  The device that embeds the MCP may also host a RADIUS client that
      will solicit an AAA server to check whether connections received
      from a given source IP address are authorized or not
      ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]).


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.

Joe