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