idnits 2.17.1 draft-ietf-mptcp-threat-07.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 (January 11, 2011) is 4848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4960' is defined on line 729, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-12) exists of draft-ietf-mptcp-multiaddressed-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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: Informational January 11, 2011 5 Expires: July 15, 2011 7 Threat Analysis for TCP Extensions for Multi-path Operation with 8 Multiple Addresses 9 draft-ietf-mptcp-threat-07 11 Abstract 13 Multi-path TCP (MPTCP for short) describes the extensions proposed 14 for TCP so that endpoints of a given TCP connection can use multiple 15 paths to exchange data. Such extensions enable the exchange of 16 segments using different source-destination address pairs, resulting 17 in the capability of using multiple paths in a significant number of 18 scenarios. In particular, some level of multihoming and mobility 19 support can be achieved through these extensions. However, the 20 support for multiple IP addresses per endpoint may have implications 21 on the security of the resulting MPTCP protocol. This note includes 22 a threat analysis for MPTCP. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 15, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10 64 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10 65 6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12 66 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14 67 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Multi-path TCP (MPTCP for short) describes the extensions proposed 80 for TCP [RFC0793] so that endpoints of a given TCP connection can use 81 multiple paths to exchange data. Such extensions enable the exchange 82 of segments using different source-destination address pairs, 83 resulting in the capability of using multiple paths in a significant 84 number of scenarios. In particular, some level of multihoming and 85 mobility support can be achieved through these extensions. However, 86 the support for multiple IP addresses per endpoint may have 87 implications on the security of the resulting MPTCP protocol. This 88 note includes a threat analysis for MPTCP. It should be noted that 89 there are there may other ways to provide multiple paths for a TCP 90 connection other than the usage of multiple addresses. The threat 91 analysis performed in this document is limited to the specific case 92 of using multiple addresses per endpoint. 94 2. Scope 96 There are multiple ways to achieve Multi-path TCP. Essentially what 97 is needed is for different segments of the communication to be 98 forwarded through different paths by enabling the sender to specify 99 some form of path selector. There are multiple options for such a 100 path selector, including the usage of different next hops, using 101 tunnels to different egress points and so on. In this note, we will 102 focus on a particular approach, namely MPTCP, that rely on the usage 103 of multiple IP address per endpoint and that uses different source- 104 destination address pairs as a mean to express different paths. So, 105 in the rest of this note, the MPTCP expression will refer to this 106 Multi-addressed flavour of Multi-path TCP 107 [I-D.ietf-mptcp-multiaddressed]. 109 In this note we perform a threat analysis for MPTCP. Introducing the 110 support of multiple addresses per endpoint in a single TCP connection 111 may result in additional vulnerabilities compared to single-path TCP. 112 The scope of this note is to identify and characterize these new 113 vulnerabilities. So, the scope of the analysis is limited to the 114 additional vulnerabilities resulting from the multi-address support 115 compared to the current TCP protocol (where each endpoint only has 116 one address available for use per connection). In other words, a 117 full analysis of the complete set of threats is explicitly out of the 118 scope. The goal of this analysis is to help the MPTCP protocol 119 designers create an MPTCP specification that is as secure as the 120 current TCP. It is a non-goal of this analysis to help in the design 121 of MPTCP that is more secure than regular TCP. 123 In particular, we will focus on attackers that are not along the 124 path, at least not during the whole duration of the connection. In 125 the current single path TCP, an on-path attacker can launch a 126 significant number of attacks, including eavesdropping, connection 127 hijacking Man-in-the-Middle attacks and so on. However, it is not 128 possible for the off-path attackers to launch such attacks. There is 129 a middle ground in case the attacker is located along the path for a 130 short period of time to launch the attack and then moves away, but 131 the attack effects still apply. These are the so-called time-shifted 132 attacks. Since these are not possible in today's TCP, we will also 133 consider them as part of the analysis. So, summarizing, we will 134 consider both attacks launched by off-path attackers and time-shifted 135 attacks. Attacks launched by on-path attackers are out of scope, 136 since they also apply to current single-path TCP. 138 It should be noted, however, that some current on-path attacks may 139 become more difficult with multi-path TCP, since an attacker (on a 140 single path) will not have visibility of the complete data stream. 142 3. Related work 144 There is a significant amount of previous work in terms of analysis 145 of protocols that support address agility. In this section we 146 present the most relevant ones and we relate them to the current 147 MPTCP effort. 149 Most of the problems related to address agility have been deeply 150 analyzed and understood in the context of Route Optimization support 151 in Mobile IPv6 (MIPv6 RO) [RFC3775]. [RFC4225] includes the rational 152 for the design of the security of MIPv6 RO. All the attacks 153 described in the aforementioned analysis apply here and are an 154 excellent basis for our own analysis. The main differences are: 155 o In MIPv6 RO, the address binding affects all the communications 156 involving an address, while in the MPTCP case, a single connection 157 is at stake. In other words, if a binding between two addresses 158 is created at the IP layer, this binding can and will affect all 159 the connections that involve those addresses. However, in MPTCP, 160 if an additional address is added to an ongoing TCP connection, 161 the additional address will/can only affect the connection at hand 162 and not other connections even if the same address is being used 163 for those other connections. The result is that in MPTCP there is 164 much less at stake and the resulting vulnerabilities are less. On 165 the other hand, it is very important to keep the assumption valid 166 that the address bindings for a given connection do not affect 167 other connections. If reusing of binding or security information 168 is to be considered, this assumption could be no longer valid and 169 the full impact of the vulnerabilities must be assessed. 171 o In MIPv6 RO, there is the assumption that the original path 172 through which the connection has been established is always 173 available and in case it is not, the communication will be lost. 174 In MPTCP, it is an explicit goal to provide communication 175 resilience when one of the address pairs is no longer usable, so 176 it is not possible to leverage on the original address pair to be 177 always working. 178 o MIPv6 RO is of course designed for IPv6 and it is an explicit goal 179 of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security 180 solutions rely on the usage of some characteristics of IPv6 (such 181 as the usage of CGAs [RFC3972]), which will not be usable in the 182 context of MPTCP. 183 o As opposed to MPTCP, MIPv6 RO does not have a connection state 184 information, including sequence numbers, port numbers that could 185 be leveraged to provide security in some form. 187 In the Shim6 [RFC5533] design, similar issues related to address 188 agility were considered and a threat analysis was also performed 189 [RFC4218]. The analysis performed for Shim6 also largely applies to 190 the MPTCP context, the main difference being: 191 o Similarly to the MPTCP case, the Shim6 protocol is a layer 3 192 protocol so all the communications involving the target address 193 are at stake, as opposed to the MPTCP case, where the impact can 194 be limited to a single TCP connection. 195 o Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as 196 identifiers and leverages on some of their properties to provide 197 the security, such as relying on CGAs or HBAs [RFC5535], which is 198 not possible in the MPTCP case where IPv4 addresses must be 199 supported. 200 o Similarly to MIPv6 RO, Shim6 does not have a connection state 201 information, including sequence numbers, port that could be 202 leveraged to provide security in some form. 204 SCTP [RFC4960]is a transport protocol that supports multiple 205 addresses per endpoint and as such, the security implications are 206 very close to the ones of MPTCP. A security analysis, identifying a 207 set of attacks and proposed solutions was performed in [RFC5062]. 208 The results of this analysis apply directly to the case of MPTCP. 209 However, the analysis was performed after the base SCTP protocol was 210 designed and the goal of the document was essentially to improve the 211 security of SCTP. As such, the document is very specific to the 212 actual SCTP specification and relies on the SCTP messages and 213 behaviour to characterize the issues. While some them can be 214 translated to the MPTCP case, some may be caused by specific 215 behaviour of SCTP as defined. 217 So, the conclusion is that while we do have a significant amount of 218 previous work that is closely related and we can and will use it as a 219 basis for this analysis, there is a set of characteristics that are 220 specific to MPTCP that grant the need for a specific analysis for 221 MPTCP. The goal of this analysis is to help MPTCP protocol designers 222 to include a set of security mechanisms that prevent the introduction 223 of new vulnerabilities to the Internet due to the adoption of MPTCP. 225 4. Basic MPTCP. 227 As we stated earlier, the goal of this document is to serve as input 228 for MPTCP protocol designers to properly take into account the 229 security issues. As such, the analysis cannot be performed for a 230 specific MPTCP specification, but must be a general analysis that 231 applies to the widest possible set of MPTCP designs. In order to do 232 that, we will characterize what are the fundamental features that any 233 MPTCP protocol must provide and attempt to perform the security 234 implications only assuming those. In some cases, we will have a 235 design choice that will significantly influence the security aspects 236 of the resulting protocol. In that case we will consider both 237 options and try to characterize both designs. 239 We assume that any MPTCP will behave in the case of a single address 240 per endpoint as TCP. This means that a MPTCP connection will be 241 established by using the TCP 3-way handshake and will use a single 242 address pair. 244 The addresses used for the establishment of the connection do have a 245 special role in the sense that this is the address used as identifier 246 by the upper layers. In particular, the address used as destination 247 address in the SYN packet is the address that the application is 248 using to identify the peer and has been obtained either through the 249 DNS (with or without DNSSEC validation) or passed by a referral or 250 manually introduced by the user. As such, the initiator does have a 251 certain amount of trust in the fact that it is establishing a 252 communication with that particular address. If due to MPTCP, packets 253 end up being delivered to an alternative address, the trust that the 254 initiator has placed on that address would be deceived. In any case, 255 the adoption of MPTCP necessitates a slight evolution of the 256 traditional TCP trust model, in that the initiator is additionally 257 trusting the peer to provide additional addresses which it will trust 258 to the same degree as the original pair. An application or 259 implementation that cannot trust the peer in this way should not make 260 use of multiple paths. 262 During the 3-way handshake, the sequence number will be synchronized 263 for both ends, as in regular TCP. We assume that a MPTCP connection 264 will use a single sequence number for the data, even if the data is 265 exchanged through different paths, as MPTCP provides an in-order 266 delivery service of bytes 268 Once the connection is established, the MPTCP extensions can be used 269 to add addresses for each of the endpoints. In order to do that each 270 end will need to send a control message containing the additional 271 address(es). In order to associate the additional address to an 272 ongoing connection, the connection needs to be identified. We assume 273 that the connection can be identified by the 4-tuple of source 274 address, source port, destination address, destination port used for 275 the establishment of the connection. So, at least, the control 276 message that will convey the additional address information can also 277 contain the 4-tuple in order to inform about what connection the 278 address belong to (if no other connection identifier is defined). 279 There are two different ways to convey address information: 280 o Explicit mode: the control message contain a list of addresses. 281 o Implicit mode: the address added is the one included in the source 282 address field of the IP header 284 These two modes have different security properties for some type of 285 attacks. The explicit mode seems to be the more vulnerable to abuse. 286 In particular, the implicit mode may benefit from forms of ingress 287 filtering security, which would reduce the possibility of an attacker 288 to add any arbitrary address to an ongoing connection. However, it 289 should be noted that ingress filtering deployment is far from 290 universal, and as such it is unwise to rely on it as a basis for the 291 protection of MPTCP. 293 In addition, further consideration about the interaction between 294 ingress filtering and implicit mode signaling is needed in the case 295 that we need to remove an address that is no longer available from 296 the MPTCP connection. In particular a host attached to a network 297 that performs ingress filtering and using implicit signaling would 298 not be able to remove an address that is no longer available (either 299 because of a failure or due to a mobility event) from an ongoing 300 MPTCP connection. 302 In addition, we will assume that MPTCP will use all the address pairs 303 that it has available for sending packets and that it will distribute 304 the load based on congestion among the different paths. 306 5. Flooding attacks 308 The first type of attacks that are introduced by address agility are 309 the so called flooding (or bombing) attacks. The setup for this 310 attack is depicted in the following figure: 312 +--------+ (step 1) +------+ 313 |Attacker| ------------------------- |Source| 314 | A |IPA IPS| S | 315 +--------+ /+------+ 316 / 317 (step 2) / 318 / 319 v IPT 320 +------+ 321 |Target| 322 | T | 323 +------+ 325 The scenario consists of an attacker A who has an IP address IPA. A 326 server that can generate a significant amount of traffic (such as a 327 streaming server), called source S and that has IP address IPS. In 328 addition, we have the target of the flooding attack, target T which 329 has an IP address IPT. 331 In the first step of this attack (depicted as step 1 in the figure), 332 the attacker A establishes a MPTCP connection with the source of the 333 traffic server S and starts downloading a significant amount of 334 traffic. The initial connection only involves one IP address per 335 endpoint, namely IPA and IPS. Once that the download is on course, 336 the second step of the attack (depicted as step 2 in the figure) is 337 that the attacker A adds IPT as one of the available addresses for 338 the communication. How the additional address is added depends on 339 the MPTCP address management mode. In explicit address management, 340 the attacker A only needs to send a signaling packet conveying 341 address IPT. In implicit mode, the attacker A would need to send a 342 packet with IPT as the source address. Depending on whether ingress 343 filtering is deployed and the location of the attacker, it may be 344 possible or not for the attacker to send such a packet. At this 345 stage, the MPTCP connection still has a single address for the Source 346 S i.e. IPS but has two addresses for the Attacker A, namely IPA and 347 IPT. The attacker now attempts to get the Source S to send the 348 traffic of the ongoing download to the Target T IP address i.e. IPT. 349 The attacker can do that by pretending that the path between IPA and 350 IPT is congested but that the path between IPS and IPT is not. In 351 order to do that, it needs to send ACKs for the data that flows 352 through the path between IPS and IPT and do not send ACKs for the 353 data that is sent to IPA. The actual details of this will depend on 354 how the data sent through the different paths is ACKed. One 355 possibility is that ACKs for the data sent using a given address pair 356 should come in packets containing the same address pair. If so, the 357 attacker would need to send ACKs using packets containing IPT as the 358 source address to keep the attack flowing. This may be possible or 359 not depending on the deployment of ingress filtering and the location 360 of the attacker. The attacker would also need to guess the sequence 361 number of the data being sent to the Target. Once the attacker 362 manages to perform these actions the attack is on place and the 363 download will hit the target. It should be noted that in this type 364 of attacks, the Source S still thinks it is sending packets to the 365 Attacker A while in reality it is sending the packet to Target T. 367 Once that the traffic from the Source S start hitting the Target T, 368 the target will react. In particular, since the packets are likely 369 to belong to a non existent TCP connection, the Target T will issue 370 RST packets. It is relevant then to understand how MPTCP reacts to 371 incoming RST packets. It seems that the at least the MPTCP that 372 receives a RST packet should terminate the packet exchange 373 corresponding to the particular address pair (maybe not the complete 374 MPTCP connection, but at least it should not send more packets with 375 the address pair involved in the RST packet). However, if the 376 attacker, before redirecting the traffic has managed to increase the 377 window size considerably, the flight size could be enough to impose a 378 significant amount of traffic to the Target node. There is a subtle 379 operation that the attacker needs to achieve in order to launch a 380 significant attack. On the one hand it needs to grow the window 381 enough so that the flight size is big enough to cause enough effect 382 and on the other hand the attacker needs to be able to simulate 383 congestion on the IPA-IPS path so that traffic is actually redirected 384 to the alternative path without significantly reducing the window. 385 This will heavily depend on how the coupling of the windows between 386 the different paths works, in particular how the windows are 387 increased. Some designs of the congestion control window coupling 388 could render this attack ineffective. In particular, if the MPTCP 389 protocol requires performing slow start per subflow, then the 390 flooding will be limited by the slow-start initial window size. 392 Previous protocols, such as MIPv6 RO and SCTP, that have to deal with 393 this type of attacks have done so by adding a reachability check 394 before actually sending data to a new address. In other words, the 395 solution used in other protocols, would include the Source S to 396 explicitly asking the host sitting in the new address (in this case 397 the Target T sitting in IPT) whether it is willing to accept packets 398 from the MPTCP connection identified by the 4-tuple IPA, port A, IPS, 399 port S. Since this is not part of the established connection that 400 Target T has, T would not accept the request and Source S would not 401 use IPT to send packets for this MPTCP connection. Usually, the 402 request also includes a nonce that cannot be guessed by the attacker 403 A so that it cannot fake the reply to the request easily. In 404 particular, In the case of SCTP, it sends a message with a 64-bit 405 nonce (in a HEARTBEAT). 407 One possible approach to do this reachability test would be to 408 perform a 3-way handshake for each new address pair that is going to 409 be used in a MPTCP connection. While there are other reasons for 410 doing this (such as NAT traversal), such approach would also act as a 411 reachability test and would prevent the flooding attacks described in 412 this section. 414 Another type of flooding attack that could potentially be performed 415 with MPTCP is one where the attacker initiates a communication with a 416 peer and includes a long list of alternative addresses in explicit 417 mode. If the peer decides to establish subflows with all the 418 available addresses, the attacker have managed to achieve an 419 amplified attack, since by sending a single packet containing all the 420 alternative addresses it triggers the peer to generate packets to all 421 the destinations. 423 6. Hijacking attacks 425 6.1. Hijacking attacks to the Basic MPTCP protocol 427 The hijacking attacks essentially use the MPTCP address agility to 428 allow an attacker to hijack a connection. This means that the victim 429 of a connection thinks that it is talking to a peer, while it is 430 actually exchanging packets with the attacker. In some sense it is 431 the dual of the flooding attacks (where the victim thinks it is 432 exchanging packets with the attacker but in reality is sending the 433 packets to the target). 435 The scenario for a hijacking attack is described in the next figure. 437 +------+ +------+ 438 | Node | ------------------------- | Node | 439 | 1 |IP1 IP2| 2 | 440 +------+ /+------+ 441 / 442 / 443 / 444 v IPA 445 +--------+ 446 |Attacker| 447 | A | 448 +--------+ 450 In this case, we have a MPTCP connection established between Node 1 451 and Node 2. The connection is using only one address per endpoint, 452 namely IP1 and IP2. The attacker then launches the hijacking attack 453 by adding IPA as an additional address for Node 1. In this case, 454 there is not much difference between explicit or implicit address 455 management, since in both cases the Attacker A could easily send a 456 control packet adding the address IPA, either as control data or as 457 the source address of the control packet. In order to be able to 458 hijack the connection, the attacker needs to know the 4-tuple that 459 identifies the connection, including the pair of addresses and the 460 pair of ports. It seems reasonable to assume that knowing the source 461 and destination IP addresses and the port of the server side is 462 fairly easy for the attacker. Learning the port of the client (i.e. 463 of the initiator of the connection) may prove to be more challenging. 464 The attacker would need to guess what the port is or to learn it by 465 intercepting the packets. Assuming that the attacker can gather the 466 4-tuple and issue the message adding IPA to the addresses available 467 for the MPTCP connection, then the attacker A has been able to 468 participate in the communication. In particular: 469 o Segments flowing from the Node 2:Depending how the usage of 470 addresses is defined, Node 2 will start using IPA to send data to. 471 In general, since the main goal is to achieve multi-path 472 capabilities, we can assume that unless there are already many IP 473 address pairs in use in the MPTCP connection, Node 2 will start 474 sending data to IPA. This means that part of the data of the 475 communication will reach the Attacker but probably not all of it. 476 This per se, already has negative effects, since Node 1 will not 477 receive all the data from Node 2. Moreover, from the application 478 perspective, this would result in DoS attack, since the byte flow 479 will stop waiting for the missing data. However, it is not enough 480 to achieve full hijacking of the connection, since part of data 481 will be still delivered to IP1, so it would reach Node 1 and not 482 the Attacker. In order for the attacker to receive all the data 483 of the MPTCP connection, the Attacker must somehow remove IP1 of 484 the set of available addresses for the connection. in the case of 485 implicit address management, this operation is likely to imply 486 sending a termination packet with IP1 as source address, which may 487 or not be possible for the attacker depending on whether ingress 488 filtering is in place and the location of the attacker. If 489 explicit address management is used, then the attacker will send a 490 remove address control packet containing IP1. The result is that 491 once IP1 is removed, all the data sent by Node 2 will reach the 492 Attacker and the incoming traffic has been hijacked. 493 o Segments flowing to the Node 2: As soon as IPA is accepted by Node 494 2 as part of the address set for the MPTCP connection, the 495 Attacker can send packets using IPA and those packets will be 496 considered by Node 2 as part of MPTCP connection. This means that 497 the attacker will be able to inject data into the MPTCP 498 connection, so from this perspective, the attacker has hijacked 499 part of the outgoing traffic. However, Node 1 would still be able 500 to send traffic that will be received by Node 2 as part of the 501 MPTCP connection. This means that there will be two sources of 502 data i.e. Node 1 and the attacker, potentially preventing the 503 full hijacking of the outgoing traffic by the attacker. In order 504 to achieve a full hijacking, the attacker would need to remove IP1 505 from the set of available addresses. This can be done using the 506 same techniques described in the previous paragraph. 508 A related attack that can be achieved using similar techniques would 509 be a Man-in-the-Middle (MitM) attack. The scenario for the attack is 510 depicted in the figure below. 512 +------+ +------+ 513 | Node | --------------- | Node | 514 | 1 |IP1 IP2| 2 | 515 +------+ \ /+------+ 516 \ / 517 \ / 518 \ / 519 v IPA v 520 +--------+ 521 |Attacker| 522 | A | 523 +--------+ 525 In this case, there is an established connection between Node 1 and 526 Node 2. The Attacker A will use the MPTCP address agility 527 capabilities to place itself as a MitM. In order to do so, it will 528 add IP address IPA as an additional address for the MPTCP connection 529 on both Node 1 and Node 2. This is essentially the same technique 530 described earlier in this section, only that it is used against both 531 nodes involved in the communication. The main difference is that in 532 this case, the attacker can simply sniff the content of the 533 communication that is forwarded through it and in turn forward the 534 data to the peer of the communication. The result is that the 535 attacker can place himself in the middle of the communication and 536 sniff part of the traffic unnoticed. Similar considerations about 537 how the attacker can manage to get to see all the traffic by removing 538 the genuine address of the peer apply. 540 6.2. Time-shifted hijacking attacks 542 A simple way to prevent off-path attackers to launch hijacking 543 attacks is to provide security of the control messages that add and 544 remove addresses by the usage of a cookie. In this type of 545 approaches, the peers involved in the MPTCP connection agree on a 546 cookie, that is exchanged in plain text during the establishment of 547 the connection and that needs to be presented in every control packet 548 that adds or removes an address for any of the peers. The result is 549 that the attacker needs to know the cookie in order to launch any of 550 the hijacking attacks described earlier. This implies that off path 551 attackers can no longer perform the hijacking attacks and that only 552 on-path attackers can do so, so one may consider that a cookie based 553 approach to secure MPTCP connection results in similar security than 554 current TCP. While it is close, it is not entirely true. 556 The main difference between the security of a MPTCP protocol secured 557 through cookies and the current TCP protocol are the time shifted 558 attacks. As we described earlier, a time shifted attack is one where 559 the attacker is along the path during a period of time, and then 560 moves away but the effects of the attack still remains, after the 561 attacker is long gone. In the case of a MPTCP protocol secured 562 through the usage of cookies, the attacker needs to be along the path 563 until the cookie is exchanged. After the attacker has learnt the 564 cookie, it can move away from the path and can still launch the 565 hijacking attacks described in the previous section. 567 There are several types of approaches that provide some protection 568 against hijacking attacks and that are vulnerable to some forms of 569 time-shifted attacks. We will next present some general taxonomy of 570 solutions and we describe the residual threats: 571 o Cookie-based solution: As we described earlier, one possible 572 approach is to use a cookie, that is sent in clear text in every 573 MPTCP control message that adds a new address to the existing 574 connection. The residual threat in this type of solution is that 575 any attacker that can sniff any of these control messages will 576 learn the cookie and will be able to add new addresses at any 577 given point in the lifetime of the connection. Moreover, the 578 endpoints will not detect the attack since the original cookie is 579 being used by the attacker. Summarizing, the vulnerability window 580 of this type of attacks includes all the flow establishment 581 exchanges and it is undetectable by the endpoints. 582 o Shared secret exchanged in plain text: An alternative option that 583 is somehow more secure than the cookie based approach is to 584 exchange a key in clear text during the establishment of the first 585 subflow and then validate the following subflows by using a keyed 586 HMAC signature using the shared key. This solution would be 587 vulnerable to attackers sniffing the message exchange for the 588 establishment of the first subflow, but after that, the shared key 589 is not transmitted any more, so the attacker cannot learn it 590 through sniffing any other message. Unfortunately, in order to be 591 compatible with NATs (see analysis below) even though this 592 approach includes a keyed HMAC signature, this signature cannot 593 cover the IP address that is being added. This basically means 594 that this type of approaches are also vulnerable to integrity 595 attacks of the exchanged messages. This means that even though 596 the attacker cannot learn the shared key by sniffing the 597 subsequent subflow establishment, the attacker can modify the 598 subflow establishment message and change the address that is being 599 added. So, the vulnerability window for confidentially to the 600 shared key is limited to the establishment of the first subflow, 601 but the vulnerability window for integrity attacks still includes 602 all the subflow establishment exchanges. These attacks are still 603 undetectable by the endpoints. It should be noted that the SCTP 604 security falls in this category. 605 o Strong crypto anchor exchange. Another approach that could be 606 used would be to exchange some strong crypto anchor while the 607 establishment of the first subflow, such as a public key or a hash 608 chain anchor. In this case, subsequent subflows could be 609 protected by using the crypto material associated to that anchor. 610 An attacker in this case would need to change the crypto material 611 exchanged in the connection establishment phase. As a result the 612 vulnerability window for forging the crypto anchor is limited to 613 the initial connection establishment exchange. Similarly to the 614 previous case, due to NAT traversal considerations, the 615 vulnerability window for integrity attacks include all the subflow 616 establishment exchanges. As opposed to the previous one, because 617 the attacker needs to change the crypto anchor, this approach are 618 detectable by the endpoints, if they communicate directly. 620 6.3. NAT considerations 622 In order to be widely adopted MPTCP must work through NATs. NATs are 623 an interesting device from a security perspective. In terms of MPTCP 624 they essentially behave as a Man-in-the-Middle attacker. As we have 625 described earlier, MPTCP security goal is to prevent from any 626 attacker to insert their addresses as valid addresses for a given 627 MPTCP connection. But that is exactly what a NAT does, they modify 628 the addresses. So, if MPTCP is to work through NATs, MPTCP must 629 accept address rewritten by NATs as valid addresses for a given 630 session. The most direct corollary is that the MPTCP messages that 631 add addresses in the implicit mode (i.e. the SYN of new subflows) 632 cannot be protected against integrity attacks, since they must allow 633 for NATs to change their addresses. This basically rules out any 634 solution that would rely on providing integrity protection to prevent 635 an attacker from changing the address used in a subflow establishment 636 exchange. This implies that alternative creative mechanisms are 637 needed to protect from integrity attacks to the MPTCP signaling that 638 adds new addresses to a connection. It is far from obvious how one 639 such creative approach could look like at this point. 641 7. Recommendation 643 The presented analysis shows that there is a tradeoff between the 644 complexity of the security solution and the residual threats. In 645 order to define a proper security solution, we need to assess the 646 tradeoff and make a recommendation. After evaluating the different 647 aspects in the MPTCP WG, our conclusion are as follows: 649 MPTCP should implement some form of reachability check using a random 650 nonce (e.g. TCP 3-way handshake) before adding a new address to an 651 ongoing communication in order to prevent flooding attacks. 653 The default security mechanisms for MPTCP should be to exchange a key 654 in clear text in the establishment of the first subflow and then 655 secure following address additions by using a keyed HMAC using the 656 exchanged key. 658 MPTCP security mechanism should support using a pre-shared key to be 659 used in the keyed HMAC, providing a higher level of protection than 660 the previous one. 662 A mechanism to prevent replay attacks using these messages should be 663 provided e.g. a sequence number protected by the HMAC. 665 The MPTCP protocol should be extensible and it should able to 666 accommodate multiple security solutions, in order to enable the usage 667 of more secure mechanisms if needed. 669 8. Security Considerations 671 This note contains a security analysis for MPTCP, so no further 672 security considerations need to be described in this section. 674 9. IANA Considerations 676 This document does not require any action from IANA. 678 10. Contributors 680 Alan Ford - Roke Manor Research Ltd. 682 11. Acknowledgments 684 Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, 685 Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil 686 Eardley reviewed an earlier version of this document and provided 687 comments to improve it. 689 Mark Handley pointed out the problem with NATs and integrity 690 protection of MPTCP signaling. 692 Marcelo Bagnulo is partly funded by Trilogy, a research project 693 supported by the European Commission under its Seventh Framework 694 Program. 696 12. References 698 12.1. Normative References 700 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 701 RFC 793, September 1981. 703 12.2. Informative References 705 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 706 Nordmark, "Mobile IP Version 6 Route Optimization Security 707 Design Background", RFC 4225, December 2005. 709 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 710 Multihoming Solutions", RFC 4218, October 2005. 712 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 713 RFC 3972, March 2005. 715 [RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security 716 Attacks Found Against the Stream Control Transmission 717 Protocol (SCTP) and Current Countermeasures", RFC 5062, 718 September 2007. 720 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 721 June 2009. 723 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 724 in IPv6", RFC 3775, June 2004. 726 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 727 Shim Protocol for IPv6", RFC 5533, June 2009. 729 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 730 RFC 4960, September 2007. 732 [I-D.ietf-mptcp-multiaddressed] 733 Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 734 Multipath Operation with Multiple Addresses", 735 draft-ietf-mptcp-multiaddressed-02 (work in progress), 736 October 2010. 738 Author's Address 740 Marcelo Bagnulo 741 Universidad Carlos III de Madrid 742 Av. Universidad 30 743 Leganes, Madrid 28911 744 SPAIN 746 Phone: 34 91 6248814 747 Email: marcelo@it.uc3m.es 748 URI: http://www.it.uc3m.es