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