RFC 7430

Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)

📅 published July 2015, from ietf

Internet Engineering Task Force (IETF) 🎀

RFC: 7430 ✨ Title: Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) Authors: M. Bagnulo (UC3M), C. Paasch (UCLouvain), F. Gont (SI6 Networks / UTN-FRH), O. Bonaventure (UCLouvain), C. Raiciu (UPB) Category: Informational ISSN: 2070-1721 Date: July 2015 Obsoletes / Updates: This document's header doesn't list anything it obsoletes or updates. 🌸

Abstract 🔥

okay so this doc takes a long, hard look at the leftover threats for Multipath TCP (MPTCP) and brainstorms some ways to fix them 💅

Status of This Memo 🧚

bestie, this one is not an Internet Standards Track spec. It's published for information only 🫶

It's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. It went through public review and got the green light from the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💜

If you want the latest status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc7430 ✨

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🍓

Table of Contents 🦋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.  ADD_ADDR Attack . . . . . . . . . . . . . . . . . . . . . . .   4
    2.1.  Possible Security Enhancements to Prevent This Attack . .  10
  3.  DoS Attack on MP_JOIN . . . . . . . . . . . . . . . . . . . .  11
    3.1.  Possible Security Enhancements to Prevent This Attack . .  12
  4.  SYN Flooding Amplification  . . . . . . . . . . . . . . . . .  12
    4.1.  Possible Security Enhancements to Prevent This Attack . .  13
  5.  Eavesdropper in the Initial Handshake . . . . . . . . . . . .  13
    5.1.  Possible Security Enhancements to Prevent This Attack . .  14
  6.  SYN/JOIN Attack . . . . . . . . . . . . . . . . . . . . . . .  14
    6.1.  Possible Security Enhancements to Prevent This Attack . .  14
  7.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .  15
    7.1.  MPTCP Security Improvements for a Standards Track
          Specification . . . . . . . . . . . . . . . . . . . . . .  15
    7.2.  Security Enhancements for MPTCP . . . . . . . . . . . . .  16
  8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
  9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
    9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
    9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

okay so this doc is a sidekick to the threat analysis for Multipath TCP (MPTCP) [RFC6824], which lives in RFC 6181 [RFC6181] 🧚 RFC 6181 looked at the whole solution space for extending TCP to use multiple IP addresses per connection. The big goal was to learn from earlier multi-address protocols, especially Shim6 [RFC5533], the Stream Control Transmission Protocol (SCTP) [RFC4960], and Mobile IPv6 (MIP6) [RFC6275], so MPTCP could be designed with that wisdom. That means RFC 6181 came out before the real MPTCP spec (RFC 6824) was finished, and it wrote down some recommendations that the spec authors considered along the way 💅

This doc adds to RFC 6181 by running a vulnerability analysis on the mechanisms in RFC 6824. The point is to find possible security issues with MPTCP as it's currently specified, and then suggest security enhancements to fix them 🔥

The security goal of RFC 6824 was to make MPTCP no worse than single-path TCP that's already out there. We still think that goal makes sense, so we analyze on the same terms. This doc covers all the threats specific to MPTCP (as defined in RFC 6824) that aren't possible with single-path TCP. So threats that TCP and MPTCP share are not covered here 🦋

For each attack, we say what type of attacker it is. Attackers can be sorted by location like this:

  • Off-path attacker. This attacker doesn't need to sit on any of the paths of the MPTCP session at any point during its lifetime. So an off-path attacker cannot eavesdrop on any of the packets of the MPTCP session 🙈
  • Partial-time on-path attacker. This attacker needs to be on at least one of the paths for part of the MPTCP session's lifetime, though not the whole thing. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The exact needs get spelled out in each attack description 🌸
  • On-path attacker. This attacker needs to be on at least one of the paths for the entire duration of the MPTCP session. The attacker can be in the forward and/or backward directions for the initial subflow and/or other subflows. The exact needs get spelled out in each attack description 👑

Attackers can also be sorted by what they actually do:

  • Eavesdropper. This attacker can capture some of the packets of the MPTCP session to pull off the attack, but it can't change, discard, or delay any packet of the MPTCP session. It can be in the forward and/or backward directions for the initial subflow and/or other subflows. The exact needs get spelled out in each attack description 👀
  • Active attacker. This attacker can change, discard, or delay some of the packets of the MPTCP session. It can be in the forward and/or backward directions for the initial subflow and/or other subflows. The exact needs get spelled out in each attack description 💀

This doc considers these combos of attackers:

  • an on-path eavesdropper
  • an on-path active attacker
  • an off-path active attacker
  • a partial-time on-path eavesdropper
  • a partial-time on-path active attacker

For the rest of the doc, we describe the different attacks that work against the MPTCP protocol in RFC 6824 and suggest security enhancements for each one ✨

2. ADD_ADDR Attack 🍓

Summary of the Attack 🫶

  • Type of attack: MPTCP session hijack enabling a man-in-the-middle (MitM) attack
  • Type of attacker: off-path active attacker

Description 🧚

this one is giving hijack energy 😭 The attacker uses the ADD_ADDR option defined in RFC 6824 to take over an ongoing MPTCP session, and then sets itself up to run a man-in-the-middle attack on that session 🔥

Here's the setup. Host A, with address IPA, has one MPTCP session with Host B, with address IPB. The MPTCP subflow between IPA and IPB uses port PA on Host A and port PB on Host B. The tokens for the MPTCP session are TA and TB for Host A and Host B, respectively. Host C is the attacker, and it owns address IPC. Here's how the attack plays out:

  1. Host C sends a forged packet with source address IPA, destination address IPB, source port PA, and destination port PB. The packet has the ACK flag set. The TCP sequence number for the segment is i, and the ACK sequence number is j. We'll assume all of these are valid for now, and we'll get to what the attacker needs in order to figure them out later. The packet contains the ADD_ADDR option, which announces IPC as an alternative address for the connection. It also carries an 8-bit address identifier that doesn't give any real security benefit 💅
  2. Host B receives the ADD_ADDR message and replies by sending a TCP SYN packet.
Note: The MPTCP specification [RFC6824] states that the host receiving the ADD_ADDR option may initiate a new subflow. If the host is configured so that it does not initiate a new subflow, the attack will not succeed. For example, on the current Linux implementation, the server does not create subflows. Only the client does so. 🙈

The source address for this packet is IPB, and the destination address is IPC. The source port is PB', and the destination port is PA' (it is not required that PA=PA' nor that PB=PB'). The sequence number for this packet is the new initial sequence number for this subflow. The ACK sequence number isn't relevant because the ACK flag isn't set. The packet carries an MP_JOIN option and the token TA. It also carries a random nonce generated by Host B, called RB 🦋

  1. Host C receives the SYN+MP_JOIN packet from Host B and alters it. It changes the source address to IPC and the destination address to IPA. Then it sends the modified packet to Host A, impersonating Host B 😈
  2. Host A receives the SYN+MP_JOIN message and replies with a SYN/ACK+MP_JOIN message. The packet has source address IPA and destination address IPC, along with all the other needed parameters. In particular, Host A computes a valid Hashed Message Authentication Code (HMAC) and places it in the MP_JOIN option 🔐
  3. Host C receives the SYN/ACK+MP_JOIN message and changes the source address to IPC and the destination address to IPB. It sends the modified packet to IPB, impersonating Host A 🎭
  4. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the HMAC of the MP_JOIN option and confirms that it's valid. It replies with an ACK+MP_JOIN packet. The packet has source address IPB and destination address IPC, along with all the other needed parameters. The returned MP_JOIN option contains a valid HMAC computed by Host B ✅
  5. Host C receives the ACK+MP_JOIN message from Host B and alters it. It changes the source address to IPC and the destination address to IPA. It sends the modified packet to Host A, impersonating Host B 👑
  6. Host A receives the ACK+MP_JOIN message and creates the new subflow. Bestie, at this point the attacker has managed to place itself as a MitM for one subflow of the existing MPTCP session 😳🕷️. It should be noted that the subflow between addresses IPA and IPB that does not flow through the attacker still exists, so the attacker has not completely intercepted all the packets in the communication (yet) 👀. If the attacker wishes to completely intercept the MPTCP session, it can do the following additional step.
  7. Host C sends two TCP RST messages. One TCP RST packet is sent to Host B, with source address IPA, destination address IPB, and source and destination ports PA and PB, respectively. The other TCP RST message is sent to Host A, with source address IPB, destination address IPA, and source and destination ports PB and PA, respectively. Both RST messages must contain a valid sequence number 🎯. Note that figuring the sequence numbers to be used here for subflow A is the same difficulty as being able to send the initial ADD_ADDR option with valid sequence number and ACK value. If there are more subflows, then the attacker needs to find the sequence number and ACK for each subflow. At this point, the attacker has managed to fully hijack the MPTCP session 💀🫣.

Information required by the attacker to perform the described attack:

In order to perform this attack the attacker needs to guess or know the following pieces of information. The attacker needs this information for one of the subflows belonging to the MPTCP session ✨.

  • the four-tuple {Client-side IP Address, Client-side Port, Server-side Address, Server-side Port} that identifies the target TCP connection
  • a valid sequence number for the subflow
  • a valid ACK sequence number for the subflow
  • a valid address identifier for IPC

TCP connections are uniquely identified by the four-tuple {Source Address, Source Port, Destination Address, Destination Port}. Thus, in order to attack a TCP connection, an attacker needs to know or be able to guess each of the values in that four-tuple. Assuming the two peers of the target TCP connection are known, the Source Address and the Destination Address can be assumed to be known 🧠.

Note: In order to be able to successfully perform this attack, the attacker needs to be able to send packets with a forged source address. This means that the attacker cannot be located in a network where techniques like ingress filtering [RFC2827] or source address validation [RFC7039] are deployed. However, ingress filtering is not as widely implemented as one would expect and hence cannot be relied upon as a mitigation for this kind of attack. 🙃

Assuming the attacker knows the application protocol for which the TCP connection is being employed, the server-side port can also be assumed to be known. Finally, the client-side port will generally not be known and will need to be guessed by the attacker. The chances of an attacker guessing the client-side port will depend on the ephemeral port range employed by the client and whether or not the client implements port randomization [RFC6056] 🎲.

Assuming TCP sequence number randomization is in place (see e.g., [RFC6528]), an attacker would have to blindly guess a valid TCP sequence number. That is,

RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =<
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

As a result, the chances of an attacker succeeding will depend on the TCP receive window size at the target TCP peer 🪟.

Note: Automatic TCP buffer tuning mechanisms have become common for popular TCP implementations; hence, very large TCP window sizes of values up to 2 MB could end up being employed by such TCP implementations. 📈

According to [RFC793], the acknowledgement number is considered valid as long as it does not acknowledge the receipt of data that has not yet been sent. That is, the following expression must be true:

SEG.ACK <= SND.NXT

However, for implementations that support [RFC5961], the following (stricter) validation check is enforced:

SND.UNA - MAX.SND.WND <= SEG.ACK <= SND.NXT

Finally, in order for the address identifier to be valid, the only requirement is that it needs to be different from the ones already being used by Host A in that MPTCP session, so a random identifier is likely to work 🎀.

Given that a large number of factors affect the chances of an attacker successfully performing the aforementioned off-path attacks, we provide two general expressions for the expected number of packets the attacker needs to send to succeed in the attack: one for MPTCP implementations that support [RFC5961] and another for MPTCP implementations that do not 🧮.

Implementations that do not support RFC 5961:

Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS

Where the new parameters are:

  • Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
  • RCV_WND: TCP receive window size (RCV.WND) at the target node.
  • EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.
  • MSS: Maximum Segment Size, assuming the attacker will send full segments to maximize the chances of getting a hit.

Notes:

  • The value "2^32" represents the size of the TCP sequence number space.
  • The value "2" accounts for two different ACK numbers (separated by 2^31) that should be employed to make sure the ACK number is valid.

The following table contains some sample results for the number of required packets, based on different values of RCV_WND and EPH_PORT_SIZE for an MSS of 1500 bytes 📊.

      +-------------+---------+---------+--------+---------+
      | Ports \ Win |  16 KB  |  128 KB | 256 KB | 2048 KB |
      +-------------+---------+---------+--------+---------+
      |     4000    |  699050 |  87381  | 43690  |   5461  |
      +-------------+---------+---------+--------+---------+
      |    10000    | 1747626 |  218453 | 109226 |  13653  |
      +-------------+---------+---------+--------+---------+
      |    50000    | 8738133 | 1092266 | 546133 |  68266  |
      +-------------+---------+---------+--------+---------+

     Table 1: Maximum Number of Packets for Successful Attack

Implementations that do support RFC 5961:

Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
EPH_PORT_SIZE/2 * 1/MSS

Where:

  • Packets: Maximum number of packets required to successfully perform an off-path (blind) attack.
  • RCV_WND: TCP receive window size (RCV.WND) at the target MPTCP endpoint.
  • SND_MAX_WND: Maximum TCP send window size ever employed by the target MPTCP endpoint (MAX.SND.WND).
  • EPH_PORT_SIZE: Number of ports comprising the ephemeral port range at the "client" system.

Notes:

  • The value "2^32" represents the size of the TCP sequence number space.
  • The parameter "MAX.SND.WND" is specified in [RFC5961].
  • The value "2 * SND_MAX_WND" results from the expression "SND.NXT - SND.UNA - MAX.SND.WND", assuming that, for connections that perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND". If an attacker targets a TCP endpoint that is not actively transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND" (and hence a successful attack would typically require more packets).

The following table contains some sample results for the number of required packets, based on different values of RCV_WND, SND_MAX_WND, and EPH_PORT_SIZE. For these implementations, only a limited number of sample results are provided (as an indication of how [RFC5961] increases the difficulty of performing these attacks) 🛡️.

    +-------------+-------------+-----------+-----------+---------+
    | Ports \ Win |    16 KB    |   128 KB  |   256 KB  | 2048 KB |
    +-------------+-------------+-----------+-----------+---------+
    |     4000    | 45812984490 | 715827882 | 178956970 | 2796202 |
    +-------------+-------------+-----------+-----------+---------+

       Table 2: Maximum Number of Packets for Successful Attack

Note:

In the aforementioned table, all values are computed with RCV_WND equal to SND_MAX_WND.

2.1. Possible Security Enhancements to Prevent This Attack

  1. To include the token of the connection in the ADD_ADDR option. This would make it harder for the attacker to launch the attack, since the attacker needs to either eavesdrop the token (so this can no longer be a blind attack) or to guess it, but a random 32-bit number is not easy to guess 🔐. However, this would imply that any eavesdropper that is able to see the token would be able to launch this attack. This solution then increases the vulnerability window against eavesdroppers from the initial 3-way handshake for the MPTCP session to any exchange of the ADD_ADDR messages 😬.
  2. To include the HMAC of the address contained in the ADD_ADDR option. The key used for the HMAC is the concatenation of the key of the receiver and the key of the sender (in the same way they are used for generating the HMAC of the MP_JOIN message). This makes it much more secure, since it requires the attacker to have both keys (either by eavesdropping it in the first exchange or by guessing it). Because this solution relies on the key used in the MPTCP session, the protection of this solution would increase if new key generation methods are defined for MPTCP (e.g., using Secure Socket Layer (SSL) keys as has been proposed) 🦋.
  3. To include the destination address of the SYN packet in the HMAC of the MP_JOIN message. As the attacker requires changing the destination address to perform the described attack, protecting it would prevent the attack. It wouldn't allow hosts behind NATs to be reached by an address in the ADD_ADDR option, even with static NAT bindings (like a web server at home) 🏠.

Of the options described above, option 2 is recommended as it achieves a higher security level while preserving the required functionality (i.e., NAT compatibility) 👑💖

3. DoS Attack on MP_JOIN ✨

  • Type of attack: MPTCP denial-of-service attack, preventing the hosts from creating new subflows 💀
  • Type of attacker: off-path active attacker 🙈

okay so this one is about the initial SYN+MP_JOIN message in the 3-way handshake for extra subflows 🫶 Right now, when that SYN+MP_JOIN shows up, the receiving host has to create state for it. That's because the SYN+MP_JOIN carries the 32-bit token (which tells the receiver which MPTCP session this is) and the 32-bit random nonce used in the HMAC calculation. The third ACK of the handshake doesn't resend any of that info, so the host has to store state as soon as the SYN+MP_JOIN lands. Lowkey a big deal 😭

Say Host A and Host B have an MPTCP session going, with tokens TA and TB. An attacker sends a SYN+MP_JOIN to Host B using the valid token TB, and boom, Host B creates state. Each MPTCP session can only hold a certain number of these half-open connections, and that limit depends on the implementation 🌸 The attacker just keeps sending SYN+MP_JOINs with different 5-tuples until the limit is full. The source address on the attack packets is probably forged, and it'll usually be an address that isn't in use. If it were a real address, the SYN/ACK from Host B would get a RST back from that node, which would clear the state at Host B, so the attacker wants a ghost address 👻 For more on classic SYN flooding and the usual fixes, check out [RFC4987].

Once that limit is hit, Host A can't send any more SYN+MP_JOINs to Host B. Main character villain arc 💅

To pull this off, the attacker needs the token TB. A partial-time on-path eavesdropper can grab it by watching the 3-way handshake when an extra subflow is set up between Host A and Host B 👀 If the attacker is never on-path, they have to guess the 32-bit token instead 🎲

3.1. Possible Security Enhancements to Prevent This Attack

Here's the glow-up idea 🦋 The third packet of the 3-way handshake could also carry the 32-bit token and the random nonce from the SYN+MP_JOIN. On top of that, Host B would generate its own random nonce in a reproducible way, like a hash of the 5-tuple + initial sequence number + local secret ✨ That means Host B can reply to a SYN+MP_JOIN without creating any state. Then, when the third ACK arrives, Host B checks the HMAC and only then creates the state. Stateless until it's verified, bestie, it's giving security 🔐

4. SYN Flooding Amplification 🌊

  • Type of attack: The attacker uses SYN+MP_JOIN messages to amplify the SYN flooding attack.
  • Type of attacker: off-path active attacker

okay the vibe here is "amplifying a SYN flood" 💅 SYN flooding attacks [RFC4987] use SYN messages to drain the server's resources and stop new TCP connections from getting in. A popular defense is SYN cookies [RFC4987], which let the server handle the initial SYN without storing state.

With MPTCP, the initial SYN can also be handled statelessly with those SYN cookies 🍓 But, as we just covered in the last section, SYN+MP_JOIN messages currently aren't handled statelessly. That opens a whole new attack vector 😱 The attacker opens an MPTCP session with a regular SYN, which creates state, and then fires off as many SYN+MP_JOINs as the server will accept, each with a different combo of source address and source port. The server's resources get eaten up, but the attacker never has to create state on their end 🫠 This is an amplification attack: the attacker only pays for the state of the initial SYN, while the server pays for the initial SYN plus the state for every single SYN+MP_JOIN that follows. Unfair, I know 💀

4.1. Possible Security Enhancements to Prevent This Attack

  1. The solution from the previous DoS attack on MP_JOIN would also stop this one 🙌
  2. Limiting the number of half-open subflows to a low number (e.g., three subflows) would also limit how much damage this attack can do 🧱

5. Eavesdropper in the Initial Handshake 👂

  • Type of attack: An eavesdropper present in the initial handshake, where the keys are exchanged, can hijack the MPTCP session at any time in the future.
  • Type of attacker: partial-time on-path eavesdropper

so this is the sneaky one 🕵️‍♀️ The attacker is on the path while the initial 3-way handshake happens, which means they can learn the keys used in the MPTCP session. Then they can walk away from the path and still hijack the session later on. Iconic villain move, not gonna lie 😈 This weakness was spotted while designing the MPTCP security solution [RFC6181], and the threat was considered acceptable 🤷‍♀️

5.1. Possible Security Enhancements to Prevent This Attack

There are a bunch of techniques that could stop this attack, and each one comes with its own trade-offs ⚖️ For now, we'll just list them and point you to some useful resources 📚

  1. Use of hash chains. Hash chains for MPTCP have been explored in [HASH-CHAINS].
  2. Use of SSL keys for MPTCP security, as described in [MPTCP-SSL].
  3. Use of Cryptographically Generated Addresses (CGAs) for MPTCP security. CGAs [RFC3972] have been used before to secure multi-addressed protocols like Shim6 [RFC5533] 🦋
  4. Use of tcpcrypt [TCPCRYPT].
  5. Use of DNSSEC. DNSSEC has been proposed to secure the Mobile IP protocol [DNSSEC] 🌈

6. SYN/JOIN Attack 🎀

  • Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added.
  • Type of attacker: partial-time on-path eavesdropper

okay bestie, the attacker is on the path when the SYN/JOIN exchange happens 👀 That lets them add any new address they want, just by swapping out the source address on the SYN/JOIN packet for one they pick. This weakness was also spotted while designing the MPTCP security solution [RFC6181], and the threat was considered acceptable 🫤

6.1. Possible Security Enhancements to Prevent This Attack

Here's the tea 🍵 This vulnerability is baked in because of the NAT support requirement. MPTCP has to work through NATs if it's going to be deployable on today's Internet. The thing is, NAT behavior looks exactly the same as this attack, so they're basically indistinguishable 😵‍💫 That makes it impossible to secure the source address, since locking it down would stop MPTCP from working through NATs. So the solution can't rely on securing the address. A more promising route is to protect the payload being exchanged, which limits how much damage the attack can do to the communication. Think tcpcrypt [TCPCRYPT] or something similar 🔒

7. Recommendations 📝

The current MPTCP specification [RFC6824] is Experimental, and there's an ongoing effort to move it to Standards Track 🚀 We think the MPTCP security work should follow two threads:

  • The work on improving MPTCP security so that the MPTCP specification [RFC6824] can become a Standards Track document.
  • The work on analyzing possible additional security enhancements to provide a more secure version of MPTCP.

We'll break these down in the subsections below 💖

7.1. MPTCP Security Improvements for a Standards Track Specification

We believe that for MPTCP to move to Standards Track, the ADD_ADDR attack must be addressed 🛠️ The fix we think should be adopted is adding an HMAC to the ADD_ADDR message, with the address being added used as input to the HMAC as well as the key. That would make ADD_ADDR as secure as the JOIN message 🔐 Also, if we come up with a more secure way to create the key used in the MPTCP connection, then both MP_JOIN and ADD_ADDR get more secure automatically, since both use the same key in the HMAC. Two for one, periodt ✨

We think that's enough for MPTCP to progress as a Standards Track document, because its security level is similar to single-path TCP based on our earlier analysis 💅 It would also be exactly the same security level as other Standards Track documents. Specifically, it would match SCTP with dynamic addresses, as defined in [RFC5061]. The Security Considerations section of RFC 5061 (which is a Standards Track document) says:

The addition and or deletion of an IP address to an existing
association does provide an additional mechanism by which existing
associations can be hijacked.  Therefore, this document requires
the use of the authentication mechanism defined in [RFC4895] to
limit the ability of an attacker to hijack an association.

Hijacking an association by using the addition and deletion of an
IP address is only possible for an attacker who is able to
intercept the initial two packets of the association setup when
the SCTP-AUTH extension is used without pre-shared keys.  If such
a threat is considered a possibility, then the [RFC4895] extension
MUST be used with a preconfigured shared endpoint pair key to
mitigate this threat.

So this is the same security level MPTCP would reach with the ADD_ADDR security measure recommended in this document 🎯

7.2. Security Enhancements for MPTCP

We also think it's worth exploring other ways to secure MPTCP 🌸 As we said earlier, securing JOIN messages is fundamentally incompatible with NAT support, so a real fix probably involves protecting the data itself. Integrating MPTCP with approaches like tcpcrypt [TCPCRYPT], and integrating with SSL, both look promising 🧚

8. Security Considerations 🔐

This whole document is about security considerations for MPTCP. Literally the whole thing 😭💜

9. References 📚

9.1. Normative References 📚

Okay bestie, these are the docs the spec needs you to have read, no skipping 🧚

9.2. Informative References 🔍

These ones are the extra reading for when you want to go down the rabbit hole, no pressure 💅

Acknowledgements 🫶

Huge thank you to Mark Handley 🌸 for his comments on the attacks and countermeasures in this doc, he's literally the GOAT for this one. Big thanks also to Alissa Cooper, Phil Eardley, Yoshifumi Nishida, Barry Leiba, Stephen Farrell, and Stefan Winter for their comments and reviews. You all made this so much better 💖

Marcelo Bagnulo, Christoph Paasch, Oliver Bonaventure, and Costin Raiciu are partially funded by the EU Trilogy 2 project ✨

Authors' Addresses 💌

The squad behind this doc, with their contact info, so you can slide into their inbox 🦋

Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid  28911
Spain

Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI:   http://www.it.uc3m.es


Christoph Paasch
UCLouvain

Email: christoph.paasch@gmail.com


Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   http://www.si6networks.com


Olivier Bonaventure
UCLouvain
Place Sainte Barbe, 2
Louvain-la-Neuve,   1348
Belgium

Email: olivier.bonaventure@uclouvain.be


Costin Raiciu
Universitatea Politehnica Bucuresti
Splaiul Independentei 313a
Bucuresti
Romania

Email: costin.raiciu@cs.pub.ro
📦 where this page comes from