MPTCP Working Group F. Duchene Internet-Draft O. Bonaventure Intended status: Experimental UCLouvain Expires: January 9, 2017 July 08, 2016 Multipath TCP Address Advertisement draft-duchene-mptcp-add-addr-00 Abstract Multipath TCP [RFC6824] defines the ADD_ADDR option that allows a host to announce its addresses to the remote host. In this document we propose some improvements to this mechanism. Status of This Memo This Internet-Draft is submitted 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 January 9, 2017. Copyright Notice Copyright (c) 2016 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. Duchene & Bonaventure Expires January 9, 2017 [Page 1] Internet-Draft MPTCP ADDR July 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Proposed ADD_ADDR option . . . . . . . . . . . . . . . . . . 4 2.1. Reliability . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Backup . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Priorities . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Path diversity . . . . . . . . . . . . . . . . . . . . . 9 2.5. Load balancing . . . . . . . . . . . . . . . . . . . . . 10 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Security considerations . . . . . . . . . . . . . . . . . . . 11 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Multipath TCP is an extension to TCP [RFC0793] that was specified in [RFC6824]. Multipath TCP allows hosts to use multiple paths to send and receive the data belonging to one connection. For this, a Multipath TCP is composed of several TCP connections that are called subflows. [RFC6824] defines two options to manage the host addresses: o ADD_ADDR is used to announce one address bound to a host (possibly combined with a port number) o REMOVE_ADDR is used to indicate that an address previously attached to a host is not anymore attached to this host To cope with Network Address Translation (NAT), the ADD_ADDR and REMOVE_ADDR options contain an address identifier encoded as an 8 bits integer. When the initial subflow is created, it is assumed to be initiated from the address of the client whose identifier is 0 towards the address of the server whose identifier is also 0. Both the client and the server can use ADD_ADDR to advertise the other addresses that they use. When an additional subflow is created, the MP_JOIN option placed in the SYN (resp. SYN+ACK) contains the identifier of the address used to create (resp. accept) the subflow. The latest Multipath TCP draft [I-D.ietf-mptcp-rfc6824bis] defines the ADD_ADDR option as shown in Figure 1. Duchene & Bonaventure Expires January 9, 2017 [Page 2] Internet-Draft MPTCP ADDR July 2016 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|(resvd)| Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | | Truncated HMAC (8 octets) | | +-------------------------------+ | | +-------------------------------+ Figure 1: The Multipath TCP ADD_ADDR option format In this document, we propose to slightly modify the format of this option based on issues that have been detected while working with the Multipath TCP implementation in the Linux kernel. More precisely, we address four different problems. The first, discussed in Section 2.1, is that the ADD_ADDR option is sent unreliably. This implies that the host sending an ADD_ADDR option cannot be sure that the address that it has advertised has been learned by the distant host. The second issue, discussed in Section 2.2 is the handling of backup subflows. Multipath TCP supports the creation of backup subflows through the B bit in the MP_JOIN option. These backup subflows consume energy and radio ressources on mobile devices and it would be useful for a host to be able to advertise a backup address that would be used to create subflows after a failure. The third issue is that multihomed hosts may have preferences on the utilisation of some of their addresses/interfaces to create additional subflows. Section 2.3 proposes a priority field that allows them to advertise these preferences. The fourth issue is that multihomed hosts, especially with IPv6, often have several addresses assigned to each interface. In this case, it can be difficult to establish disjoint paths between the communicating hosts. Section 2.4 proposes a community field in the ADD_ADDR option to indicate that some addresses share the same path. The last issue, discussed in Section 2.5 is that some hosts, e.g. servers behind a load balancer or clients behind a firewall, may want to indicate that the address used for the initial subflow should not be used to create additional ones. Duchene & Bonaventure Expires January 9, 2017 [Page 3] Internet-Draft MPTCP ADDR July 2016 2. Proposed ADD_ADDR option To cope with the issues described later in this document we propose a new format for this option. The format for this new option is shown in Figure 2. 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|E|(rsv)| Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +---------------+---------------+---------------+---------------+ | Commu |prio |B| Port (2 octets, optional) | | +---------------+---------------+---------------+ | | | | Truncated HMAC (8 octets) +---------------+ | | +-----------------------------------------------+ Figure 2: The proposed Multipath TCP new ADD_ADDR option format 2.1. Reliability A first issue with the ADD_ADDR option is that since it is transmitted as a TCP option, it is not delivered reliably [Cellnet12]. When a host announces an IPv4 address, it can insert the ADD_ADDR option inside a segment that carries data that would thus be delivered reliably like user data. However, if the ADD_ADDR option contains an IPv6 address, it might be too large to fit inside a segment that already contains a DSS option and possibly other options such as the [RFC1323] timestamps. Given its length, the ADD_ADDR option cannot be placed in the same segment as a DSS option. In these two cases, the ADD_ADDR option will be often transmitted inside a duplicate ACK that is not delivered reliably. [Cellnet12] proposes a method to improve the reliability of the transmission of the ADD_ADDR option, but to our knowledge this method has never been implemented. To cope with packet losses, we propose to rely on the "E" (Echo) flag in the ADD_ADDR option (Figure 3). Duchene & Bonaventure Expires January 9, 2017 [Page 4] Internet-Draft MPTCP ADDR July 2016 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|E|(rsv)| Address ID | +---------------+---------------+-------+-------+---------------+ Figure 3: The part of the proposed Multipath TCP new ADD_ADDR option format with the Echo flag The "E" flag is the "Echo" flag. When set to 0, it indicates that the host sending this option is advertising a new address to the receiving host. When set to 1, it indicates that the host sending this option acknowledges the reception of an ADD_ADDR option by echoing it. Upon reception of an ADD_ADDR option without the "E" flag set, the receiving host MUST return the exact option that it received with the "E" flag set to 1 to indicate the reception of the ADD_ADDR option. If an host advertising a new address does nt receive an echo, or receives an invalid echo of the option it MAY retransmit the ADD_ADDR. To cope with the loss of the echo of the option, if an host that advertised a new address without receiving the echo receives an MP_JOIN on this address, it MUST consider this address as having been echoed, and MUST NOT retransmit this ADD_ADDR again. 2.2. Backup The subflows that compose a Multipath TCP connection are not all equal. [RFC6824] defines two types of subflows: o the regular subflows o the backup subflows The regular subflows can be used to transport any data. The backup subflows are intended to be used only when all the regular subflows fail. [RFC6824] defines them by using the following sentence: "Hosts can indicate at initial subflow setup whether they wish the subflow to be used as a regular or backup path - a backup path only being used if there are no regular paths available." In [RFC6824] a host can specify the type of a subflow during the three-way-handshake by using the "B" flag of the MP_JOIN option as shown in Figure 4 and Figure 5 or when the subflow is already established by sending an MP_PRIO option shown in Figure 6. Duchene & Bonaventure Expires January 9, 2017 [Page 5] Internet-Draft MPTCP ADDR July 2016 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| |B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | Receiver's Token (32 bits) | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 4: Join Connection (MP_JOIN) Option (for Initial SYN) 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 = 16 |Subtype| |B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | | | Sender's Truncated HMAC (64 bits) | | | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 5: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) 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| |B| AddrID (opt) | +---------------+---------------+-------+-----+-+--------------+ Figure 6: Change Subflow Priority (MP_PRIO) Option Both solutions rely on the principle that a subflow can be set in backup mode only when being already established or during the subflow setup. On mobile devices, backup subflows consume radio ressources when they are established. This could unnecessarily consume both energy on the mobile device [ATC14] and radio ressources in the network for subflows that do not carry any data. Measurements on smartphones [PAM2016] indicate that many subflows do not carry any data but still consume resources for the SYN, RST and FIN packets. To allow hosts using Multipath TCP to save ressources, we propose to add the "B" "Backup" Flag in the ADD_ADDR option as shown in Figure 7. This would allow an host to save ressources by being aware Duchene & Bonaventure Expires January 9, 2017 [Page 6] Internet-Draft MPTCP ADDR July 2016 of the remote backup addresses that could be used if all the non- backup subflows fail without having to establish a subflow, achieving a break-before-make scheme. 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 +---------------+---------------+---------------+---------------+ | Commu |prio |B| Port (2 octets, optional) | | +---------------+---------------+---------------+ | Figure 7: The part of the proposed Multipath TCP new ADD_ADDR option format with the Backup flag 2.3. Priorities The backup mode defined in [RFC6824] only supports an "all-or- nothing" mode in the usage of the subflows, where an host might just prefer to use certain subflow over others. To allow an host to inform the receving host about its preference in terms of subflow usage, we propose to modify the ADD_ADDR option by adding 3 "priority" bits as shown in Figure 8. 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 +---------------+---------------+---------------+---------------+ | Commu |prio |B| Port (2 octets, optional) | | +---------------+---------------+---------------+ | Figure 8: The part of the proposed Multipath TCP new ADD_ADDR option format with the priority bits This host MAY use this priority to determine when to establish a subflow towards this address. The priority field MUST be interpreted as an unsigned integer value with the highest numerical value being the most preferred one. To allow the priority of an already established subflow to be modified, we propose to modify the MP_PRIO option by adding the 3 priority bits next to the "B" flag has shown in Figure 9. Duchene & Bonaventure Expires January 9, 2017 [Page 7] Internet-Draft MPTCP ADDR July 2016 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|prio |B| AddrID (opt) | +---------------+---------------+-------+-----+-+--------------+ Figure 9: Change Subflow Priority (MP_PRIO) Option with 3 priority bits added To allow the hosts to advertise a per-subflow priority during the three-way-handshake we modify the MP_JOIN option by adding the 3 priority bits as shown in Figure 10 and 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 = 12 |Subtype| prio|B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | Receiver's Token (32 bits) | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 10: Join Connection (MP_JOIN) Option (for Initial SYN) with the 3 priority bits 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 = 16 |Subtype| prio|B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | | | Sender's Truncated HMAC (64 bits) | | | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 11: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) with the 3 priority bits The priority bits included in the MP_JOIN specify indicate the priority associated to this subflow. A host MAY use this information when scheduling packets over this particular subflow. Duchene & Bonaventure Expires January 9, 2017 [Page 8] Internet-Draft MPTCP ADDR July 2016 2.4. Path diversity +--- IPv4 1 ---+ | | +--- IPv6 1 ---+--- Interface 1 ---+ | | | client --- Internet ---+--- IPv6 2 ---+ | | +--- Server | | | | +--- IPv4 1 ---+--- Interface 2 ---+ Figure 12: A dual stack server with multiple IP addresses attached to the same interface. As shown in Figure 12 a host might have several IP addresses assigned to a single interface. Some clients would like to be able to create subflows over disjoint paths to maximise the diversity of the subflows. With the current ADD_ADDR option, the host receiving several ADD_ADDR has no way of knowing the diversity between these path. In the case of Figure 12 it could end up establishing 4 subflows where 2 could be sufficient to maximise diversity. To allow a host to inform the receiving host about the diversity of several addresses we propose to modify the ADD_ADDR to include 4 bits describing a "Community" associated to this address. The community values are an opaque field and it is expected that two addresses having the same community share some resources. 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 +---------------+---------------+---------------+---------------+ | Commu |B|prio | Port (2 octets, optional) | | +---------------+---------------+---------------+ | Figure 13: The part of the proposed Multipath TCP new ADD_ADDR option format with the Community bits With the community bits, a dual-stack host could elect to regroup all the addresses attached to a single interface under the same community, allowing the receiving host to decide on which advertised addresses it wants to establish new subflows. Duchene & Bonaventure Expires January 9, 2017 [Page 9] Internet-Draft MPTCP ADDR July 2016 2.5. Load balancing Many large web sites are served by servers that are behind a load balancer. The load balancer receives the connection establishment attempts and forwards them to the actual servers that serve the requests. One issue for the end-to-end deployment of Multipath TCP is it ability to be used on load-balancers. Different types of load balancers are possible. We consider a simple but important load balancer than does not maintain any per-flow state. This load balancer is illustrated in illustrated in Figure 14. A stateless load balancer can be implemented by hashing the five tuple (IP addresses and port numbers) of each incoming packet and forward them to one of the servers based on the hash value computed. With TCP, this load balancer ensures that all the packets that belong to one TCP connection are sent to the same server. +--+---- S1 ---|LB|---- S2 +--+---- S3 Figure 14: Stateless load balancer With Multipath TCP, this approach cannot be used anymore when subflows are created by the clients. Such subflows can use any five tuple and thus packets belonging to them will be forwarded over any server, not necessarily the one that was selected by the hashing function for the initial subflow. To allow Multipath TCP to work for hosts being hosted behind unmodified layer 4 load balancers, we propose to use the unused "B" flag in the MP_CAPABLE option sent (shown in Figure 15 in the SYN+ACK. This flag would allow a host behind a layer 4 load balancer to inform the other host that this address MUST NOT be used to create additional subflows. A host receiving an MP_CAPABLE with the "B" set to 1 MUST NOT try to establish a subflow to the address used in the MP_CAPABLE. This bit can also be used in the MP_CAPABLE option sent in the SYN by a client that resides behind a NAT or firewall or does not accept server- initiated subflows. Duchene & Bonaventure Expires January 9, 2017 [Page 10] Internet-Draft MPTCP ADDR July 2016 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|B|C|D|E|F|G|H| +---------------+---------------+-------+-------+---------------+ | Option Sender's Key (64 bits) | | (if option Length > 4) | | | +---------------------------------------------------------------+ | Option Receiver's Key (64 bits) | | (if option Length > 12) | | | +-------------------------------+-------------------------------+ | Data-Level Length (16 bits) | Checksum (16 bits, optional) | +-------------------------------+-------------------------------+ Figure 15: Multipath Capable (MP_CAPABLE) Option This bit can be used by the servers behind a stateless load balancers. Each of these servers has a different IP address than the address of the load balancer. The servers set the "B" flag in the MP_CAPABLE option that they return and advertise their own address by using the ADD_ADDR option. Upon reception of this option, the clients can create the additional subflows towards these addresses. Compared with current stateless load balancers, an advantage of this approach is that the packets belonging to the additional subflows do not need to pass through the load balancer. 3. IANA considerations This document proposes some modifications to the Multipath TCP options defined in [RFC6824]. These modifications do not require any specific action from IANA. 4. Security considerations The security considerations defined for Multipath TCP in [RFC6182] and [RFC7430] are applicable. The "E" flag, community and priority values in the ADD_ADDR option do not change the security considerations for the handling of this option. Since the ADD_ADDR option is protected by an HMAC, an off- path attacker cannot inject such an option in an existing Multipath TCP connection. Duchene & Bonaventure Expires January 9, 2017 [Page 11] Internet-Draft MPTCP ADDR July 2016 The "priority" field of the MP_PRIO option is not protected by a HMAC. It could be useful to consider the utilisation of an HMAC to protect this option like the ADD_ADDR option. The "B" flag of the MP_CAPABLE option does not change the security considerations of this option. If an attacker that resides on a path sets this bit, it could prevent the establishment of subflows. However, Multipath TCP does not protect against an attacker that resides on the path of the initial subflow and can modify the SYN/ SYN+ACK packets. 5. Conclusion In this document, we have discussed several issues with the advertisement of addresses with the address advertisement in Multipath TCP. We have proposed several modifications to the protocol to address these issues. 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, DOI 10.17487/RFC6824, January 2013, . 6.2. Informative References [ATC14] Yeon-sup Lim, ., Yung-Chih Chen, ., Nahum, Erich., Don Towsley, ., and . Richard Gibbens, "How green is multipath TCP for mobile devices?", AllThingsCellular14 , 2014. [Cellnet12] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. Bonaventure, "Exploring Mobile/WiFi Handover with Multipath TCP", ACM SIGCOMM workshop on Cellular Networks (Cellnet12) , 2012, . [I-D.ietf-mptcp-rfc6824bis] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ietf-mptcp-rfc6824bis-06 (work in progress), July 2016. Duchene & Bonaventure Expires January 9, 2017 [Page 12] Internet-Draft MPTCP ADDR July 2016 [PAM2016] Quentin De Coninck, ., Matthieu Baerts, ., Benjamin Hesmans, ., and O. Bonaventure, "A First Analysis of Multipath TCP on Smartphones", 17th International Passive and Active Measurements Conference , April 2016, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992, . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, . [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/ RFC7430, July 2015, . Authors' Addresses Fabien Duchene UCLouvain Email: fabien.duchene@uclouvain.be Olivier Bonaventure UCLouvain Email: Olivier.Bonaventure@uclouvain.be Duchene & Bonaventure Expires January 9, 2017 [Page 13]