idnits 2.17.1 draft-ietf-mptcp-attacks-03.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 3 instances 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 (February 24, 2015) is 3346 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 normative reference: RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: August 28, 2015 UCLouvain 6 F. Gont 7 SI6 Networks / UTN-FRH 8 O. Bonaventure 9 UCLouvain 10 C. Raiciu 11 UPB 12 February 24, 2015 14 Analysis of MPTCP residual threats and possible fixes 15 draft-ietf-mptcp-attacks-03 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 August 28, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 . . 10 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. SYN/JOIN attack . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Possible security enhancements to prevent this attack . . 14 67 7. Reccomendations . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Security enhancements for MPTCP . . . . . . . . . . . . . 15 69 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 11.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 This document provides a complement to the threat analysis for 80 Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181]. 81 RFC 6181 provided a threat analysis for the general solution space of 82 extending TCP to operate with multiple IP addresses per connection. 83 Its main goal was to leverage previous experience acquired during the 84 design of other multi-address protocols, notably SHIM6 [RFC5533], 85 SCTP [RFC4960] and MIPv6 [RFC6275] for designing MPTCP. Thus, RFC 86 6181 was produced before the actual MPTCP specification (RFC6824) was 87 completed, and documented a set of reccommendations that were 88 considered during the production of such specification. 90 This document complements RFC 6181 with a vulnerability analysis of 91 the specific mechanisms specified in RFC 6824. The motivation for 92 this analysis is to identify possible security issues with MPTCP as 93 currently specified and propose security enhancements to address the 94 identified security issues. 96 The goal of the security mechanisms defined in RFC 6824 were to make 97 MPTCP no worse than currently available single-path TCP. We believe 98 that this goal is still valid, so we will perform our analysis on the 99 same grounds. This document describes all the threats identified 100 that are specific to MPTCP (as defined in RFC6824) that are not 101 possible with (single-path) TCP. This means that threats that are 102 common to TCP and MPTCP are not covered in this document. 104 Types of attackers: for all attacks considered in this document, we 105 identify the type of attacker. We can classify the attackers based 106 on their location as follows: 108 o Off-path attacker. This is an attacker that does not need to be 109 located in any of the paths of the MPTCP session at any point in 110 time during the lifetime of the MPTCP session. This means that 111 the Off-path attacker cannot eavesdrop any of the packets of the 112 MPTCP session. 114 o Partial time On-path attacker. This is an attacker that needs to 115 be in at least one of the paths during part but not during the 116 entire lifetime of the MPTCP session. The attacker can be in the 117 forward and/or backward directions, for the initial subflow and/or 118 other subflows. The specific needs of the attacker will be made 119 explicit in the attack description. 121 o On-path attacker. This attacker needs to be on at least one of 122 the paths during the whole duration of the MPTCP session. The 123 attacker can be in the forward and/or backward directions, for the 124 initial subflow and/or other subflows. The specific needs of the 125 attacker will be made explicit in the attack description. 127 We can also classify the attackers based on their actions as follows: 129 o Eavesdropper. The attacker is able to capture some of the packets 130 of the MPTCP session to perform the attack, but it is not capable 131 of changing, discarding or delaying any packet of the MPTCP 132 session. The attacker can be in the forward and/or backward 133 directions, for the initial subflow and/or other subflows. The 134 specific needs of the attacker will be made explicit in the attack 135 description. 137 o Active attacker. The attacker is able to change, discard or delay 138 some of the packets of the MPTCP session. The attacker can be in 139 the forward and/or backward directions, for the initial subflow 140 and/or other subflows. The specific needs of the attacker will be 141 made explicit in the attack description. 143 In this document, we consider the following possible combinations of 144 attackers: 146 o an On-path eavesdropper 148 o an On-path active attacker 150 o an Off-path active attacker 152 o a Partial-time On-path eavesdropper 154 o a Partial-time On-path active attacker 156 In the rest of the document we describe different attacks that are 157 possible against the MPTCP protocol specified in RFC6824 and we 158 propose possible security enhancements to address them. 160 2. ADD_ADDR attack 162 Summary of the attack: 164 Type of attack: MPTCP session hijack enabling Man-in-the-Middle. 166 Type of attacker: Off-path, active attacker. 168 Description: 170 In this attack, the attacker uses the ADD_ADDR option defined in 171 RFC6824 to hijack an ongoing MPTCP session and enables himself to 172 perform a Man-in-the-Middle attack on the MPTCP session. 174 Consider the following scenario. Host A with address IPA has one 175 MPTCP session with Host B with address IPB. The MPTCP subflow 176 between IPA and IPB is using port PA on host A and port PB on host B. 177 The tokens for the MPTCP session are TA and TB for Host A and Host B 178 respectively. Host C is the attacker. It owns address IPC. The 179 attack is executed as follows: 181 1. Host C sends a forged packet with source address IPA, destination 182 address IPB, source port PA and destination port PB. The packet 183 has the ACK flag set. The TCP sequence number for the segment is 184 i and the ACK sequence number is j. We will assume all these are 185 valid, we discuss what the attacker needs to figure these ones 186 later on. The packet contains the ADD_ADDR option. The ADD_ADDR 187 option announces IPC as an alternative address for the 188 connection. It also contains an eight bit address identifier 189 which does not bring any strong security benefit. 191 2. Host B receives the ADD_ADDR message and it replies by sending a 192 TCP SYN packet. (Note: the MPTCP specification states that the 193 host receiving the ADD_ADDR option may initiate a new subflow. 194 If the host is configured so that it does not initiate a new 195 subflow the attack will not succeed. For example, on the current 196 Linux implementation, the server does not create subflows. Only 197 the client does so.) The source address for the packet is IPB, 198 the destination address for the packet is IPC, the source port is 199 PB' and the destination port is PA' (It is not required that 200 PA=PA' nor that PB=PB'). The sequence number for this packet is 201 the new initial sequence number for this subflow. The ACK 202 sequence number is not relevant as the ACK flag is not set. The 203 packet carries an MP_JOIN option and it carries the token TA. It 204 also carries a random nonce generated by Host B called RB. 206 3. Host C receives the SYN+MP_JOIN packet from Host B, and it alters 207 it in the following way. It changes the source address to IPC 208 and the destination address to IPA. It sends the modified packet 209 to Host A, impersonating Host B. 211 4. Host A receives the SYN+MP_JOIN message and it replies with a 212 SYN/ACK+MP_JOIN message. The packet has source address IPA and 213 destination address IPC, as well as all the other needed 214 parameters. In particular, Host A computes a valid HMAC and 215 places it in the MP_JOIN option. 217 5. Host C receives the SYN/ACK+MP_JOIN message and it changes the 218 source address to IPC and the destination address to IPB. It 219 sends the modified packet to IPB impersonating Host A. 221 6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the 222 HMAC of the MP_JOIN option and confirms its validity. It replies 223 with an ACK+MP_JOIN packet. The packet has source address IPB 224 and destination address IPC, as well as all the other needed 225 parameters. The returned MP_JOIN option contains a valid HMAC 226 computed by Host B. 228 7. Host C receives the ACK+MP_JOIN message from B and it alters it 229 in the following way. It changes the source address to IPC and 230 the destination address to IPA. It sends the modified packet to 231 Host A impersonating Host B. 233 8. Host A receives the ACK+MP_JOIN message and creates the new 234 subflow. 236 At this point the attacker has managed to place itself as a 237 MitM for one subflow for the existing MPTCP session. It 238 should be noted that there still exists the subflow between 239 address IPA and IPB that does not flow through the attacker, 240 so the attacker has not completely intercepted all the packets 241 in the communication (yet). If the attacker wishes to 242 completely intercept the MPTCP session it can do the following 243 additional step. 245 9. Host C sends two TCP RST messages. One TCP RST packet is sent to 246 Host B, with source address IPA and destination address IPB and 247 source and destination ports PA and PB, respectively. The other 248 TCP RST message is sent to Host A, with source address IPB and 249 destination address IPA and source and destination ports PB and 250 PA, respectively. Both RST messages must contain a valid 251 sequence number. Note that figuring the sequence numbers to be 252 used here for subflow A is the same difficulty as being able to 253 send the initial ADD_ADDR option with valid Sequence number and 254 ACK value. If there are more subflows, then the attacker needs 255 to find the Sequence Number and ACK for each subflow. 257 At this point the attacker has managed to fully hijack the 258 MPTCP session. 260 Information required by the attacker to perform the described attack: 262 In order to perform this attack the attacker needs to guess or know 263 the following pieces of information: (The attacker need this 264 information for one of the subflows belonging to the MPTCP session.) 266 o the four-tuple {Client-side IP Address, Client-side Port, Server- 267 side Address, Servcer-side Port} that identifies the target TCP 268 connection 270 o a valid sequence number for the subflow 272 o a valid ACK sequence number for the subflow 274 o a valid address identifier for IPC 276 TCP connections are uniquely identified by the four-tuple {Source 277 Address, Source Port, Destination Address, Destination Port}. Thus, 278 in order to attack a TCP connection, an attacker needs to know or be 279 able to guess each of the values in that four-tuple. Assuming the 280 two peers of the target TCP connection are known, the Source Address 281 and the Destination Address can be assumed to be known. 283 We note that in order to be able to successfully perform this 284 attack, the attacker needs to be able to send packets with a 285 forged source address. This means that the attacker cannot be 286 located in a network where techniques like ingress filtering 288 [RFC2827] or source address validation [RFC7039] are deployed. 289 However, ingress filtering is not as widely implemented as one 290 would expect, and hence cannot be relied upon as a mitigation for 291 this kind of attack. 293 Assuming the attacker knows the application protocol for which the 294 TCP connection is being employed, the server-side port can also be 295 assumed to be known. Finally, the client-side port will generally 296 not be known, and will need to be guessed by the attacker. The 297 chances of an attacker guessing the client-side port will depend on 298 the ephemeral port range employed by the client, and whether the 299 client implements port randomization [RFC6056]. 301 Assuming TCP sequence number randomization is in place (see e.g. 302 [RFC6528]), an attacker would have to blindly guess a valid TCP 303 sequence number. That is, 305 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< 306 SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 308 As a result, the chances of an attacker to succeed will depend on the 309 TCP receive window size at the target TCP peer. 311 We note that automatic TCP buffer tuning mechanisms have been 312 become common for popular TCP implementations, and hence very 313 large TCP window sizes of values up to 2 MB could end up being 314 employed by such TCP implementations. 316 According to [RFC0793], the Acknowledgement Number is considered 317 valid as long as it does not acknowledge the receipt of data that has 318 not yet been sent. That is, the following expression must be true: 320 SEG.ACK <= SND.NXT 322 However, for implementations that support [RFC5961], the following 323 (stricter) validation check is enforced: 325 SND.UNA - SND.MAX.WND <= SEG.ACK <= SND.NXT 327 Finally, in order for the address identifier to be valid, the only 328 requirement is that it needs to be different than the ones already 329 being used by Host A in that MPTCP session, so a random identifier is 330 likely to work. 332 Given that a large number of factors affect the chances of an 333 attacker of successfully performing the aforementioned off-path 334 attacks, we provide two general expressions for the expected number 335 of packets the attacker needs to send to succeed in the attack: one 336 for MPTCP implementations that support [RFC5961], and another for 337 MPTCP implementations that do not. 339 Implementations that do not support RFC 5961 341 Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS 343 Where the new : 345 Packets: 346 Maximum number of packets required to successfully perform an off- 347 path (blind) attack. 349 RCV_WND: 350 TCP receive window size (RCV.WND) at the target node. 352 EPH_PORT_SIZE: 353 Number of ports comprising the ephemeral port range at the 354 "client" system. 356 MSS: 357 Maximum Segment Size, assuming the attacker will send full 358 segments to maximize the chances to get a hit. 360 Notes: 361 The value "2^32" represents the size of the TCP sequence number 362 space. 363 The value "2" accounts for 2 different ACK numbers (separated by 364 2^31) that should be employed to make sure the ACK number is 365 valid. 367 The following table contains some sample results for the number of 368 required packets, based on different values of RCV_WND and 369 EPH_PORT_SIZE for a MSS of 1500 bytes. 371 +-------------+---------+---------+--------+---------+ 372 | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | 373 +-------------+---------+---------+--------+---------+ 374 | 4000 | 699050 | 87381 | 43690 | 5461 | 375 +-------------+---------+---------+--------+---------+ 376 | 10000 | 1747626 | 218453 | 109226 | 13653 | 377 +-------------+---------+---------+--------+---------+ 378 | 50000 | 8738133 | 1092266 | 546133 | 68266 | 379 +-------------+---------+---------+--------+---------+ 381 Table 1: Max. Number of Packets for Successful Attack 383 Implementations that do support RFC 5961 384 Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) * 385 EPH_PORT_SIZE/2 * 1/MSS 387 Where: 389 Packets: 390 Maximum number of packets required to successfully perform an off- 391 path (blind) attack. 393 RCV_WND: 394 TCP receive window size (RCV.WND) at the target MPTCP endpoint. 396 SND_MAX_WND: 397 Maximum TCP send window size ever employed by the target MPTCP 398 end-point (SND.MAX.WND). 400 EPH_PORT_SIZE: 401 Number of ports comprising the ephemeral port range at the 402 "client" system. 404 Notes: 405 The value "2^32" represents the size of the TCP sequence number 406 space. 407 The parameter "SND_MAX_WND" is specified in [RFC5961]. 408 The value "2*SND_MAX_WND" results from the expresion "SND.NXT - 409 SND.UNA - MAX.SND.WND", assuming that, for connections that 410 perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND". 411 If an attacker targets a TCP endpoint that is not actively 412 transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND" 413 (and hence a successful attack would typically require more 414 packets). 416 The following table contains some sample results for the number of 417 required packets, based on different values of RCV_WND, SND_MAX_WND, 418 and EPH_PORT_SIZE. For these implementations, only a limited number 419 of sample results are provided, just as an indication of how 420 [RFC5961] increases the difficulty of performing these attacks. 422 +-------------+-------------+-----------+-----------+---------+ 423 | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | 424 +-------------+-------------+-----------+-----------+---------+ 425 | 4000 | 45812984490 | 715827882 | 178956970 | 2796202 | 426 +-------------+-------------+-----------+-----------+---------+ 428 Table 2: Max. Number of Packets for Successful Attack 430 Note: 432 In the aforementioned table, all values are computed with RCV_WND 433 equal to SND_MAX_WND. 435 2.1. Possible security enhancements to prevent this attack 437 1. To include the token of the connection in the ADD_ADDR option. 438 This would make it harder for the attacker to launch the attack, 439 since he needs to either eavesdrop the token (so this can no 440 longer be a blind attack) or to guess it, but a random 32 bit 441 number is not so easy to guess. However, this would imply that 442 any eavesdropper that is able to see the token, would be able to 443 launch this attack. This solution then increases the 444 vulnerability window against eavesdroppers from the initial 3-way 445 handshake for the MPTCP session to any exchange of the ADD_ADDR 446 messages. 448 2. To include the HMAC of the address contained in the ADD_ADDR 449 option concatenated with the key of the receiver and the key of 450 the sender (in the same way they are used for generating the HMAC 451 of the MP_JOIN message) of the ADD_ADDR message. This makes it 452 much more secure, since it requires the attacker to have both 453 keys (either by eavesdropping it in the first exchange or by 454 guessing it). Because this solution relies on the key used in 455 the MPTCP session, the protection of this solution would increase 456 if new key generation methods are defined for MPTCP (e.g. using 457 SSL keys as has been proposed). 459 3. To include the destination address of the SYN packet in the HMAC 460 of the MP_JOIN message. As the attacker requires to change the 461 destination address to perform the described attack, protecting 462 it would prevent the attack. It wouldn't allow hosts behind NATs 463 to be reached by an address in the ADD_ADDR option, even with 464 static NAT bindings (like a web server at home). 466 Out of the options described above, option 2 is reccommended as it 467 achieves a higher security level while preserving the required 468 functionality (i.e. NAT compatibility). 470 3. DoS attack on MP_JOIN 472 Summary of the attack: 474 Type of attack: MPTCP Denial-of-Service attack, preventing the 475 hosts from creating new subflows. 477 Type of attacker: Off-path, active attacker 479 Description: 481 As currently specified, the initial SYN+MP_JOIN message of the 3-way 482 handshake for additional subflows creates state in the host receiving 483 the message. This is because the SYN+MP_JOIN contains the 32-bit 484 token that allows the receiver to identify the MPTCP-session and the 485 32-bit random nonce, used in the HMAC calculation. As this 486 information is not resent in the third ACK of the 3-way handshake, a 487 host must create state upon reception of a SYN+MP_JOIN. 489 Assume that there exists an MPTCP-session between host A and host B, 490 with token Ta and Tb. An attacker, sending a SYN+MP_JOIN to host B, 491 with the valid token Tb, will trigger the creation of state on host 492 B. The number of these half-open connections a host can store per 493 MPTCP-session is limited by a certain number, and it is 494 implementation-dependent. The attacker can simply exhaust this limit 495 by sending multiple SYN+MP_JOINs with different 5-tuples. The 496 (possibly forged) source address of the attack packets will typically 497 correspond to an address that is not in use, or else the SYN/ACK sent 498 by Host B would elicit a RST from the impersonated node, thus 499 removing the corresponding state at Host B. Further discussion of 500 traditional SYN-flood attacks and common mitigations can be found in 501 [RFC4987] 503 This effectively prevents the host A from sending any more 504 SYN+MP_JOINs to host B, as the number of acceptable half-open 505 connections per MPTCP-session on host B has been exhausted. 507 The attacker needs to know the token Tb in order to perform the 508 described attack. This can be achieved if it is a Partial-time On- 509 path eavesdropper , observing the 3-way handshake of the 510 establishment of an additional subflow between host A and host B. If 511 the attacker is never on-path, it has to guess the 32-bit token. 513 3.1. Possible security enhancements to prevent this attack 515 The third packet of the 3-way handshake could be extended to contain 516 also the 32-bit token and the random nonce that has been sent in the 517 SYN+MP_JOIN. Further, host B will have to generate its own random 518 nonce in a reproducible fashion (e.g., a Hash of the 5-tuple + 519 initial sequence-number + local secret). This will allow host B to 520 reply to a SYN+MP_JOIN without having to create state. Upon the 521 reception of the third ACK, host B can then verify the correctness of 522 the HMAC and create the state. 524 4. SYN flooding amplification 526 Summary of the attack: 528 Type of attack: The attacker can use the SYN+MP_JOIN messages to 529 amplify the SYN flooding attack. 531 Type of attacker: Off-path, active attacker 533 Description: 535 SYN flooding attacks [RFC4987] use SYN messages to exhaust the 536 server's resources and prevent new TCP connections. A common 537 mitigation is the use of SYN cookies [RFC4987] that allow the 538 stateless processing of the initial SYN message. 540 With MPTCP, the initial SYN can be processed in a stateless fashion 541 using the aforementioned SYN cookies. However, as we described in 542 the previous section, as currently specified, the SYN+MP_JOIN 543 messages are not processed in a stateless manner. This opens a new 544 attack vector. The attacker can now open a MPTCP session by sending 545 a regular SYN and creating the associated state but then send as many 546 SYN+MP_JOIN messages as supported by the server with different source 547 address source port combinations, consuming server's resources 548 without having to create state in the attacker. This is an 549 amplification attack, where the cost on the attacker side is only the 550 cost of the state associated with the initial SYN while the cost on 551 the server side is the state for the initial SYN plus all the state 552 associated to all the following SYN+MP_JOIN. 554 4.1. Possible security enhancements to prevent this attack 556 1. The solution described for the previous DoS attack on MP_JOIN 557 would also prevent this attack. 559 2. Limiting the number of half open subflows to a low number (e.g. 3 560 subflows) would also limit the impact of this attack. 562 5. Eavesdropper in the initial handshake 564 Summary of the attack 566 Type of attack: An eavesdropper present in the initial handshake 567 where the keys are exchanged can hijack the MPTCP session at any 568 time in the future. 570 Type of attacker: a Partial-time On-path eavesdropper 572 Description: 574 In this case, the attacker is present along the path when the initial 575 3-way handshake takes place, and therefore is able to learn the keys 576 used in the MPTCP session. This allows the attacker to move away 577 from the MPTCP session path and still be able to hijack the MPTCP 578 session in the future. This vulnerability was readily identified at 579 the moment of the design of the MPTCP security solution and the 580 threat was considered acceptable. 582 5.1. Possible security enhancements to prevent this attack 584 There are many techniques that can be used to prevent this attack and 585 each of them represents different tradeoffs. At this point, we limit 586 ourselves to enumerate them and provide useful pointers. 588 1. Use of hash-chains. The use of hash chains for MPTCP has been 589 explored in [hash-chains] 591 2. Use of SSL keys for MPTCP security as described in 592 [I-D.paasch-mptcp-ssl] 594 3. Use of Cryptographically-Generated Addresses (CGAs) for MPTCP 595 security. CGAs [RFC3972] have been used in the past to secure 596 multi addressed protocols like SHIM6 [RFC5533]. 598 4. Use of TCPCrypt [I-D.bittau-tcp-crypt] 600 5. Use DNSSEC. DNSSEC has been proposed to secure the Mobile IP 601 protocol [dnssec] 603 6. SYN/JOIN attack 605 Summary of the attack 607 Type of attack: An attacker that can intercept the SYN/JOIN 608 message can alter the source address being added. 610 Type of attacker: a Partial-time On-path eavesdropper 612 Description: 614 The attacker is present along the path when the SYN/JOIN exchange 615 takes place, and this allows the attacker to add any new address it 616 wants to by simply substituting the source address of the SYN/JOIN 617 packet for one it chooses. This vulnerability was readily identified 618 at the moment of the design of the MPTCP security solution and the 619 threat was considered acceptable. 621 6.1. Possible security enhancements to prevent this attack 623 It should be noted that this vulnerability is fundamental due to the 624 NAT support requirement. In other words, MPTCP must work through 625 NATs in order to be deployable in the current Internet. NAT behavior 626 is unfortunately indistinguishable from this attack. It is 627 impossible to secure the source address, since doing so would prevent 628 MPTCP to work though NATs. This basically implies that the solution 629 cannot rely on securing the address. A more promising approach would 630 be then to look into securing the payload exchanged, limiting the 631 impact that the attack would have in the communication (e.g. 632 TCPCrypt [I-D.bittau-tcp-crypt] or similar). 634 7. Reccomendations 636 Current MPTCP specification [RFC6824] is experimental. There is an 637 ongoing effort to move it to Standards track. We believe that the 638 work on MPTCP security should follow two threads: 640 o The work on improving MPTCP security so that is enough to become a 641 Standard Track document. 643 o The work on analyzing possible additional security enhancements to 644 provide a more secure version of MPTCP. 646 We will expand on these two next. 648 MPTCP security for a Standard Track specification. 650 We believe that in order for MPTCP to progress to Standard Track, the 651 ADD_ADDR attack must be addressed. We believe that the solution that 652 should be adopted in order to deal with this attack is to include an 653 HMAC to the ADD_ADDR message (with the address being added used as 654 input to the HMAC, as well as the key). This would make the ADD_ADDR 655 message as secure as the JOIN message. In addition, this implies 656 that if we implement a more secure way to create the key used in the 657 MPTCP connection, then the security of both the MP_JOIN and the 658 ADD_ADDR messages is automatically improved (since both use the same 659 key in the HMAC). 661 We believe that this is enough for MPTCP to progress as a Standard 662 track document, because the security level is similar to single path 663 TCP, as results from our previous analysis. Moreover, the security 664 level achieved with these changes is exactly the same as other 665 Standard Track documents. In particular, this would be the same 666 security level as SCTP with dynamic addresses as defined in 667 [RFC5061]. The Security Consideration section of RFC5061 (which is a 668 Standard Track document) reads: 670 The addition and or deletion of an IP address to an existing 671 association does provide an additional mechanism by which existing 672 associations can be hijacked. Therefore, this document requires 673 the use of the authentication mechanism defined in [RFC4895] to 674 limit the ability of an attacker to hijack an association. 675 Hijacking an association by using the addition and deletion of an 676 IP address is only possible for an attacker who is able to 677 intercept the initial two packets of the association setup when 678 the SCTP-AUTH extension is used without pre-shared keys. If such 679 a threat is considered a possibility, then the [RFC4895] extension 680 must be used with a preconfigured shared endpoint pair key to 681 mitigate this threat. 683 This is the same security level that would be achieved by MPTCP plus 684 the ADD_ADDR security measure reccommended. 686 7.1. Security enhancements for MPTCP 688 We also believe that is worthwhile exploring alternatives to secure 689 MPTCP. As we identified earlier, the problem is securing JOIN 690 messages is fundamentally incompatible with NAT support, so it is 691 likely that a solution to this problem involves the protection of the 692 data itself. Exploring the integration of MPTCP and approaches like 693 TCPCrypt [I-D.bittau-tcp-crypt] or integration with SSL seem 694 promising venues. 696 8. Security considerations 698 This whole document is about security considerations for MPTCP. 700 9. IANA Considerations 702 There are no IANA considerations in this memo. 704 10. Acknowledgments 706 We would like to thank Mark Handley for his comments on the attacks 707 and countermeasures discussed in this document. thanks to Alissa 708 Copper, Phil Eardley, Yoshifumi Nishida, Barry Leiba, Stephen 709 Farrell, Stefan Winter for the comments and review. Marcelo Bagnulo, 710 Christophe Paasch, Oliver Bonaventure and Costin Raiciu are partially 711 funded by the EU Trilogy 2 project. 713 11. References 714 11.1. Normative References 716 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 717 793, September 1981. 719 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 720 RFC 3972, March 2005. 722 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 723 Robustness to Blind In-Window Attacks", RFC 5961, August 724 2010. 726 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 727 Protocol Port Randomization", BCP 156, RFC 6056, January 728 2011. 730 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 731 Number Attacks", RFC 6528, February 2012. 733 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 734 Kozuka, "Stream Control Transmission Protocol (SCTP) 735 Dynamic Address Reconfiguration", RFC 5061, September 736 2007. 738 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 739 "Authenticated Chunks for the Stream Control Transmission 740 Protocol (SCTP)", RFC 4895, August 2007. 742 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 743 "TCP Extensions for Multipath Operation with Multiple 744 Addresses", RFC 6824, January 2013. 746 11.2. Informative References 748 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 749 Multipath Operation with Multiple Addresses", RFC 6181, 750 March 2011. 752 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 753 Shim Protocol for IPv6", RFC 5533, June 2009. 755 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 756 4960, September 2007. 758 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 759 in IPv6", RFC 6275, July 2011. 761 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 762 Defeating Denial of Service Attacks which employ IP Source 763 Address Spoofing", BCP 38, RFC 2827, May 2000. 765 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 766 "Source Address Validation Improvement (SAVI) Framework", 767 RFC 7039, October 2013. 769 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 770 Mitigations", RFC 4987, August 2007. 772 [I-D.paasch-mptcp-ssl] 773 Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP 774 handshake with external keys", draft-paasch-mptcp-ssl-00 775 (work in progress), October 2012. 777 [I-D.bittau-tcp-crypt] 778 Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, 779 D., and Q. Slack, "Cryptographic protection of TCP Streams 780 (tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress), 781 February 2014. 783 [hash-chains] 784 Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security 785 for multipath TCP: a constructive approach", International 786 Journal of Internet Protocol Technology 6, 2011. 788 [dnssec] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy, 789 "OAM-DNSSEC: Route Optimization for Aeronautical Mobility 790 using DNSSEC", 4th ACM International Workshop on Mobility 791 in the Evolving Internet Architecture MobiArch 2009, 2009. 793 Authors' Addresses 795 Marcelo Bagnulo 796 Universidad Carlos III de Madrid 797 Av. Universidad 30 798 Leganes, Madrid 28911 799 SPAIN 801 Phone: 34 91 6249500 802 Email: marcelo@it.uc3m.es 803 URI: http://www.it.uc3m.es 804 Christoph Paasch 805 UCLouvain 806 Place Sainte Barbe, 2 807 Louvain-la-Neuve, 1348 808 Belgium 810 Email: christoph.paasch@uclouvain.be 812 Fernando Gont 813 SI6 Networks / UTN-FRH 814 Evaristo Carriego 2644 815 Haedo, Provincia de Buenos Aires 1706 816 Argentina 818 Phone: +54 11 4650 8472 819 Email: fgont@si6networks.com 820 URI: http://www.si6networks.com 822 Olivier Bonaventure 823 UCLouvain 824 Place Sainte Barbe, 2 825 Louvain-la-Neuve, 1348 826 Belgium 828 Email: olivier.bonaventure@uclouvain.be 830 Costin Raiciu 831 Universitatea Politehnica Bucuresti 832 Splaiul Independentei 313a 833 Bucuresti 834 Romania 836 Email: costin.raiciu@cs.pub.ro