RFC 6181
Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
RFC 6181: Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses ✨
okay bestie, this one is from March 2011 and it's an Informational doc, so it's not a standards-track spec 🎀. It was written by M. Bagnulo of UC3M, and the title block doesn't list anything it obsoletes or updates. The whole vibe is "here's how multi-address MPTCP could get hacked" 💀🔥
Abstract
Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. These extensions let segments travel between different source-destination address pairs, which means multiple paths can be used in a lot of different scenarios 🦋. You can get some multihoming and mobility support this way too. BUT the fact that each endpoint can have multiple IP addresses might have security implications for the resulting MPTCP 😬. This note is the threat analysis for MPTCP.
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes 🧚.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💅.
For the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6181 🌸.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the date this document was published. Please actually read these docs, because they spell out your rights and restrictions for this document 🙈. 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Basic MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flooding Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
6. Hijacking Attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking Attacks to the Basic MPTCP . . . . . . . . . . . 10
6.2. Time-Shifted Hijacking Attacks . . . . . . . . . . . . . . 13
6.3. NAT Considerations . . . . . . . . . . . . . . . . . . . . 14
7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 161. Introduction ✨
Okay so, MPTCP is the extensions proposed for TCP [RFC0793] that let both ends of a TCP connection use multiple paths to swap data 🦋. Segments can go out over different source-destination address pairs, so the connection can use multiple paths in a whole bunch of situations. Some multihoming and mobility support comes along for the ride too. The catch is that letting each endpoint have multiple IP addresses could have security implications for MPTCP, so this note digs into those threats 👑.
Just so we're clear, there are lots of other ways to get multiple paths for a TCP connection that don't involve using multiple addresses. The threat analysis in this doc is only about the specific case of multiple addresses per endpoint 💜.
2. Scope ✨
There are a few ways to get Multipath TCP, and they all boil down to the same thing: different segments of the conversation need to get forwarded along different paths, which means the sender needs some kind of path selector 🧚. Next hops, tunnels to different egress points, and other options can all work as path selectors. This note only looks at one approach, MPTCP, which depends on each endpoint having multiple IP addresses and uses different source-destination address pairs to show which path is which. From here on, "MPTCP" means this multi-addressed flavor of Multipath TCP [MPTCP-MULTIADDRESSED] 🎀.
The goal of this note is to do a threat analysis for MPTCP. Adding support for multiple addresses per endpoint inside a single TCP connection might bring new vulnerabilities compared to single-path TCP, so this note's job is to find and describe those new ones 🔥. The analysis is limited to the extra vulnerabilities that come from multi-address support, compared to today's TCP, where each endpoint only has one address per connection. A full analysis of every threat is explicitly out of scope. The point is to help MPTCP designers build a spec that's as secure as current TCP. Making MPTCP more secure than regular TCP is explicitly a non-goal 🙅♀️.
The focus is on attackers who aren't on the path, at least not for the whole connection 💅. With single-path TCP, an on-path attacker can do a lot of damage: eavesdropping, connection hijacking, Man-in-the-Middle (MiTM) attacks, and more 😭. Off-path attackers can't pull those off. There's also a middle ground where an attacker sits on the path for a short time, launches the attack, leaves, and the effects still stick around. These are called time-shifted attacks. They aren't possible in today's TCP, but they're still considered in this analysis because they matter for MPTCP 🦋. So in summary, attacks from off-path attackers and time-shifted attacks are both in scope. Attacks from on-path attackers are out of scope, since they already apply to current single-path TCP 🌈.
That said, some current on-path attacks may get harder with Multipath TCP, since an attacker sitting on a single path won't be able to see the whole data stream 👀✨.
3. Related Work ✨
okay so bestie, there's already a ton of previous work on address agility 🧠💖. Like, a LOT. The most relevant pieces are below, so grab your snacks 🍓.
Most of the problems with address agility were already dissected pretty thoroughly in the context of Route Optimization support in Mobile IPv6 (MIPv6 RO) [RFC3775]. [RFC4225] covers the reasoning behind the security design of MIPv6 RO 🔐. Every attack described in that analysis applies here too, so it's an amazing starting point for ours 🫶. But MPTCP isn't identical to MIPv6 RO, so here's how they're different:
- In MIPv6 RO, an address binding affects all the communications involving that address, while in the MPTCP case, a single connection is at stake 🎯. If a binding between two addresses is created at the IP layer, it can and will affect every connection using those addresses. In MPTCP, though, if an extra address gets added to an ongoing TCP connection, that address only affects that connection, not the others, even if the same address is being used for them 💅. So in MPTCP there's way less on the line, and the resulting vulnerabilities are smaller. Still, it's super important to keep the assumption that address bindings for one connection don't affect other connections. If anyone wants to reuse binding or security information, that assumption might stop being valid, and the full impact of the vulnerabilities would have to be assessed 😳.
- In MIPv6, there's a trusted third party called the Home Agent, who can help with some security problems (more on that in the next bullet) 🧚.
- In MIPv6 RO, it's assumed that the original address (the Home Address) the connection was established through is always available. If it isn't, the communication gets lost 💀. MIPv6 handles this by leaning on the trusted party (the Home Agent) to relay packets to the Mobile Node's current location. In MPTCP, though, it's an explicit goal to keep communication resilient when one of the address pairs stops being usable, so you can't rely on the original address pair always working 🌈.
- MIPv6 RO is, of course, designed for IPv6, while it's an explicit goal of MPTCP to support both IPv6 and IPv4 🌸. Some MIPv6 RO security solutions depend on special IPv6 features, like Cryptographically Generated Addresses (CGA) [RFC3972], and those won't be usable for MPTCP.
- Unlike MPTCP, MIPv6 RO doesn't have connection-state information, like sequence numbers or port numbers, that could be used to provide security in some form 🙈.
Shim6 [RFC5533] also looked at similar address agility issues, and a threat analysis was performed for it [RFC4218] ✨. The Shim6 analysis mostly applies to the MPTCP context too, with a few big differences:
- Shim6 is a layer 3 protocol, so every communication involving the target address is at stake. In MPTCP, the impact can be limited to a single TCP connection 🦋.
- Just like MIPv6 RO, Shim6 only uses IPv6 addresses as identifiers, and it leans on their properties for security, like relying on CGA or Hash-Based Addresses (HBA) [RFC5535]. That isn't possible for MPTCP, because IPv4 addresses have to be supported there 👑.
- Just like MIPv6 RO, Shim6 doesn't have connection-state information, like sequence numbers or ports, that could be used to provide security in some form 💜.
Stream Control Transmission Protocol (SCTP) [RFC4960] is a transport protocol that supports multiple addresses per endpoint, and its security implications are very close to MPTCP's 👯. A security analysis identifying a set of attacks and proposed solutions was performed in [RFC5062] 🔥. Those results apply directly to MPTCP. However, that analysis happened after base SCTP was designed, and its goal was basically to improve SCTP's security. So the document is very specific to the actual SCTP specification and relies on SCTP messages and behavior to characterize the issues. Some of them can be translated to the MPTCP case, but some may be caused by SCTP's specific behavior, so not everything carries over 🙃.
So, the conclusion is: there's a lot of closely related previous work, and we'll absolutely use it as a basis for this analysis 🫶. But MPTCP has characteristics of its own, which means it needs a specific analysis of its own too 💅. The goal here is to help MPTCP designers include security mechanisms that prevent MPTCP from introducing new vulnerabilities to the Internet 🛡️✨.
4. Basic MPTCP 🦋
The goal of this document is to serve as input for MPTCP designers, so they can properly take security issues into account 🧠. Because of that, the analysis can't be done for one specific MPTCP specification. It has to be a general analysis that applies to the widest possible set of MPTCP designs 🌍. To do that, the fundamental features that any MPTCP must provide are identified, and only those are assumed while doing the security analysis. Sometimes there's a design choice that significantly influences the security of the resulting protocol. In those cases, both options are considered 👑.
It's assumed that any MPTCP will behave like TCP when there's a single address per endpoint 💖. That means an MPTCP connection gets established using the TCP 3-way handshake and uses a single address pair 🤝.
The addresses used to establish the connection have a special role, because that's the address the upper layers use as the identifier 🎀. The address used as the destination address in the SYN packet is the one the application uses to identify the peer. The application got it through the DNS (with or without DNS Security (DNSSEC) validation), through a referral, or because the user typed it in manually 📇. So the initiator has a certain amount of trust that it's establishing communication with that particular address 🥺. If MPTCP causes packets to end up being delivered to an alternative address, the trust the initiator placed in that address would be deceived 😭. Either way, adopting MPTCP calls for a slight evolution of the traditional TCP trust model: the initiator is also trusting the peer to provide additional addresses, and it will trust those addresses to the same degree as the original pair 🫢. An application or implementation that can't trust the peer in this way should not make use of multiple paths 🚫.
During the 3-way handshake, the sequence number gets synchronized for both ends, just like in regular TCP 🔄. It's assumed that an MPTCP connection uses a single sequence number for the data, even when the data is exchanged through different paths, since MPTCP provides an in-order delivery service of bytes 📜.
Once the connection is established, the MPTCP extensions can be used to add addresses for each of the endpoints 🌷. This happens when each end sends a control message containing the additional address(es). To associate the additional address with an ongoing connection, the connection needs to be identified 🔍. It's assumed that the connection can be identified by the 4-tuple of source address, source port, destination address, and destination port used to establish it 🧩. So, at the very least, the control message carrying the additional address information can also contain the 4-tuple, to tell the receiver which connection the address belongs to (if no other connection identifier is defined) 💌. There are two different ways to convey address information:
- Explicit mode: the control message contains a list of addresses 📝.
- Implicit mode: the address added is the one included in the
source addressfield of the IP header 🪄.
These two modes have different security properties for some types of attacks ⚖️. The explicit mode seems to be the more vulnerable one to abuse 😬. The implicit mode may benefit from forms of ingress filtering security, which would reduce an attacker's ability to add any arbitrary address to an ongoing connection 🛡️. However, ingress filtering deployment is far from universal, so it's unwise to rely on it as the basis for protecting MPTCP 🙅♀️.
More consideration is needed on how ingress filtering and implicit mode signaling interact when an address that's no longer available is removed from the MPTCP connection 🤔. A host attached to a network that performs ingress filtering and uses implicit signaling wouldn't be able to remove an address that's no longer available (whether because of a failure or a mobility event) from an ongoing MPTCP connection 😩.
It's assumed that MPTCP will use all the address pairs it has available for sending packets, and that it will distribute the load among the different paths based on congestion 🌊✨.
5. Flooding Attacks ✨
okay so the first kind of attack that address agility brings along is the flooding (or bombing) attack 💣 here's the setup, bestie:
+--------+ (step 1) +------+
|Attacker| ------------------------- |Source|
| A |IPA IPS| S |
+--------+ /+------+
/
(step 2) /
/
v IPT
+------+
|Target|
| T |
+------+so the scenario has an Attacker A with IP address IPA 😈 and a server that can push out a ton of traffic (think a streaming server), called source S, with IP address IPS. then there's Target T, sitting at IPT 🎯
in step 1, the Attacker A sets up an MPTCP connection with the traffic server S and starts downloading a huge amount of data 📥 the starting connection only has one IP address per endpoint, IPA and IPS. once the download is going, in step 2, the Attacker A adds IPT as another address for the communication 👀 how that address gets added depends on the MPTCP address management mode. in explicit address management, the Attacker A just has to send a signaling packet that carries address IPT. in implicit mode, the Attacker A would have to send a packet with IPT as the source address. whether that's even possible depends on if ingress filtering is deployed and where the attacker is sitting 🤷♀️
at this point, the MPTCP connection still has one address for the Source S, which is IPS, but it has two addresses for the Attacker A, namely IPA and IPT. the attacker now tries to get the Source S to send the ongoing download over to the Target T's IP address, IPT 😭 the trick is pretending that the path between IPA and IPT is congested while the path between IPS and IPT is totally fine. to pull that off, it has to send ACKs for the data flowing through the path between IPS and IPT, and not send ACKs for the data sent to IPA. how exactly this works depends on how the data sent over the different paths gets ACKed. one possibility is that ACKs for the data sent using a given address pair should come in packets containing that same address pair. if that's the case, the attacker would need to send ACKs in packets with IPT as the source address to keep the attack going. again, that may or may not be possible depending on ingress filtering and where the attacker is. the attacker would also need to guess the sequence number of the data being sent to the Target 🧠 once the attacker pulls all this off, the attack is in place and the download hits the target 💥 in this kind of attack, the Source S still thinks it's sending packets to the Attacker A, when in reality it's sending them to Target T. main character villain arc, honestly 💀
once traffic from the Source S starts hitting the Target T, the target is going to react 🫠 since those packets most likely belong to a TCP connection that doesn't exist, the Target T will send out RST packets. it's important to understand how MPTCP reacts to incoming RST packets 👀 it seems that at the very least, the MPTCP that receives an RST packet should stop the packet exchange for that particular address pair (maybe not the whole MPTCP connection, but at minimum it should not send any more packets using the address pair involved in the RST packet) 🛑 however, if the attacker has managed to grow the window size a lot before redirecting the traffic, the flight size could be big enough to dump a significant amount of traffic on the Target node 📈 there's a subtle balance the attacker has to hit to launch a meaningful attack. on one hand, it needs to grow the window enough that the flight size is big enough to actually have an effect. on the other hand, the attacker needs to be able to simulate congestion on the IPA-IPS path so the traffic actually gets redirected to the alternate path without the window getting significantly reduced 🎯 this depends heavily on how the coupling of the windows between the different paths works, especially how the windows get increased. some designs of congestion control window coupling could make this attack totally ineffective 🙅♀️ and if MPTCP requires performing slow start per subflow, then the flooding is limited by the slow-start initial window size 🐢
other protocols that have had to deal with this kind of attack, like MIPv6 RO and SCTP, handled it by adding a reachability check before actually sending data to a new address 🔍 the approach those other protocols use involves the Source S explicitly asking the host sitting at the new address (the Target T sitting at IPT) whether it's willing to accept packets from the MPTCP connection identified by the 4-tuple IPA, port A, IPS, port S. since this isn't part of the established connection that Target T has, T would not accept the request, and Source S would not use IPT to send packets for this MPTCP connection 🙅♀️ usually, the request also includes a nonce that can't be guessed by the Attacker A, so the attacker can't easily fake the reply 🔐 in the case of SCTP, it sends a message with a 64-bit nonce (in a HEARTBEAT) 💜
one possible way to do this reachability test would be to perform a 3-way handshake for each new address pair that's going to be used in an MPTCP connection ✨ there are other reasons to do this too (like NAT traversal), but this approach would also act as a reachability test and would prevent the flooding attacks described in this section 🛡️
another flooding attack that could potentially be pulled off with MPTCP is one where the attacker starts a communication with a peer and includes a long list of alternative addresses in explicit mode 📋 if the peer decides to set up subflows with all of the available addresses, the attacker has managed to create an amplified attack. by sending a single packet with all those alternative addresses, it gets the peer to generate packets to all of those destinations 📣 small ask, huge consequences 😭
6. Hijacking Attacks ✨
6.1. Hijacking Attacks to the Basic MPTCP 💅
okay so hijacking attacks basically use MPTCP's address agility to let an attacker take over a connection 😭 The victim thinks it's talking to its peer, but it's actually exchanging packets with the attacker. It's kinda the dual of flooding attacks, where the victim thinks it's chatting with the attacker but is really sending its packets to the target 🙈
The scenario for a hijacking attack is shown in the next figure 🦋
+------+ +------+
| Node | ------------------------- | Node |
| 1 |IP1 IP2| 2 |
+------+ /+------+
/
/
/
v IPA
+--------+
|Attacker|
| A |
+--------+An MPTCP connection is established between Node 1 and Node 2 🎀 The connection is only using one address per endpoint, IP1 and IP2. The attacker then launches the hijack by adding IPA as an extra address for Node 1. Honestly there's not much difference between explicit and implicit address management here, because in both cases the Attacker A could easily send a control packet adding the address IPA, either as control data or as the source address of the control packet. To hijack the connection, the attacker needs to know the 4-tuple that identifies it, which includes the pair of addresses and the pair of ports. It seems reasonable to assume that knowing the source and destination IP addresses and the port of the server side is fairly easy for the attacker. Learning the port of the client (aka the initiator of the connection) might be more challenging, though 🥺 The attacker would need to guess it or learn it by intercepting the packets. Assuming the attacker can gather the 4-tuple and issue the message adding IPA to the addresses available for the MPTCP connection, the Attacker A has now been able to participate in the communication ✨ Specifically:
- Segments flowing from the Node 2: Depending on how the usage of addresses is defined, Node 2 will start using IPA to send data to. Generally, since the main goal is to get multipath capabilities, you can assume that unless there are already many IP address pairs in use in the MPTCP connection, Node 2 will start sending data to IPA. So part of the data reaches the attacker, but probably not all of it. This already has negative effects, since Node 1 won't receive all the data from Node 2 💀 From the application's point of view, this turns into a Denial-of-Service (DoS) attack, since the byte flow stops and waits for the missing data. But it's not enough for a full hijack, because part of the data still gets delivered to IP1, so it reaches Node 1 and not the attacker. For the attacker to receive all of the MPTCP connection's data, they must somehow remove IP1 from the set of available addresses for the connection. With implicit address management, this operation will likely mean sending a termination packet with IP1 as the source address, which may or may not be possible depending on whether ingress filtering is in place and where the attacker is located. If explicit address management is used, the attacker sends a remove address control packet containing IP1. Once IP1 is removed, all the data sent by Node 2 reaches the attacker, and the incoming traffic is hijacked 👑 slay
- Segments flowing to the Node 2: As soon as Node 2 accepts IPA as part of the address set for the MPTCP connection, the attacker can send packets using IPA, and Node 2 will treat those packets as part of the MPTCP connection. So the attacker can inject data into the connection, which means they've hijacked part of the outgoing traffic. However, Node 1 can still send traffic that Node 2 receives as part of the MPTCP connection. That means there are two sources of data, Node 1 and the attacker, which could stop the attacker from fully hijacking the outgoing traffic 🫶 To fully hijack it, the attacker would need to remove IP1 from the set of available addresses. They can do that with the same techniques described in the previous bullet.
A related attack that uses similar techniques is a MiTM attack 👀 The scenario is depicted in the figure below.
+------+ +------+
| Node | --------------- | Node |
| 1 |IP1 IP2| 2 |
+------+ \ /+------+
\ /
\ /
\ /
v IPA v
+--------+
|Attacker|
| A |
+--------+There's an established connection between Node 1 and Node 2. The Attacker A uses the MPTCP address agility capabilities to place themself as a MiTM 😈 To do that, they add the IP address IPA as an extra address for the MPTCP connection on both Node 1 and Node 2. It's basically the same technique we just went over, except it's used against both nodes in the conversation. The main difference is that now the attacker can simply sniff the content of the communication that gets forwarded through them, and then forward the data on to the peer. The result: the attacker sits right in the middle of the conversation and can sniff part of the traffic totally unnoticed 🕵️♀️ Similar considerations apply to how the attacker might manage to see all the traffic by removing the genuine address of the peer.
6.2. Time-Shifted Hijacking Attacks 🧚
A simple way to stop off-path attackers from launching hijacking attacks is to secure the control messages that add and remove addresses using a cookie 🍓 With this kind of approach, the peers in the MPTCP connection agree on a cookie that's exchanged in plaintext during connection establishment, and it has to be presented in every control packet that adds or removes an address for either peer. So the attacker needs to know the cookie to launch any of the hijacking attacks we covered earlier. This means off-path attackers can no longer do the hijacking attacks, and only on-path attackers can. So you might think a cookie-based approach to securing an MPTCP connection gives you similar security to current TCP. It's close, but it's not entirely true 😬
The big difference between the security of MPTCP secured with cookies and current TCP is the time-shifted attacks 🕰️ Like we said earlier, a time-shifted attack is one where the attacker is on the path for a period of time, then moves away, but the effects of the attack still stick around long after they're gone. With MPTCP secured through cookies, the attacker only needs to be on the path until the cookie is exchanged. Once they've learned the cookie, they can leave the path and still launch the hijacking attacks from the previous section 🔥
There are several types of approaches that provide some protection against hijacking attacks but are vulnerable to some forms of time-shifted attacks. Here's a general taxonomy of the solutions and the residual threats for each type:
- Cookie-based solution: As described earlier, one option is to send a cookie in cleartext in every MPTCP control message that adds a new address to the existing connection. The residual threat here is that any attacker who can sniff one of these control messages will learn the cookie and will be able to add new addresses at any point in the connection's lifetime 😭 Plus, the endpoints won't detect the attack, because the original cookie is the one the attacker is using. Summing up: the vulnerability window for this type of attack includes all the flow establishment exchanges, and it's undetectable by the endpoints.
- Shared secret exchanged in plaintext: A more secure alternative to the cookie-based approach is to exchange a key in cleartext during establishment of the first subflow, then validate the following subflows using a keyed Hashed Message Authentication Code (HMAC) signature with that shared key 💜 This solution is vulnerable to attackers sniffing the message exchange for the first subflow's establishment. After that, though, the shared key isn't transmitted anymore, so the attacker can't learn it by sniffing any other message. The catch is that, to stay compatible with NATs (see analysis below), this signature can't cover the IP address being added, even though the approach includes a keyed HMAC signature. So this type of approach is also vulnerable to integrity attacks on the exchanged messages 🙈 Even though the attacker can't learn the shared key by sniffing later subflow establishments, they can modify the subflow establishment message and change the address being added. So the vulnerability window for confidentiality of the shared key is limited to the first subflow's establishment, but the vulnerability window for integrity attacks still includes all the subflow establishment exchanges. These attacks are still undetectable by the endpoints. SCTP security falls into this category 🦋
- Strong crypto anchor exchange: Another option is to exchange some strong crypto anchor during establishment of the first subflow, such as a public key or a hash chain anchor. Subsequent subflows can then be protected using the crypto material associated with that anchor 🌈 An attacker here would need to change the crypto material exchanged during connection establishment. As a result, the vulnerability window for forging the crypto anchor is limited to the initial connection establishment exchange. Similar to the previous case, because of NAT traversal considerations, the vulnerability window for integrity attacks includes all the subflow establishment exchanges. Since the attacker needs to change the crypto anchor, this approach is detectable by the endpoints, if they communicate directly ✨
6.3. NAT Considerations ✨
okay so bestie, MPTCP has to work through NATs or nobody's going to use it 😭 and NATs are lowkey sus from a security angle. From MPTCP's point of view, a NAT acts like a MiTM attacker 👀 The whole security goal is to stop any attacker from slipping their addresses in as valid addresses for an MPTCP connection. But rewriting addresses is literally what a NAT does 💀 So if MPTCP wants to work through NATs, it MUST accept addresses that NATs have rewritten as valid addresses for a given session. Wait, careful, the original says "must" here, so I'm keeping it lowercase in the spec: MPTCP must accept addresses rewritten by NATs as valid addresses for a given session. 🎀
The most direct consequence is that MPTCP messages that add addresses in implicit mode (aka the SYN of new subflows) cannot be protected against integrity attacks, because they have to let NATs change the addresses. 🥺 That rules out any solution that depends on integrity protection to stop an attacker from changing the address used in a subflow establishment exchange. So we need alternative creative mechanisms to protect the MPTCP signaling that adds new addresses to a connection from integrity attacks. Honestly, it's far from obvious what one of those creative approaches could even look like at this point 🫠
In explicit mode, you could protect the address included in the MPTCP option. The real question is which address to put in the MPTCP option that carries address information. If the address included is the one configured on the host interface, and that interface is behind a NAT, the address info is useless 💔 The address isn't actually reachable from the other end, so there's no point conveying it, and even less point securing it. You could imagine using NAT traversal techniques, like Session Traversal Utilities for NAT (STUN), to learn the address and port the NAT has assigned, and then convey that information in a secure way. That's possible, but it depends on NAT traversal techniques and on tools for conveying the address and port securely, so it's not a freebie 🙃
7. Recommendation 🌸
The analysis we just went through shows there's a tradeoff between how complex the security solution is and the residual threats 🧠 After the MPTCP WG evaluated the different aspects, here's what they landed on:
- MPTCP should implement some form of reachability check using a random nonce (e.g., TCP 3-way handshake) before adding a new address to an ongoing communication, in order to prevent flooding attacks. 🦋
- The default security mechanisms for MPTCP should be to exchange a key in cleartext in the establishment of the first subflow, and then secure following address additions by using a keyed HMAC using the exchanged key. 🔐
- MPTCP security mechanism should support using a pre-shared key to be used in the keyed HMAC, providing a higher level of protection than the previous one. 👑
- A mechanism to prevent replay attacks using these messages should be provided, e.g., a sequence number protected by the HMAC. 🔁
- The MPTCP should be extensible and it should be able to accommodate multiple security solutions, in order to enable the usage of more secure mechanisms if needed. 🌈
8. Security Considerations 💀
This note contains a security analysis for MPTCP, so no further security considerations need to be described in this section. 🚨
9. Contributors 🫶
Alan Ford - Roke Manor Research, Ltd.10. Acknowledgments 💜
Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil Eardley, Jari Arkko, David Harrington, Dan Romascanu, and Alexey Melnikov all reviewed an earlier version of this document and gave comments to make it better, and we're so grateful 🥹✨
Mark Handley pointed out the problem with NATs and integrity protection of MPTCP signaling. Main character energy 👑
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. 🇪🇺🎀
11. References 📚
11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.11.2. Informative References
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security
Attacks Found Against the Stream Control Transmission
Protocol (SCTP) and Current Countermeasures", RFC 5062,
September 2007.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[MPTCP-MULTIADDRESSED]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Work
in Progress, October 2010.Author's Address 💌
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.esThat's the whole doc, bestie! 🧚💖
📦 where this page comes from
- ietf: rfc6181 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms