Re: [multipathtcp] MPTCP and middle box behavior

[Olivier Bonaventure <[e-mail]>]

Ed,

> I just posted a draft, labeled 'draft-lopez-mptcp-middlebox-00’ on
> 'Multipath TCP Middlebox Behavior’.  This draft explores the potential
> impact of existing middleboxes onto MPTCP sessions, as well as predicts
> potential responses by developers and deployers of middleboxes.  I
> appreciate your review and comments.

Thanks for your draft. As I'm not in Hawai, here are some initial comments.

Section 1

The MPTCP design was heavily influenced by the requirement to traverse 
various types of (TCP-aware) middleboxes. As you point in your document, 
there will probably be MPTCP-aware middleboxes that will appear in the 
future.

When considering these middleboxes, we need to distinguish between 
implicit middleboxes that operate "transparently" on-path and explicit 
middleboxes. Usually, neither the client nor the server are aware of the 
existance of the on-path middleboxes. Such middleboxes exist, but pose a 
wide range of problems as explained in
http://www.ietf.org/id/draft-hildebrand-middlebox-erosion-01.txt

This short draft should be read by anyone working on middleboxes...

The explicit middleboxes are more interesting and more useful to 
discuss. These middleboxes can be known by the client and/or the server. 
An example of an explicit middlebox is an MPTCP-aware load balancer that 
sits in front of a normal TCP server.



Section 2

" The existence and utilization of multiple forwarding
    paths, and the use of different IP source and destination addresses
    on each subflow is inconsequential to the network, as it is the MPTCP
    endpoints that are responsible for the overall MPTCP session
    integrity."

I agree with the first part of the sentence. We are now on an Internet 
which is different from the Internet of the early 2000s when most 
middleboxes that are deployed today were invented. Today, a typical 
device has multiple interfaces. Even the single-homed devices have 
multiple addresses when they are dual-stack. Unfortunately, many 
middleboxes still assume that we live in an early 2000s Internet.

Now that endhosts have multiple addresses, they try to use them. Various 
techniques exist and are used at different layers of the protocol stack. 
At the application layer, happyeyeballs uses different 
interfaces/addresses to distribute http requests. Several applications 
use HTTP range requests to distribute data over different interfaces.

Thanks to its standardisation, MPTCP should be considered as an 
opportunity to better organise the utilisation of the different 
interfaces on the endhosts.

" A strong example of an
    erroneous middlebox result would be the resulting false-negatives due
    to failures in signature-matching functions, since the matching data
    is distributed across multiple TCP subflows. "

An explicit middlebox would by design be able to see all the packets 
belonging to an MPTCP connection. Reassembling all the data at the MPTCP 
level is different than reassembling at the TCP connection level but is 
feasible. This will require additional code on the middelboxes that want 
to observe all the traffic.

2.1

The single-session bias is inded a problem for many existing middleboxes.

"However, other packet transformations, such as
    manipulation of DiffServ values or payload substitutions, can have
    very unintended effects of the overall MPTCP session."

I do not understand how Diffserv tagging would affect MPTCP. Could you 
be more precise ?

Concerning payload substitution, if the length of the data changes, 
MPTCP would fall back to regular TCP thanks to the DSS checksum (if 
enabled).

" The issuance
    of a TCP reset (RST) by a middlebox only fast closes the individual
    TCP subflow, and not the overall MPTCP session. "

Indeed and as explained in 
http://tools.ietf.org/html/draft-bonaventure-mptcp-tls-00 MPTCP can 
react to a RST inserted by a middlebox and reestablish a subflow over 
the same or another path.

"Ultimately, the
    solution to overcoming single-session bias effect will require
    evolution of middleboxes that are MPTCP-aware."

MPTCP-aware middleboxes should be explicit and not implict. There are 
many interesting things that can be done with explicit middleboxes, see 
e.g.
http://inl.info.ucl.ac.be/publications/multipath-middlebox
http://inl.info.ucl.ac.be/publications/evolving-internet-connection-acrobatics

2.2

"A grave issue would be in the substitution of data within a single
    TCP subflow, and its impact on the overall MPTCP session.  There are
    no functions defined in which the integrity of data contained within
    one TCP subflow is validated by another subflow. "

I'm not sure I correctly understand these sentences. Do you discuss the 
substitution of data by a middlebox or something else ? What kind of 
function integrity would you expect ?

3 Independent Responses By Middlebox Providers

    "The likely outcome is that providers of middleboxes will initially
    view MPTCP traffic as an attack relative to their operation. "


A consequence of this could be that MPTCP hosts would see middlebox 
interference as an attack on a given path and could decide to stop using 
this path. For example, consider a smartphone that uses 3G and WiFi. If 
there is a middlebox on the WiFi path that blocks MPTCP, then the 
smartphone could decide to only use 3G where there is no middlebox 
interference.

3.1 MPTCP Fallback to TCP

"   This is easily accomplished in one of two ways.  First is to drop TCP
    traffic that contains TCP Options for MPTCP.  Second is to filter out
    TCP Options for MPTCP, and forward the packet without the options."

This is what some firewalls do today by removing the MP_CAPABLE option 
from the SYN or replacing it with NOOP. Note that a host can detect this 
behaviour and stop using this path.

If middlebox vendors want to go in this direction, the clean solution is 
to remove the MP_CAPABLE option from the SYN segments.

3.2

"   It may also occur that a middlebox, rather than detecting the start
    of an MPTCP session, may instead detect the creation of a new TCP
    subflow via a Join Connection (MP_JOIN) MPTCP option.  The issuance
    of a TCP Reset (RST) would only affect this TCP subflow, but not the
    overall MPTCP session."

Removing the MP_JOIN option form the SYN would result in a RST and all 
the traffic would be sent on the other path where there is (hopefully) 
no middlebox.

"   RFC-6824 [RFC6824] does allow for fast closure of an overall MPTCP
    session, via the MP_FASTCLOSE option.  However, this option must be
    authenticated with the key of the host to which it is sent.  A
    middlebox, with only visibility of an MP_JOIN would not have
    knowledge of the key credentials of either Host A or Host B to be
    able to masquerade an MP_FASTCLOSE option.

    This is of course a trade-off.  While middlebox providers may desire
    the ability to issue third-party MP_FASTCLOSE options to both MPTCP
    hosts, providing the ability to do so would present a significant
    security challenge.  Middleboxes have little recourse when only in
    the path of secondary TCP subflows of an MPTCP session."

Again we need to distinguish between explicit and implict middleboxes. 
An implicit middlebox should not be able to close an MPTCP session. 
Otherwise an attacker could do the same. For explicit middleboxes, we 
could imagine solution where a host transfers some credentials (e.g. the 
authentication keys) to the middlebox.

There are other ways that a middlebox could mess up with MPTCP, but I 
don't think that it would be useful to list all possible interactions in 
an IETF draft.

3.5

"   The in-path model is in essence an MPTCP<>MPTCP proxy, in which a
    middlebox inserts itself as a man-in-the-middle (MITM) between two
    MPTCP endpoints"

By design, this in-path model is broken because it is impossible to 
ensure that all packets will always pass through the MPTCP proxy if it 
operates as a MITM. It could work in some ISP networks that control both 
WiFi and 3G and hope that all the traffic from their users will pass 
through their gateways, but users expect to be able to use any WiFi 
together with their 3G network and thus some traffic will bypass this 
transparent proxy.


"The out-of-path model assumes that MPTCP capable endpoints, or
    downstream devices, will encapsulate their traffic, or a copy of
    their traffic, to a third-party middlebox."

I think that we need to distinguish between server-side proxies and 
client-side proxies.

A server-side proxy is similar to a load-balancer and will probably rely 
on the DNS to announce itself and always appear on path.

A client-side proxy is different. The client needs to be explicitly 
configured to always forward its MPTCP traffic via its designated proxy. 
This proxy could provide additional services to the client such as 
firewall/IDS, session survivability when the client moves and becomes 
unreachable, data buffering, ... Encapsulation is a possible way to 
force the traffic from the client to reach the proxy, but there are 
probably other solutions.

"   Note that the MPTCP endpoints do not need to explicitly negotiate
    such a proxy, and may not even be aware of such a proxy taking
    place."

But one of the endpoints must be aware of the existence of the proxy. If 
you develop such a solution, then a chain of proxies should become possible.


Olivier
-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be