idnits 2.17.1 draft-bagnulo-mptcp-attacks-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-bittau-tcp-crypt-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Informational C. Paasch 5 Expires: January 15, 2014 UCLouvain 6 F. Gont 7 SI6 Networks / UTN-FRH 8 O. Bonaventure 9 UCLouvain 10 C. Raiciu 11 UPB 12 July 14, 2013 14 Analysis of MPTCP residual threats and possible fixes 15 draft-bagnulo-mptcp-attacks-00 17 Abstract 19 This documents performs an analysis of the residual threats for MPTCP 20 and explores possible solutions to them. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 15, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. ADD_ADDR attack . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Possible security enhancements to prevent this attack . . 9 59 3. DoS attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 10 60 3.1. Possible security enhancements to prevent this attack . . 11 61 4. SYN flooding amplification . . . . . . . . . . . . . . . . . 11 62 4.1. Possible security enhancements to prevent this attack . . 12 63 5. Eavesdropper in the initial handshake . . . . . . . . . . . . 12 64 5.1. Possible security enhancements to prevent this attack . . 13 65 6. Security considerations . . . . . . . . . . . . . . . . . . . 13 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 This document provides a complement to the threat analysis for 76 Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181]. 77 RFC 6181 provided a threat analysis for the general solution space of 78 extending TCP to operate with multiple IP addresses per connection. 79 Its main goal was to leverage previous experience acquired during the 80 design of other multi-address protocols, notably SHIM6 [RFC5533], 81 SCTP [RFC4960] and MIPv6 [RFC3775] during the design of MPTCP. Thus, 82 RFC 6181 was produced before the actual MPTCP specification (RFC6824) 83 was completed, and documented a set of recommendations that were 84 considered during the production of such specification. 86 This document complements RFC 6181 with a vulnerability analysis of 87 the specific mechanisms specified in RFC 6824. The motivation for 88 this analysis is to identify possible security issues with MPTCP as 89 currently specified and propose security enhancements to address the 90 identified security issues. 92 The goal of the security mechanisms defined in RFC 6824 were to make 93 MPTCP no worse than currently available single-path TCP. We believe 94 that this goal is still valid, so we will perform our analysis on the 95 same grounds. 97 Types of attackers: for all attacks considered in this documents, we 98 identify the type of attacker. We can classify the attackers based 99 on their location as follows: 101 o Off-path attacker. This is an attacker that does not need to be 102 located in any of the paths of the MPTCP session at any point in 103 time during the lifetime of the MPTCP session. This means that 104 the Off-path attacker cannot eavesdrop any of the packets of the 105 MPTCP session. 107 o Partial time On-path attacker. This is an attacker that needs to 108 be in at least one of the paths during part but not during the 109 entire lifetime of the MPTCP session. The attacker can be in the 110 forward and/or backward directions, for the initial subflow and/or 111 other subflows. The specific needs of the attacker will be made 112 explicit in the attack description. 114 o On-path attacker. This attacker needs to be on at least one of 115 the paths during the whole duration of the MPTCP session. The 116 attacker can be in the forward and/or backward directions, for the 117 initial subflow and/or other subflows. The specific needs of the 118 attacker will be made explicit in the attack description. 120 We can also classify the attackers based on their actions as follows: 122 o Eavesdropper. The attacker is able to capture some of the packets 123 of the MPTCP session to perform the attack, but it is not capable 124 of changing, discarding or delaying any packet of the MPTCP 125 session. The attacker can be in the forward and/or backward 126 directions, for the initial subflow and/or other subflows. The 127 specific needs of the attacker will be made explicit in the attack 128 description. 130 o Active attacker. The attacker is able to change, discard or delay 131 some of the packets of the MPTCP session. The attacker can be in 132 the forward and/or backward directions, for the initial subflow 133 and/or other subflows. The specific needs of the attacker will be 134 made explicit in the attack description. 136 In this document, we consider the following possible combinations of 137 attackers: 139 o an On-path eavesdropper 141 o an On-path active attacker 143 o an Off-path active attacker 144 o a Partial-time On-path eavesdropper 146 o a Partial-time On-path active attacker 148 In the rest of the document we describe different attacks that are 149 possible against the MPTCP protocol specified in RFC6824 and we 150 propose possible security enhancements to address them. 152 2. ADD_ADDR attack 154 Summary of the attack: 156 Type of attack: MPTCP session hijack enabling Man-in-the-Middle. 158 Type of attacker: Off-path, active attacker. 160 Threat: Medium 162 Description: 164 In this attack, the attacker uses the ADD_ADDR option defined in 165 RFC6824 to hijack an ongoing MPTCP session and enables himself to 166 perform a Man-in-the-Middle attack on the MPTCP session. 168 Consider the following scenario. Host A with address IPA has one 169 MPTCP session with Host B with address IPB. The MPTCP subflow 170 between IPA and IPB is using port PA on host A and port PB on host B. 171 The tokens for the MPTCP session are TA and TB for Host A and Host B 172 respectively. Host C is the attacker. It owns address IPC. The 173 attack is executed as follows: 175 1. Host C sends a forged packet with source address IPA, destination 176 address IPB, source port PA and destination port PB. The packet 177 has the ACK flag set. The TCP sequence number for the segment is 178 i and the ACK sequence number is j. We will assume all these are 179 valid, we discuss what the attacker needs to figure these ones 180 later on. The packet contains the ADD_ADDR option. The ADD_ADDR 181 option announces IPC as an alternative address for the 182 connection. It also contains an eight bit address identifier 183 which does not bring any strong security benefit. 185 2. Host B receives the ADD_ADDR message and it replies by sending a 186 TCP SYN packet. (Note: the MPTCP specification states that the 187 host receiving the ADD_ADDR option may initiate a new subflow. 188 If the host is configured so that it does not initiate a new 189 subflow the attack will not succeed. For example, on the Linux 190 implementation, the server does not create subflows. Only the 191 client does so.) The source address for the packet is IPB, the 192 destination address for the packet is IPC, the source port is PB' 193 and the destination port is PA' (It is not required that PA=PA' 194 nor that PB=PB'). The sequence number for this packet is the new 195 initial sequence number for this subflow. The ACK sequence 196 number is not relevant as the ACK flag is not set. The packet 197 carries an MP_JOIN option and it carries the token TA. It also 198 carries a random nonce generated by Host B called RB. 200 3. Host C receives the SYN+MP_JOIN packet from Host B, and it alters 201 it in the following way. It changes the source address to IPC 202 and and the destination address to IPA. It sends the modified 203 packet to Host A, impersonating Host B. 205 4. Host A receives the SYN+MP_JOIN message and it replies with a SYN 206 /ACK+MP_JOIN message. The packet has source address IPA and 207 destination address IPC, as well as all the other needed 208 parameters. In particular, Host A computes a valid HMAC and 209 places it in the MP_JOIN option. 211 5. Host C receives the SYN/ACK+MP_JOIN message and it changes the 212 source address to IPC and the destination address to IPB. It 213 sends the modified packet to IPB impersonating Host A. 215 6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the 216 HMAC of the MP_JOIN option and confirms its validity. It replies 217 with an ACK+MP_JOIN packet. The packet has source address IPB 218 and destination address IPC, as well as all the other needed 219 parameters. The returned MP_JOIN option contains a valid HMAC 220 computed by Host B. 222 7. Host C receives the ACK+MP_JOIN message from B and it alters it 223 in the following way. It changes the source address to IPC and 224 the destination address to IPA. It sends the modified packet to 225 Host A impersonating Host B. 227 8. Host A receives the ACK+MP_JOIN message and creates the new 228 subflow. 230 At this point the attacker has managed to place itself as a 231 MitM for one subflow for the existing MPTCP session. It 232 should be noted that there still exists the subflow between 233 address IPA and IPB that does not flow through the 234 attacker, so the attacker has not completely intercepted 235 all the packets in the communication (yet). If the 236 attacker wishes to completely intercept the MPTCP session 237 it can do the following additional step. 239 9. Host C sends two TCP RST messages. One TCP RST packet is sent to 240 Host B, with source address IPA and destination address IPB and 241 source and destination ports PA and PB, respectively. The other 242 TCP RST message is sent to Host A, with source address IPB and 243 destination address IPA and source and destination ports PB and 244 PA, respectively. Both RST messages must contain a valid 245 sequence number. Note that figuring the sequence numbers to be 246 used here for subflow A is the same difficulty as being able to 247 send the initial ADD_ADDR option with valid Sequence number and 248 ACK value. If there are more subflows, then the attacker needs 249 to find the Sequence Number and ACK for each subflow. 251 At this point the attacker has managed to fully hijack the 252 MPTCP session. 254 Information required by the attacker to perform the described attack: 256 In order to perform this attack the attacker needs to guess or know 257 the following pieces of information: (The attacker need this 258 information for one of the subflows belonging to the MPTCP session.) 260 o the four-tuple {Client-side IP Address, Client-side Port, Server- 261 side Address, Servcer-side Port} that identifies the target TCP 262 connection 264 o a valid sequence number for the subflow 266 o a valid ACK sequence number for the subflow 268 o a valid address identifier for IPC 270 TCP connections are uniquely identified by the four-tuple {Source 271 Address, Source Port, Destination Address, Destination Port}. Thus, 272 in order to attack a TCP connection, an attacker needs to know or be 273 able to guess each of the values in that four-tuple. Assuming the 274 two peers of the target TCP connection are known, the Source Address 275 and the Destination Address can be assumed to be known. 277 We note that in order to be able to successfully perform this 278 attack, the attacker needs to be able to send packets with a 279 forged source address. This means that the attacker cannot be 280 located in a network where techniques like ingress filtering 281 [RFC2827] or source address validation [I-D.ietf-savi-framework] 282 are deployed. However, ingress filtering is not as widely 283 implemented as one would expect, and hence cannot be relied upon 284 as a mitigation for this kind of attack. 286 Assuming the attacker knows the application protocol for which the 287 TCP connection is being employed, the server-side port can also be 288 assumed to be known. Finally, the client-side port will generally 289 not be known, and will need to be guessed by the attacker. The 290 chances of an attacker guessing the client-side port will depend on 291 the ephemeral port range employed by the client, and whether the 292 client implements port randomization [RFC6056]. 294 Assuming TCP sequence number randomization is in place (see e.g. 295 [RFC6528]), an attacker would have to blindly guess a valid TCP 296 sequence number. That is, 298 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< 299 SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 301 As a result, the chances of an attacker to succeed will depend on the 302 TCP receive window size at the target TCP peer. 304 We note that automatic TCP buffer tuning mechanisms have been 305 become common for popular TCP implementations, and hence very 306 large TCP window sizes of values up to 2 MB could end up being 307 employed by such TCP implementations. 309 According to [RFC0793], the Acknowledgement Number is considered 310 valid as long as it does not acknowledge the receipt of data that has 311 not yet been sent. That is, the following expression must be true: 313 SEG.ACK <= SND.NXT 315 However, for implementations that support [RFC5961], the following 316 (stricter) validation check is enforced: 318 SND.UNA - SND.MAX.WND <= SEG.ACK <= SND.NXT 320 Finally, in order for the address identifier to be valid, the only 321 requirement is that it needs to be different than the ones already 322 being used by Host A in that MPTCP session, so a random identifier is 323 likely to work. 325 Given that a large number of factors affect the chances of an 326 attacker of successfully performing the aforementioned off-path 327 attacks, we provide two general expressions for the expected number 328 of packets the attacker needs to send to succeed in the attack: one 329 for MTCP implementations that support [RFC5961], and another for 330 MPTCP implementations that do not. 332 Implementations that do not support RFC 5961 333 Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS 335 Where the new : 337 Packets: 338 Maximum number of packets required to successfully perform an off- 339 path (blind) attack. 341 RCV_WND: 342 TCP receive window size (RCV.WND) at the target node. 344 EPH_PORT_SIZE: 345 Number of ports comprising the ephemeral port range at the 346 "client" system. 348 MSS: 349 Maximum Segment Size, assuming the attacker will send full 350 segments to maximize the chances to get a hit. 352 Notes: 353 The value "2^32" represents the size of the TCP sequence number 354 space. 355 The value "2" accounts for 2 different ACK numbers (separated by 356 2^31) that should be employed to make sure the ACK number is 357 valid. 359 The following table contains some sample results for the number of 360 required packets, based on different values of RCV_WND and 361 EPH_PORT_SIZE for a MSS of 1500 bytes. 363 +-------------+---------+---------+--------+---------+ 364 | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | 365 +-------------+---------+---------+--------+---------+ 366 | 4000 | 699050 | 87381 | 43690 | 5461 | 367 +-------------+---------+---------+--------+---------+ 368 | 10000 | 1747626 | 218453 | 109226 | 13653 | 369 +-------------+---------+---------+--------+---------+ 370 | 50000 | 8738133 | 1092266 | 546133 | 68266 | 371 +-------------+---------+---------+--------+---------+ 373 Table 1: Max. Number of Packets for Successful Attack 375 Implementations that do not support RFC 5961 377 Packets = (2^32/(RCV_WND)) * (2^32/(SND_MAX_WND)) * EPH_PORT_SIZE/2 * 378 1/MSS 380 Where: 382 Packets: 383 Maximum number of packets required to successfully perform an off- 384 path (blind) attack. 386 RCV_WND: 387 TCP receive window size (RCV.WND) at the target MPTCP endpoint. 389 SND_MAX_WND: 390 Maximum TCP send window size ever employed by the target MPTCP 391 end-point (SND.MAX.WND). 393 EPH_PORT_SIZE: 394 Number of ports comprising the ephemeral port range at the 395 "client" system. 397 Notes: 398 The value "2^32" represents the size of the TCP sequence number 399 space. 400 The parameter "SND_MAX_WND" is specified in [RFC5961]. 402 The following table contains some sample results for the number of 403 required packets, based on different values of RCV_WND, SND_MAX_WND, 404 and EPH_PORT_SIZE. For these implementations, only a limited number 405 of sample results are provided, just as an indication of how 406 [RFC5961] increases the difficulty of performing these attacks. 408 +-------------+-------------+------------+-----------+---------+ 409 | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | 410 +-------------+-------------+------------+-----------+---------+ 411 | 4000 | 91625968967 | 1431655765 | 357913941 | 559240 | 412 +-------------+-------------+------------+-----------+---------+ 414 Table 2: Max. NUmber of Packets for Successful Attack 416 Note: 417 In the aforementioned table, all values are computed with RCV_WND 418 equal to SND_MAX_WND. 420 2.1. Possible security enhancements to prevent this attack 422 1. To include the token of the connection in the ADD_ADDR option. 423 This would make it harder for the attacker to launch the attack, 424 since he needs to either eavesdrop the token (so this can no 425 longer be a blind attack) or to guess it, but a random 32 bit 426 number is not so easy to guess. However, this would imply that 427 any eavesdropper that is able to see the token, would be able to 428 launch this attack. This solution then increases the 429 vulnerability window against eavesdroppers from the initial 3-way 430 handshake for the MPTCP session to any exchange of the ADD_ADDR 431 messages. 433 2. To include the HMAC of the address contained in the ADD_ADDR 434 option concatenated with the key of the receiver of the ADD-ADDR 435 message. This makes it much more secure, since it requires the 436 attacker to have both keys (either by eavesdropping it in the 437 first exchange or by guessing it). Because this solution relies 438 on the key used in the MPTCP session, the protection of this 439 solution would increase if new key generation methods are defined 440 for MPTCP (e.g. using SSL keys as has been proposed). 442 3. To include the destination address of the ADD_ADDR msg in the 443 HMAC. This would certainly make the attack harder (the attacker 444 would need to know the key). It wouldn't allow hosts behind NATs 445 to be reached by an address in the ADD_ADDR option, even with 446 static NAT bindings (like a web server at home). Probably it 447 would make sense to combine it option 2) (i.e. to have the HMAC 448 of the address in the ADD_ADDR option and the destination address 449 of the packet. 451 4. To include the destination address of the SYN packet in the HMAC 452 of the MP_JOIN message. This has the same problems than option 453 3) in the presence of NATs. 455 3. DoS attack on MP_JOIN 457 Summary of the attack: 459 Type of attack: MPTCP Denial-of-Service attack, preventing the 460 hosts from creating new subflows. 462 Type of attacker: Off-path, active attacker 464 Threat: Low (? - as it is hard to guess the 32-bit token and still 465 then the attacker only prevents the creation of new subflows) 467 Description: 469 As currently specified, the initial SYN+MP_JOIN message of the 3-way 470 handshake for additional subflows creates state in the host receiving 471 the message. This, because the SYN+MP_JOIN contains the 32-bit token 472 that allows the receiver to identify the MPTCP-session and the 32-bit 473 random nonce, used in the HMAC calculation. As this information is 474 not resent in the third ACK of the 3-way handshake, a host must 475 create state upon reception of a SYN+MP_JOIN. 477 Assume that there exists an MPTCP-session between host A and host B, 478 with token Ta and Tb. An attacker, sending a SYN+MP_JOIN to host B, 479 with the valid token Tb, will trigger the creation of state on host 480 B. The number of these half-open connections a host can store per 481 MPTCP-session is limited by a certain number, and it is 482 implementation-dependent. The attacker can simply exhaust this limit 483 by sending multiple SYN+MP_JOINs with different 5-tuples. The 484 (possibly forged) source address of the attack packets will typically 485 correspond to an address that is not in use, or else the SYN/ACK sent 486 by Host B would elicit a RST from the impersonated node, thus 487 removing the corresponding state at Host B. Further discussion of 488 traditional SYN-flod attacks and common mitigations can be found in 489 [RFC4987] 491 This effectively prevents the host A from sending any more 492 SYN+MP_JOINs to host B, as the number of acceptable half-open 493 connections per MPTCP-session on host B has been exhausted. 495 The attacker needs to know the token Tb in order to perform the 496 described attack. This can be achieved if it is a partial on-time 497 eavesdropper, observing the 3-way handshake of the establishment of 498 an additional subflow between host A and host B. If the attacker is 499 never on-path, it has to guess the 32-bit token. 501 Christoph: can you provide text about the birthday paradox and busy 502 servers? 504 3.1. Possible security enhancements to prevent this attack 506 The third packet of the 3-way handshake could be extended to contain 507 also the 32-bit token and the random nonce that has been sent in the 508 SYN+MP_JOIN. Further, host B will have to generate its own random 509 nonce in a reproducible fashion (e.g., a Hash of the 5-tuple + 510 initial sequence-number + local secret). This will allow host B to 511 reply to a SYN+MP_JOIN without having to create state. Upon the 512 reception of the third ACK, host B can then verify the correctness of 513 the HMAC and create the state. 515 4. SYN flooding amplification 517 Summary of the attack: 519 Type of attack: The attacker can use the SYN+MP_JOIN messages to 520 amplify the SYN flooding attack. 522 Type of attacker: Off-path, active attacker 524 Threat: Medium 526 Description: 528 SYN flooding attacks [RFC4987] use SYN messages to exhaust the 529 server's resources and prevent new TCP connections. A common 530 mitigation is the use of SYN cookies [RFC4987] that allow the 531 stateless processing of the initial SYN message. 533 With MPTCP, the initial SYN can be processed in a stateless fashion 534 using the aforementioned SYN cookies. However, as we described in 535 the previous section, as currently specified, the SYN+MP_JOIN 536 messages are not processed in a stateless manner. This opens a new 537 attack vector. The attacker can now open a MPTCP session by sending 538 a regular SYN and creating the associated state but then send as many 539 SYN+MP_JOIN messages as supported by the server with different source 540 address source port combinations, consuming server's resources 541 without having to create state in the attacker. This is an 542 amplification attack, where the cost on the attacker side is only the 543 cost of the state associated with the initial SYN while the cost on 544 the server side is the state for the initial SYN plus all the state 545 associated to all the following SYN+MP_JOIN. 547 4.1. Possible security enhancements to prevent this attack 549 1. The solution described for the previous DoS attack on MP_JOIN 550 would also prevent this attack. 552 2. Limiting the number of half open subflows to a low number (like 553 3) would also limit the impact of this attack. 555 5. Eavesdropper in the initial handshake 557 Summary of the attack 559 Type of attack: An eavesdropper present in the initial handshake 560 where the keys are exchanged can hijack the MPTCP session at any 561 time in the future. 563 Type of attacker: a Partial-time On-path eavesdropper 565 Threat: Low 567 Description: 569 In this case, the attacker is present along the path when the initial 570 3-way handshake takes place, and therefore is able to learn the keys 571 used in the MPTCP session. This allows the attacker to move away 572 from the MPTCP session path and still be able to hijack the MPTCP 573 session in the future. This vulnerability was readily identified at 574 the moment of the design of the MPTCP security solution and the 575 threat was considered acceptable. 577 5.1. Possible security enhancements to prevent this attack 579 There are many techniques that can be used to prevent this attack and 580 each of them represents different tradeoffs. At this point, we limit 581 ourselves to enumerate them and provide useful pointers. 583 1. Use of hash-chains. The use of hash chains for MPTCP has been 584 explored in [hash-chains] 586 2. Use of SSL keys for MPTCP security as described in 587 [I-D.paasch-mptcp-ssl] 589 3. Use of Cryptographically-Generated Addresses (CGAs) for MPTCP 590 security. CGAs [RFC3972] have been used in the past to secure 591 multi addressed protocols like SHIM6 [RFC5533]. 593 4. Use of TCPCrypt [I-D.bittau-tcp-crypt] 595 5. Use DNSSEC. DNSSEC has been proposed to secure the Mobile IP 596 protocol [dnssec] 598 6. Security considerations 600 This whole document is about security considerations for MPTCP. 602 7. IANA Considerations 604 There are no IANA considerations in this memo. 606 8. Acknowledgments 608 We would like to thank Mark Handley for his comments on the attacks 609 and countermeasures discussed in this document. 611 9. References 613 9.1. Normative References 615 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 616 793, September 1981. 618 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 619 RFC 3972, March 2005. 621 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 622 Robustness to Blind In-Window Attacks", RFC 5961, August 623 2010. 625 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 626 Protocol Port Randomization", BCP 156, RFC 6056, January 627 2011. 629 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 630 Number Attacks", RFC 6528, February 2012. 632 9.2. Informative References 634 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 635 "TCP Extensions for Multipath Operation with Multiple 636 Addresses", RFC 6824, January 2013. 638 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 639 Multipath Operation with Multiple Addresses", RFC 6181, 640 March 2011. 642 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 643 Shim Protocol for IPv6", RFC 5533, June 2009. 645 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 646 4960, September 2007. 648 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 649 in IPv6", RFC 3775, June 2004. 651 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 652 Defeating Denial of Service Attacks which employ IP Source 653 Address Spoofing", BCP 38, RFC 2827, May 2000. 655 [I-D.ietf-savi-framework] 656 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 657 "Source Address Validation Improvement Framework", draft- 658 ietf-savi-framework-06 (work in progress), January 2012. 660 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 661 Mitigations", RFC 4987, August 2007. 663 [I-D.paasch-mptcp-ssl] 664 Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP 665 handshake with external keys", draft-paasch-mptcp-ssl-00 666 (work in progress), October 2012. 668 [I-D.bittau-tcp-crypt] 669 Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, 670 D., and Q. Slack, "Cryptographic protection of TCP Streams 671 (tcpcrypt)", draft-bittau-tcp-crypt-03 (work in progress), 672 September 2012. 674 [hash-chains] 675 Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security 676 for multipath TCP: a constructive approach", International 677 Journal of Internet Protocol Technology 6, 2011. 679 [dnssec] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy, 680 "OAM-DNSSEC: Route Optimization for Aeronautical Mobility 681 using DNSSEC", 4th ACM International Workshop on Mobility 682 in the Evolving Internet Architecture MobiArch 2009, 2009. 684 Authors' Addresses 686 Marcelo Bagnulo 687 Universidad Carlos III de Madrid 688 Av. Universidad 30 689 Leganes, Madrid 28911 690 SPAIN 692 Phone: 34 91 6249500 693 Email: marcelo@it.uc3m.es 694 URI: http://www.it.uc3m.es 696 Christoph Paasch 697 UCLouvain 698 Place Sainte Barbe, 2 699 Louvain-la-Neuve, 1348 700 Belgium 702 Email: christoph.paasch@uclouvain.be 704 Fernando Gont 705 SI6 Networks / UTN-FRH 706 Evaristo Carriego 2644 707 Haedo, Provincia de Buenos Aires 1706 708 Argentina 710 Phone: +54 11 4650 8472 711 Email: fgont@si6networks.com 712 URI: http://www.si6networks.com 713 Olivier Bonaventure 714 UCLouvain 715 Place Sainte Barbe, 2 716 Louvain-la-Neuve, 1348 717 Belgium 719 Email: olivier.bonaventure@uclouvain.be 721 Costin Raiciu 722 Universitatea Politehnica Bucuresti 723 Splaiul Independentei 313a 724 Bucuresti 725 Romania 727 Email: costin.raiciu@cs.pub.ro