MPTCP Working Group O. Bonaventure Internet-Draft UCLouvain Updates: RFC6824 (if approved) July 06, 2015 Intended status: Informational Expires: January 7, 2016 Multipath TCP Address Advertisement draft-bonaventure-mptcp-addr-00 Abstract Multipath TCP [RFC6824] defines the ADD_ADDR option to allow a host to announce its addresses to the remote host. In this document we analyze some of the issues with the address advertisement technique defined [RFC6824] and propose some modifications to mitigate these problems. We also show that the reverse DNS could be an excellent alternative to advertise the stable addresses of a server. 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 7, 2016. Copyright Notice 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 Bonaventure Expires January 7, 2016 [Page 1] Internet-Draft MPTCP ADDR July 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Issues with ADD_ADDR . . . . . . . . . . . . . . . . . . . . 3 2.1. Usage of the Address Identifiers . . . . . . . . . . . . 4 2.2. Reliability of the ADD_ADDR Option . . . . . . . . . . . 5 3. Learning the Addresses bound to a host through the DNS . . . 5 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Multipath TCP is an extension to TCP [RFC0793] that was specified in [RFC6824]. Multipath TCP was designed with multi-addressed hosts in mind [RFC6182]. A Multipath TCP connection is composed of subflows that are established between any of the addresses of the communicating hosts. [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. Experience with Multipath TCP shows that these two options allow to support multi-homed or dual-stack servers [TMA2015] and mobile devices [Cellnet12]. While the ADD_ADDR option has been supported in the Linux implementation of Multipath TCP, other implementors have chosen to not support it [I-D.eardley-mptcp-implementations-survey] while still supporting the REMOVE_ADDR option. Bonaventure Expires January 7, 2016 [Page 2] Internet-Draft MPTCP ADDR July 2015 In this document, we first analyse in Section 2 several issues with the current ADD_ADDR option as defined in [RFC6824] and [I-D.ietf-mptcp-rfc6824bis]. Then in Section 3 we show how Multipath TCP could leverage the existing DNS to obtain information about the different addresses attached to a server. 2. Issues with ADD_ADDR A first issue are the security risks if an attacker is able to send spoofed TCP segments that include the ADD_ADDR option. Multipath TCP [RFC6824] defines the ADD_ADDR option shown in Figure 1. 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| IPVer | Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | +-------------------------------+ Figure 1: The ADD_ADDR option From a security viewpoint, this option introduces a potential security risk if an attacker is able to send a spoofed ADD_ADDR option. [I-D.ietf-mptcp-rfc6824bis] proposes a new format for this option by placing a truncated HMAC inside the option to authenticate it. The format for this new option (ADD_ADDR2) 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| IPVer | Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | | Truncated HMAC (8 octets) | | +-------------------------------+ | | +-------------------------------+ Figure 2: The ADD_ADDR2 option Bonaventure Expires January 7, 2016 [Page 3] Internet-Draft MPTCP ADDR July 2015 2.1. Usage of the Address Identifiers A second issue with the ADD_ADDR option is the management of the address identifiers. At first glance, a Multipath TCP implementation could maintain a table of the IP addresses bound to the local host and associate one identifier with each address. When a new IP address is configured, it is added to the table and the index in the table can be used as its identifier. If a local address stops to be bound to the host, the Multipath TCP can extract its identifier from the table and send the REMOVE_ADDR option over all existing Multipath TCP connections. Unfortunately, such a naive implementation is not possible with the current Multipath TCP implementation. As defined in [RFC6824], the identifiers 0 are assigned to the addresses that were used for the establishment of the initial subflow. This is because the MP_CAPABLE option does not contain any field to encode an address identifier in contrast with the MP_JOIN option. An annoying consequence of this design choice is that a Multipath TCP implementation must at least remember the identifier of the address that was used to create the initial subflow. It cannot simply rely on the global address table described above because when an address fails, it must be able to send a REMOVE_ADDR with for address identifier 0 if this address was used to create the initial subflow. This forces a Multipath TCP implementation to at least store the address identifier of the initial subflow for each connection. One suggestion to ease the maintenance of the addresses on a Multipath TCP implementation would be to stop assuming that the address identifier 0 corresponds to the address used to establish the initial subflow. Instead, the implementation should maintain a table of all the addresses that it uses with Multipath TCP and assign one strictly positive identifier to each address. In this case, each address assigned to the host has the same address identifier for all the Multipath TCP connections. When a new address is learned, it is automatically assigned the next available address identifier and can be announced over all existing Multipath TCP connections depending on the policy applied for the address announcements. When an address is not bound anymore to this host, then the same REMOVE_ADDR option can be sent over all Multipath TCP connections. There is one missing element in the solution discussed above : how to announce the real address identifier that corresponds to the initial subflow. A simple solution to this problem is to use the ADD_ADDR option without an address as shown in Figure 3. Bonaventure Expires January 7, 2016 [Page 4] Internet-Draft MPTCP ADDR July 2015 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| IPVer | Address ID | +---------------+---------------+-------+-------+---------------+ Figure 3: The ADD_ADDR option indicating the address identifier of the current subflow This empty ADD_ADDR option indicates the address identifier of the address on the subflow over which it has been transmitted. It MUST only be used on the initial subflow since on the other subflows the same information is carried reliably in the MP_JOIN option of the SYN segments. The IPVer field of this ADD_ADDR option MUST match the IP version used for the initial subflow. 2.2. Reliability of the ADD_ADDR Option A third issue with the ADD_ADDR option is that since it is transmitted as a TCP option, it is not delivered reliably [Cellnet12]. If it announces an IPv4 address, the ADD_ADDR option could be inserted inside a segment that carries data and would thus be delivered reliably like the 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_ADDR2 option cannot be placed in the same segment as a DSS option. In these two cases, the ADD_ADDR/ADD_ADDR2 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, some implementations could decide to transmit several copies of the ADD_ADDR option over the same connection. 3. Learning the Addresses bound to a host through the DNS [RFC6824] defines the ADD_ADDR option as the basic technique to learn the addresses bound to the remote host. Given the importance of learning those addresses, one would expect this technique to be supported by all Multipath TCP implementations. This is not the case, since only the Linux implementation of Multipath TCP supports the ADD_ADDR option [I-D.eardley-mptcp-implementations-survey] as defined in [RFC6824]. The other implementations do not support this option [I-D.eardley-mptcp-implementations-survey]. This design choice was probably motivated by security concerns with this option and also because these implementations assume that only the client Bonaventure Expires January 7, 2016 [Page 5] Internet-Draft MPTCP ADDR July 2015 creates the subflows and the server is single-homed. In this case, the client (e.g. a smartphone), can create the subflows from any of its own addresses towards the single address of the server. However, with the deployment of IPv6, the number of dual-stack clients and servers will grow and it will be important for a host that creates a connection towards the IPv4 address of a server to also learn the IPv6 address associated to this particular server. We show in this section that the DNS could be used to distribute the addressing information that is required by Multipath TCP. There are three possibilities to use to DNS to distribute the list of addresses associated to a given server. A first approach is to use the existing forward DNS and consider that all the 'A' and 'AAAA' records associated with a name correspond to the same server and can be used to establish Multipath TCP subflows. Unfortunately, when several records are associated to a DNS name, this is often for load balancing reasons and those records point to the addresses of different hosts. A second approach would be to define a new DNS record that contains the list of the IP addresses associated to a given host. However, this would require to deploy a new type of DNS record. Proposals that were made in the past to define new RR types were not endorsed by the IETF (e.g., one single RR for dual stack hosts [I-D.li-dnsext-ipv4-ipv6] or a distinct RR for IPv4-Embedded IPv6 Address [I-D.boucadair-behave-dns-a64]). The third approach that we propose in this document is to use the reverse DNS to encode the information about the alternate addresses that are associated to a given host. The reverse DNS tree typically only contains PTR records that associate names to reverse IPv4 or IPv6 addresses. However, nothing prevents the use of the reverse DNS to store A and AAAA records. This is the approach that we recommend. It does not require any change to the DNS protocol and can leverage dynamic updates to the DNS [RFC3007] and DNSSec to authenticate the advertisement of addresses [RFC4034]. As an example, consider the server whose name is mptcp.example.org and which is reachable via the following IP addresses taken from the documentation prefixes [RFC3849] [RFC5737] : o 192.0.2.10 o 198.51.100.23 o 2001:db8::1234 The forward DNS will contain the following records for this server Bonaventure Expires January 7, 2016 [Page 6] Internet-Draft MPTCP ADDR July 2015 mptcp.example.org. 7200 IN A 192.0.2.10 mptcp.example.org. 7200 IN A 198.51.100.23 mptcp.example.org. 7200 IN AAAA 2001:db8::1234 In addition, the following entries would be added in the reverse DNS. 10.2.0.192.in-addr.arpa. 7200 IN AAAA 2001:db8::1234 10.2.0.192.in-addr.arpa. 7200 IN A 198.51.100.23 23.100.51.198.in-addr.arpa. 7200 IN AAAA 2001:db8::1234 23.100.51.198.in-addr.arpa. 7200 IN A 192.0.2.10 4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 8.b.d.0.1.0.0.2.ip6.arpa. 7200 IN A 192.0.2.10 4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 8.b.d.0.1.0.0.2.ip6.arpa. 7200 IN A 198.51.100.23 These reverse records can, of course, be signed with DNSSec [RFC4034]. 4. Conclusion In this document, we have discussed several issues with the advertisement of addresses with the ADD_ADDR and ADD_ADDR2 options in Multipath TCP. Then, we have shown that the reverse DNS can be used by servers to advertise their alternate IP addresses. This does not require any modification to the DNS protocol and could be used by applications that do not want or cannot rely on the ADD_ADDR option. 5. Acknowledgements This work was partially supported by the FP7-Trilogy2 project. This document was improved thanks to the comments and suggestions received from Fabien Duchene, Benjamin Hesmans and Mohammed Boucadair. 6. Informative References [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, . Bonaventure Expires January 7, 2016 [Page 7] Internet-Draft MPTCP ADDR July 2015 [I-D.boucadair-behave-dns-a64] Boucadair, M. and E. Burgey, "A64: DNS Resource Record for IPv4-Embedded IPv6 Address", draft-boucadair-behave-dns- a64-02 (work in progress), September 2010. [I-D.eardley-mptcp-implementations-survey] Eardley, P., "Survey of MPTCP Implementations", draft- eardley-mptcp-implementations-survey-02 (work in progress), July 2013. [I-D.ietf-mptcp-rfc6824bis] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ietf-mptcp-rfc6824bis-04 (work in progress), March 2015. [I-D.li-dnsext-ipv4-ipv6] Li, L., Li, Z., and X. Duan, "DNS Extensions to Support IPv4 and IPv6", draft-li-dnsext-ipv4-ipv6-02 (work in progress), October 2009. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. Bonaventure Expires January 7, 2016 [Page 8] Internet-Draft MPTCP ADDR July 2015 [TMA2015] Hesmans, B., Hoang Tran-Viet, ., Sadre, R., and O. Bonaventure, "A first look at real Multipath TCP traffic", TMA 2015 , April 2015, . Author's Address Olivier Bonaventure UCLouvain Email: Olivier.Bonaventure@uclouvain.be Bonaventure Expires January 7, 2016 [Page 9]