Subject: [multipathtcp] MPTCP Proxy questions

From: Jordan Melzer <[email-masked]>
Date: Thu, 31 Jul 2014 19:38:06 -0600

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

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?

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