Re: [multipathtcp] MPTCP Proxy questions

[Weixinpeng <[e-mail]>]

Hi Jordan,
Please see comments inline. Thanks!
BR,
Xinpeng

From: multipathtcp [mailto:[e-mail]] On Behalf Of Jordan Melzer
Sent: Friday, August 08, 2014 3:03 PM
To: [e-mail] Mailing List
Subject: Re: [multipathtcp] MPTCP Proxy questions


Thank you Xinpeng.

I realize I accidentally wrote “off-net” instead of “off-path”.  The “off-path” link is the bottom one that goes around the proxy.  Hopefully that clears up some of my comments.  If both hosts are MP-capable, the “off-path” link may be something we would like a proxy that is trying to insert to allow and not affect.

For the case where a client is MP-capable but the server is not, the only change in behaviour to what you outline in your draft is that the proxy uses a REMOVE_ADDR message instead of the P flag to suppress the second sub-flow establishment.  Your solution based on the “P” flag involves fewer packets and clearly has no race condition.  I didn’t feel that the draft directly addressed what the alternative to the new flag was and how that flag was an improvement.

[Wei] Honesty speaking, there is no significant difference between a legal proxy and a malicious MITM, because the security mechanism provided by MPTCP is not aim to protect the communication session for the case a MITM locates on the path between two hosts, so an entity locates on the path can do **everything** it wish agnostically to end host including acting as a proxy. The reason why “P” flag is preferred is that we want to inform the existence of proxy to end host, so for the user side, it could choose to fall back to normal TCP in case it does not want to use the proxy.


Without the “P” flag, the flow might be as follows:

MP-Capable Client: A                MPTCP Proxy: P             Server: B
     ------                         ------                    ------

<session setup, proxy passes traffic with no changes>



        MP_CAPABLE (syn)   ----->

      [A's key, flags]

<Server response indicates it is not MP_CAPABLE>

                                                       <-----     syn/ack



                               <--- MP_CAPABLE (syn/ack)

                                    [P's key, flags]



      ACK + MP_CAPABLE      ->

      [A's key, P's key, flags]

                                                  ACK  ---->

<proxy adds a new address>


                                      ADD_ADDR

                               <-      [IP#-P1,

                                      IP#-P1's Address ID]

<proxy removes original subflow>

                               <-    REMOVE_ADDR
                                     [Address ID zero]

The client should now create subflows from each of its interfaces to the proxy.  The proxy transfers data back and forth between this connection with the client and the session it is conducting with the server using the spoofed IP of the client.  As I have not tried this, I cannot verify that it works.
[Wei] Seems the above flow chart would be ok for the scenario.

For the case where two hosts are MP-capable but single-interfaced and a proxy in the network with a west-facing interface of P1 and two east-facing interfaces (P2 and P3) and where P1 and P2 are naturally on-path, if the proxy would like to introduce new routes, the packet flow might look something like this:


MP-Capable Host: A                MPTCP Proxy: P           MP-Capable Host: B
     ------                         ------                    ------

<session setup, proxy passes traffic with no changes>



        MP_CAPABLE (syn)       --------------------->

      [A's key, flags]

                               <---------------------           MP_CAPABLE (syn/ack)

                                                             [B's key, flags]

      ACK + MP_CAPABLE      ----------------------->

      [A's key, B's key, flags]

<proxy adds a new address for each side>


                                      ADD_ADDR

                               <-      [IP#-P1,

                                      IP#-P1's Address ID]



                                      ADD_ADDR               ->

                                       [IP#-P3,

                                      IP#-P3's Address ID]
<when the client sends an MP_JOIN, the proxy changes the addresses / address IDs>





MP_JOIN               ->

      [B's token, A's nonce,

       A's Address ID, flags]





                               MP_JOIN               ->

                               [B's token, A's nonce,

                               P3's Address ID, flags]





                                                  <-          MP_JOIN

                                                             [B's HMAC, B's nonce,

                                                             B's Address ID, flags]







                        <-    MP_JOIN

                             [B's HMAC, B's nonce,

                              P1's Address ID, flags]









      ACK + MP_JOIN       ---  NAT -->

      [A's HMAC]



                           <--- NAT ----                        ACK

I would welcome suggestions on a better mechanism for this.  Let me note that the expired draft-hampel-mptcp-proxies-anchors-00 included quite a few approaches to proxying.

Re multiple sub-flows, if a client uses additional local ports, it can create multiple flows on a single interface.  By starting new flows on different ports, a client could try to probe for ECMP routes in the network.

Jordan


From: Weixinpeng [mailto:[e-mail]]
Sent: August 6, 2014 10:14 PM
To: Jordan Melzer; [e-mail]<mailto:[e-mail]> Mailing List
Cc: Xiongchunshan (Sam); 邓灵莉/Lingli Deng
Subject: RE: MPTCP Proxy questions

Hi Jordan,
Thanks for providing your valuable thoughts. I haven’t work on homenet, and I need to clarify something below before providing you my detailed comments. Thanks!

BR,
Xinpeng


From: Jordan Melzer [mailto:[e-mail]]
Sent: Thursday, August 07, 2014 5:55 AM
To: Weixinpeng; [e-mail]<mailto:[e-mail]> Mailing List
Cc: Xiongchunshan (Sam); Zhulei (MBB Research); 邓灵莉/Lingli Deng
Subject: RE: MPTCP Proxy questions

Dear Xinpeng,

Thank you for your comments, they are much appreciated.  To be clear, I did not write the slides I linked to on bonding two access networks – they were slides presented to the homenet group at IETF 90.  As one of their authors was from Huawei, you may have more insight into their use case than I do.  I have implemented a similar use case, one where a residential gateway uses WiFi (and specifically 802.11s) as an access mechanism in addition to DSL.  In both this use case and the homenets one, the end clients may have a single interface, with multiple interfaces becoming available at the residential gateway.  As you noted, a scenario in which the client has a single interface and is not MP-capable but is proxied by an MP-capable gateway is included in draft-deng-mptcp-proxy-00.

For these sorts of use cases, if we encounter a situation where the client is MP capable and the server is MP capable but both have a single interface, we would still want the residential gateway to do something to allow its two upstream connections to be used.  Similarly, we would want a client with a second, “off-net” interface to be able to use it.

Without off-net link:
+--------+     +-------+           +--------+
|        |     |       +------+    |        |
| client +-----+ proxy |      +----+ server |
|        |     |       +------+    |        |
+---+----+     +-------+           +--------+

With off-net link:
+--------+     +-------+           +--------+
|        |     |       +------+    |        |
| client +-----+ proxy |      +-+--+ server |
|        |     |       +------+ |  |        |
+---+----+     +-------+        |  +--------+
    |                           |
    +---------------------------+
[Wei] I am not quite clear about this figure: 1) what off-net link stands for? 2) For the endpoint of off-net link, one is client and what about the other end, is it something like a gateway? 3)how the off-net link acts?
Thanks for your explanation for these or you may providing some references for me.
The role of the “proxy” here is to allow its two upstream links to be used.  The criticism from the homenets slides about this being a network-layer problem may be somewhat valid, but the network layer doesn’t expose mid-network multipath topology to the transport layer and the network layer doesn’t solve this problem on its own.

Re the “off-net” proxy comments below, I was suggesting removing and adding addresses via MPTCP messages, rather than changing the address on packets.  The proxy can tell the client to add an address for it (I believe this can be done implicitly by sending a packet with one’s one address as the source) and remove the address for the server (an MPTCP option).  An MP-capable client will try out all of its interfaces against the proxy.  This is what I meant by leveraging the MITM to proxy all of the traffic.  As I have never actually tried this and missed whatever prior discussion there was at the design stage, I welcome comments on the list about whether or not this is a) correct and b) a feature.  I believe it to be both.  If this isn’t clear, I can try it again with a packet-flow diagram.
[Wei] It would be very much appreciated if you could provide a more detailed description for this. thanks.

Similarly, I believe that in the two scenarios above where obth sides are MP-capable but unable, on their own, to leverage multiple paths mid-network, the proxy could add its own interfaces to both sides and pass traffic back and forth across it, effectively allowing for the multiple paths mid-network to be used.  Another option would be for the default client behaviour to be to test out multiple flows on the different network interfaces in order to probe out ECMP routes and kill them off if they don’t add value.  It’s a bit aggressive, but it’s an end-to-end solution.  Bittorrent clients used to be (and probably still are) much more aggressive than this.
[Wei] 1) I think the above paragraph is about the scenarios that client is MP capable and the server is MP capable but both have a single interface, but if so, how to understand “test out multiple flows on the different network interfaces”?  2) how should I interpret “add its own interfaces to both sides”?

Thoughts?

Jordan

From: Weixinpeng [mailto:[e-mail]]
Sent: August-05-14 11:19 PM
To: Jordan Melzer; [e-mail]<mailto:[e-mail]> Mailing List
Cc: Xiongchunshan (Sam); Zhulei (MBB Research); 邓灵莉/Lingli Deng
Subject: RE: MPTCP Proxy questions

Hi Jordan,
Thanks for your questions.
Please see my comments inline. Thanks!

BR,
Xinpeng
From: multipathtcp [mailto:[e-mail]] On Behalf Of Jordan Melzer
Sent: Friday, August 01, 2014 9:38 AM
To: [e-mail]<mailto:[e-mail]> Mailing List
Subject: [multipathtcp] MPTCP Proxy questions

Hi everyone,

I recently implemented a simple “on-path” MPTCP “proxy” by running TCP MITM software (Mallory) on a machine with an MPTCP enabled kernel (UC Louvain).  It is not a sophisticated proxy – though Mallory’s plugin architecture could allow it to be – but having something running as a proxy raises a number of questions for me, and these may be of general interest.

The application I used it for is similar to the “hybrid access network” model recently presented within homenet: https://tools.ietf.org/agenda/90/slides/slides-90-homenet-2.pdf

While the homenet model sees LTE being used to augment DSL speeds, in my prototype multiple WiFi networks from neighbouring home gateways can be used to improve access rates at the home gateway.  The GRE-based solution suggested within homenet could only work with a single connection of unknown rate.  I used an on-path MPTCP proxy at the residential gateway, which is viable for aggregating any number of connections of unknown rate.  MPTCP was dismissed within the homenet proposal for being at the wrong layer.  I would welcome comments on that.  Another approach, one used by a system called Binder out of the University of Edinburgh (http://www.cs.stir.ac.uk/~mmf/res/pubs/lcdnet13.pdf) used an OpenVPN tunnel to ensure that all traffic was over MPTCP within the ISP network.  In this model and in the homenet one, there must be a tunnel termination point at the ISP.
[Wei] As my understanding, the purpose of work you are doing in homenet model is to use different network access service at home to simultaneously to provide a faster and reliable access rate for users?
For the following reasons listed in your slides that MPTCP is not suitable for your homenet:
– Application layer [Wei] It is more suitable to see MPTCP as a transport layer service not application layer.
 – Multihomed hosts rather than multihoming RG  [Wei] I think the MPTCP proxy mechanism could be suitable for multihoming RG scenario, the architecture have been mentioned in  draft-deng-mptcp-proxy-00, and we will discuss this latter version of draft-wei-mptcp-proxy-mechanism
 – Lack the mechanism on packet-based traffic [Wei]In MPTCP, packet distribution on different interfaces in decided by MPTCP itself.
   – TCP application only [Wei]Right.

In a proxy model, should MPTCP see wide deployment on the Internet, an ISP-side MPTCP proxy becomes superfluous.  What should happen when both sides are MPTCP enabled is a good question – how should the multiple paths available from the residential gateway onwards be signalled?
[Wei] Do you mean both end host are MPTCP capable? If that case, the proxy will not act as a proxy and have nothing to do with the traffic. Could you explain this in more detail? :“how should the multiple paths available from the residential gateway onwards be signalled?”


Re draft-wei-mptcp-proxy-mechanism-00.txt, the new feature suggested in the draft is a mechanism to indicate the presence of an “off-path” proxy and provide an IP address for it.  As it appears to be possible to leverage the MITM on the primary connection to address the off-path case by simply hijacking the connection through removing the original destination address and adding the proxy address, it would be helpful for the draft to directly address what makes the new mechanism suggested preferable to the mechanism that is already available.  Is an explicitly signalled proxy valuable for the kind of use case above, where multiple paths are available starting deeper in the network?
[Wei]  In off-path model，we assume that there is a proxy located in the path of initial sub-flow from MPTCP host, the reason why by simply hijacking the connection and replacing original destination address with proxy address is not enough is that if proxy’s address is not explicitly signaled to MPTCP host, for the subsequent sub-flows their destination address will be also TCP host’s address, and  these sub-flows are not assured to pass through the proxy that the initial sub-flow passed. Off-path model would be especially useful in case MPTCP host uses service from different network operators simultaneously.

I will have some comments on the larger proxy use cases draft later.  Despite having implemented what we are calling a proxy and having worked on a system that requires one, I am somewhat ambivalent about gateways that assist the user without the user’s consent, and am somewhat hesitant to even call them proxies – in other contexts a proxy is usually designated by a user
[Wei] There are different kinds of proxies which are transparent or non-transparent to end user, and I think we should only see the proxy with user’s consent as just one of them.
.  I don’t have a proposal yet on how to make proxying more consensual or to do useful things in situations where MPTCP is enabled but could work more effectively if the network provided more information about itself.  I would welcome either thoughts on those concerns or specific solutions.  Hopefully I’ll have some to suggest in the coming days.
Regards,
Jordan

Jordan Melzer
TELUS Communications