idnits 2.17.1 draft-bagnulo-mptcp-threat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2010) is 5190 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 February 8, 2010 5 Expires: August 12, 2010 7 Threat Analysis for Multi-addressed/Multi-path TCP 8 draft-bagnulo-mptcp-threat-01 10 Abstract 12 Multi-addresses/Multi-path TCP (MPTCP for short) describes the 13 extensions proposed for TCP so that each endpoint of a given TCP 14 connection can use multiple IP addresses to exchange data (instead of 15 a single IP address per endpoint as currently defined). Such 16 extensions enable the exchange of segments using different source- 17 destination address pairs, resulting in the capability of using 18 multiple paths in a significant number of scenarios. In particular, 19 some level of multihoming and mobility support can be achieved 20 through these extensions. However, the support for multiple IP 21 addresses per endpoint may have implications on the security of the 22 resulting MPTCP protocol. This note includes a threat analysis for 23 MPTCP. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 12, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 9 71 6.2. Time-shifted hijacking attacks to cookie based secured 72 MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Multi-addresses/Multi-path TCP (MPTCP for short) describes the 82 extensions proposed for TCP so that each endpoint of a given TCP 83 connection can use multiple IP addresses to exchange data (instead of 84 a single IP address per endpoint as currently defined). Such 85 extensions enable the exchange of segments using different source- 86 destination address pairs, resulting in the capability of using 87 multiple paths in a significant number of scenarios. In particular, 88 some level of multihoming and mobility support can be achieved 89 through these extensions. However, the support for multiple IP 90 addresses per endpoint may have implications on the security of the 91 resulting MPTCP protocol. This note includes a threat analysis for 92 MPTCP. 94 2. Scope 96 There are multiple ways to achieve Multi-path TCP. Essentially what 97 is needed is for different segments of the communication to be 98 forwarded through different paths by enabling the sender to specify 99 some form of path selector. There are multiple options for such path 100 selector, including the usage of different next hops, using tunnels 101 to different egress points and so on. In this note, we will focus on 102 a particular approach, namely MPTCP approaches that rely on the usage 103 of multiple IP address per endpoint and that use different source- 104 destination address pairs as a mean to express different paths. So, 105 in the rest of this note, the MPTCP expression will refer to this 106 Multi-addressed flavour of Multi-path TCP. 108 Scope of the analysis 110 In this note we perform a threat analysis for MPTCP. Introducing the 111 support of multiple addresses per endpoint in a single TCP connection 112 may result in additional vulnerabilities. The scope of this note is 113 to identify and characterize these new vulnerabilities. So, the 114 scope of the analysis is limited to the additional vulnerabilities 115 resulting from the multi-address support compared to the current TCP 116 protocol (where each endpoint only has one address available for use 117 per connection). In other words, a full analysis of the complete set 118 of threats is explicitly out of the scope. The goal of this analysis 119 is to help the MPTCP protocol designers to create a MPTCP that is as 120 secure as the current TCP. It is a non goal of this analysis to help 121 in the design of MPTCP that is more secure than regular TCP. 123 In particular, we will focus on attackers that are not along the 124 path, at least not during the whole duration of the connection. In 125 the current single path TCP, on-path attacker can launch a 126 significant number of attacks, including eavesdropping, connection 127 hijacking Man in the Middle attacks and so on. However, it is not 128 possible for the off-path attackers to launch such attacks. There is 129 a middle ground in case the attacker is located along the path for a 130 short period of time to launch the attack and then moves away, but 131 the attack effects still apply. These are the so-called time-shifted 132 attacks. Since these are not possible in today's TCP, we will also 133 consider them as part of the analysis. So, summarizing, we will 134 consider both attacks launched by off-path attackers and time-shifted 135 attacks. Attacks launched by on-path attackers are out of scope, 136 since they also apply to current single-path TCP. 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). [RFC4225] includes the rational for the 151 design of the security of MIPv6 RO. All the attacks described in the 152 aforementioned analysis apply here and are an excellent basis for our 153 own analysis. The main differences are: 154 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. 169 In MIPv6 RO, there is the assumption that the original path 170 through which the connection has been established is always 171 available and in case it is not, the communication will be lost. 172 In MPTCP, it is an explicit goal to provide communication 173 resilience when one of the address pairs is no longer usable, so 174 it is not possible to leverage on the original address pair to be 175 always working. 176 MIPv6 RO is of course designed for IPv6 and it is an explicit goal 177 of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security 178 solutions rely on the usage of some characteristics of IPv6 (such 179 as the usage of CGAs [RFC3972]), which will no be usable in the 180 context of MPTCP. 182 In the Shim6 design, similar issues related to address agility were 183 considered and a threat analysis was also performed [RFC4218]. The 184 analysis performed for Shim6 also largely applies to the MPTCP 185 context, the main difference being: 186 Similarly to the MPTCP case, the Shim6 protocol is a layer 3 187 protocol so all the communications involving the target address 188 are at stake, as opposed to the MPTCP case, where the impact can 189 be limited to a single TCP connection. 190 Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as 191 identifiers and leverages on some of their properties to provide 192 the security, such as relying on CGAs or HBAs [RFC5535], which is 193 not possible in the MPTCP case where IPv4 addresses must be 194 supported. 196 SCTP is a transport protocol that supports multiple addresses per 197 endpoint and as such, the security implications are very close to the 198 ones of MPTCP. A security analysis, identifying a set of attacks and 199 proposed solutions was performed in [RFC5062]. The results of this 200 analysis apply directly to the case of MPTCP. However, the analysis 201 was performed after the base SCTP protocol was designed and the goal 202 of the document was essentially to improve the security of SCTP. As 203 such, the document is very specific to the actual SCTP specification 204 and relies on the SCTP messages and behaviour to characterize the 205 issues. While some them can be translated to the MPTCP case, some 206 may be caused by specific behaviour of SCTP as defined. In 207 particular, one issue that is different in the MPTCP case compared to 208 the SCTP case is that in MPTCP it is fundamental that multiple paths 209 are used simultaneously, which does have security implications. 211 So, the conclusion is that while we do have a significant amount of 212 previous work that is closely related and we can and will use it as a 213 basis for this analysis, there are a set of characteristics that are 214 specific to MPTCP that grant the need for a specific analysis for 215 MPTCP. The goal of this analysis is to help MPTCP protocol designers 216 to include a set of security mechanisms that prevent the introduction 217 of new vulnerabilities to the Internet due to the adoption of MPTCP. 219 4. Basic MPTCP. 221 As we stated earlier, the goal of this document is to serve as input 222 for MPTCP protocol designers to properly take into account the 223 security issues. As such, the analysis cannot be performed for a 224 specific MPTCP specification, but must be a general analysis that 225 applies to the widest possible set of MPTCP designs. In order to do 226 that, we will characterize what are the fundamental features that any 227 MPTCP protocol must provide and attempt to perform the security 228 implications only assuming those. In some cases, we will have a 229 design choice that will significantly influence the security aspects 230 of the resulting protocol. In that case we will consider both 231 options and try to characterize both designs. 233 We assume that any MPTCP will behave in the case of a single address 234 per endpoint as TCP. This means that a MPTCP connection will be 235 established by using the TCP 3-way handshake and will use a single 236 address pair. 238 The addresses used for the establishment of the connection do have a 239 special role in the sense that this is the address used as identifier 240 by the upper layers. In particular, the address used as destination 241 address in the SYN packet is the address that the application is 242 using to identify the peer and has been obtained either through the 243 DNS (with or without DNSSEC validation) or passed by a referral or 244 manually introduced by the user. As such, the initiator does have a 245 certain amount of trust in the fact that it is establishing a 246 communication with that particular address. If due to MPTCP, packets 247 end up being delivered to an alternative address, the trust that the 248 initiator has placed on that address would be deceived. In any case, 249 the adoption of MPTCP necessitates a slight evolution of the 250 traditional TCP trust model, in that the initiator is additionally 251 trusting the peer to provide additional addresses which it will trust 252 to the same degree as the original pair. An application or 253 implementation that cannot trust the peer in this way should not make 254 use of multiple paths. 256 During the 3-way handshake, the sequence number will be synchronized 257 for both ends, as in regular TCP. We assume that a MPTCP connection 258 will use a sequence number for the data, even if the data is 259 exchanged through different paths. 261 Once the connection is established, the MPTCP extensions can be used 262 to add addresses for each of the endpoints. In order to do that each 263 end will need to send a control message containing the additional 264 address(es). In order to associate the additional address to an 265 ongoing connection, the connection needs to be identified. We assume 266 that the connection can be identified by the 4-tuple of source 267 address, source port, destination address, destination port used for 268 the establishment of the connection. So, at least, the control 269 message that will convey the additional address information can also 270 contain the 4-tuple in order to inform about what connection the 271 address belong to (if no other connection identifier is defined). 272 There are two different ways to convey address information: 273 o Explicit mode: the control message contain a list of addresses. 274 o Implicit mode: the address added is the one included in the source 275 address field of the IP header 277 These two modes have significantly different security properties. 278 The explicit mode seems to be the more vulnerable to abuse. In 279 particular, the implicit mode may benefit from forms of ingress 280 filtering security, which would reduce the possibility of an attacker 281 to add any arbitrary address to an ongoing connection. 283 In addition, we will assume that MPTCP will use all the address pairs 284 that it has available for sending packets and that it will distribute 285 the load based on congestion among the different paths. 287 5. Flooding attacks 289 The first type of attacks that are introduced by address agility are 290 the so called flooding (or bombing) attacks. The setup for this 291 attack is depicted in the following figure: 293 +--------+ (step 1) +------+ 294 |Attacker| ------------------------- |Source| 295 | A |IPA IPS| S | 296 +--------+ /+------+ 297 / 298 (step 2) / 299 / 300 v IPT 301 +------+ 302 |Target| 303 | T | 304 +------+ 306 The scenario consists of an attacker A who has an IP address IPA. A 307 server that can generate a significant amount of traffic (such as a 308 streaming server), called source S and that has IP address IPS. In 309 addition, we have the target of the flooding attack, target T which 310 has an IP address IPT. 312 In the first step of this attack (depicted as step 1 in the figure), 313 the attacker A establishes a MPTCP connection with the source of the 314 traffic server S and starts downloading a significant amount of 315 traffic. The initial connection only involves one IP address per 316 endpoint, namely IPA and IPS. Once that the download is on course, 317 the second step of the attack (depicted as step 2 in the figure) is 318 that the attacker A adds IPT as one of the available addresses for 319 the communication. How the additional address is added depends on 320 the MPTCP address management mode. In explicit address management, 321 the attacker A only needs to send a signaling packet conveying 322 address IPT. In implicit mode, the attacker A would need to send a 323 packet with IPT as the source address. Depending on whether ingress 324 filtering is deployed and the location of the attacker, it may be 325 possible or not for the attacker to send such packet. At this stage, 326 the MPTCP connection still has a single address for the Source S i.e. 327 IPS but has two addresses for the Attacker A, namely IPA and IPT. 328 The attacker now attempts to get the Source S to send the traffic of 329 the ongoing download to the Target T IP address i.e. IPT. The 330 attacker can do that by pretending that the path between IPA and IPT 331 is congested but that the path between IPS and IPT is not. In order 332 to do that, it needs to send ACKs for the data that flows through the 333 path between IPS and IPT and do not send ACKs for the data that is 334 sent to IPA. The actual details of this will depend on how the data 335 sent through the different paths is ACKed. One possibility is that 336 ACKs for the data sent using a given a given address pair should come 337 in packets containing the same address pair. If so, the attacker 338 would need to send ACKs using packets containing IPT as the source 339 address to keep the attack flowing. This may be possible or not 340 depending on the deployment of ingress filtering and the location of 341 the attacker. The attacker would also need to guess the sequence 342 number of the data being sent to the Target. Once the attacker 343 manages to perform these actions the attack is on place and the 344 download will hit the target. It should be noted that in this type 345 of attacks, the Source S still thinks it is sending packets to the 346 Attacker A while in reality it is sending the packet to Target T. 348 Once that the traffic from the Source S start hitting the Target T, 349 the target will react. In particular, since the packets are likely 350 to belong to a non existent TCP connection, the Target T will issue 351 RST packets. It is relevant then to understand how MPTCP reacts to 352 incoming RST packets. It seems that the at least the MPTCP that 353 receives a RST packet should terminate the packet exchange 354 corresponding to the particular address pair (maybe not the complete 355 MPTCP connection, but at least it should not send more packets with 356 the address pair involved in the RST packet). However, if the 357 attacker, before redirecting the traffic has managed to increase the 358 window size considerably, the flight size could be enough to impose a 359 significant amount of traffic to the Target node. There is a subtle 360 operation that the attacker needs to achieve in order to launch a 361 significant attack. On the one hand it needs to grow the window 362 enough so that the flight size is big enough to cause enough effect 363 and on the other hand the attacker needs to be able to simulate 364 congestion on the IPA-IPS path so that traffic is actually redirected 365 to the alternative path without significantly reducing the window. 366 This will heavily depend on how the coupling of the windows between 367 the different paths works, in particular how the windows are 368 increased. Some designs of the congestion control window coupling 369 could render this attack ineffective. 371 Previous protocols that have to deal with this type of attacks have 372 done so by adding a reachability check before actually sending data 373 to a new address. In other words, the solution used in other 374 protocols such as MIPv6 RO, would include the Source S to explicitly 375 asking the host sitting in the new address (in this case the Target T 376 sitting in IPT) whether it is willing to accept packets from the 377 MPTCP connection identified by the 4-tuple IPA, port A, IPS, port S. 378 Since this is not part of the established connection that Target T 379 has, T would not accept the request and Source S would not use IPT to 380 send packets for this MPTCP connection. Usually, the request also 381 includes a nonce that cannot be guessed by the attacker A so that it 382 cannot fake the reply to the request easily. 384 One possible approach to do this reachability test would be to 385 perform a 3-way handshake for each new address pair that is going to 386 be used in a MPTCP connection. While there are other reasons for 387 doing this (such as NAT traversal), such approach would also act as a 388 reachability test and would prevent the flooding attacks described in 389 this section. 391 6. Hijacking attacks 393 6.1. Hijacking attacks to the Basic MPTCP protocol 395 The hijacking attacks essentially use the MPTCP address agility to 396 allow an attacker to hijack a connection. This means that the victim 397 of a connection thinks that it is talking to a peer, while it is 398 actually exchanging packets with the attacker. In some sense it is 399 the dual of the flooding attacks (where the victim thinks it is 400 exchanging packets with the attacker but in reality is sending the 401 packets to the target). 403 The scenario for a hijacking attack is described in the next figure. 405 +------+ +------+ 406 | Node | ------------------------- | Node | 407 | 1 |IP1 IP2| 2 | 408 +------+ /+------+ 409 / 410 / 411 / 412 v IPA 413 +--------+ 414 |Attacker| 415 | A | 416 +--------+ 418 In this case, we have a MPTCP connection established between Node 1 419 and Node 2. The connection is using only one address per endpoint, 420 namely IP1 and IP2. The attacker then launches the hijacking attack 421 by adding IPA as an additional address for Node 1. In this case, 422 there is not much difference between explicit or implicit address 423 management, since in both cases the Attacker A could easily send a 424 control packet adding the address IPA, either as control data or as 425 the source address of the control packet. In order to be able to 426 hijack the connection, the attacker needs to know the 4-tuple that 427 identifies the connection, including the pair of addresses and the 428 pair of ports. It seems reasonable to assume that knowing the source 429 and destination IP addresses and the port of the server side is 430 fairly easy for the attacker. Learning the port of the client (i.e. 431 of the initiator of the connection) may prove to be more challenging. 432 The attacker would need to guess what the port is or to learn it by 433 intercepting the packets. Assuming that the attacker can gather the 434 4-tuple and issue the message adding IPA to the addresses available 435 for the MPTCP connection, then the attacker A has been able to 436 participate in the communication. In particular: 437 o Segments flowing from the Node 2:Depending how the usage of 438 addresses is defined, Node 2 will start using IPA to send data to. 439 In general, since the main goal is to achieve multi-path 440 capabilities, we can assume that unless there are already many IP 441 address pairs in use in the MPTCP connection, Node 2 will start 442 sending data to IPA. This means that part of the data of the 443 communication will reach the Attacker but probably not all of it. 444 This per se, already has negative effects, since Node 1 will not 445 receive all the data from Node 2. However, it is not enough to 446 achieve full hijacking of the connection, since part of data will 447 be still delivered to IP1, so it would reach Node 1 and not the 448 Attacker. In order for the attacker to receive all the data of 449 the MPTCP connection, the Attacker must somehow remove IP1 of the 450 set of available addresses for the connection. in the case of 451 implicit address management, this operation is likely to imply 452 sending a termination packet with IP1 as source address, which may 453 or not be possible for the attacker depending on whether ingress 454 filtering is in place and the location of the attacker. If 455 explicit address management is used, then the attacker will send a 456 remove address control packet containing IP1. The result is that 457 once IP1 is removed, all the data sent by Node 2 will reach the 458 Attacker and the incoming traffic has been hijacked. 459 o Segments flowing to the Node 2: As soon as IPA is accepted by Node 460 2 as part of the address set for the MPTCP connection, the 461 Attacker can send packets using IPA and those packets will be 462 considered by Node 2 as part of MPTCP connection. This means that 463 the attacker will be able to inject data into the MPTCP 464 connection, so from this perspective, the attacker has hijacked 465 part of the outgoing traffic. However, Node 1 would still be able 466 to send traffic that will be received by Node 2 as part of the 467 MPTCP connection. This means that there will be two source of 468 data i.e. Node 1 and the attacker, potentially preventing the 469 full hijacking of the outgoing traffic by the attacker. In order 470 to achieve a full hijacking, the attacker would need to remove IP1 471 from the set of available addresses. This can be done using the 472 same techniques described in the previous paragraph. 474 A related attack that can be achieved using similar techniques would 475 be a Man in the Middle (MitM) attack. The scenario for the attack is 476 depicted in the figure below. 478 +------+ +------+ 479 | Node | --------------- | Node | 480 | 1 |IP1 IP2| 2 | 481 +------+ \ /+------+ 482 \ / 483 \ / 484 \ / 485 v IPA v 486 +--------+ 487 |Attacker| 488 | A | 489 +--------+ 491 In this case, there is an established connection between Node 1 and 492 Node 2. The Attacker A will use the MPTCP address agility 493 capabilities to place itself as a MitM. In order to do so, it will 494 add IP address IPA as an additional address for the MPTCP connection 495 on both Node 1 and Node 2. this is essentially the same technique 496 described earlier in this section, only that it is used against both 497 nodes involved in the communication. The main difference is that in 498 this case, the attacker can simply sniff the content of the 499 communication that is forwarded through it and in turn forward the 500 data to the peer of the communication. The result is that the 501 attacker can place himself in the middle of the communication and 502 sniff part of the traffic unnoticed. Similar considerations about 503 how the attacker can manage to get to see all the traffic by removing 504 the genuine address of the peer apply. 506 6.2. Time-shifted hijacking attacks to cookie based secured MPTCP 508 A simple way to prevent off-path attackers to launch hijacking 509 attacks is to provide security of the control messages that add and 510 remove addresses by the usage of a cookie. In this type of 511 approaches, the peers involved in the MPTCP connection agree on a 512 cookie, that is exchanged in plain text during the establishment of 513 the connection and that needs to be presented in every control packet 514 that adds or removes an address for any of the peers. The result is 515 that the attacker needs to know the cookie in order to launch any of 516 the hijacking attacks described earlier. This implies that off path 517 attackers can no longer perform the hijacking attacks and that only 518 on-path attackers can do so, so one may consider that a cookie based 519 approach to secure MPTCP connection results in similar security than 520 current TCP. While it is close, it is not entirely true. 522 The main difference between the security of a MPTCP protocol secured 523 through cookies and the current TCP protocol are the time shifted 524 attacks. As we described earlier, a time shifted attack is one where 525 the attacker is along the path during a period of time, and then 526 moves away but the effects of the attack still remains, after the 527 attacker is long gone. In the case of a MPTCP protocol secured 528 through the usage of cookies, the attacker needs to be along the path 529 until the cookie is exchanged. After the attacker has learnt the 530 cookie, it can move away from the path and can still launch the 531 hijacking attacks described in the previous section. 533 7. Security Considerations 535 This note contains a security analysis for MPTCP, so no further 536 security considerations need to be described in this section 538 8. Contributors 540 Alan Ford - Roke Manor Research Ltd. 542 9. Acknowledgments 544 Rolf Winter reviewed an earlier version of this document and provided 545 comments to improve it. 547 Marcelo Bagnulo is partly funded by Trilogy, a research project 548 supported by the European Commission under its Seventh Framework 549 Program. 551 10. Informative References 553 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 554 Nordmark, "Mobile IP Version 6 Route Optimization Security 555 Design Background", RFC 4225, December 2005. 557 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 558 Multihoming Solutions", RFC 4218, October 2005. 560 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 561 RFC 3972, March 2005. 563 [RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security 564 Attacks Found Against the Stream Control Transmission 565 Protocol (SCTP) and Current Countermeasures", RFC 5062, 566 September 2007. 568 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 569 June 2009. 571 Author's Address 573 Marcelo Bagnulo 574 Universidad Carlos III de Madrid 575 Av. Universidad 30 576 Leganes, Madrid 28911 577 SPAIN 579 Phone: 34 91 6248814 580 Email: marcelo@it.uc3m.es 581 URI: http://www.it.uc3m.es