INTERNET-DRAFT E. Lopez Intended Status: Informational Fortinet Expires: May 15, 2015 November 11, 2014 Multipath TCP Middlebox Behavior draft-lopez-mptcp-middlebox-00 Abstract As implementation of MPTCP continues to grow, there will be interaction concerns regarding MPTCP sessions relative to the functionality of middleboxes, particularly those focused on network- based security. The purpose of this draft is to review this interaction of MPTCp sessions and middleboxes, the likely response of middlebox providers in dealing with any functional degradation due to MPTCP, and the potential requirements to support proxy functionality for MPTCP sessions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. E. Lopez Expires May 15, 2015 [Page 1] INTERNET DRAFT Informational November 11, 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Impact of MPTCP on Middleboxes . . . . . . . . . . . . . . . . 3 2.1 Single-Session Bias . . . . . . . . . . . . . . . . . . . . 4 2.2 Middlebox Function Degradation . . . . . . . . . . . . . . . 4 3 Independent Responses By Middlebox Providers . . . . . . . . . . 5 3.1 MPTCP Fallback to TCP . . . . . . . . . . . . . . . . . . . 5 3.2 Fast Closure of Existing MPTCP Sessions . . . . . . . . . . 5 3.3 Development of MPTCP-Aware Middlebox Functions . . . . . . . 6 3.4 Independent TCP<>MPTCP Edge Proxies . . . . . . . . . . . . 6 3.5 MPTCP Third-Party Proxies . . . . . . . . . . . . . . . . . 7 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 E. Lopez Expires May 15, 2015 [Page 2] INTERNET DRAFT Informational November 11, 2014 1 Introduction Multipath TCP (MPTCP) as described in RFC 6824 [RFC6824], provides for end-to-end support for sessions utilizing multiple TCP subflows to allow MPTCP sessions to benefit from the available performance increase and persistence of using multiple forwarding paths. A difficulty comes from the deployment of middleboxes performing traffic inspection functions that are unaware of the multipath nature of the overall session, as well as suffering from a lack of visibility to all of the data within the complete session. In either case, the functionality offered by the middlebox is degraded in the presence of MPTCP sessions, where this was not the case for TCP sessions. Much of this is based on the what could be termed the 'single-session bias' on the part of middlebox functionality. This means that the majority of functions supported by middleboxes, relative to TCP, assume that the information required by the function exists within a single TCP session. Clearly, the evolution of MPTCP invalidates this assumption or single-session bias. For example, a middlebox performing a network security function, such as intrusion prevention system (IPS), may not see all of the traffic required to match a signature within a single TCP subflow, even though the intrusion data is present within the overall MPTCP session. Even if this example IPS does happen to trigger on an intrusion, its actions would be likely be limited to the singular TCP subflow, rather than the overall MPTCP session. The purpose of this draft is discuss the impact of MPTCP sessions on middlebox operation, with an attempt to understand how middleboxes will respond to the growing presence of MPTCP traffic. The evolution of support for MPTCP on middleboxes will result in requirements to support proxy functions to allow the data from all TCP subflows associated with an MPTCP session to be examined at an aggregation point on the network. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Impact of MPTCP on Middleboxes Overall MPTCP sessions are an aggregation of one or more associated TCP subflows. Early implementations of MPTCP are generally E. Lopez Expires May 15, 2015 [Page 3] INTERNET DRAFT Informational November 11, 2014 associated with establishing sessions between endpoint devices, while intermediate network devices handling the TCP subflows do not require awareness of the overall MPTCP session to perform packet forwarding decisions. 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. However, intermediate network nodes, i.e. middleboxes, may perform functions on traffic other than forwarding. Such functions, if performed independently on a single TCP subflow, may provide erroneous or skewed results, as well as negatively impact the integrity of the overall MPTCP session. 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. A strong example of impact to the integrity of the MPTCP session would be the imposition of rate-limiting or packet transformation functions on the data contained within a single TCP subflow, and subsequent requirements placed on the MPTCP speakers to detect a degraded subflow. 2.1 Single-Session Bias Most middleboxes suffer from what can be termed a 'single-session bias', in which each session is considered a unique data transfer between two endpoints, such that the functions being performed by the middlebox are bounded to the data within that single session. In the case of TCP, sessions are seen as unique, rather than an element of an overall MPTCP subflow. Even if a middlebox were to have visibility to all of the TCP subflows associated with an MPTCP session, each subflow would be segregated from the others by a differential set of source and/or destination IP addresses, as well as by different TCP sequence values. Without an understanding of MPTCP, MPTCP sessions are impacted by the interaction of middleboxes on individual TCP subflows. MPTCP has been designed to be tolerant of NAT functions performed by middleboxes. However, other packet transformations, such as manipulation of DiffServ values or payload substitutions, can have very unintended effects of the overall MPTCP session. The issuance of a TCP reset (RST) by a middlebox only fast closes the individual TCP subflow, and not the overall MPTCP session. Ultimately, the solution to overcoming single-session bias effect will require evolution of middleboxes that are MPTCP-aware. 2.2 Middlebox Function Degradation E. Lopez Expires May 15, 2015 [Page 4] INTERNET DRAFT Informational November 11, 2014 The functionality provided by middleboxes is too large in scope to cover within a single document. However, we can extropolate possible avenues for their functional degradation and failure , based on understanding the nature of MPTCP. Since data within an MPTCP session can make use of multiple paths, a middlebox on any single path can suffer from a lack of complete visibility to the overall MPTCP session traffic. The likely outcome of this lack of visibility is a failure of middlebox function due to false-negative conditions. 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. Data substitution within a single TCP subflow impacts the integrity of the overall MPTCP session, and is a significant security issue relative to MPTCP session operation. 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. It is of course desirable for middleboxes to evolve to become MPTCP aware, and even support future MPTCP proxy functions. The following subsections describe methods in which middleboxes may respond to the presence of MPTCP traffic. 3.1 MPTCP Fallback to TCP The methodology for MPTCP session fallback to standard TCP is clearly defined in RFC-6824 [RFC6824], section 3.6. Therefore the conditions under which such fallback can occur become available actions under which a middlebox can react to the presence of MPTCP. By forcing fallback to standard TCP, the middlebox can effectively mitigate functional degradation issues associated with MPTCP. 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. 3.2 Fast Closure of Existing MPTCP Sessions 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. E. Lopez Expires May 15, 2015 [Page 5] INTERNET DRAFT Informational November 11, 2014 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. 3.3 Development of MPTCP-Aware Middlebox Functions Another area of advancement is in the development of MPTCP middlebox functions. Much of this effort would result in blacklisting/whitelisting of MPTCP-capable sites. For example, web filtering solutions may include information on if sites are MPTCP- capable, and offer middlebox operators the option to allow MPTCP sessions toward specific sets of sites, rather than in a general allow/block state. Note that this assumes that the middlebox is in the path of the initial TCP subflow establishing the MPTCP session. 3.4 Independent TCP<>MPTCP Edge Proxies When deployed close to endpoints, the development of TCP<>MPTCP proxies would allow middleboxes visibility to all traffic associated with an MPTCP seesion. If effect, the middlebox becomes the endpoint for the MPTCP session. This would require the development of an explicit proxy function to convert standard TCP sessions from endpoints into an MPTCP session from a multipath-capable middlebox. The Internet-Draft 'draft-wei-mptcp-proxy-mechanism-00' [WEI] provides an in-depth description of how such independent TCP<>MPTCP proxies could function. However, the use of such edge-proxies assume that: - The MPTCP edge proxy is in the primary forwarding path between endpoints- The MPTCP edge proxy would force fallback to TCP for MPTCP capable endpoints behind the proxy This would be necessary to prevent potential failures due to nested MPTCP sessions when both endpoints and middleboxes are MPTCP capable. E. Lopez Expires May 15, 2015 [Page 6] INTERNET DRAFT Informational November 11, 2014 3.5 MPTCP Third-Party Proxies While the development of MPTCP edge proxies is relatively straightforward, their deployment does not cover the cases under which a third-party can observe traffic from all TCP sub-flows for a given MPTCP session. It is not the intention of this draft to speculate on why it would be desirable to allow a third-party to perform such an aggregation of TCP subflows, and certainly from the standpoint of the MPTCP endpoints, such an aggregation is likely sub- optimal to the performance and resiliency of MPTCP sessions. However, the intent of this section regards what a third-party middlebox could do. Two distinct models for a third-party proxy can be described: an in- path model, and an out-of-path model. 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 Host A <============> Middlebox <============> Host B Within the in-path model, it could be assumed that the Middlebox could adjust the initiation of an MPTCP session, for example by modification of a DNS Reply message, indicating that Host B is masqueraded by an IP address on the Middlebox. Host A then initiates an MPTCP proxy to the Middlebox, which in turn by its proxy function then establishes a separate MPTCP session to Host B. 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. Traffic encapsulation can be used to differentially forward packets to a third-party. In this case, the third-party middlebox is assumed to be transparent to the MPTCP session establishment between endpoints. 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. 4 Security Considerations This draft is fully concerned about the integrity of MPTCP sessions as they traverse middleboxes imposed in their path. While the deployment of middleboxes may in fact be benevolent in intent or practice, such devices may currently suffer from a single-session E. Lopez Expires May 15, 2015 [Page 7] INTERNET DRAFT Informational November 11, 2014 bias relative to TCP subflows in an overall MPTCP session, which can cause erroneous or degraded functionality, with potential impact on the overall MPTCP session. As middleboxes become MPTCP aware, the rise of independent and third-party proxy functions may exploit MITM weaknesses available within and external to the MPTCP protocol. 5 IANA Considerations There are no new requirements for IANA consideration in this draft. However, 'draft-wei-mptcp-proxy-mechanism-00' [WEI] suggests that a new flag 'P' in MPTCP MP_CAPABLE option needs to be defined, refer to RFC 6824, Section 3.1. This flag could be used by a proxy to inform MPTCP capable host the existence of proxy, although as this draft suggests such proxies can we created without informing the MPTCP capable hosts of their presence. 6 References 6.1 Normative References [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. 6.2 Informative References [WEI] Wei.X, Xiong, C. "MPTCP proxy mechanisms", draft-wei-mptcp- proxy-mechanism-00, June 2014 Authors' Addresses Edward Lopez Fortinet 899 Kifer Road Sunnyvale, CA 94086 EMail: elopez@fortinet.com E. Lopez Expires May 15, 2015 [Page 8]