Subject: [multipathtcp] MPTCP and Middleboxes

From: Edward Lopez <[email-masked]>
Date: Mon, 29 Jul 2013 16:37:10 +0000

I apologize as I am new to the mailing list, and it may be that some of this has already been answered.  Upon listening to Olivier's excellent presentation, I developed a simple VM-based environment to consider the implications of MPTCP on a middlebox:

  |------------ MBOX_A ------------|
  |              |  |              |
MPTCP_1      |---|  |            MPTCP_2
  |          |      |              |
  |----------[- MBOX_B ------------|
             |   |
             |   |
            Internet

Subnet MPTCP_1<>MBOX_A = 192.168.6.0/24
Subnet MPTCP_2<>MBOX_A = 192.168.7.0/24
Subnet MPTCP_1<>MBOX_B = 192.168.9.0/24
Subnet MPTCP_2<>MBOX_B = 192.168.10.0/24
Subnet MBOX_A<>MBOX_B = 192.168.100.0/24

In all cases the MPTCP host is .2 and and MBOX is .1, except on the MBOX_A<>MBOX_B subnet, where MBOX_B is .2.  All routing has been statically defined on the MBOX devices, so that full reachability is established.  When MPTCP is configured, the routing as configured as defined by the 'multipath-tcp.org<http://multipath-tcp.org>' website.  When MPTCP is disabled, or for non-TCP traffic, the default gateways on the MPTCP devices point to MBOX_A

Each MBOX has been configured to support data leakage protection (DLP), where it is detecting the transfer of files which have been specifically fingerprinted.  I have provide the fingerprint pattern of large PDF files on an Apache server on MPTCP_2.

With MPTCP disabled, all traffic flows across MBOX_A, and MBOX_A correctly detects and alerts on the transfers of fingerprinted files.  However, when MPTCP is configured, neither MBOX detects the transfer of fingerprinted files, since the transfer is taking place across two separate TCP sub-flows, and the MBOX units are operating independantly.  I suspect that any content inspection or heuristic/statistical detection technologies (AV, IPS, DoS, etc.) would be similarly affected.

This is a double-edged sword.  Basically MPTCP is effectively allowing asymmetric data flows relative to the MBOX units, while effectively defeating any asymmetric traffic defenses.  It is not clear to me that a middlebox, upon detective an MPTCP sub-flow, can meaningfully single to the MPTCP unit initiating the session that an MPTCP session is unacceptable, and must be defaulted down to a simple TCP session.

I am of the mindset that middlebox providers should look towards providing MPTCP proxy services, which may actually be useful in providing MPTCP support for hosts that do not natively provide it.  But it seems that we need to provide a explicit means for intermediate devices to request an MPTCP session be restarted as a standard TCP session.

Again, I apologize if this topic has been covered.  I appreciate any input on this topic.

Thanks!
Ed

Ed Lopez - Fortinet
VP, Carrier Solutions
1090 Kifer Road
Sunnyvale, CA 94086
Cell: +1 703 220 0988
[email-masked]<mailto:[email-masked]>

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Catalin Nicutar <[email-masked]>
Date: Mon, 29 Jul 2013 20:39:45 +0300

Hello,

On Mon, Jul 29, 2013 at 7:37 PM, Edward Lopez <[email-masked]> wrote:
> It is not clear to me that a middlebox, upon detective an MPTCP sub-flow,
> can meaningfully single to the MPTCP unit initiating the session that an
> MPTCP session is unacceptable, and must be defaulted down to a simple TCP
> session.
> [....]
> But it seems that we
> need to provide a explicit means for intermediate devices to request an
> MPTCP session be restarted as a standard TCP session.

If I understand your question correctly, the middlebox would simply have to
strip the MPTCP option during the handshake and the connection would
automatically fall back to regular TCP. There also provisions for falling
back to TCP after the handshake, when data has already been ACKed
at the connection level.

Best regards,
Catalin Nicutar

---

From: Edward Lopez <[email-masked]>
Date: Tue, 30 Jul 2013 05:00:16 +0000

I concur with the fallback capabilities, but in the bigger picture, it is certainly not desirable to have for example enterprise next-generation firewalls doing this on a persistent basis.  As I see it so far, there are four models for how such middleboxes should participate.

1) Acceptance - This is in the case of middleboxes that are unaware of mctcp, and continue operation.  Such would be the case of stateful firewalls, load-balancers, etc. which are not performing any application-layer inspections or transforms.  However, devices that are ignorant of mptcp while performing application-layer services will find mptcp as a potential vulnerability
2) Fallback - The middlebox detects the mptcp and forces a fallback to simple tcp.  As noted, this can be done, but it is not desirable to have middleboxes purely treat mptcp as a vulnerability to be suppressed
3) Aggregate - It seems likely that in many cases, particularly in the case of enterprise gateway implementations, that all tcp sub-flows will pass through a single middlebox.  In this case, the middlebox provider can choose to passively all sub-flows in aggregate to perform its desired functions
4) Proxy - I see it likely that middleboxes will actually perform simple tcp to mptcp proxy services.  This could be useful in a number of architectures

In my opinion, if mptcp is to achieve standardization, we need to have a closer look at how middleboxes will participate.  It is currently far too easy for middlebox providers to force fallback to simple tcp or otherwise treat mptcp as a vulnerability to be detected and corrected.  I see the potential value of support of the aggregate and proxy models, which in turn strengthens support of the mptcp protocol itself.

Thanks!
Ed Lopez

On Jul 29, 2013, at 1:39 PM, Catalin Nicutar <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

On Mon, Jul 29, 2013 at 7:37 PM, Edward Lopez <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
Catalin Nicutar

---

From: Scott Brim <[email-masked]>
Date: Tue, 30 Jul 2013 08:20:33 +0200

IMHO you are right.  A similar problem occurs in reverse, with intrusion
detection systems on multiple ingresses into a site.  The answer for
those boxes seems to be to be conservative and simply not allow traffic
that looks like partial sessions.  Unfortunately IDSs and other
middleboxes are becoming more useful, not less.

Scott