idnits 2.17.1 draft-bagnulo-mptcp-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Experimental A. Andersdotter 5 Expires: January 9, 2020 Article 19 6 C. Paasch 7 Apple 8 July 8, 2019 10 Privacy threats and possible countermeasures for Multipath-TCP (MPTCP) 11 draft-bagnulo-mptcp-privacy-00.txt 13 Abstract 15 This note performs a differential analysis of the threats regarding 16 privacy of the Multipath TCP protocol compared to regular TCP and 17 proposes a set of countermeasures for the threats identified. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Types of attackers . . . . . . . . . . . . . . . . . . . 3 56 2.2. Detailed attack mechanics. . . . . . . . . . . . . . . . 4 57 2.2.1. Attacks using MP_CAPABLE and MP_JOIN. . . . . . . . . 4 58 2.2.2. Attacks using ADD_ADDR. . . . . . . . . . . . . . . . 4 59 3. Countermeasures. . . . . . . . . . . . . . . . . . . . . . . 4 60 4. MPTCP privacy features. . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Informative References . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Multipath-TCP (MPTCP) [RFC6824] [I-D.ietf-mptcp-rfc6824bis] is a set 70 of extensions to TCP that enable the use of multiple IP addresses 71 throughout the lifetime of a (MP)TCP connection. The use of multiple 72 addresses in a connection allows two main uses cases, namely mobility 73 and multihoming. In the case of multihoming, if an endpoint is 74 connected to the Internet through multiple interfaces simultaneously 75 (each ones having a different IP address), the use of MPTCP allow 76 additional fault tolerance as the connection can be preserved by 77 using an alternative IP address even if the IP address originally 78 used to establish the connection is rendered unavailable. In the 79 case of mobility, as an endpoint changes is attachment to the 80 Internet, it acquires a new IP address associated to its new 81 attachment point. By using MPTCP, connections can be preserved 82 throughout the changes of attachment points and their respective IP 83 addresses by adding the new IP addresses to the ongoing MPTCP 84 connections. 86 Because of its very nature, the operation of MPTCP presents privacy 87 implications, as other protocols that bind multiple IP addresses to a 88 given endpoint [I-D.nordmark-id-loc-privacy]. Because MPTCP 89 explicitly associated multiple IP addresses to a given connection and 90 hence to a given endpoint, it discloses information about the node 91 whereabouts to third parties. In this note, we perform an analysis 92 of the privacy implications of the operation of the MPTCP compared to 93 regular TCP and we provide a set of countermeasures to address the 94 identified threats. It is out of the scope of this document to 95 identify privacy threats that equally affect both MPTCP and TCP, such 96 as the ones resulting from exchanging unencrypted data that can be 97 observed by eavesdroppers along the path. As mentioned earlier, we 98 only identify threats against privacy introduced by MPTCP which are 99 not present in TCP. 101 2. Threat Analysis 103 The threats concerning privacy of the use of MPTCP are essentially 104 two: 106 Movement tracking: In the case that MPTCP is used for mobility, 107 the use of multiple addresses in the same MPTCP connection can be 108 used by an attacker to track the movement of the victim. Since IP 109 addresses can be related to location (in a more or less accurate 110 manner), by observing the different addresses used in a MPTCP 111 connection, the attacker can track the itinerary of the victim. 113 More accurate positioning. If multiple address are used 114 simultaneously in a MPTCP connection, this implies that the 115 endpoint is connected at the multiple attachment points at the 116 same time, potentially providing the means for a more accurate 117 positioning of the endpoint (e.g. if an endpoint is exposing the 118 IP address of the cellular access it is providing less information 119 than when it also exposes the IP address of an Internet coffee 120 wifi access). 122 2.1. Types of attackers 124 We classify the types of attackers based on their topological 125 location, which determines the amount of information they have access 126 to. the different types of attackers are: 128 Partially on-path attacker. This attacker is located along one or 129 more, but not all the paths used to exchange MPTCP signaling 130 information. As such, it is able to see some but not all the 131 MPTCP packets. 133 Full On-path attacker. This attacker is able to eavesdrop all the 134 MPTCP signaling message exchange, but it is not the other endpoint 135 of the information. 137 Endpoint: in this case, the other endpoint of the MPTCP connection 138 is the attacker (in the sense that it will use the information 139 revealed through MPTCP for other purposes beyond the MPTCP 140 operation e.g. the endpoint may decide to sell the location and 141 tracking information of the MPTCP endpoints to third parties). 143 2.2. Detailed attack mechanics. 145 2.2.1. Attacks using MP_CAPABLE and MP_JOIN. 147 A MPTCP endpoint initiates a MPTCP connection by including the 148 MP_CAPABLE option in the SYN message. After that, it uses the 149 MP_JOIN option to add subsequent subflows using other IP address to 150 the existent connection. The MP_JOIN message include a token that is 151 used by the MPTCP receiver to identify which of the ongoing MPTCP 152 connections this particular subflow is being added to. In order for 153 an attacker to bind the different address together, it must be able 154 to observe at least two messages carrying two different addresses. 155 In particular, by observing the initial MP_CAPABLE SYN and a 156 following MP_JOIN message, the attacker can relate these two IP 157 addresses. Also, by observing two MP_JOIN messages carrying 158 different IP addresses but the same toke, the attacker can also 159 relate the two IP addresses together. 161 This attack can be executed by any attacker that is capable of 162 observing the different MP_CAPABLE and MP_JOIN messages. So, for a 163 partially on-path attacker, the attack will be as effective as the 164 number of used path the attacker has access to. If it only has 165 access to one path, the attacker would not gather any information. 166 Both full on-path attackers and the endpoint would have access to all 167 the information, so the attack effectiveness is complete. 169 Both versions of MPTCP, i.e. [RFC6824] [I-D.ietf-mptcp-rfc6824bis] 170 are equally affected by this attack. 172 2.2.2. Attacks using ADD_ADDR. 174 The ADD_ADDR option allows the sender of the message to add an IP 175 address to the existing connection. From a privacy perspective, the 176 packet containing the ADD_ADDR information already discloses a 177 binding between two addresses, the address used a source address of 178 the packet and the address included in the ADD_ADDR option. This 179 attack can be performed by any attacker who is able to observe the 180 message, including partial and full on-path attackers and the 181 endpoint itself. This attack can be combined with the attack done 182 using MP_CAPABLE AND MP_JOIN messages described in the previous 183 section, to retrieve a larger set of addresses. This attack affects 184 both version [RFC6824] [I-D.ietf-mptcp-rfc6824bis] of MPTCP. 186 3. Countermeasures. 188 It is possible to design countermeasures to prevent the described 189 attacks. 191 ADD_ADDR attack. 193 In order to prevent the ADD_ADDR based attack, it would be possible 194 to encrypt the address carried in the ADD_ADDR message, for example 195 with the key exchanged in the MP_CAPABLE exchange. By doing this, 196 only the attackers who have observed the initial MP_CAPABLE message 197 would be able to decrypt the content of the ADD_ADDR message, 198 significantly limiting the attack surface. 200 MP_CAPABLE and MP_JOIN. 202 In order to prevent the MP_CAPABLE/MP_JOIN attack, it would necessary 203 to change the token in every MP_JOIN message. the difficulty with 204 this of course is that the token is used a key to identify which 205 MPTCP connection this new subflow belongs to. Using different tokens 206 would be possible as long as the receiver would be able to decrypt it 207 and find the ongoing connection that this new subflow belongs to. 209 For instance, the token could be the hash of the concatenation of a 210 trail of n zeros, the key and the new IP address of the flow. This 211 token would change with every new subflow, since the IP address would 212 change (we could also add the source port, to support the case of 213 multiple subflows with the same source IP address). Upon the 214 reception of an MP_JOIN message, the receiver would need to try with 215 all the keys of ongoing connections. It will know it has succeeded, 216 because the correct one will result in a trail of n zeros. The 217 problem with this mechanism is that it imposes an additional cost in 218 terms of computation upon the establishment of a new subflow. 220 Additional countermeasures could be int he form of a recommendation 221 about when to establish a new subflow or when to announce new 222 addresses using ADD_ADDR. Generating awareness that doing so 223 discloses private information of the endpoint would make 224 implementations more conservative when advertising IP addresses. 226 4. MPTCP privacy features. 228 MPTCP also provides some positive side effects with regard to 229 privacy. In particular, because the information is spread across 230 multiple paths, in order to be able to eavesdrop all the content of a 231 MPTCP connection, the attacker needs to be present in all used paths, 232 making more challenging for the attacker to fulfill its goal. 234 5. Security Considerations 235 6. IANA Considerations 237 7. Acknowledgements 239 This work was supported by the Spanish Ministry of Economy and 240 Competitiveness through the 5G-City project (TEC2016-76795-C6-3-R). 242 8. Informative References 244 [I-D.ietf-mptcp-rfc6824bis] 245 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 246 Paasch, "TCP Extensions for Multipath Operation with 247 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work 248 in progress), June 2019. 250 [I-D.nordmark-id-loc-privacy] 251 Nordmark, E., "Privacy issues in ID/locator separation 252 systems", draft-nordmark-id-loc-privacy-00 (work in 253 progress), July 2018. 255 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 256 "TCP Extensions for Multipath Operation with Multiple 257 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 258 . 260 Authors' Addresses 262 Marcelo Bagnulo 263 UC3M 265 Email: marcelo@it.uc3m.es 267 Amelia Andersdotter 268 Article 19 270 Email: amelia@article19.org 272 Christoph Paasch 273 Apple 275 Email: cpaasch@apple.com