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

[<[e-mail]>]

Hi Jaliusz,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Juliusz Chroboczek [mailto:[e-mail]]
> Envoyé : jeudi 20 avril 2017 22:03
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> >>> What I meant by "native MPTCP connections" is that the CPE won't proxy
> >>> a SYN that contains MP_CPABALE received from an MPTCP-capable
> >>> client. That is, the CPE won't modify the destination IP address to
> the
> >>> one of the network-located proxy. That SYN+MP_CPABALE will be received
> >>> and handled directly by the remote server.
> 
> >> It will still act as a middlebox, though, with no way for the client to
> >> avoid it.
> 
> > No. This is not true.
> 
> > Connections that are not eligible to network-assisted MPTCP service
> > WON'T involve a proxy.
> 
> I've probably missed something, then.  I don't see anything in -10 that
> says that non-eligible packets are forwarded statelessly without any
> modification, including forwarding unknown IP and TCP options.

[Med] Two comments here: 

* We don't touch/alter existing IP/TCP options/EHs for ** both ** eligible and non-eligible flows. This is something we will call out explicitly in the document to avoid misinterpretation. We are adding MPTCP options at the TCP option level and MP_CONVERT IE in the first SYN.  That's all. 

* The document is focusing more on "what we are doing" not "what we are not doing". It says for instance: 

   Any data that is eligible to be transported over the MPTCP connection
   ^^^^^^^^^^^^^^^^^^^^^^^^
   is sent by the Client towards the MCP over the MPTCP connection.  The
   MCP then forwards these data over the regular TCP connection until
   they reach the server.  The same forwarding principle applies for the
   data sent by the Server over the TCP connection with the MCP. 

and

   Any data received by the upstream MCP over the upstream TCP
   connection will be forwarded by the MCP over the bound downstream
   MPTCP connection, assuming such data are eligible to MPTCP transport.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   The same applies for data received over the downstream MPTCP
   connection which will be forwarded by the upstream MCP over the
   upstream TCP connection.

So, other flows will be processed following any default forwarding behavior in place: that default may be NAT44, IPv4-in-IPv6 encap without NAT (DS-Lite), IPv4-in-IPv6 encap with port-restricted NAT (MAP-E, lw4o6), CLAT (464xlat), IPv4/IPv6 translation (MAP-E), ....

The text will be updated to call this out.       

  All I see
> on the subject is Section 4.3 paragraph 2, which I find hardly reassuring.
> 
> My gut feeling is that either the proxy is implemented at the upper
> layers, in which case it terminates all connections and hence discards any
> unknown options, or it is implemented at a lower layer, allowing it to
> bypass selected packets, in which case it is no longer a mere upper layer
> proxy.  I just don't see how you can have it both ways.
> 
> Could you please explain what I'm missing?

[Med] 
* This is an MPTCP proxy that does not need to understand IP/TCP options that are carried in the original SYN. 
* The proxy located at the network side does only process packets that are destined explicitly to it (i.e., DST@ of the packet==proxy@). 
* Packets that are not eligible to MPTCP-assisted service, will be forwarded without involving a proxy. 
* Even if that proxy is embedded in a device that is on a default forwarding path, the proxy won't intercept those packets because the destination address != proxy@. 

> 
> -- Juliusz