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