Multipath TCP G. Hampel Internet-Draft T. Klein Intended status: Standards Track Alcatel-Lucent Expires: August 11, 2012 February 8, 2012 MPTCP Proxies and Anchors draft-hampel-mptcp-proxies-anchors-00 Abstract MPTCP proxies and anchors are network-based functions, which support MPTCP connections. The MPTCP proxy provides multipath support for MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This facilitates incremental deployment of MPTCP. The MPTCP anchor permits subflow establishment for MPTCP connections when direct interaction between end hosts fails. This permits tolerance to local IP protocol restrictions and it provides robustness in case of break- before-make mobility events. MPTCP proxies and anchors are especially suited for wireless access environments. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 11, 2012. Copyright Notice Copyright (c) 2012 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 Hampel & Klein Expires August 11, 2012 [Page 1] Internet-Draft MPTCP Proxies and Anchors February 2012 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. MPTCP Network Functions . . . . . . . . . . . . . . . . . . . 4 2.1. MPTCP Proxy . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. MPTCP Anchor . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Implicit vs. Explicit Proxies . . . . . . . . . . . . . . 5 2.4. Implicit vs. Explicit Anchors . . . . . . . . . . . . . . 5 2.5. End-Host Authentication . . . . . . . . . . . . . . . . . 6 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 4. Operation with MPTCP Proxies . . . . . . . . . . . . . . . . . 8 4.1. Introduction of Implicit Proxy . . . . . . . . . . . . . . 8 4.2. Subflow Management with Implicit Proxy . . . . . . . . . . 11 4.3. Introduction of Explicit Proxy . . . . . . . . . . . . . . 12 4.4. Subflow Management with Explicit Proxy . . . . . . . . . . 15 5. Operation with MPTCP Anchors . . . . . . . . . . . . . . . . . 16 5.1. Introduction of Implicit Anchor . . . . . . . . . . . . . 16 5.2. Subflow Management with Implicit Anchor . . . . . . . . . 17 5.3. Introduction of Explicit Anchor . . . . . . . . . . . . . 19 5.4. Subflow Management with Explicit Anchor . . . . . . . . . 21 5.5. Protocol Translation with Anchor . . . . . . . . . . . . . 21 5.6. Connection Robustness with Anchor . . . . . . . . . . . . 22 6. Host Configuration . . . . . . . . . . . . . . . . . . . . . . 23 7. New Signaling . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. PROXY Flag . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. ANCHOR Flag . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. JOIN Flag . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Anchor-Reserved Address-Id Value . . . . . . . . . . . . . 26 7.5. SEEK_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26 7.6. FWD_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Hampel & Klein Expires August 11, 2012 [Page 2] Internet-Draft MPTCP Proxies and Anchors February 2012 1. Introduction Currently, a host can enjoy the advantages of MPTCP only if its peer supports MPTCP as well [1]. This requirement creates an impediment to incremental deployment since the incentive for a host to upgrade to MPTCP is small as long as its potential peers have not upgraded too. The incremental deployment problem especially applies to wireless environments, where traffic is dominated by interactions between mobile clients and network-side servers. While MPTCP can be rolled out rather quickly on mobile devices due to their short life cycle and frequent kernel upgrades, changes on application servers are usually harder to conduct. Further, the benefit of MPTCP may be more obvious to mobile users than to application service providers. The incremental deployment problem can be overcome through the introduction of the MPTCP proxy, which resides in the network and provides MPTCP support for MPTCP-capable hosts (e.g. mobile devices) on behalf of their MPTCP-unaware peers (e.g. application services). Since MPTCP proxies will most likely be run by network operators rather than application service providers they can support a multitude of application services, which makes incremental deployment of MPTCP rather efficient. Further, network operators may see a benefit in MPTCP deployment since it adds value to the network services they provide and since they mostly support a billing mechanism to reimburse themselves from MPTCP operation. The MPTCP anchor is another MPTCP network function whose main purpose is to support end-to-end multipath connections. It operates as a subflow relay to facilitate subflow establishment between end points that do not enjoy direct reachability. This may happen, for instance, if the end points pertain to different IP protocols or if the hosts have lost end-to-end connectivity after a break-before-make mobility event. The anchor function is most beneficial for peer-to-peer applications such as voice/video communciations, which are run on MPTCP-enabled mobile or multi-homed devices. Flexibility in IP protocol support is important for this use case during the rollout of IPv6. The anchor function further allows the network operator to provide differentiated services for over-the-top applications. This document discusses relevant features and signaling enhancements needed for the support of MPTCP proxies and MPTCP anchors. Hampel & Klein Expires August 11, 2012 [Page 3] Internet-Draft MPTCP Proxies and Anchors February 2012 2. MPTCP Network Functions All network-based functions that interact with MPTCP connections through MPTCP signaling are referred to as "MPTCP network functions". MPTCP network functions are assumed to reside on "MPTCP network nodes". We consider two types of MPTCP network functions namely the MPTCP proxy and the MPTCP anchor. Anchor- and proxy functions can be collocated on one MPTCP network node. 2.1. MPTCP Proxy The MPTCP proxy supports MPTCP on behalf of an MPTCP-unaware host. It splits the connection between multipath-capable and multipath- unaware host into a MPTCP section and a TCP section, respectively (Figure 1). All subflows established by the multipath-capable host terminate at the proxy. Proxy operation is discussed in Section 4. ______ MPTCP TCP ______ | | | | | |-----------\ ________ | | | | \ | | | | | Host |-------------+| Proxy |---------------| Host | | | / |________| | | | |-----------/ | | |______| |______| Split connection with MPTCP Proxy Figure 1 2.2. MPTCP Anchor The MPTCP anchor provides a network-based access point (i.e. IP address), which a MPTCP host can use to create additional subflows to the peer. The anchor relays all packets arriving from this host to the peer and vice versa. This creates a split subflow consistent of one section between host and anchor and the other between anchor and peer (Figure 2). The anchor's operation involves address- and eventually also port translation. Anchors can also insert or modify MPTCP options of passing or relayed packets. Anchor addresses can be introduced during connection establishment or at any later point in time. Anchor functions can be invoked or released during the entire lifetime of the connection. An anchor function can interconnect end points using different IP Hampel & Klein Expires August 11, 2012 [Page 4] Internet-Draft MPTCP Proxies and Anchors February 2012 protocol versions with a subflow. In this case the anchor operates as an IP protocol translator (Section 5.5). The anchor also serves as a "meeting point" for the establishment of a new subflows when all other subflows have failed and direct end-to-end subflow establishment is not possible. This applies to scenarios where both end hosts have simultaneously moved or when one host moves while the other resides behind a firewall (Section 5.6). Anchor operation is discussed in Section 5. ______ ______ | | SFL_0 ________ SFL_0 | | | |------------\ | | /-------------| | | | SFL_1 +| Anchor |+ SFL_1 | | | Host |------------/ |________| \-------------| Host | | | SFl_2 SFL_2 | | | |---------------------------------------| | |______| |______| MPTCP connection with Anchor Figure 2 2.3. Implicit vs. Explicit Proxies An implicit proxy resides on the direct routing path between two hosts engaging into a connection. This allows the hosts to establish the connection directly with each other, while the proxy can derive all information via packet inspection, insert and modify packets as necessary and thereby create the MPTCP-TCP split connection. This proxy is referred to as "implicit" since not explicit signaling is necessary. When the proxy does *not* reside on the direct routing path between both hosts, explicit signaling is needed to introduce the proxy to the connection. The same applies to a proxy that does not reside on the path used for connection initiation. Such a proxy is referred to as "explicit" proxy. An implicit proxy typically resides on a central router in the access network used by one of the hosts during connection establishment. An explicit proxy can reside in any network. 2.4. Implicit vs. Explicit Anchors The terms "implicit" and "explicit" can also be defined for anchors. An implicit anchor resides on the routing path used by a subflow of a Hampel & Klein Expires August 11, 2012 [Page 5] Internet-Draft MPTCP Proxies and Anchors February 2012 MPTCP connection. This allows the anchor to derive all necessary connection-related information via packet inspection during the establishment of this subflow. Then, it can insert and modify packets as necessary and thereby offer anchor services to the end hosts. When an implicit anchor resides on the initial subflow, it can offer services to *both* end hosts. Otherwise, it can offer services only to the subflow-initiating end host (see Section 5). When the anchor does not reside on a direct routing path between both connection end points, explicit signaling is needed to introduce the anchor to the connection. Such an anchor is referred to as "explicit" anchor. Anchors can support connections between two hosts as well as between a host and a MPTCP proxy. Usually, anchors are more beneficial in the former of the two scenarios. 2.5. End-Host Authentication MPTCP proxies and anchors should support an explicit or implicit mechanism to authenticate one of the connection's end hosts. This allows the proxy- or anchor operator to charge for operation of the respective MPTCP network function. There are also security reasons that require end-host authentication as outlined in Section 8. Hampel & Klein Expires August 11, 2012 [Page 6] Internet-Draft MPTCP Proxies and Anchors February 2012 3. Deployment Scenarios The predominant use case for MPTCP proxies and MPTCP anchors is seen in wireless access networks. This is motivated by the increasing number of wireless devices that support multiple access technologies as well as multi-homing. In one deployment scenario, the MPTCP network function resides on a central router of a wireless access network, e.g. a 3G/4G mobile network. Especially 3G and 4G mobile network operators may see an incentive for MPTCP proxy support since it allows them to dynamically offload traffic from licensed to unlicensed spectrum. Further, 3G- and 4G mobile networks already provide a centralized architecture, security support and charging functions, which can be used for MPTCP proxy or anchor operation. There are also technical reasons to place MPTCP proxies inside cellular networks which are related to the wide-area coverage these networks typically provide. Therefore, the connection can be established via the cellular interface and subsequently migrated to other paths and networks. This substantially simplifies signaling since an implicit proxy/anchor can be used. Further, the cellular network can be used for reachability. It is expected that anchor- and proxy functions are collocated. For any deployment scenario, MPTCP-capable hosts need to be configured appropriately so that they can take advantage of implicit and explicit MPTCP network functions. Some aspects of host configuration are discussed in Section 6. Hampel & Klein Expires August 11, 2012 [Page 7] Internet-Draft MPTCP Proxies and Anchors February 2012 4. Operation with MPTCP Proxies Proxies must be introduced to the connection during connection establishment and stay engaged during the entire lifetime of the connection. 4.1. Introduction of Implicit Proxy MPTCP TCP ______ ________ ______ | | | | | | | Host | IP_A0 |Implicit| IP_B0 | Host | | A |--|--------|--| Proxy |--|---------|--| B | |______| SFL_0 |________| |______| | | _|_ _|_ |\ IP_A1 /| IP_PROX | \ / | | \----------------/ | | SFL_1 | | | \----------------------/ SFL_2 MPTCP-TCP split connection with implicit MPTCP proxy Figure 3 The MPTCP-capable host starts a MPTCP connection by sending a TCP SYN packet with MP_CAPABLE option to its peer. The proxy inspects the packet and caches the end point locators consistent of IP addresses and port numbers as well as the key enclosed in the MP_CAPABLE option. Based on these locators, the proxy identifies and intercepts the peer's SYN-ACK response packet. The implicit proxy does not change the locators contained on the packet. In case the SYN-ACK response does not hold the MP_CAPABLE option, the proxy initiates multipath support. It creates a key on behalf of the peer, inserts a MP_CAPABLE option with this key into the SYN-ACK packet, and then forwards the packet to the connection-initiating host. If the SYN-ACK response *does* contain an MP_CAPABLE option, the proxy is not needed. In this case, the network node can provide anchor functionality (see Section 5). Hampel & Klein Expires August 11, 2012 [Page 8] Internet-Draft MPTCP Proxies and Anchors February 2012 MPTCP MPTCP MPTCP TCP HOST NETWORK NODE NETWORK NODE HOST | | | | | SYN + MP_CAPABLE | | | | ----------------+--------------------+------------------->| | | | | | | add MP_CAPAPBLE_ | | | | \| SYN-ACK | |<-------------------+--------------------X--------------- | | | | | | | PROXY | | | P | | ACK + MP_CAPABLE | P | | ----------------+--------------------+------------------->| | | P | | | P | Connection initiation by MPTCP-capable host with implicit proxies on initial path Figure 4 If multiple implicit proxies reside on the initial path, the proxy closest to the peer should become the MPTCP end point. Since this proxy is the first to receive the peer's SYN-ACK packet, it automatically assumes multipath support by inserting the MP_CAPABLE option. Hampel & Klein Expires August 11, 2012 [Page 9] Internet-Draft MPTCP Proxies and Anchors February 2012 TCP MPTCP MPTCP MPTCP HOST NETWORK NODE NETWORK NODE HOST | | | | | | _add MP_CAPABLE | | | SYN |/ | | | -----------------X--------------------+------------------->| | | | | | | | SYN-ACK+MP_CAPABLE| |<-------------------+--------------------+---------------- | | | | | | PROXY | | | P _add MP_CAPABLE | | | ACK P/ | | | -----------------X--------------------+------------------->| | P | | | P | | Connection initiation by MPTCP-unaware host with implicit proxies on initial path Figure 5 The implicit proxy can also support scenarios, where the peer rather than the connection-initiating host is MPTCP-capable. In this case, the MPTCP proxy adds the MP_CAPABLE option with its own key to the initial SYN packet. If the SYN-ACK response by the peer carries the MP_CAPABLE header, the proxy assumes multipath support. If multiple proxies reside on the initial path in this latter case, the proxy closest to the session-initiating host should become the MPTCP end point. Since this proxy is the first to receive the peer's SYN packet, it automatically assumes multipath support by inserting the MP_CAPABLE option into this SYN packet. These signaling procedures work fine as long as at least one of the end hosts supports MPTCP. A problem occurs, when multiple proxies reside on the initial path but *neither* of the end hosts supports MPTCP. In this case, one proxy may add MP_CAPABLE to the SYN packet and the other to the SYN-ACK response packet. In this manner, both proxies end up creating a TCP-MPTCP-TCP split connection with multipath support between each other. Such a situation is likely to occur when each of the hosts' access networks supports a proxy. To avoid such a situation, the proxy inserting the MP_CAPABLE option into the SYN packet has to reveal its true nature by adding a PROXY flag to this option. When another proxy inspects the SYN packet and finds the MP_CAPABLE option with PROXY flag set, it should not insert Hampel & Klein Expires August 11, 2012 [Page 10] Internet-Draft MPTCP Proxies and Anchors February 2012 MP_CAPABLE to the SYN-ACK response. For implicit proxies, end-host authentication is implicitly provided by the host's access authentication as long as the proxy resides in the access network of one of the end hosts. This makes additional signaling for end-host authentication unnecessary. While this solution restricts operation of implicit proxies to access providers and their affiliates (e.g. roaming partners), it covers the most relevant deployment scenarios. 4.2. Subflow Management with Implicit Proxy Since the proxy splits the connection into a MPTCP section and a TCP section, it becomes the end point for all further subflows. These subflows may be initiated by the MPTCP-capable host or by the proxy itself. When the proxy is implicit, it must inform the multipath-capable host about its existence as well as its IP address. Otherwise, the multipath-capable host may try to establish subflows with the multipath-unaware peer. For this purpose, implicit proxies should set the PROXY flag on those MP_CAPABLE options they insert into SYN or SYN-ACK packets. This flag informs the multipath-capable host that the remote end point is represented by a proxy. After connection establishment, the proxy should advertise its address via ADD_ADDR to the multipath-capable host. This step is necessary since the host does not know the proxy's address. Currently, the ADD_ADDR option also conveys the request for immediate subflow establishment to the enclosed address. This request has the purpose to enable subflow creation in reverse direction, i.e. when the peer resides behind a firewall. Obviously, immediate subflow creation is not desirable when a proxy announces its IP address as an alterative end point. Therefore, the ADD_ADDR option should be furnished with a JOIN flag, which allows differentiating between the two purposes of ADD_ADDR. Hence subflow creation is only requested when the JOIN flag is set. Since MPTCP options are not delivered reliably, the ADD_ADDR option may get lost. In this case, the host has no means to find out about the proxy's IP address. For that reason, an additional SEEK_ADDR option should be supported which allows the host to solicit address advertisements by MPTCP network nodes and the peer. SEEK ADDR should hold a field for the IP version requested. If this Hampel & Klein Expires August 11, 2012 [Page 11] Internet-Draft MPTCP Proxies and Anchors February 2012 field is set to zero, addresses pertaining to any IP version can be advertised. 4.3. Introduction of Explicit Proxy ________ | | |Explicit| | Proxy | MPTCP |________| TCP | _|_ IP_PROX ______ /|\ ______ | | / | \ | | | Host | IP_A0 / | \ IP_B0 | Host | | A |--|------------/ | \-----------|--| B | |______| SFL_0 | |______| | /| _|_ IP_A1 / | |\-------------------/ | | SFL_1 | | | \-----------------------/ SFL_2 MPTCP-TCP split connection with explicit MPTCP proxy Figure 6 If the proxy does not reside on the direct routing path of the intended connection the connection initiator must provide the proxy with explicit information on the peer's network locator, i.e. IP address and port number. Since the explicit proxy may reside in a different network, additional signaling for host authentication has to be supported as well. In case connection establishment reveals that both end hosts support MPTCP (or if the peer is supported by an implicit proxy), the explicit proxy function is not needed. In this case, the MPTCP network node automatically assumes explicit anchor function since it splits the initial subflow. For connection establishment, the following signaling approaches are considered: o In-band MPTCP signaling: The peer's network locator (i.e. IP address and port number) and the host's authentication information are sent in-band on MPTCP options. Since the amount of Hampel & Klein Expires August 11, 2012 [Page 12] Internet-Draft MPTCP Proxies and Anchors February 2012 information is too large to fit into the TCP header of the initial SYN packet additional packets need to be exchanged for signaling purposes. A simple handhake can be realized where the MPTCP keys are used as authenticators (Figure 7): MPTCP EXPL MPTCP TCP HOST A NETWORK NODE HOST B | | | | SYN + MP_CAP(KEY_A) | | | -------------------------->| | | | | | SYN-ACK + MP_CAP(KEY_P) | | |<-------------------------- | | | | | | ACK + FWD_ADDR(IP_B) | | | -------------------------->| SYN + MP_CAP(KEY_A) | | | ----------------------------->| | | | | | SYN-ACK | | |<----------------------------- | | | | | PROXY | | P | | ACK + MP_CAP() P ACK | |<--------------------------- P ----------------------------->| | P | | P | Connection establishment with explicit proxy and in-band MPTCP signaling Figure 7 * The connection-initiating host (host A) sends the SYN packet with MP_CAPABLE containing key_A as authenticator to the explicit MPTCP network node which caches key_A and host A's locator. * The MPTCP network node answers with SYN_ACK enclosing MP_CAPABLE with key_P as its own authenticator. It should *not* set the PROXY flag, since it doesn't know at this point if proxy function is required. * Host A sends an ACK enclosing FWD_ADDR, which holds the peer's (i.e. host B's) IP address. FWD_ADDR may also hold a port number if it is different from the port number used to address Hampel & Klein Expires August 11, 2012 [Page 13] Internet-Draft MPTCP Proxies and Anchors February 2012 the MPTCP network node. * The MPTCP network node sends SYN with MP_CAPABLE holding key A to host B using its own IPaddress. It also sets the ANCHOR flag in MP_CAPABLE as discussed in Section 5. * If host B is not MPTCP-capable, it responds with a simple SYN- ACK packet. Otherwise, it inserts MP_CAPABLE with key B into the SYN-ACK packet. If MP_CAPABLE is absent, the MPTCP network node assumes proxy function. Otherwise, it assumes anchor function. * The proxy function sends an ACK to host A and encloses the MP_CAPABLE header with the PROXY flag set. This informs host A that host B does not support MPTCP and that the MPTCP network node has assumed proxy function. The MP_CAPABLE option does not have to hold any key at this point since all keying information has already been exchanged. * The proxy function also sends a simple ACK to host B. o Out-of-band MPTCP signaling: MPTCP introduces a separate signaling connection to exchange the necessary signaling information prior to establishment of the traffic connection. Since such an out-of- band solution substantially extends the present scope of MPTCP it is not further considered. o Independent signaling: The host and the explict MPTCP network node use an independent signaling protocol, in which the host authenticates itself and provides the peer's locator. This protocol can be supported on session or application layer such as SIP [2], for instance. In this protocol, host and MPTCP network node establish the 64-bit key, which is cached by the proxy together with the peer's locator and inserted by the host into MP_CAPABLE when initiating the MPTCP connection. This allows the network node to find the peer's locator and to forward the SYN packet to the peer using its own IP address. The network node should set the ANCHOR flag when relaying the MP_CAPABLE packet to the peer. In case the SYN-ACK return packet arriving from the peer does *not* contain an MP_CAPABLE option, the network node assume proxy function. In this case, the proxy inserts MP_CAPABLE into the SYN-ACK packet, sets the PROXY flag and sends the packet to the connection-initiating host using its own IP address and port number as the packet's source. The host responds with an ACK holding its own key as well as the key contained in the SYN-ACK packet. Security issues related to such explicit proxy solutions are Hampel & Klein Expires August 11, 2012 [Page 14] Internet-Draft MPTCP Proxies and Anchors February 2012 discussed in Section 8. It makes little sense to consider explicit-proxy scenarios where the connection-initiating host is not MPTCP-capable. 4.4. Subflow Management with Explicit Proxy Subflow establishment with an explicit proxy follows along the same lines as for an implicit proxy. The explicit proxy, however, does not have to send an ADD_ADDR option since the host already knows the proxy's address. Hampel & Klein Expires August 11, 2012 [Page 15] Internet-Draft MPTCP Proxies and Anchors February 2012 5. Operation with MPTCP Anchors The anchor function splits subflows into two subflow sections, where each section interconnects an end host with one of the anchor's IP addresses (Figure 8). The anchor relays all packets arriving on one subflow section to the other by rewriting the IP addresses of the packet headers. The anchor may also translate port numbers. Anchors can also insert or modify MPTCP options of passing packets. To keep end-to-end semantics in tact, the end nodes must have full awareness of the anchor's presence and its operation, i.e. if subflows are split and if an IP address belongs to an anchor or to the peer. Further, each host must know about the address-id its peer uses on the remote section of a split subflow. This ensures proper subflow tear-down in case the peer announces address removal via REMOVE_ADDR option. Anchors can be introduced during connection establishment or at any later point in time. Anchor services can be invoked or released during the entire lifetime of the connection. 5.1. Introduction of Implicit Anchor ______ ________ ______ | | | | | | | Host | IP_A0 |Implicit| IP_B0 | Host | | A |--|--------|--| Anchor |--|---------|--| B | |______| SFL_0 |________| SFL_0 / |______| | | / | _|_ _|_ / _|_ |\ IP_A1 / \ IP_ANCH / | IP_B1 | \ / \ / | | \----------------/ \-------/ | | Split SFL_1 Split SFL_1 | | | \----------------------------------------------/ SFL_2 MPTCP connection with implicit MPTCP anchor Figure 8 When an implicit anchor resides on the initial path, it caches the locators (i.e. IP addresses and port numbers) of the initial subflow as well as the keys exchanged during connection establishment. This allows the anchor to derive the corresponding tokens and cache them together with the end hosts' locators of this subflow. Hampel & Klein Expires August 11, 2012 [Page 16] Internet-Draft MPTCP Proxies and Anchors February 2012 Then, the anchor advertises its IP address to the end hosts by sending an ADD_ADDR option to one or to both end hosts. The ADD_ADDR option can be inserted into a packet that is passing on the initial subflow. The anchor may also insert a port number into the ADD_ADDR option. The anchor has to mark the ADD_ADDR option in a manner that allows the host receiving the option to distinguish it from an ADD_ADDR option sent by the peer. For this purpose, the anchor should set the address-id in the ADD_ADDR option to an anchor-reserved value (e.g. 255). This does not lead to any conflict in case multiple anchors advertise their addresses with the same address-id value, since anchor addresses are considered invariants that need not be removed. Obviously, neither end hosts nor proxies should use this anchor- reserved address-id value. When an implicit anchor resides on the path used by a later subflow, it caches the subflows locators as well as the token used during subflow establishment. Obviously, anchor support can only be provided for the host that initiated this subflow (host A) but not for its peer (host B) since the anchor only knows host B's token. Therefore, the anchor advertises its IP address (and port number) only to host A. The host receiving an ADD_ADDR options from an anchor caches the anchor's address and port number contained in this option. When the ADD_ADDR option does not carry a port number, the remote port number of the subflow, where the option arrived, is cached instead. Since the delivery of ADD_ADDR is not reliable, an end host may proactively seek anchor addresses via the SEEK_ADDR option introduced above. Both anchor and peer should respond with an ADD_ADDR option. The host can differentiate the originators of these replies by the enclosed address-id value. 5.2. Subflow Management with Implicit Anchor When a host wishes to establish a subflow via anchor, it initiates a subflow to the address and port number cached for the anchor. Based on the destination port number of the SYN packet and the token contained in MP_JOIN, the anchor identifies the peer's locator and forwards the packet to the peer using one of its own addresses and port numbers as the packet's source. The peer's SYN-ACK return packet and all following packets are relayed by the anchor in the same manner. Since the anchor does not change the address-ids contained in the MP_JOIN options of the initial handshake, each host learns the peer's address-id used for this split-subflow. Hampel & Klein Expires August 11, 2012 [Page 17] Internet-Draft MPTCP Proxies and Anchors February 2012 While the host initiating the subflow (host A) is aware of the anchor's presence, its peer (host B) may not know that this subflow is split because the anchor has not introduced itself to the peer or because the corresponding ADD_ADDR option got lost. In such a case, host B may falsely assume that the anchor's IP address belongs to host A and map it to the address-id contained in MP_JOIN. This may lead to a conflict, in case host A has announced (or will announce) this address-id for another address. Further, host B may be tempted to use the anchor's IP address for further subflows without knowing that this may invoke triangular routing. To avoid such misunderstanding, the MP_JOIN option on the SYN packet has to be marked with an ANCHOR flag. This flag tells host B, that the source address on the packet header belongs to an anchor and that it is not associated with the address-id carried in the MP_JOIN option. The ANCHOR flag should be set by the anchor when relaying the SYN packet. While host B may implicitly learn the anchor's IP address in this manner, it is not advised to use this anchor for new subflows unless the anchor has explicitly advertised its IP address. Host B can solicit such IP address advertisement via SEEK_ADDR sent on the split subflow. Each host should cache the peer's address-id together with the state information it holds for the corresponding split subflow. In case the host receives an REMOVE_ADDR option, it can identify and tear down all split-subflows pertaining to the address-id held in this option. The establishment of split subflows via anchor may introduce address- ids without the corresponding IP addresses. This is a similar situation as when direct end-to-end subflows pass network address translators, and it does not pose any principle problem. The anchor caches the host's locators and address-ids of the split subflow together with all information it holds for this connection. The anchor further keeps subflow-related state information for a short time frame after the subflow has been closed. The tokens and address ids are held for a short time after the last subflow known by this anchor has been closed. The tear-down delay permits the anchor to support break-before-make mobility scenarios discussed below. Hampel & Klein Expires August 11, 2012 [Page 18] Internet-Draft MPTCP Proxies and Anchors February 2012 5.3. Introduction of Explicit Anchor ________ | | |Explicit| | Anchor | |________| | _|_ IP_ANCH ______ /|\ ______ | | / | \ | | | Host | IP_A0 / | \ IP_B0 | Host | | A |--|------------/ | \-----------|--| B | |______| Split SFL_0 | Split SFL_0 |______| | / Split SFL_1 | _|_ IP_A1 / (using same path) _|_ IP_B1 |\-------------------/ | | Split SFL_1 | | | \----------------------------------------------/ SFL_2 MPTCP-TCP split connection with explicit MPTCP anchor Figure 9 If the anchor does not reside on a direct routing path it has to be introduced via explicit signaling by one of the hosts. The signaling has to include authentication information and the peer's locator. Since these are the same conditions as for explicit proxies the same solution scenarios can be applied as discussed in Section 4.3. For the reasons mentioned above, only scenarios with in-band MPTCP signaling and independent signaling are considered. o In-band MPTCP signaling: The first four steps of the connection establishment are identical to those discussed for the explicit proxy (see Figure 7 and Figure 10): Hampel & Klein Expires August 11, 2012 [Page 19] Internet-Draft MPTCP Proxies and Anchors February 2012 MPTCP EXPL MPTCP MPTCP HOST A NETWORK NODE HOST B | | | | SYN + MP_CAP(KEY_A) | | | -------------------------->| | | | | | SYN-ACK + MP_CAP(KEY_P) | | |<-------------------------- | | | | | | ACK + FWD_ADDR(IP_B) | | | -------------------------->| SYN + MP_CAP(KEY_A) | | | ----------------------------->| | | | | | SYN-ACK + MP_CAP(KEY_B) | | |<----------------------------- | | | | | ANCHOR | | A | | ACK + MP_CAP(KEY_B) A ACK + MP_CAP(KEY_A, KEY_B) | |<--------------------------- A ----------------------------->| | A | | A | Connection establishment with explicit anchor and in-band MPTCP signaling Figure 10 * Steps 1-4 of connection establishment with explicit proxy. * In case host B is MPTCP-capable, it inserts MP_CAPABLE with key B into the SYN-ACK response packet. Upon reception of this packet, the MPTCP network node assumes anchor function instead of proxy function. * The anchor function sends an ACK to host A and encloses the MP_CAPABLE header with key_B and it sets the ANCHOR flag. This informs host A that host B does support MPTCP and that the MPTCP network node has assumed anchor function. At this point, host A overwrites key_P with key_B. * The anchor function also sends an ACK to host B, where it inserts MP_CAPABLE with key_A and key_B and sets the ANCHOR flag. This tells host B that an anchor resides on the initial path. Hampel & Klein Expires August 11, 2012 [Page 20] Internet-Draft MPTCP Proxies and Anchors February 2012 o Independent signaling: The explicit MPTCP network node relays the host's SYN packet holding the MP_CAPABLE option to the peer. If the SYN-ACK return packet holds the MP_CAPABLE option, the MPTCP network node assumes anchor function and the initial subflow becomes a split subflow. When relaying the SYN-ACK packet to the connection-initiating host, the anchor should set the ANCHOR flag. The host responds with an ACK holding MP_CAPABLE with both keys. In case host B is not multipath-aware it may be supported by an implicit proxy residing on the path between host B and the explicit anchor. This proxy may reside in host B's access network for instance. The implicit proxy sets the PROXY flag in the MP_CAPABLE option of the SYN-ACK return packet as described in section 4.1. Since the explicit anchor sets the ANCHOR flag at the same time, host A can infer that the PROXY flag was set by an implicit proxy. A host can also introduce an explicit anchor after connection establishment. This has only limited benefit since the peer won't be able to proactively use this anchor. Further, it is rather complicated to embed such an anchor introduction into the MP_JOIN handshake. For that reason, only methods involving independent signaling protocols are considered here. Such a protocol has to provide authentication information, the remote end point locator and the remote tokens used on this connection. 5.4. Subflow Management with Explicit Anchor After introduction of the explicit anchor, establishment of further split subflows follows the same procedure as discussed for implicit anchors in Section 5.2. 5.5. Protocol Translation with Anchor The anchor can be used for IP protocol translation on a split subflow in case host A wishes to support IPv6 on a new interface while host B only supports IPv4. Protocol translation further becomes necessary when one host moves from an IPv4 network to an IPv6 network while the peer's network only supports IPv4 (and vice versa). In such scenarios, host A sends SEEK_ADDR on all subflows with the IPVer field set to IPv6. In response, anchors will send their respective IPv6 addresses. Then, host A initiates a new subflow to one anchors' IPv6 address. Since the anchor has cached at least one of host B's IPv4 addresses, it can create an IPv6/IPv4 split-subflow using an IPv6 and an IPv4 address. Hampel & Klein Expires August 11, 2012 [Page 21] Internet-Draft MPTCP Proxies and Anchors February 2012 5.6. Connection Robustness with Anchor The anchor can provide enhanced connection robustness in scenarios where the only remaining subflow breaks and direct end-to-end subflow establishment is not possible. This may happen, for instance, when both hosts simultaneously move to a new address. Direct subflow establishment is not possible in this case since neither host knows the peer's new IP address. In another scenario, a host moves to a new IP address while the peer resides behind a firewall. The host cannot reach the peer since the firewall blocks packets arriving from a new address. The peer cannot reach the host either since it does not know the host's new IP address. In these scenarios, each host will try to establish a direct subflow first. If this fails each host tries subflow establishment via an anchor. Since the anchor recognizes the connection based on token and port number contained in each host's SYN-packet, it can cache the host's new address contained on the packet and use it as the destination for SYN-packets sent by the peer. In this manner, a new subflow can be established via the anchor. For this purpose, the anchor should keep connection-related state information for some time after the subflow it is residing on has been torn down. The procedure further requires that the anchor holds both end hosts' tokens. This applies to anchors that reside on the initial path during connection establishment. Hampel & Klein Expires August 11, 2012 [Page 22] Internet-Draft MPTCP Proxies and Anchors February 2012 6. Host Configuration MPTCP-capable hosts should be appropriately configured to take advantage of MPTCP network functions. In a deployment scenario, where proxies and anchors are integrated with a central router of a 3G/4G cellular network, the host should initiate connections that deserve MPTCP support via the cellular interface if possible. After connection establishment, additional paths can be established and utilized for traffic exchange. In case explicit MPTCP network functions are provided, the host must be configured to support the proprietary protocol that introduces these nodes to the MPTCP connection. It must further be configured with the IP addresses for explicit proxies. The details on host configuration and the criteria on path selection are beyond the scope of this document. Hampel & Klein Expires August 11, 2012 [Page 23] Internet-Draft MPTCP Proxies and Anchors February 2012 7. New Signaling The following subsections discuss signaling changes necessary to support MPTCP network functions. 7.1. PROXY Flag The PROXY flag needs to be added to the MP_CAPABLE option. The PROXY flag is set by MPTCP network nodes to announce that they assume proxy function. The PROXY flag serves two purposes. It avoids that implicit proxies residing on the initial path between MPTCP-unaware hosts sustain a MPTCP connection with each other. It also informs a MPTCP-capable host that a proxy provides MPTCP on behalf of an MPTCP-unaware peer. This avoids unnecessary attempts by this host to establish subflows directly with the MPTCP-unaware peer. The PROXY flag can be added into the header of the MP_CAPAPBLE option (shown as "P" in Figure 11). 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|C|P|A|(resvd)|S| +---------------+---------------+-------+-------+-+-+-+-------+-+ | ... ... | MP_CAPABLE header with PROXY (P) and ANCHOR (A) flags Figure 11 7.2. ANCHOR Flag The ANCHOR flag needs to be added to the MP_CAPABLE option and to the MP_JOIN option. The flag informs the receiving host (or proxy) that an anchor has relayed this packet. This avoids misunderstandings about the source IP address of the packet and the address-id it carries. The ANCHOR flag can be added to the headers of MP_CAPAPBLE and MP_JOIN (shown as "A" in Figure 11 and Figure 12). Hampel & Klein Expires August 11, 2012 [Page 24] Internet-Draft MPTCP Proxies and Anchors February 2012 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 = 12 |Subtype| |A|B| Address ID | +---------------+---------------+-------+---+-+-+---------------+ | ... ... | MP_JOIN header for SYN and SYN-ACK with ANCHOR flag Figure 12 7.3. JOIN Flag The ADD_ADDR option is currently overloaded with two requests: 1) Cache this address and 2) initiate a subflow to this address right away. While this bundling of requests makes sense for end-to-end interactions, it becomes problematic for proxies and anchors, which only want to inform the peers about their respective addresses. The issue can be resolved by adding a JOIN flag to the ADD_ADDR option. This, however, creates some issues since the option has no room left for additional information. The option is further rather long, especially if IPv6 addresses and port numbers have to be carried. The following approaches can be considered: o The IPVer field is reduced from 4 to 3 bits as proposed by Olivier Bonaventure. This still leaves room for 5 future IP versions apart from IPv4 and IPv6. (Note that IP version = 0 is used by SEEK_ADDR to refer to "all IP versions"). The released bit is available for the JOIN flag. o The ADDRESS ID field is reduced by 1 bit to allocate room for JOIN as proposed by Costin Raiciu. This reduces the number of simultaneously supported addresses from 256 to 128 (or 255 and 127 if the anchor-reserved address-id is included as well). o The ADD_ADDR option only provides addresses and address-ids while a new option conveys the request to create a subflow with respect to a specific address id. A similar proposal was also made by Yoshifumi Nishida. o An octet is added to the ADD_ADDR option. Hampel & Klein Expires August 11, 2012 [Page 25] Internet-Draft MPTCP Proxies and Anchors February 2012 7.4. Anchor-Reserved Address-Id Value The anchor-reserved address-id value is used when anchors advertise their IP address via ADD_ADDR. It informs the receiving host that the address belongs to an anchor and not to the peer. The anchor reserved address-id value could be set for 255, for instance. 7.5. SEEK_ADDR Option The SEEK_ADDR option is sent by a host to solicit its peer as well as proxies and anchors to advertise their addresses. This option is necessary for operation with proxies and anchors, which rely on reliable address advertising. The SEEK_ADDR option holds the IP version field. If the value of this field is set to zero, addresses to all IP versions are sought. SEEK_ADDR also permits peers and MPTCP network nodes to reduce address advertising. It is not necessary, for instance, to preemptively advertise IPv6 addresses on connections that only use IPv4 and vice versa. The SEEK_ADDR option only holds the IP version field which leads to length of 3 octets (Figure 13). 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +---------------+---------------+-------+-------+ | Kind | Length |Subtype| IPVer | +---------------+---------------+-------+-------+ SEEK_ADDR option Figure 13 7.6. FWD_ADDR Option The FWD_ADDR option is used by a host to forward its peer's IP address and port number to an explicit MPTCP network node. The fields of the FWD_ADDR are identical to that of the ADD_ADDR option. Since both options have different semantic meanings they should also carry different subtypes. Hampel & Klein Expires August 11, 2012 [Page 26] Internet-Draft MPTCP Proxies and Anchors February 2012 8. Security Mobility and multi-homing protocols are vulnerable to session redirection attacks such as session hijacking and distributed DoS (DDoS)[3]. For MPTCP, these matters have been discussed in [4]. The introduction of implicit proxies and anchors does not add new principal vulnerabilities. One potential weakness is seen in connections via explicit proxy (or anchor), since the proxy can be used by the adversary to disguise its true location. In a DDoS attack, the adversary establishes multiple connections with the victim host and then floods the victim with a high volume of traffic on each connection. The severity of such an attack does not change when these connections are conducted via explicit proxy. Since the proxy uses its own IP address to forward the attacker's packets to the victim, the attacker's IP address remains hidden to the victim. This makes it impossible for the victim to identify an adversary prior to accepting a connection and to trace back the traffic flood to the attacker's location. One could argue that this situation could be improved by specifying a strong authentication method to be exercised between host and proxy. This, however, is not necessarily the case since a strong authentication protocol by itself does not enforce the use of strong authenticators. Note that this situation is different for mobility protocols like Mobile IPv6. In Mobile IPv6, the home agent uses the mobile host's unique home address as the source for traffic originated by the mobile host. The home address is therefore an authenticator of the traffic originator. To support the same level of security, the explicit proxy could use a unique IP address for each host. While such an approach is feasible in IPv6 it may have limited applicability in IPv4 due to IP address exhaustion. Hampel & Klein Expires August 11, 2012 [Page 27] Internet-Draft MPTCP Proxies and Anchors February 2012 9. Acknowledgements The authors wish to acknowledge suggestions and contributions on proxies and anchors by Olivier Bonaventure, Philip Eardley, Alan Ford, Mark Handley, Yoshifumi Nishida and Costin Raiciu. Hampel & Klein Expires August 11, 2012 [Page 28] Internet-Draft MPTCP Proxies and Anchors February 2012 10. References [1] Ford, A., Raiciu, C., Greenhalgh, A., and M. Handley, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 6182, June 2002. [3] Nikander, P., Arkko, J., Auro, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005. [4] Bangulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011. Hampel & Klein Expires August 11, 2012 [Page 29] Internet-Draft MPTCP Proxies and Anchors February 2012 Authors' Addresses Georg Hampel Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 US Phone: +1 908 582 2377 Fax: +1 908 582 8222 Email: georg.hampel@alcatel-lucent.com Thierry Klein Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 US Phone: +1 908 582 3585 Fax: +1 908 582 8222 Email: thierry.klein@alcatel-lucent.com Hampel & Klein Expires August 11, 2012 [Page 30]