Network Working Group M. Bagnulo Internet-Draft UC3M Intended status: Experimental A. Andersdotter Expires: January 9, 2020 Article 19 C. Paasch Apple July 8, 2019 Privacy threats and possible countermeasures for Multipath-TCP (MPTCP) draft-bagnulo-mptcp-privacy-00.txt Abstract This note performs a differential analysis of the threats regarding privacy of the Multipath TCP protocol compared to regular TCP and proposes a set of countermeasures for the threats identified. 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 https://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, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Bagnulo, et al. Expires January 9, 2020 [Page 1] Internet-Draft MPTCP privacy July 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Types of attackers . . . . . . . . . . . . . . . . . . . 3 2.2. Detailed attack mechanics. . . . . . . . . . . . . . . . 4 2.2.1. Attacks using MP_CAPABLE and MP_JOIN. . . . . . . . . 4 2.2.2. Attacks using ADD_ADDR. . . . . . . . . . . . . . . . 4 3. Countermeasures. . . . . . . . . . . . . . . . . . . . . . . 4 4. MPTCP privacy features. . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Multipath-TCP (MPTCP) [RFC6824] [I-D.ietf-mptcp-rfc6824bis] is a set of extensions to TCP that enable the use of multiple IP addresses throughout the lifetime of a (MP)TCP connection. The use of multiple addresses in a connection allows two main uses cases, namely mobility and multihoming. In the case of multihoming, if an endpoint is connected to the Internet through multiple interfaces simultaneously (each ones having a different IP address), the use of MPTCP allow additional fault tolerance as the connection can be preserved by using an alternative IP address even if the IP address originally used to establish the connection is rendered unavailable. In the case of mobility, as an endpoint changes is attachment to the Internet, it acquires a new IP address associated to its new attachment point. By using MPTCP, connections can be preserved throughout the changes of attachment points and their respective IP addresses by adding the new IP addresses to the ongoing MPTCP connections. Because of its very nature, the operation of MPTCP presents privacy implications, as other protocols that bind multiple IP addresses to a given endpoint [I-D.nordmark-id-loc-privacy]. Because MPTCP explicitly associated multiple IP addresses to a given connection and hence to a given endpoint, it discloses information about the node whereabouts to third parties. In this note, we perform an analysis of the privacy implications of the operation of the MPTCP compared to regular TCP and we provide a set of countermeasures to address the identified threats. It is out of the scope of this document to identify privacy threats that equally affect both MPTCP and TCP, such Bagnulo, et al. Expires January 9, 2020 [Page 2] Internet-Draft MPTCP privacy July 2019 as the ones resulting from exchanging unencrypted data that can be observed by eavesdroppers along the path. As mentioned earlier, we only identify threats against privacy introduced by MPTCP which are not present in TCP. 2. Threat Analysis The threats concerning privacy of the use of MPTCP are essentially two: Movement tracking: In the case that MPTCP is used for mobility, the use of multiple addresses in the same MPTCP connection can be used by an attacker to track the movement of the victim. Since IP addresses can be related to location (in a more or less accurate manner), by observing the different addresses used in a MPTCP connection, the attacker can track the itinerary of the victim. More accurate positioning. If multiple address are used simultaneously in a MPTCP connection, this implies that the endpoint is connected at the multiple attachment points at the same time, potentially providing the means for a more accurate positioning of the endpoint (e.g. if an endpoint is exposing the IP address of the cellular access it is providing less information than when it also exposes the IP address of an Internet coffee wifi access). 2.1. Types of attackers We classify the types of attackers based on their topological location, which determines the amount of information they have access to. the different types of attackers are: Partially on-path attacker. This attacker is located along one or more, but not all the paths used to exchange MPTCP signaling information. As such, it is able to see some but not all the MPTCP packets. Full On-path attacker. This attacker is able to eavesdrop all the MPTCP signaling message exchange, but it is not the other endpoint of the information. Endpoint: in this case, the other endpoint of the MPTCP connection is the attacker (in the sense that it will use the information revealed through MPTCP for other purposes beyond the MPTCP operation e.g. the endpoint may decide to sell the location and tracking information of the MPTCP endpoints to third parties). Bagnulo, et al. Expires January 9, 2020 [Page 3] Internet-Draft MPTCP privacy July 2019 2.2. Detailed attack mechanics. 2.2.1. Attacks using MP_CAPABLE and MP_JOIN. A MPTCP endpoint initiates a MPTCP connection by including the MP_CAPABLE option in the SYN message. After that, it uses the MP_JOIN option to add subsequent subflows using other IP address to the existent connection. The MP_JOIN message include a token that is used by the MPTCP receiver to identify which of the ongoing MPTCP connections this particular subflow is being added to. In order for an attacker to bind the different address together, it must be able to observe at least two messages carrying two different addresses. In particular, by observing the initial MP_CAPABLE SYN and a following MP_JOIN message, the attacker can relate these two IP addresses. Also, by observing two MP_JOIN messages carrying different IP addresses but the same toke, the attacker can also relate the two IP addresses together. This attack can be executed by any attacker that is capable of observing the different MP_CAPABLE and MP_JOIN messages. So, for a partially on-path attacker, the attack will be as effective as the number of used path the attacker has access to. If it only has access to one path, the attacker would not gather any information. Both full on-path attackers and the endpoint would have access to all the information, so the attack effectiveness is complete. Both versions of MPTCP, i.e. [RFC6824] [I-D.ietf-mptcp-rfc6824bis] are equally affected by this attack. 2.2.2. Attacks using ADD_ADDR. The ADD_ADDR option allows the sender of the message to add an IP address to the existing connection. From a privacy perspective, the packet containing the ADD_ADDR information already discloses a binding between two addresses, the address used a source address of the packet and the address included in the ADD_ADDR option. This attack can be performed by any attacker who is able to observe the message, including partial and full on-path attackers and the endpoint itself. This attack can be combined with the attack done using MP_CAPABLE AND MP_JOIN messages described in the previous section, to retrieve a larger set of addresses. This attack affects both version [RFC6824] [I-D.ietf-mptcp-rfc6824bis] of MPTCP. 3. Countermeasures. It is possible to design countermeasures to prevent the described attacks. Bagnulo, et al. Expires January 9, 2020 [Page 4] Internet-Draft MPTCP privacy July 2019 ADD_ADDR attack. In order to prevent the ADD_ADDR based attack, it would be possible to encrypt the address carried in the ADD_ADDR message, for example with the key exchanged in the MP_CAPABLE exchange. By doing this, only the attackers who have observed the initial MP_CAPABLE message would be able to decrypt the content of the ADD_ADDR message, significantly limiting the attack surface. MP_CAPABLE and MP_JOIN. In order to prevent the MP_CAPABLE/MP_JOIN attack, it would necessary to change the token in every MP_JOIN message. the difficulty with this of course is that the token is used a key to identify which MPTCP connection this new subflow belongs to. Using different tokens would be possible as long as the receiver would be able to decrypt it and find the ongoing connection that this new subflow belongs to. For instance, the token could be the hash of the concatenation of a trail of n zeros, the key and the new IP address of the flow. This token would change with every new subflow, since the IP address would change (we could also add the source port, to support the case of multiple subflows with the same source IP address). Upon the reception of an MP_JOIN message, the receiver would need to try with all the keys of ongoing connections. It will know it has succeeded, because the correct one will result in a trail of n zeros. The problem with this mechanism is that it imposes an additional cost in terms of computation upon the establishment of a new subflow. Additional countermeasures could be int he form of a recommendation about when to establish a new subflow or when to announce new addresses using ADD_ADDR. Generating awareness that doing so discloses private information of the endpoint would make implementations more conservative when advertising IP addresses. 4. MPTCP privacy features. MPTCP also provides some positive side effects with regard to privacy. In particular, because the information is spread across multiple paths, in order to be able to eavesdrop all the content of a MPTCP connection, the attacker needs to be present in all used paths, making more challenging for the attacker to fulfill its goal. 5. Security Considerations Bagnulo, et al. Expires January 9, 2020 [Page 5] Internet-Draft MPTCP privacy July 2019 6. IANA Considerations 7. Acknowledgements This work was supported by the Spanish Ministry of Economy and Competitiveness through the 5G-City project (TEC2016-76795-C6-3-R). 8. Informative References [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-18 (work in progress), June 2019. [I-D.nordmark-id-loc-privacy] Nordmark, E., "Privacy issues in ID/locator separation systems", draft-nordmark-id-loc-privacy-00 (work in progress), July 2018. [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, . Authors' Addresses Marcelo Bagnulo UC3M Email: marcelo@it.uc3m.es Amelia Andersdotter Article 19 Email: amelia@article19.org Christoph Paasch Apple Email: cpaasch@apple.com Bagnulo, et al. Expires January 9, 2020 [Page 6]