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