INTERNET-DRAFT X.Wei Intended Status: Standards Track C.Xiong Expires: January 2, 2016 Huawei Technologies E. Lopez Fortinet July 1, 2015 MPTCP proxy mechanisms draft-wei-mptcp-proxy-mechanism-02 Abstract Multipath TCP provides the ability to simultaneously use multiple paths between peers for a TCP/IP session, and it could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. This document discusses the mechanism of a new network entity, named MPTCP proxy, which is aimed to assist MPTCP capable peer to use MPTCP session in case of one of the peers not being MPTCP capable or to act as an aggregation point for sublfows. 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 X.Wei Expires January 2, 2016 [Page 1] INTERNET DRAFT MPTCP proxy July 1, 2015 Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 MPTCP Proxy models . . . . . . . . . . . . . . . . . . . . . . 4 4 MPTCP Proxy Solutions . . . . . . . . . . . . . . . . . . . . . 5 4.1 Mechanisms for on-path MPTCP proxy . . . . . . . . . . . . 5 4.2 Mechanisms for off-path MPTCP proxy . . . . . . . . . . . . 7 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 X.Wei Expires January 2, 2016 [Page 2] INTERNET DRAFT MPTCP proxy July 1, 2015 1 Introduction Nowadays, the volume of mobile devices, e.g. smart phone, has increased greatly, and most of these devices have more than one interface for network communication, for example it's very common for a smart phone to have a cellular network interface and a WLAN interface; at the same time, multi-homing scenarios have been more and more common. All these situations provide a good pre-condition for the implementation of MPTCP [MPTCP Protocol]. Some network operators also show interests in MPTCP, they want to utilize MPTCP's multipath feature to realize optimization of their network performances, such as resource pooling, network mobility etc. But there are still some barriers existing for the promotion of MPTCP, and one of them is that now almost all of the ICP (Internet Content Provider) servers on the Internet are traditional TCP servers and there seems no motivation for these traditional servers to embed MPTCP into their protocol stack, this situation leads to the fact that when communicating with these servers the MPTCP capable devices have to fall back to traditional TCP and cannot fully utilize their MPTCP capability. Besides, the multipath feature of MPTCP protocol brings impacts on the performances of some kinds of network middleboxes which are deployed to enhance network performance or to provide traffic optimization for network traffic. For example, middleboxes, such as HTTP proxy, video/audio optimizer and firewall are deployed enroute by network operators to provide performance enhancements, and all of these middleboxes need to have knowledge about the entire content of the traffic flow in order to function properly on the flow. But for MPTCP traffic, it is likely that only a part of subflows traverse the middlebox, and leads these middleboxes to be blind about the traffic, and the result would be that the endhost could not benefit from performance enhancement service or the traffic from endhost could be blocked by firewall because the firewall cannot trust the traffic. A more detailed description of MPTCP's impacts on middleboxes can be found in [Lopez]. For all the middlebox scenarios, we can conclude a basic requirement that the MPTCP traffic should be able to aggregate at middlebox. To support the use of MPTCP session between a MPTCP host and a TCP host, and to make MPTCP traffic get benefits from network middlebox that providing performance enhancement, this document defines a new entity named MPTCP proxy (or proxy for abbreviation). 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", X.Wei Expires January 2, 2016 [Page 3] INTERNET DRAFT MPTCP proxy July 1, 2015 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. MPTCP proxy (proxy): An entity used to support MPTCP session between MPTCP capable host and non-MPTCP capable host. ICP: Internet Content Provider. 3 MPTCP Proxy models To support the use of MPTCP session between MPTCP host and TCP host, or to help to aggregate MPTCP subflows, there are mainly two models of proxy for different scenarios: the first one is that the proxy is deployed on the common direct routing path of traffic from different access network, and this kind of proxy is referred as on-path proxy, an example is shown in Figure 1; the second one is that the proxy locates only on the direct routing path of traffic from one of the access networks the MPTCP capable host attached to, and this kind of proxy is referred as off-path proxy, an example is shown in Figure 2. _.---.. ,' `. .' Access +--| Network 1|-------+ | `. ,' | +--------+ | `.._,,,' | +--------+ +--------------+ |Host (A)|--+ +-----|MPTCP |----|Host(B) | |(MPTCP) |--+ ,--'''--. +-----|Proxy(P)| |(TCP) | +--------+ | ,' Access `. | +--------+ +--------------+ +-- Network 2---------+ ' `.._ _,,' `'' Figure 1: Scenario of on-path proxy deployment For the scenario shown in Figure 1, the MPTCP capable host A has two network interfaces and connects to two access networks simultaneously through the two interfaces. In this case, the proxy is located on the path shared by the two access networks' traffic, for example, the proxy could be deployed by Host B (e.g. OTT server) side. X.Wei Expires January 2, 2016 [Page 4] INTERNET DRAFT MPTCP proxy July 1, 2015 _.---.. ,' `. .' Access +--------+ +--------------+ +--| Network 1|---------|MPTCP |----|Host(B) | | `. ,' |Proxy(P)| | | +--------+ | `.._,,,' +--|-----+ +--------------+ |Host(A) |--+ | | |--+ ,--'''--. | +--------+ | ,' Access `. | +-- Network 2. | --------------+ `.._ _,,' `'' Figure 2: Scenario of off-path proxy deployment For the scenario shown in Figure 2, MPTCP proxy is located only on the direct routing path of traffic from one of the access networks the MPTCP capable host attached to, for example, the proxy could be located at aggregation point such as firewall. As shown in Figure 2, the MPTCP proxy is located on the natural routing path of traffic from access network 1, but not on the natural routing path of traffic from access network 2, which means when host A communicates using MPTCP with host B, the subflow through access network 2 will not be naturally routed to MPTCP proxy. The MPTCP communication in this scenario could occur between a MPTCP host and a TCP host, or two MPTCP hosts. The following sections will discuss the detailed mechanisms of on-path proxy and off-path proxy as introduced above. 4 MPTCP Proxy Solutions 4.1 Mechanisms for on-path MPTCP proxy When the direct routing path of all the sub-flows of a MPTCP capable host pass through the same proxy, the proxy will act as on-path proxy, and the on-path proxy could be transparent to the end host, i.e. end host itself knows nothing about the existence of the proxy. X.Wei Expires January 2, 2016 [Page 5] INTERNET DRAFT MPTCP proxy July 1, 2015 +-------+ +--------------+ +--------------+ |Host(A)| |MPTCP Proxy(P)| |ICP Server(B) | |(MPTCP)| +--------|-----+ |(TCP) | +-|-----+ | +-------|------+ |-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A)-->| | +---------------------------------+ | | |create temp. entry for connection| | | +---------------------------------+ | | |<--------SYN+ACK ---------| | +------------+ | | |create Key-P| | | +------|-----+ | <--SYN+ACK+MP_CAPABLE(Key-P)---| | | | | -ACK+MP_CAPABLE(Key-A,Key-P)---> | | |---------ACK--------------> | +------------+ | |<------Data----------->|Data Mapping|<----Data---------->| | +------|-----+ | | +--|------+ | |---------SYN+MP_JOIN-------> | | | | inspect | | <-----SYN+ACK+MP_JOIN-------- MPTCP | | | | signal | | |--- -----ACK+MP_JOIN-------> and | | | |establish| | <---------ACK --------------|sub-flow | | | +--|------+ | | +------------+ | |<======Data===========>|Data Mapping|<----Data---------->| | +------|-----+ | Figure 3: On-path proxy for connection between MPTCP Host and TCP Server The function of on-path proxy could mainly be divided into three sub- functions: supporting for initial MPTCP capability negotiation, supporting for sub-flow establishment and data mapping. Figure 3 shows an example signal flow for on-path proxy. The following clauses focus on the description of each sub-function. (1) Supporting for initial MPTCP capability negotiation The MPTCP capable host starts a connection establishment procedure by sending the first handshake packet with MP_CAPABLE option, including Host's Key-A, to ICP server; proxy inspects the packet and creates a temporary entry, which will be used to match SYN/ACK response from ICP server, for the connection, then the proxy forwards the packet to ICP X.Wei Expires January 2, 2016 [Page 6] INTERNET DRAFT MPTCP proxy July 1, 2015 server. (2)Supporting for sub-flow establishment After the initial MPTCP connection established, Host could choose to start a new MPTCP sub-flow. Because Host is unaware of the existence of proxy, so Host will start the new sub-flow with ICP server, i.e. the destination IP address of SYN/MP_JOIN packet is ICP server's IP address. The proxy inspects sub-flow establishment signal packet, i.e. SYN/MP_JOIN, and decides whether it has provided proxy function for the MPTCP session through the token included in MP_JOIN. If proxy has provided proxy function for the MPTCP session, then it will provide proxy function for the sub-flow; otherwise proxy will not take any action on the establishment of sub-flow. (3)Data mapping Proxy implements two separate kinds of data mapping: forward mapping and reverse mapping. Forward mapping means mapping data from MPTCP session to TCP session; reverse mapping means mapping data from TCP session to MPTCP session. Figure 4 shows the data mapping function of proxy. In forward mapping, proxy maps data from all sub-flows belonging to MPTCP session to a single TCP flow in TCP session. +-----------------------+ MPTCP | Mapping | TCP +--+ | +-----+ +---+ | +----------+ |Host|<===|>|MPTCP|<<<<>>>>|TCP|<-+-->|ICP server| +--+ | +-----+ +---+ | +----------+ |proxy | +-----------------------+ Figure 4: Data mapping function of proxy 4.2 Mechanisms for off-path MPTCP proxy When proxy locates on the initial sub-flow's direct routing path, but some other sub-flow's direct routing path might not go through the same proxy, then proxy could act in off-path model. The main difference between on-path model proxy and off-path model proxy is that in off-path model proxy needs to steer sub-flows to proxy, and Host will start new sub-flow with proxy, but not with its peer host. X.Wei Expires January 2, 2016 [Page 7] INTERNET DRAFT MPTCP proxy July 1, 2015 +-------+ +--------------+ +--------------+ |Host(A)| |MPTCP Proxy(P)| |ICP Server(B) | |(MPTCP)| +--------|-----+ |(TCP) | +-|-----+ | +-------|------+ |-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A) ->| | +---------------------------------+ | | |create temp. entry for connection| | | +---------------------------------+ | | |<--------SYN+ACK ---------| | +------------+ | | |create Key-P| | | +------|-----+ | <--SYN+ACK+MP_CAPABLE(Key-P,P)-| | | | | -ACK+MP_CAPABLE(Key-A,Key-P)--->---------ACK--------------> | +------------+ | |<------Data----------->|Data Mapping|<----Data---------->| | +------|-----+ | |<------ADD_ADDR(proxy IP)-----| | | +--|------+ | |------SYN+MP_JOIN----------> | | | | inspect | | <-----SYN+ACK+MP_JOIN-------- MPTCP | | | | signal | | |------ACK+MP_JOIN----------> and | | | |establish| | <---------ACK --------------|sub-flow | | | +--|------+ | | +------------+ | |<======Data===========>|Data Mapping|<----Data---------->| | +------|-----+ | Figure 5:Off-path proxy for connection between MPTCP Host and TCP Server Similar to on-path model proxy, the function of off-path proxy could also be divided into three sub-functions: supporting for initial MPTCP capability negotiation, supporting for sub-flow establishment and data mapping. Figure 5 shows an example signal flow for on-path proxy. (1) Supporting for initial MPTCP capability negotiation The MPTCP capable Host starts a connection establishment procedure by sending the first handshake packet with MP_CAPABLE option, including Key-A, to ICP server; proxy inspects the packet and creates a temporary entry, which is used by proxy to match SYN/ACK response from ICP server, then the proxy forwards the packet to ICP server. Proxy inspects the second handshake SYN/ACK packet from ICP server, if X.Wei Expires January 2, 2016 [Page 8] INTERNET DRAFT MPTCP proxy July 1, 2015 MP_CAPABLE option is included in SYN/ACK packet, then it means the ICP server is MPTCP capable and the proxy could choose whether to act as proxy or not for the connection, for example if the proxy wants to act as an aggregation point for MPTCP subflow traffics then it could choose to act proxy function for the MPTCP session; but if the purpose of proxy is just provide MPTCP support for communication between MPTCP host and legacy TCP host, then it could choose not to act proxy function; if no MP_CAPABLE option is included in SYN/ACK, the proxy will generate Key-P on behalf of ICP server to finish MPTCP connection with Host. To avoid Host starts the establishment of sub-flow with ICP server's IP address, proxy notifies Host the existence of itself through sending a P flag in MP_CAPABLE option in SYN/ACK packet. When Host receives this P flag it SHOULD NOT start the new sub-flow with ICP server's IP address any more, but chooses to establish sub-flow with proxy after obtaining proxy's IP address. There are reasons why a new P flag needs to be defined for explicit indication the existence of proxy, instead of implicitly inject the proxy into MPTCP session using existing MPTCP signaling , e.g. using ADD_ADDR/ADDR_JOIN to inform MPTCP host of proxy's IP address, and using REMOVE_ADDR to disable initial subflow between MPTCP host and its peer host:When a new subflow is to be established, the subflow management strategy should be considered. As stated in [MPTCP Experience], "The subflows are created immediately after the creation of the initial subflow", so MPTCP host might have started a new subflow before a REMOVE_ADDR is received, due to message delay or lost of REMOVE_ADDR, in that case the new subflow might be established between MPTCP host and its peer host but not between MPTCP host and proxy. (2)Supporting for sub-flow establishment In off-path model, after MPTCP capable Host has established the initial sub-flow in MPTCP session with the assistance of proxy, proxy could advertise its own IP address in ADD_ADDR option to Host, and then Host could establish new sub-flow with proxy. (3)Data mapping The data mapping function for off-path proxy is the same as the function described in on-path model. 5 Conclusion This document provides two kinds of proxy modes, which could be used to support MPTCP capable Host in two different scenarios. For the first on- path MPTCP proxy, there is no need to modify the current MPTCP stack implementation of the host; for the off-path MPTCP proxy, it requires X.Wei Expires January 2, 2016 [Page 9] INTERNET DRAFT MPTCP proxy July 1, 2015 the MPTCP capable host needs to support a new defined P flag. 6 Security Considerations The P flag provides a method for explicitly interpose a proxy function in MPTCP session, but this does not bring more security risks than MPTCP protocol itself, because even without P flag, an on-path middlebox could still interpose it in MPTCP session using existing MPTCP protocol signaling. 7 IANA Considerations A new flag 'P' in MPTCP MP_CAPABLE option [MPTCP Protocol] needs to be defined refer to RFC 6824, Section 3.1. This flag is used by proxy to inform MPTCP capable host the existence of proxy, besides the 'P' flag could also be used to inform other potential MPTCP proxy its presence. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+---------------+ | Kind | Length |Subtype|Version|A|P|C|D|E|F|G|H| +---------------+---------------+-------+-------+---------------+ | Option Sender's Key (64 bits) | | | | | +---------------------------------------------------------------+ | Option Receiver's Key (64 bits) | | (if option Length == 20) | | | +---------------------------------------------------------------+ 8 References 8.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [MPTCP Protocol]Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013, . X.Wei Expires January 2, 2016 [Page 10] INTERNET DRAFT MPTCP proxy July 1, 2015 8.2 Informative References [Deng] L.Deng, D.Liu, T.Sun. "draft-deng-mptcp-mobile-network-proxy- 01", April 18, 2014 [Lopez] E. Lopez. "draft-lopez-mptcp-middlebox-00", November 11, 2014 [MPTCP Experience] O. Bonaventure et al. "draft-ietf-mptcp- experience-00". September 16, 2014 Authors' Addresses Xinpeng Wei Huawei Technoligies Beijing, China EMail: weixinpeng@huawei.com Chunshan Xiong Huawei Technoligies Beijing, China EMail: sam.xiongchunshan@huawei.com Edward Lopez Fortinet 899 Kifer Road Sunnyvale, CA 94086 EMail: elopez@fortinet.com X.Wei Expires January 2, 2016 [Page 11]