RFC 4866
Enhanced Route Optimization for Mobile IPv6
Enhanced Route Optimization for Mobile IPv6 🎀
RFC 4866, a Standards Track document from the Network Working Group, dated May 2007 📅
- Authors: J. Arkko (Ericsson Research NomadicLab), C. Vogt (Universitaet Karlsruhe (TH)), and W. Haddad (Ericsson Research) 🫶
- Category: Standards Track
- Obsoletes: nothing is listed in the title block
- Updates: nothing is listed in the title block
Status of This Memo ✨
okay so this document is an Internet standards track protocol for the whole Internet community 🌐 It also asks everyone for discussion and suggestions for improvements, so bring your ideas bestie 💜 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 🦋
Copyright Notice 💅
Copyright (C) The IETF Trust (2007).
Abstract 🌸
this doc is giving an enhanced version of Mobile IPv6 route optimization 🔥 The upgrades are lower handoff delays, increased security, and reduced signaling overhead. literally iconic 👑
Table of Contents 🧚
1. Introduction ....................................................3
2. Objectives ......................................................4
2.1. Handoff Latency ............................................5
2.2. Security ...................................................5
2.3. Signaling Overhead .........................................7
3. Protocol Design .................................................7
3.1. Cryptographically Generated Home Addresses .................7
3.2. Non-Cryptographic Care-of Addresses ........................8
3.3. Semi-Permanent Security Associations .......................8
3.4. Initial Home Address Tests .................................8
3.5. Concurrent Care-of Address Tests ...........................9
3.6. Credit-Based Authorization .................................9
3.7. Parallel Home and Correspondent Registrations .............10
4. Protocol Operation .............................................10
4.1. Sending Binding Update Messages ...........................10
4.2. Receiving Binding Update Messages .........................18
4.3. Sending Binding Acknowledgment Messages ...................22
4.4. Receiving Binding Acknowledgment Messages .................23
4.5. Sending CGA Parameters ....................................25
4.6. Receiving CGA Parameters ..................................26
4.7. Sending Permanent Home Keygen Tokens ......................27
4.8. Receiving Permanent Home Keygen Tokens ....................28
4.9. Renewing Permanent Home Keygen Tokens .....................28
4.10. Handling Payload Packets .................................28
4.11. Credit Aging .............................................31
4.12. Simultaneous Movements ...................................32
5. Option Formats and Status Codes ................................32
5.1. CGA Parameters Option .....................................32
5.2. Signature Option ..........................................33
5.3. Permanent Home Keygen Token Option ........................34
5.4. Care-of Test Init Option ..................................35
5.5. Care-of Test Option .......................................35
5.6. CGA Parameters Request Option .............................36
5.7. Status Codes ..............................................36
6. Security Considerations ........................................38
6.1. Home Address Ownership ....................................39
6.2. Care-of Address Ownership .................................41
6.3. Credit-Based Authorization ................................43
6.4. Time Shifting Attacks .....................................46
6.5. Replay Attacks ............................................47
6.6. Resource Exhaustion .......................................47
6.7. IP Address Ownership of Correspondent Node ................47
7. Protocol Constants and Configuration Variables .................49
8. IANA Considerations ............................................50
9. Acknowledgments ................................................50
10. References ....................................................51
10.1. Normative References .....................................51
10.2. Informative References ...................................511. Introduction ✨
okay so Mobile IPv6 route optimization [1] lets mobile and correspondent nodes talk over a direct routing path 🛤️ even when the mobile node's IP connectivity changes. Both end nodes use a stable "home address" to identify the mobile node at stack layers above IP 💖 Meanwhile, payload packets go out or come in via a "care-of address" that routes to wherever the mobile node is currently attached 📍 Mobile IPv6 swaps the home and care-of addresses when a payload packet goes through the IP layer, which is giving main character energy 💅 The link between a mobile node's home address and care-of address is called a "binding" for the mobile node 🔗
It's the mobile node's job to update its binding at the correspondent node through a "correspondent registration" whenever it changes IP connectivity 🫶 A correspondent registration also involves the mobile node's home agent. The home agent proxies the mobile node at the home address and mainly acts as a relay for payload packets exchanged with correspondent nodes that don't support route optimization 🧚 The mobile node keeps the home agent up to date about its current care-of address through "home registrations" 📬
Now for the security tea ☕ Establishing a binding during a correspondent registration requires the correspondent node to verify that the mobile node owns both the home address and the care-of address. Unprecedented impersonation and flooding threats [5] would show up if correspondent nodes took liberties with these obligations 😭 So a correspondent registration includes a "home address test" and a "care-of address test", which together are called the "return routability procedure" 🔍 These tests let the correspondent node probe the mobile node's reachability at the home and care-of addresses in an ad hoc, non-cryptographic way. If reachability checks out at both IP addresses, that suggests (though it doesn't guarantee) the mobile node owns them, and so the binding between the home address and the care-of address is legit ✅
The return routability procedure is lightweight, and it doesn't need a public-key infrastructure or a preexisting relationship between the mobile node and the correspondent node 🌈 That makes broad deployment way easier. The catch is that it slows down handoffs 🐌 Both the home address test and the care-of address test are end-to-end message exchanges between the mobile node and the correspondent node. The home address test can be especially laggy because it routes through the home agent 💀 The procedure is also vulnerable to attackers who can interpose in the home or care-of address test 🙈 Interposing doesn't get them much, though, because the return routability procedure has to be repeated at intervals of at most 7 minutes, even when the mobile node's IP connectivity hasn't changed. Repeating it costs extra signaling overhead 📈 So much effort has gone into improving Mobile IPv6 route optimization [6] to fix these downsides 🍓
This document specifies Enhanced Route Optimization, which amends route optimization in base Mobile IPv6 ✨
Enhanced Route Optimization secures a mobile node's home address against impersonation. It does this with an interface identifier that is cryptographically and verifiably bound [2] to the public component of the mobile node's public/private-key pair 🔐 The mobile node proves it owns the home address by showing evidence that it knows the corresponding private key. An initial home address test validates the home address prefix, and after that, subsequent home address tests are unnecessary 🎉 Enhanced Route Optimization also lets mobile and correspondent nodes resume bidirectional communication in parallel with a care-of address test. So the latency of the home and care-of address tests is eliminated in most cases 🚀 Using cryptographically generated home addresses also helps against impersonators who can interpose on the home address test, which makes longer binding lifetimes possible. The result is increased security and less signaling overhead 💜 Cryptographically generated home addresses and concurrent care-of address tests work best together, but a mobile node can choose to use just one of these enhancements 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3] 📖
2. Objectives 🎯
The design of route optimization in base Mobile IPv6 is pretty conservative in a lot of ways 🧁 That leaves room to optimize handoff delay, security, and signaling overhead. Enhanced Route Optimization tackles these issues, so it's a more progressive variant of Mobile IPv6 💅
Even with any Mobile IPv6 optimizations, you have to remember that mobility-related activities elsewhere in the protocol stack can have their own impact 👀 For example, attachment procedures, access control, and authentication at the link layer add their own handoff delays. So do IP layer tasks like router discovery, neighbor discovery, movement detection, and IP address configuration 🌀 The handoff delays and signaling overhead of Mobile IPv6 are usually small compared to the total delay and overhead. So the improvements from Enhanced Route Optimization should be seen in view of the entire protocol stack, periodt 🫶
To be continued in part 2 🧚 (1 of 14 done!)
2.1. Handoff Latency ✨
okay so let's talk about the lag 🫠 in base Mobile IPv6 route optimization, the handoff delay is basically stacked up from a few round trips. first there's one round-trip time between the mobile node and the home agent for the home registration 📬. then there's one round-trip between the mobile node and the home agent PLUS one round-trip between the home agent and the correspondent node for the return routability procedure 🔁. and last, one one-way trip from the mobile node to the correspondent node so the Binding Update message can get delivered 💌. (the assumption here is that the return routability procedure is mostly eaten up by the home address test, bestie 🎀)
the first payload packet sent to the new care-of address then needs one extra one-way trip to get from the correspondent node to the mobile node 🧚. the mobile node can actually keep sending right after it dispatches the Binding Update message 💅. but if it asks for a Binding Acknowledgment message from the correspondent node, comms usually stall until that ack shows up 😭.
these handoff delays in base Mobile IPv6 route optimization stack on top of whatever delays already exist at the IP layer or link layer, so they're additive 🙈
and yeah, they can be seriously noticeable for interactive and real-time apps 📞. TCP bulk transfers get hit too, since long handoff latencies can trigger successive retransmission timeouts and tank the throughput [7] 💀. so an objective of Enhanced Route Optimization is to cut that handoff latency down 🦋.
2.2. Security 🔐
the return routability procedure was built to give about the same level of security as today's non-mobile Internet [5] 👑. it guards against impersonation, denial-of-service, and flooding threats that only show up because mobility exists, unless you put countermeasures in place 🛡️. specifically, the return routability procedure meets these requirements:
- an attacker off the path from a correspondent node to a victim should not be able to trick a correspondent node into redirecting packets, which should normally be delivered to a victim, to itself, or to a third IP address 🙅♀️. otherwise the attacker could impersonate the victim to the correspondent node or cause denial of service against the victim 😤. the attacker may launch these attacks from an arbitrary position, which doesn't necessarily have to be on the path between the victim and the correspondent node 🌍.
- an attacker off the path from a correspondent node to a victim should not be able to trick the correspondent node into redirecting packets, which should normally be delivered to the attacker itself, to the victim 🚫. otherwise the attacker could flood the victim with unrequested packets 🌊. this "redirection-based flooding" is super appealing to attackers because the work of generating the flood packets and sending them to the victim lands on the correspondent node instead of on the attacker 🫣. the attacker could also spoof multiple correspondent nodes into flooding the same victim 👀. that would hit the victim way harder than a direct flood, where the attacker itself makes and sends every packet 💥. comparable amplification is today only possible through an army of compromised nodes [8] 🤖.
one way to pull off redirection-based flooding: the attacker completes the initial TCP handshake for a huge file download through its own IP address, then binds the victim's IP address (as a care-of address) to the attacker's own IP address (or home address) 🎭. the correspondent node then redirects the download to the victim 📦. the attacker can spoof acknowledgments on behalf of the victim, using the sequence numbers it picked up during the initial handshake, to keep the download going or speed it up ⚡. those acknowledgments are smaller, and typically less than the full-sized segments the correspondent node generates, which is what makes the amplification work 😈.
- attackers should not be able to cause denial of service against mobile or correspondent nodes by exploiting expensive computations involved in the mobility protocol 🙅♀️.
the return routability procedure blocks impersonation, denial of service, and redirection-based flooding from attackers who aren't on the path from a correspondent node to a victim 🙌, and it's lightweight enough not to expose expensive operations 🪶. but it does NOT protect against attackers who are located on the path from the correspondent node to the victim 😬. apps that need a higher security level are generally advised to use end-to-end protection like IP security (IPsec) or Transport Layer Security (TLS) 🔒. but even then, they're still vulnerable to denial of service or flooding 💀. plus, end-to-end security mechanisms generally need mobile and correspondent nodes to be preconfigured with authentication credentials, or they depend on a public-key infrastructure 🗝️. both of those would make it hard to widely deploy Mobile IPv6 route optimization if they were a prerequisite for the protocol 🚧. so an objective of Enhanced Route Optimization is to securely authenticate mobile nodes without preconfigured credentials or a public-key infrastructure, even when there are attackers on the path from the correspondent node to the victim 🫶✨.
2.3. Signaling Overhead 📡
a complete correspondent registration involves six message transmissions at the mobile node, totaling about 376 bytes [9] 📨. this signaling overhead might be fine if movements are infrequent 😌. for example, a mobile node that moves once every 30 minutes generates an average of 1.7 bits/s of signaling traffic 🐢. but higher mobility causes more serious overhead 🏎️. a cell size of 100 meters and a speed of 120 km/h yields a change in IP connectivity every 3 s and about 1,000 bits/s of signaling traffic 😱. that's a lot compared to a highly compressed voice stream, which typically runs at 10,000 to 30,000 bits/s 🎤.
on top of that, base Mobile IPv6 requires mobile nodes to renew a correspondent registration at least every 7 minutes ⏰. the signaling overhead comes to 7.16 bits/s if the mobile node talks to a stationary node [9] 📉. it doubles if both peers are mobile 👯♀️. this overhead may be negligible when the nodes are actively communicating, but it can be an issue for mobile nodes that are inactive and stay in the same spot for a while 🛋️. those nodes typically prefer to go into standby mode to save battery 🔋. also, the periodic refreshes eat up a chunk of wireless bandwidth that could be used more efficiently 🫠. these observations lead to the objective of Enhanced Route Optimization: reduce the signaling overhead of base Mobile IPv6 correspondent registrations as much as possible, especially when the mobile node hasn't moved for a while 🧘♀️💜.
3. Protocol Design 🛠️
Enhanced Route Optimization is a bunch of optimizations that together get us the objectives from Section 2 🎯. here's the quick summary 👇.
3.1. Cryptographically Generated Home Addresses 🔑
a Mobile IPv6 binding is basically a packet redirection from a home address to a care-of address 🗺️. the home address is the source of the redirection, and the care-of address is the destination 📍. so the packets to redirect can be identified by the home address, which is why a cryptographic ownership proof for the home address makes sense 🔏. Enhanced Route Optimization uses cryptographically generated home addresses for this [10][11] 💅. generally, a Cryptographically Generated Address (CGA) gives a strong cryptographic binding between its interface identifier and the CGA owner's public key 💎. this makes a cryptographic home address ownership proof possible without a public-key infrastructure 🙌, so other nodes can securely and autonomously authenticate the CGA owner, as long as the CGA's subnet prefix is correct ✅. cryptographically generated home addresses can replace home address tests, except for an initial test that validates the home address prefix 🔄. this means lower handoff delays and longer binding lifetimes, plus less signaling overhead for mobile nodes that temporarily don't move 🥳. Enhanced Route Optimization also optionally lets the correspondent node prove ownership of its IP address 🦋.
3.2. Non-Cryptographic Care-of Addresses 🏡
unlike a home address, a care-of address doesn't have any identifying function 🙅♀️. so a cryptographic ownership proof for a care-of address isn't really worth much 🤷♀️. since the care-of address is where packets get redirected to, what actually matters is whether the mobile node is reachable there 📬. Enhanced Route Optimization uses care-of address tests for this 🧪, but lets correspondent nodes send packets to a new care-of address before the mobile node has been found reachable there 🚀.
3.3. Semi-Permanent Security Associations 🤝
CGA-based authentication uses public-key cryptography, so it's way less computationally efficient than authenticating with a shared secret key 🐌. it also needs a big pile of supplementary CGA parameters piggybacked onto protected messages 📦. Enhanced Route Optimization gets around these downsides by using an initial CGA-based authentication to securely swap a secret permanent home keygen token between a mobile node and a correspondent node 🔐. that permanent home keygen token then authenticates the mobile node much more efficiently in later correspondent registrations ⚡. mobile and correspondent nodes renew the permanent home keygen token only on an infrequent basis 🗓️. so the token is neither constant nor short-lived, which is why the security association between the mobile node and the correspondent node is called "semi-permanent" 💫.
3.4. Initial Home Address Tests 🧐
an initial home address test is still needed, even with a cryptographic proof of home address ownership, to guard against spoofed subnet prefixes in home addresses 🕵️♀️. without any home address tests, a malicious node could cryptographically generate a home address using the subnet prefix of a victim network, and ask a correspondent node to register a binding between that spoofed home address and the attacker's own care-of address 😈. the attacker then tricks the correspondent node into sending a stream of packets to the care-of address, and then deregisters the binding or lets it expire 🎪. the result is that the correspondent node redirects the packet stream "back" to the home address, flooding the victim network with unrequested packets 🌊💀. to prevent this kind of misuse, an initial home address test is required for the mobile node and the correspondent node to establish a semi-permanent security association 🛑. the home address test is, if possible, run proactively so it saves a potentially costly message exchange via the home agent during the critical handoff period ⏱️. the home address test doesn't need to be repeated on subsequent movements 🙌✨.
3.5. Concurrent Care-of Address Tests ✨
okay so ERO lets a correspondent node (CN) start sending payload packets to the mobile node's (MN) new care-of address 🦋 before the MN has been confirmed reachable there. when the MN changes its IP connectivity, it first updates its binding at the CN to the new care-of address, and it doesn't have to prove reachability to do it 💅 the CN registers that new care-of address on a tentative basis and marks it UNVERIFIED. then payload packets can go back and forth both ways through the new care-of address while the MN's reachability there gets verified at the same time 🎀 once that verification finishes, the CN moves the care-of address to VERIFIED state. main character energy for handoffs, honestly 🌸
3.6. Credit-Based Authorization 🛡️
ngl this one is so important 😭 concurrent care-of address tests with no extra protection would let an attacker trick a CN into temporarily redirecting payload packets (the ones that were really meant for the attacker) over to a victim's IP address. this is called "redirection-based flooding" [5], and it's super appealing to an attacker because the CN is the one generating the flood packets and sending them at the victim, not the attacker. so the attacker gets to amplify the attack by a lot compared to a direct flood, where the attacker would have to make all those packets themselves 💀
ERO stops this with Credit-Based Authorization 🔥 it manages how much effort the CN spends sending payload packets to a care-of address that's still in UNVERIFIED state, so that a redirection-based flood can never be more effective than a direct flood. sending unrequested packets is just how packet-oriented networks work, and direct flooding is a threat that comes from that, whether or not mobility support exists. since redirection-based flooding can't be any more efficient than direct flooding, Credit-Based Authorization brings ERO's flooding protection up to the level of the non-mobile Internet 👑 which means ERO meets the objective of giving a security level comparable to the non-mobile Internet ✨
the "credit" is how the effort gets measured and limited 🦋 the CN keeps a credit balance to compare its own effort against the effort the MN puts into regular communications with the CN. the CN increases the credit for payload packets it receives from the MN's care-of address in VERIFIED state, and it reduces the credit in proportion to its own effort when sending payload packets to a care-of address of the MN in UNVERIFIED state 🧚
3.7. Parallel Home and Correspondent Registrations 🌈
ERO lets MNs run a correspondent registration in parallel with the matching home registration 🍓 which cuts down handoff delays. base Mobile IPv6 makes the MN wait for a Binding Acknowledgment message saying the home registration worked before it can even start the correspondent registration, so ERO is way faster 🚀
4. Protocol Operation 💖
ERO lets an MN securely authenticate to a CN based on the CGA property of its home address, and it also lets the MN ask for a concurrent care-of address test for better handoff efficiency 🫶 the messages exchanged during a correspondent registration are different depending on whether the MN wants to use either or both of these upgrades. here's how that works 👇
4.1. Sending Binding Update Messages 💌
an MN can start a correspondent registration for any of these reasons:
- to set up a new binding at a CN while it's away from its home link, so later packets get route-optimized and stop going through the MN's home agent 🦋
- to update an existing binding at the CN while it's moving from one point of IP attachment to another 🚗
- to follow up an early Binding Update message with a complete Binding Update message after getting a Binding Acknowledgment message that has a Care-of Test option 🎀
- to refresh an existing binding at the CN without changing the current point of IP attachment 🌸
- to ask the CN to renew an existing permanent home keygen token that the MN and CN share (see Section 4.5) 🔑
- to ask the CN to deregister an existing binding 🧹
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 1: Correspondent registration with authentication by a proof
of the mobile node's knowledge of a permanent home keygen token;
concurrent care-of address testno matter which of those reasons applies, the MN sends a Binding Update message to the CN 💫 that message gets authenticated with one of these three methods:
- if the MN's home address is a CGA but the MN doesn't have a permanent home keygen token in its Binding Update List entry for the CN, the MN SHOULD authenticate the Binding Update message based on the CGA property of its home address 🔐 this means sending its CGA parameters and signature to the CN and passing a reachability check at the home address too 💅
- if the MN's home address is a CGA and the MN has a permanent home keygen token in its Binding Update List entry for the CN, the MN MUST authenticate the Binding Update message by proving it knows that permanent home keygen token 🔑✨
- if the MN's home address is not a CGA, the MN MUST authenticate the Binding Update message by proving reachability at its home address 🏠
the lifetime the MN asks for in the Lifetime field of the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME (see Section 7) if the message is going to be authenticated by the CGA property of the MN's home address or by proving it knows a permanent home keygen token 🙈 if the chosen method is proving reachability at the home address, the lifetime MUST NOT exceed MAX_RR_BINDING_LIFETIME [1]. it's RECOMMENDED in every case that the MN asks for the maximum allowed lifetime so it doesn't have to keep refreshing bindings and so signaling overhead stays low 🧠 and a Binding Update message that asks to delete an existing binding at the CN MUST have its Lifetime field set to zero 🗑️
if the chosen method goes through the CGA property of the MN's home address, the MN puts its CGA parameters and signature in the Binding Update message by adding one or more CGA Parameters options (see Section 5.1), directly followed by a Signature option (see Section 5.2) 🧩 this is covered in Section 4.5. once the MN has gotten a permanent home keygen token from the CN, it MUST authenticate every later Binding Update message by proving it knows that permanent home keygen token, until the binding lifetime runs out, the permanent home keygen token gets renewed, or the MN explicitly deregisters the binding at the CN 🔒 this is what stops an attacker on the path from the CN to the MN's home address from downgrading the MN's chosen method to a reachability proof at the home address 🛡️ the MN MAY choose to ignore the CGA property of its home address and authenticate Binding Update messages by proving reachability at the home address instead. but that behavior makes it easier for on-path attackers, so it's NOT RECOMMENDED 😬
Mobile node Home agent Correspondent node
| | |
| | |
|-Home Test Init--------->|------------------------>|
| | |
|<------------------------|<--------------Home Test-|
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 2: Correspondent registration with authentication based on
reachability verification at the home address; concurrent care-of
address testthe MN also puts its CGA parameters in the Binding Update message when it wants to renew a permanent home keygen token it shares with the CN 🔄 it does this the same way as before, by adding one or more CGA Parameters options and a Signature option to the message 💖
the authenticator for the Binding Update message is calculated from either a permanent or a temporary home keygen token 🧁 which type the MN uses depends on the authentication method:
Okay bestie, so the Binding Update has to be authenticated, and the home side can be proven in three different ways 🔐🎀
- If the Binding Update is going to be authenticated based on the CGA property of the mobile node's home address, the mobile node MUST use a temporary home keygen token from the correspondent node. It might already have a valid one in its Binding Update List entry for that correspondent node, or it can grab a fresh one through a Home Test Init and Home Test exchange. 💅
- If the Binding Update is going to be authenticated by proving knowledge of a permanent home keygen token, the mobile node MUST use the permanent home keygen token that is has in its Binding Update List entry for the correspondent node. 🔑
- If the Binding Update is going to be authenticated through a proof of reachability at the home address, the mobile node MUST use a temporary home keygen token from the correspondent node. Same deal as before: it might already have a valid one saved, or it can fetch one with a Home Test Init and Home Test exchange. 🦋
Unless the whole point of the Binding Update is to delete an existing binding at the correspondent node, the authenticator also gets calculated with a care-of keygen token. The mobile node picks that one like this:
- If the mobile node has a valid care-of keygen token for the to-be-registered care-of address in its Binding Update List entry for the correspondent node, it MUST use that token when calculating the authenticator. The Binding Update is then "complete" ✨
- If the mobile node doesn't have a valid care-of keygen token in its Binding Update List entry for the correspondent node, it SHOULD set the care-of keygen token to zero and use that in the authenticator calculation. In this case the Binding Update is "early" 🌸
- If the mobile node doesn't have a valid care-of keygen token in that entry either, it MAY choose to get one through a Care-of Test Init and Care-of Test exchange, as defined in [1], without sending an early Binding Update. Then it waits for the Care-of Test message and uses the care-of keygen token inside it to calculate the authenticator for a complete Binding Update. Ngl this makes the handoff latency go up, so it is NOT RECOMMENDED 🙈
For reduced handoff delays, the mobile node SHOULD start its home and correspondent registrations at the same time for a particular care-of address. 🚀 If it wants to stop using Mobile IPv6 while it's away from its home link, it SHOULD also run the home and correspondent deregistrations in parallel. BUT when the mobile node commits its home and correspondent deregistrations after getting back to the home link following some roaming, it MUST start the home deregistration first, and it MUST wait for a Binding Acknowledgment message that says the home deregistration worked before it starts the correspondent deregistration. Why? This keeps the home agent from proxying the mobile node's home address while the mobile node is on the home link, so the two don't interfere during Duplicate Address Detection. 👑 A home deregistration only takes a link-local round-trip time when it's done from the home link, so skipping the parallel version costs basically nothing in handoff delay. Iconic restraint.
Also, when the Binding Update for the correspondent registration is going to be authenticated based on the CGA property of the mobile node's home address, or through a proof of reachability at the home address, the mobile node SHOULD start the Home Test Init and Home Test exchange before the handoff. This gets a fresh home keygen token from the correspondent node early, which speeds things up even more. A Home Test Init can be sent periodically whenever the home keygen token it got earlier is about to expire. Tokens are valid for 3.5 minutes [1], so the gap between Home Test Init messages needs to be a bit shorter than that. 🫶 Or if the link layer gives a trigger when a handoff is coming, the mobile node might be able to send the Home Test Init at exactly the right moment. Proactive home address tests are totally doable because a home address doesn't change across handoffs. Main character energy 🌈
If the mobile node starts the home address test from the home link, it MUST address the Home Test Init message directly to the correspondent node. The Home Test message will then come straight back from the correspondent node. But if the home address test starts from a visited link, the mobile node MUST tunnel the Home Test Init message to the home agent. The home agent then tunnels the Home Test message back to the mobile node. 🧚 A home address test SHOULD NOT overlap with a home registration or home deregistration, because that could make the Home Test Init or Home Test message get lost. Not the vibe 💀
If the Binding Update is early, the mobile node MUST add a Care-of Test Init option (see Section 5.4) to the message, asking the correspondent node to send back a new care-of keygen token. The Care-of Test Init option MUST come after the CGA Parameters and Signature options, if those are in the Binding Update. Once a Binding Acknowledgment with a Care-of Test option (see Section 5.5) comes back, the mobile node MUST use the care-of keygen token inside it to calculate the authenticator for a complete Binding Update, and then send that to the correspondent node. 💖
If the Binding Update is authenticated based on the CGA property of the mobile node's home address, the mobile node MAY add a CGA Parameters Request option (see Section 5.6) to the Binding Update. This asks the correspondent node to prove it owns its IP address inside the Binding Acknowledgment. That ownership proof lets the mobile node check that the permanent home keygen token in the Binding Acknowledgment was generated by the right correspondent node. Verified and iconic 🔍✨
The mobile node includes the nonce indices for the selected home and care-of keygen tokens in the Binding Update, using a Nonce Indices option [1]. Here's how the home nonce index gets picked:
- If the Binding Update is going to be authenticated based on the CGA property of the mobile node's home address, the mobile node uses a temporary home keygen token to calculate the authenticator, and the associated home nonce index MUST be taken from the Home Test message that the home keygen token came from. 🌸
- If the Binding Update is going to be authenticated by proving knowledge of a permanent home keygen token, the home nonce index MUST be set to zero. 🍓
- If the Binding Update is going to be authenticated through a proof of the mobile node's reachability at the home address, the mobile node uses a temporary home keygen token to calculate the authenticator, and the associated home nonce index MUST be taken from the Home Test message that the home keygen token came from. 🦋
The care-of nonce index follows these rules:
- If the Binding Update is complete, the care-of nonce index is taken from the Care-of Test option or Care-of Test message that the care-of keygen token (used for the authenticator) came from. 💜
- If the Binding Update is early, the care-of nonce index MUST be set to zero. 🫠
- If the purpose of the Binding Update is to delete a binding at the correspondent node, the care-of nonce index MUST be set to zero. 🧹
The Nonce Indices option goes after the CGA Parameters, Signature, Care-of Test Init, and CGA Parameters Request options, if those are included in the Binding Update as well. Almost done bestie 🥹
Last step: the mobile node calculates an authenticator for the Binding Update based on the selected home and care-of keygen tokens, following the rules in Section 5.2 and Section 6.2.7 of [1]. For a Binding Update that asks the correspondent node to delete an existing binding, the authenticator is calculated from only a home keygen token, with no care-of keygen token involved. 🙅♀️ The authenticator goes into the Authenticator field of a Binding Authorization Data option [1], which the mobile node adds to the Binding Update as the very last option. Authenticator sealed, slay 🔐👑
Here's the flow for this one, because pictures help 🦋
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-Care-of Test Init-------------------------------->|
| | |
| | |
|<------------Binding Ack-| |
|<-------------------------------------Care-of Test-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 3: Correspondent registration with authentication by a proof
of the mobile node's knowledge of a permanent home keygen token;
explicit care-of address testOkay bestie, the time-sequence diagrams in Figure 1 through Figure 3 show how Enhanced Route Optimization actually plays out, using a few picked message exchanges. ✨
Figure 1 is a correspondent registration where an early Binding Update message gets authenticated by proving the mobile node knows a permanent home keygen token 🔑. The early message carries a Care-of Test Init option, which asks the correspondent node to tuck a fresh care-of keygen token into a Care-of Test option inside the Binding Acknowledgment message 🎀. Then the mobile node wraps things up with a complete Binding Update message. Sooo clean 💅
Figure 2 is another correspondent registration, but this time the Binding Update is authenticated by proof of reachability at the home address 🏠. The home address test happens proactively, before the handoff, so the mobile node can send a Binding Update right after the handoff happens 🦋. This Binding Update is early too, and a care-of keygen token comes back with the Binding Acknowledgment message 🌸
Figure 3 is the one where the mobile node gets a fresh care-of keygen token first, through the dedicated Care-of Test Init and Care-of Test exchange 🧚. After that, it sends a complete Binding Update message authenticated with the CGA property of the home address. Main character energy 👑
4.2. Receiving Binding Update Messages 💌
When the correspondent node gets a Binding Update message, it must first check whether the sending mobile node is the legit owner of the home address in that message 🕵️♀️. The correspondent node picks the authentication method based on the home nonce index in the Nonce Indices option of the Binding Update message, and on whether the Binding Update message has CGA Parameters and Signature options:
- If the home nonce index is set to a non-null value and the Binding Update message includes one or more
CGA Parametersoptions followed by aSignatureoption, the correspondent node MUST authenticate the Binding Update message based on the CGA property of the mobile node's home address. 💖 - If the home nonce index is zero and the Binding Update message does not include one or more
CGA Parametersoptions followed by aSignatureoption, the correspondent node MUST authenticate the Binding Update message by a proof of the mobile node's knowledge of a permanent home keygen token. 🔑 - If the home nonce index is set to a non-null value and the Binding Update message does not include one or more
CGA Parametersoptions followed by aSignatureoption, the correspondent node MUST authenticate the Binding Update message through a proof of the mobile node's reachability at the home address. 🏡
On top of the validation procedure for Binding Update messages specified in [1], the correspondent node must also take these extra steps to reject Binding Update messages that are authenticated the wrong way 🚫:
- If the Binding Update message includes one or more
CGA Parametersoptions followed by aSignatureoption and the home nonce index is zero, the correspondent node MUST send a Binding Acknowledgment message with status code 150 ("Non-null home nonce index expected"). This makes sure that a Binding Update authenticated based on the CGA property of the mobile node's home address also proves reachability at the home address. No shortcuts, periodt 💅 - If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the correspondent node MUST verify that it has a Binding Cache entry for the mobile node that includes a permanent home keygen token. If there's no Binding Cache entry for the mobile node, or the existing one doesn't include a permanent home keygen token, the correspondent node MUST reject the Binding Update message by sending a Binding Acknowledgment message with status code 147 ("Permanent home keygen token unavailable"). 🥺
- If the Binding Update message is to be authenticated through a proof of the mobile node's reachability at the home address, the correspondent node MUST verify that its Binding Cache entry for the mobile node does not have a permanent home keygen token. If the Binding Cache entry does have one, the correspondent node MUST reject the Binding Update message by sending a Binding Acknowledgment message with status code 149 ("Permanent home keygen token exists"). This stops an attacker from downgrading the authentication method to hijack a legit mobile node's binding. Not on my watch 😤
The authenticator for the Binding Update message is calculated from a permanent or temporary home keygen token. Which type the correspondent node uses to validate the authenticator, and how it gets or recomputes that token, depends on the authentication method 🧩:
- If the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address, the correspondent node MUST recompute the temporary home keygen token defined by the (non-null) home nonce index in the
Nonce Indicesoption of the Binding Update message, and it MUST use this recomputed token to validate the authenticator of the message. ✨ - If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the correspondent node MUST use the permanent home keygen token in its Binding Cache entry for the mobile node to validate the authenticator of the Binding Update message. 🔐
- If the Binding Update message is to be authenticated through verification of the mobile node's reachability at the home address, the correspondent node MUST recompute the temporary home keygen token defined by the (non-null) home nonce index in the
Nonce Indicesoption of the Binding Update message, and it MUST use this recomputed token to validate the authenticator of the message. 🏠
Unless the Binding Update message is meant to delete an existing binding at the correspondent node, the authenticator is also calculated from a care-of keygen token 🧁. Which care-of keygen token gets used depends on whether the Binding Update message is complete or early:
- If the care-of nonce index in the
Nonce Indicesoption of the Binding Update message is set to a non-null value, the Binding Update message is complete. In this case, the correspondent node MUST recompute the care-of keygen token identified by the care-of nonce index, and it MUST use this recomputed token to validate the authenticator of the message. 🎀 - If the care-of nonce index in the
Nonce Indicesoption of the Binding Update message is zero, the Binding Update message is early. The care-of keygen token used to validate the authenticator of the Binding Update message is zero in this case. 🌱
Last step: the correspondent node validates the authenticator in the Binding Update message using the chosen home and care-of keygen tokens, following the algorithm in Section 9.5.1 of [1]. 🧮
If validation fails, the correspondent node MUST discard the Binding Update message. It may have to send a Binding Acknowledgment message with a status code that shows the failure, as described in [1]. 🙅♀️
As long as the authenticator validation in the Binding Update message succeeds, the correspondent node registers the mobile node's new care-of address. It either updates an existing Binding Cache entry or creates a brand-new one 🆕. The lifetime granted for the binding depends on the lifetime the mobile node asked for in the Lifetime field of the Binding Update message, plus the method used to authenticate it. If the Binding Update message is authenticated based on the CGA property of the mobile node's home address or by a proof of knowledge of a permanent home keygen token, the lifetime for the binding SHOULD be set to the maximum of MAX_CGA_BINDING_LIFETIME and the value in the Lifetime field of the Binding Update message. If the Binding Update message is authenticated through a proof of reachability at the home address, the lifetime for the binding SHOULD be set to the maximum of MAX_RR_BINDING_LIFETIME [1] and the value in the Lifetime field of the Binding Update message. Either way, the correspondent node may grant an even shorter lifetime, but it MUST NOT accept a longer one ⏳💜
The state of the new care-of address depends on whether the Binding Update message is complete or early 🚦:
- If the Binding Update message is complete, the new care-of address is set to
VERIFIEDstate. The correspondent node may then immediately send packets to the new care-of address without restrictions. 🟢 - If the Binding Update message is early, the new care-of address is set to
UNVERIFIEDstate. The correspondent node MUST then follow the rules in Section 4.10 for sending packets to this care-of address until the care-of address is set toVERIFIEDstate. 🟡
If the Binding Update message has one or multiple CGA Parameters options, the mobile node is asking the correspondent node to accept the included CGA parameters, either to set up a new permanent home keygen token or to renew an existing one shared between the two of them 🤝. In this case, the correspondent node MUST check whether the CGA Parameters options are directly followed by a Signature option and, if so, validate the CGA parameters and signature as described in Section 4.6. 🔍
If the CGA Parameters option is not directly followed by a Signature option, or the validation of the included CGA parameters and signature fails, the correspondent node MUST discard the Binding Update message and send a Binding Acknowledgment message with status code 148 ("CGA and signature verification failed") to the mobile node. 💔
As long as the signature in the Signature option is correct, the correspondent node generates a permanent home keygen token to share with the mobile node and stores it in its Binding Cache entry for the mobile node 🔑✨. The permanent home keygen token is sent to the mobile node inside a Binding Acknowledgment message, as described in Section 4.3. 🎁
4.3. Sending Binding Acknowledgment Messages 💌
okay so bestie, the correspondent node sends a Binding Acknowledgment message back to the mobile node after it gets a valid Binding Update message, and it does this in any of these cases: 🦋
- The
Acknowledgeflag in the Binding Update message is set. - The Binding Update message contains one or multiple CGA Parameters options directly followed by a Signature option, and the signature included in the latter was determined to be correct.
- The Binding Update message is early and includes a
Care-of Test Initoption.
if the Binding Update message also has a CGA Parameters Request option and the correspondent node's IP address is a CGA, the correspondent node MUST include its CGA parameters and signature in the Binding Acknowledgment message by adding one or more CGA Parameters options directly followed by a Signature option. ✨ this is the part that lets the mobile node check that the permanent home keygen token it got back really came from the right correspondent node, which is so iconic. if the Binding Update message has a CGA Parameters Request option but the correspondent node's IP address is not a CGA, the correspondent node ignores that option and keeps processing the Binding Update message as described below. 🙈
if the Binding Update message contains one or multiple CGA Parameters options directly followed by a Signature option, and the signature included in the latter was determined to be correct, the correspondent node MUST add a Permanent Home Keygen Token option (see Section 5.3) with a new permanent home keygen token to the Binding Acknowledgment message. the correspondent node also stores this permanent home keygen token in its Binding Cache entry for the mobile node. 🔥
if the Binding Update message includes a Care-of Test Init option, the correspondent node MUST append to the Binding Acknowledgment message a Care-of Test option with a pseudo-random value in the Care-of Keygen Token field. the Care-of Test option MUST appear after the Permanent Home Keygen Token option in case both options are present in the Binding Acknowledgment message. 💜
a Binding Authorization Data option must be added to the Binding Acknowledgment message as a last option, as described in Section 5.2 and Section 6.2.7 of [1]. 🎀
4.4. Receiving Binding Acknowledgment Messages 🧚
first things first, a mobile node verifies a received Binding Acknowledgment message according to the rules specified in [1]. as long as the message isn't rejected under those rules, the mobile node takes the following additional steps. 💅
if the mobile node included a CGA Parameters Request option in the Binding Update message and the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node first processes any CGA Parameters and Signature options in the Binding Acknowledgment message like this. if the Binding Acknowledgment message contains one or more CGA Parameters options that are directly followed by a Signature option, the mobile node MUST check the ownership of the correspondent node's IP address by verifying the included CGA parameters and signature as described in Section 4.6. if the validation of the CGA parameters and signature fails, the mobile node MUST silently discard the Binding Acknowledgment message. the mobile node MUST also silently discard the Binding Acknowledgment message if the message includes one or more CGA Parameters options that are not directly followed by a Signature option, or if the Binding Acknowledgment message lacks any CGA Parameters options in the presence of a Signature option. 😭
if the mobile node did not include a CGA Parameters Request option in the Binding Update message, or the Binding Acknowledgment message does not contain a Permanent Home Keygen Token option, the mobile node ignores any CGA Parameters and Signature options that the Binding Acknowledgment message may contain. using the CGA Parameters Request option carefully in Binding Update messages is a power move 👑, because it lets the mobile node control how much processing it spends on verifying a correspondent node's CGA, and it lets the mobile node turn that verification off when there are persistent verification failures. those failures may come from misconfigured or outdated CGA software [12] on the correspondent node side or at the mobile node itself. specifically, if the mobile node repeatedly fails to receive a Binding Acknowledgment message including valid CGA Parameters and Signature options in response to sending a Binding Update message with a CGA Parameters Request option, the mobile node SHOULD refrain from including a CGA Parameters Request option in future Binding Update messages for the same correspondent node. 🌸
if the mobile node included a CGA Parameters Request option in the Binding Update message, but the Binding Acknowledgment message does not contain any CGA Parameters or Signature options, the mobile node cannot be sure whether the correspondent node's IP address is simply not a CGA, or whether the Binding Acknowledgment message comes from an attacker on the path between the mobile node and the correspondent node. 🕵️♀️ to avoid accepting a permanent home keygen token from an on-path attacker, the mobile node MUST give precedence to Binding Acknowledgment messages that include valid CGA Parameters and Signature options over Binding Acknowledgment messages without such options. one possible algorithm the mobile node can follow here is to always accept the Binding Acknowledgment message received first. then, if that message doesn't contain valid CGA Parameters or Signature options, and another Binding Acknowledgment message including such options arrives later on, the mobile node reverts any state changes involved in accepting the first Binding Acknowledgment in favor of this subsequent one. giving precedence to Binding Acknowledgment messages with valid CGA Parameters and Signature options over those without such options lets the mobile node talk to correspondent nodes that don't use a CGA, and at the same time protects against most on-path attackers. the strategy does not protect against an attacker that can intercept Binding Acknowledgment messages from the correspondent node, but that kind of attacker could block mobility management between the two nodes anyway. 🫶 when the mobile node has permanently accepted a Binding Acknowledgment message without valid CGA Parameters and Signature options, the mobile node SHOULD refrain from including a CGA Parameters Request option in future Binding Update messages for the same correspondent node. 🥀
if the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node extracts the permanent home keygen token from this option and stores it in its Binding Update List entry for the correspondent node. future Binding Update messages will then be authenticated by a proof of the mobile node's knowledge of this permanent home keygen token. 🔐
if the Binding Acknowledgment message contains a Care-of Test option, the mobile node extracts the care-of keygen token from this option, stores the token in its Binding Update List entry for the correspondent node, and sends the correspondent node a complete Binding Update message as defined in Section 4.1. note that the complete Binding Update message will be authenticated based on the CGA property of the mobile node's home address if the Binding Acknowledgment message also includes a Permanent Home Keygen Token option. this is independent of the authentication method that was used for the corresponding early Binding Update message. 🌈
a mobile node MUST ensure that, while it has a binding for a certain home address at a correspondent node, it also has a valid binding at its home agent for the same home address. this may sometimes require the mobile node to extend the binding lifetime at the home agent, to ask a correspondent node to use a binding lifetime shorter than the permitted maximum, or to explicitly deregister an existing binding at a correspondent node. 🏠
if the mobile node authenticates Binding Update messages for a particular correspondent node by proving its knowledge of a permanent home keygen token, but registrations at this correspondent node keep failing, the mobile node SHOULD renew the permanent home keygen token. it does this by sending a Binding Update message that is authenticated based on the CGA property of its home address. this Binding Update message includes the mobile node's CGA parameters and signature, and it asks the correspondent node to generate a new permanent home keygen token and send it to the mobile node within a Binding Acknowledgment message. 🔄
if the mobile node persistently receives Binding Acknowledgment messages with status code 148 ("CGA and signature verification failed") from a correspondent node, the mobile node SHOULD authenticate future Binding Update messages for the same correspondent node through a proof of its reachability at the home address. this lets the mobile node recover from misconfigured or outdated CGA software [12] on the correspondent node side or at the mobile node itself. 🍓
4.5. Sending CGA Parameters
okay so a mobile node tucks its CGA parameters and signature into a Binding Update message for a correspondent node in any of these situations 💖
- To acquire a permanent home keygen token if the mobile node's home address is a CGA, and the mobile node does not yet have a permanent home keygen token from the correspondent node. 🎀
- To extend the lifetime of an existing binding if the mobile node already has a permanent home keygen token from the correspondent node, and the lifetime of the binding at the correspondent node is about to expire. ⏳
- To renew an existing permanent home keygen token to prevent replay attacks in the imminent event of a sequence number rollover, or for improved protection against cryptanalysis. 🔐
A correspondent node whose IP address is a CGA does the same thing in reverse 🦋. It includes its CGA parameters and signature in a Binding Acknowledgment message for the mobile node when it receives a Binding Update message with a CGA Parameters Request option.
The CGA parameters go out in the format of the CGA Parameters data structure defined in [2]. That structure gets split over one or more CGA Parameters options, as described in Section 5.1. ✨ The last CGA Parameters option MUST be directly followed by a Signature option. No exceptions, bestie 🙅♀️
The value for the Signature field in the Signature option is calculated with the signature generation algorithm defined in Section 6 of [2]. It's signed with the mobile or correspondent node's private key over this sequence of octets 🌸
mobility data =
care-of address | correspondent node IP address | MH dataWhere "|" means concatenation. "Care-of address" is the mobile node's care-of address. "Correspondent node IP address" is the IP address of the correspondent node that is visible to protocol layers above IP. If the correspondent node is mobile, "correspondent node IP address" refers to the correspondent node's home address. 🧚
"MH data" is the content of the Binding Update or Binding Acknowledgment message, including the mobility header and all options up to the last CGA Parameters option. So "MH data" leaves out the IPv6 header and any IPv6 extension headers other than the mobility header itself. 🙈 The "mobility data" is what the spec calls the "message" in Section 6 of [2].
Here's a lowkey tricky bit 👀 The Signature field value gets calculated as if the Checksum field in the mobility header was zero. The Checksum field in the transmitted packet still gets calculated the usual way, with the calculated value in the Signature field being part of the packet protected by the checksum. Iconic layering 💅
4.6. Receiving CGA Parameters
Mobile and correspondent nodes that receive a Binding Update or Binding Acknowledgment message with one or more CGA Parameters options directly followed by a Signature option first process the message as described in [1]. That includes checking the authenticator in the Authenticator field of the Binding Authorization Data option. If the message gets rejected because of an incorrect authenticator or for any other reason, it doesn't get processed any further. 🚫
If the validation of the message succeeds, the mobile or correspondent node reassembles the CGA Parameters data structure from the CGA Parameters options in the message, as described in Section 5.1. Then it runs the CGA verification algorithm defined in Section 5 of [2] 🔍
The CGA verification algorithm takes two inputs: the to-be-verified CGA and the reassembled CGA Parameters data structure. When the correspondent node runs it, the to-be-verified CGA is the mobile node's home address. When the mobile node runs it, the to-be-verified CGA is the correspondent node's IP address that is visible to protocol layers above IP. If the correspondent node is mobile, that's its home address. If the CGA verification fails, the steps below get skipped 🙃
If the CGA verification succeeds, the mobile or correspondent node does a more time-consuming check of the signature. It pulls the signature out of the Signature field in the Signature option and runs the signature verification algorithm defined in Section 6 of [2] 🧐 That algorithm takes four inputs: the to-be-verified CGA as defined above, the reassembled CGA Parameters data structure, the MH data as defined in Section 4.5, the CGA Message Type tag of Enhanced Route Optimization as defined in Section 7, and the signature itself. Lots of ingredients, very thorough 🥰
4.7. Sending Permanent Home Keygen Tokens
A correspondent node hands a mobile node a new permanent home keygen token after it has received a Binding Update message from that mobile node with CGA Parameters and Signature options included, and those options have been successfully validated as described in Section 4.6. 🎉 The permanent home keygen token is a 64-bit value randomly generated by the correspondent node. The correspondent node stores it in the binding cache entry it maintains for the mobile node. 🗝️
The correspondent node sends the permanent home keygen token to the mobile node in encrypted form, inside a Permanent Home Keygen Token option in a Binding Acknowledgment message. It sends this message even if the Acknowledge flag in the corresponding Binding Update message was clear 🙌 The correspondent node encrypts the token with the mobile node's public key using the RSAES-PKCS1-v1_5 format [4], then puts the ciphertext into the Permanent Home Keygen Token field of the Permanent Home Keygen Token option.
The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment message. That means the authenticator in the Binding Authorization Data option covers the Permanent Home Keygen Token option too. Locked in 🔒
4.8. Receiving Permanent Home Keygen Tokens
A mobile node that receives a Binding Acknowledgment message first processes it as described in [1], no matter whether the message includes a Permanent Home Keygen Token option. That includes checking the authenticator in the Authenticator field of the Binding Authorization Data option. If the message is rejected because of an incorrect authenticator or for any other reason, the mobile node does not process it any further. 🛑
Otherwise, if the mobile node accepts the Binding Acknowledgment message and the message includes a Permanent Home Keygen Token option, the mobile node pulls the ciphertext out of the Permanent Home Keygen Token field and decrypts it with its private key using the RSAES-PKCS1-v1_5 format [4]. The result is the permanent home keygen token to be used in further registrations with the correspondent node. ✨ The mobile node stores the token in the Binding Update List entry it maintains for the correspondent node 📋
4.9. Renewing Permanent Home Keygen Tokens
A mobile node that shares a permanent home keygen token with a correspondent node MUST NOT use the same sequence number twice with that permanent home keygen token, so it stays protected against replay attacks 🛡️ The mobile node MUST renew the permanent home keygen token by including its CGA parameters and signature in a Binding Update message for the correspondent node when a sequence number rollover is imminent. 🔄
Also, the mobile node MAY renew its permanent home keygen token at any time. Periodic renewal gives increased protection against cryptanalysis, which is very much a main character move 🦸♀️ Finally, the mobile node may in most cases want to renew the permanent home keygen token when the lifetime of its binding at the correspondent node expires. ⭐
4.10. Handling Payload Packets 🎀
Bestie, this is the moment after a handoff where things get fast. ✨ If the mobile node sends an early Binding Update right away, the mobile node and correspondent node can get route-optimized communication going again through the mobile node's new care-of address. 🦋 The mobile node can start sending payload packets to the correspondent node from that new care-of address as soon as it has dispatched the early Binding Update. 💨 The correspondent node then redirects its outgoing payload packets for the mobile node to the new care-of address, once it has received the early Binding Update and registered that address. And quick reminder: a "payload packet" just means a packet that comes from a protocol layer above IP. 💅
Inbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Increase credit |
| in |---------------------> | counter by |
\ VERIFIED state? / | payload packet size |
\_________________/ |_____________________|
| |
| |
| No |
| V
| _____________________
| | |
| | Deliver payload |
+--------------------------------> | packet to upper- |
| layer protocol |
|_____________________|
Figure 4: Handling outbound payload packetsOkay so, a new care-of address that got registered with an early Binding Update stays in UNVERIFIED state on the correspondent node's side until the correspondent node gets a complete Binding Update from the mobile node. 🔐 Once that happens, the correspondent node flips the care-of address to VERIFIED state. ✅ This state is a big deal because it decides how much data the correspondent node is allowed to send to that care-of address. It's there to stop amplified, redirection-based flooding attacks, so it's giving security, periodt. 🛡️ To track this, the correspondent node keeps a "credit counter" for every mobile node that has an entry in its Binding Cache. 🧁
Whenever a payload packet shows up from a mobile node whose care-of address is in VERIFIED state, the correspondent node SHOULD increase that mobile node's credit counter by the size of the packet. 💖 Policy is allowed to restrict this, though. The correspondent node MAY be limited to a smaller increase, or no increase at all. 🙈 And if an inbound payload packet comes from a care-of address in UNVERIFIED state, the credit counter just stays the same. 😌 Figure 4 is the flow chart for all of this, so check it out. 📊
Outbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Send payload |
| in |---------------------> | packet to |
\ VERIFIED state? / | care-of address |
\_________________/ |_____________________|
|
| _____________________
| No | |
| | Discard payload |
| +---------> | packet |
| | | immediately |
V | |_____________________|
_________________ | _____________________
/ \ | | |
/ Credit counter \ Yes / \ | Send payload |
| less than payload |-------> | |-------> | packet to |
\ packet size? / \ / | home address |
\_________________/ | |_____________________|
| | _____________________
| | | |
| No | | Buffer payload |
| +---------> | packet for |
| | later transmission |
| |_____________________|
V
_____________________ _____________________
| | | |
| Reduce credit | | Send payload |
| counter by |---------------------> | packet to |
| payload packet size | | care-of address |
|_____________________| |_____________________|
Figure 5: Handling outbound payload packetsNow for the other direction. 🌈 When the correspondent node has a payload packet for the mobile node, what happens next depends on two things: the state of the mobile node's care-of address, and the current credit counter value. Figure 5 lays it out. 🗺️ If the care-of address is in VERIFIED state, the correspondent node MUST send the payload packet to the mobile node's care-of address. 🚀 If the care-of address is in UNVERIFIED state and the credit counter is greater than or equal to the packet size, the correspondent node MUST reduce the counter by the packet size and still send the packet to the care-of address. 💸 But if the care-of address is in UNVERIFIED state and the counter is less than the packet size, the payload packet MUST NOT be sent to the mobile node's care-of address. 🚫 In that case the correspondent node SHOULD discard the packet, though it MAY instead buffer it until the care-of address moves to VERIFIED state, or send it to the mobile node's home address. 🧠 The credit counter does not change when the correspondent node sends a payload packet to a care-of address that is already in VERIFIED state. 💅
The state of the mobile node's care-of address never limits how much data the mobile node can send to the correspondent node. 🙌 It also doesn't change how payload packets are addressed or routed in either direction. Every payload packet from the mobile node has the care-of address in the Source Address field of the IPv6 header, and the home address goes in the Home Address option of the IPv6 Destination Options extension header. 🏠 And every payload packet from the correspondent node has the care-of address in the Destination Address field of the IPv6 header, with the home address in the IPv6 Routing extension header. 🧭
4.11. Credit Aging 🫧
The correspondent node makes sure all of its credit counters slowly go down over time. ⏳ Each credit counter gets multiplied by a factor called CreditAgingFactor, which is less than one, at fixed intervals of CreditAgingInterval length. This is called "credit aging," and it caps how much credit a mobile node can pile up, as long as the credit comes in at a steady or nearly steady rate. 📉 That also puts an upper limit on how fast the correspondent node can keep sending to a care-of address that's still in UNVERIFIED state. 🛑 Without credit aging, a sneaky node with terrible uplink capacity could pretend to be a mobile node, build up credit super slowly over a long stretch, then blow all of it in a short burst redirecting payload packets at a victim's IP address. 😱 Not it. 🙅♀️
Picking good values for CreditAgingFactor and CreditAgingInterval really matters, especially for apps where the correspondent node sends faster than the mobile node. 🏎️ If either one is too small, the credit counter could keep blocking payload packets to a care-of address in UNVERIFIED state, and that's a vibe killer. 💀 The values in Section 7 are RECOMMENDED, because they work well when the correspondent node sends a file to the mobile node over a TCP connection and the end-to-end round-trip time stays at or under 500 milliseconds. 📁✨
4.12. Simultaneous Movements 🦋
As [1] specifies, Binding Update messages get sent to a mobile correspondent node's home address. 💌 That's what lets two mobile nodes keep talking even when both of them change IP connectivity at the same time. 👯♀️ Iconic. 👑
5. Option Formats and Status Codes 💅
Enhanced Route Optimization uses a set of new mobility options and status codes. 🌸 These are on top of the ones already defined in [1], and they're described below. 🩷
5.1. CGA Parameters Option ✨
okay so the CGA Parameters option is the one that shows up in Binding Update and Binding Acknowledgment messages 💖 it carries part of the mobile or correspondent node's CGA parameters. [1] caps mobility header options at a maximum length of 255 bytes, not counting the Option Type and Option Length fields. the CGA parameters are almost always bigger than that, so you may need to chain several CGA Parameters options together to fit everything 🧩
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: CGA Parameters :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 12.
Option Length 🌸
8-bit unsigned integer representing the length of the CGA Parameters field in octets.
CGA Parameters 👑
this field holds up to 255 bytes of the CGA Parameters data structure defined in [2]. when you put all the CGA Parameters options together in the order they show up in the Binding Update message, you MUST end up with the original CGA Parameters data structure 🫶 every CGA Parameters option in the Binding Update message except the last one MUST contain exactly 255 bytes in its CGA Parameters field, and its Option Length field MUST be set to 255 to match 💅 and all the CGA Parameters options MUST sit directly one after another. a mobility option of a different type MUST NOT be squeezed in between two of them 🙈
5.2. Signature Option 🔐
the Signature option is used in Binding and Binding Acknowledgment Update messages. it carries a signature that the mobile or correspondent node makes with its private key, covering one or more of the CGA Parameters options that came before it ✨
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Signature :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 13.
Option Length 🌸
8-bit unsigned integer representing the length of the Signature field in octets.
Signature 👑
this field has the mobile or correspondent node's signature, made with that node's private key as described in Section 4.5.
5.3. Permanent Home Keygen Token Option 🗝️
the Permanent Home Keygen Token option shows up in Binding Acknowledgment messages 💜 it carries a permanent home keygen token, which the correspondent node sends back to the mobile node after getting a Binding Update that has one or more CGA Parameters options directly followed by a Signature option from the mobile node. main character energy, honestly ✨
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Permanent Home Keygen Token :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 14.
Option Length 🌸
8-bit unsigned integer representing the length of the Permanent Home Keygen Token field in octets.
Permanent Home Keygen Token 👑
this field has the permanent home keygen token that the correspondent node generated. the content of this field MUST be encrypted with the mobile node's public key, as defined in Section 4.7 🔒 before encryption, the permanent home keygen token is 8 octets long. the ciphertext [4] is what goes in the field, though, so the Permanent Home Keygen Token field might end up longer than 8 octets 🫶
5.4. Care-of Test Init Option 🧪
the Care-of Test Init option gets included in Binding Update messages 🌈 it asks a correspondent node to send back a Care-of Test option with a fresh care-of keygen token in the Binding Acknowledgment message ✨
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 15.
Option Length 🌸
this field MUST be set to zero 🙈
5.5. Care-of Test Option 🍓
the Care-of Test option shows up in Binding Acknowledgment messages 💅 it carries a fresh care-of keygen token. the correspondent node sends it to the mobile node after getting a Care-of Test Init option in a Binding Update message 🫶
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 16.
Option Length 🌸
this field MUST be set to 8. it represents the length of the Care-of Keygen Token field in octets.
Care-of Keygen Token 👑
this field has the care-of keygen token that the correspondent node generated, as specified in Section 4.3.
5.6. CGA Parameters Request Option 🌷
the CGA Parameters Request option gets included in Binding Update messages that are authenticated based on the CGA property of the mobile node's home address 💖 it asks a correspondent node to send back its CGA parameters and signature in the Binding Acknowledgment message. that lets the mobile node check that the permanent home keygen token in the Binding Acknowledgment was generated by the right correspondent node. verification slay 🔍
here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type 🦋
8-bit identifier of the type of this mobility option. its value is 11.
Option Length 🌸
this field MUST be set to zero 🫶
5.7. Status Codes ✨
okay bestie, Enhanced Route Optimization adds four brand-new status codes 💖 for Binding Acknowledgment messages, on top of the ones already defined in [1] 🎀. Here they are 👇
Permanent home keygen token unavailable (147) 🔑
A correspondent node returns a Binding Acknowledgment message with status code 147 to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through the CGA property of the mobile node's home address, but the correspondent node either does not have a Binding Cache entry for the mobile node, or the existing Binding Cache entry for the mobile node does not contain a permanent home keygen token. A Binding Acknowledgment message with status code 147 tells the mobile node that it should request a new permanent home keygen token from the correspondent node by sending the correspondent node a Binding Update message that includes its CGA parameters and signature. This is what lets the mobile node quickly recover from state loss at the correspondent node 🦋.
[1] does not allow a correspondent node to send a Binding Acknowledgment message with a status code indicating failure when the authenticator of a received Binding Update message turns out to be incorrect. That causes extra handoff latency with high probability, because the mobile node can only detect the problem after a retransmission timer expires 😭. The mobile node is also likely to assume packet loss and resend the incorrectly authenticated Binding Update message several more times. A Binding Acknowledgment message with status code 147 helps the mobile node spot the underlying problem much more efficiently when the correspondent node could not verify the CGA property of the mobile node's home address 💅.
CGA and signature verification failed (148) 🚫
A correspondent node returns a Binding Acknowledgment message with status code 148 to a mobile node if it has received from the mobile node a Binding Update message that includes one or more CGA Parameters options directly followed by a Signature option, but either the CGA property of the home address cannot be verified based on the contents of the CGA Parameters options, or the verification of the signature in the Signature option has failed.
Permanent home keygen token exists (149) 🌈
A correspondent node returns a Binding Acknowledgment message with status code 149 to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through verification of the mobile node's reachability at the home address and does not include one or more CGA Parameters options directly followed by a Signature option, but the correspondent node has a permanent home keygen token in its Binding Cache entry for the mobile node. The Binding Update message is processed further if it includes one or more CGA Parameters options directly followed by a Signature option. This lets a mobile node get a new permanent home keygen token from the correspondent node in case it has lost the existing one, for instance due to a reboot 🔄. Whether the correspondent node accepts the Binding Update message in this case depends on the verification of the CGA parameters and the signature provided in the Binding Update message 🧐.
Non-null home nonce index expected (150) 🙅♀️
A correspondent node returns a Binding Acknowledgment message with status code 150 to a mobile node if it has received from the mobile node a Binding Update message that includes one or more CGA Parameters options directly followed by a Signature option, but the home nonce index specified in the Nonce Indices option is zero. This behaviour makes sure that a Binding Update message authenticated based on the CGA property of the mobile node's home address also provides proof of the mobile node's reachability at the home address 🌸.
6. Security Considerations 🔒
Enhanced Route Optimization is different from base Mobile IPv6 because it applies a set of optimizations for better handoff performance, stronger security, and less signaling overhead 🚀. These optimizations bring the following conceptual changes to the security model [5] of base Mobile IPv6:
- Base Mobile IPv6 runs periodic tests of a mobile node's reachability at the home address as proof of home address ownership. Enhanced Route Optimization uses an initial cryptographic home address ownership proof, combined with a check of the mobile node's reachability at the home address, to securely exchange a secret permanent home keygen token 🗝️. That permanent home keygen token is used to cryptographically authenticate the mobile node during later correspondent registrations, so those later registrations can be securely bound to the initial home address ownership proof 💜. No further periodic reachability tests at the home address are performed.
- Base Mobile IPv6 requires a mobile node to prove its reachability at a new care-of address during a correspondent registration. That means the mobile node and the correspondent node have to exchange Care-of Test Init and Care-of Test messages before the mobile node can start the binding update proper 🐢. Enhanced Route Optimization lets the mobile node send the binding update first and follow up with a proof of reachability at the care-of address ⚡. Mobile and correspondent nodes can resume communications early after a handoff, while reachability verification happens at the same time ✨. The amount of data the correspondent node is allowed to send to the care-of address until reachability verification completes is governed by Credit-Based Authorization 💰.
- The maximum binding lifetime for correspondent registrations is 7 minutes in base Mobile IPv6, so a mobile node has to periodically refresh a correspondent registration when it doesn't change IP connectivity for a while 😴. This protocol raises the maximum binding lifetime to 24 hours, which cuts the need for periodic refreshes down to a negligible level 🎉.
The discussion that follows looks at what these conceptual changes to the Mobile IPv6 security model mean in practice 🧠. It should be read together with the security considerations of [1], [2], and [5] 📚.
6.1. Home Address Ownership 💖
Okay bestie, so Enhanced Route Optimization requires a mobile node to deliver a strong cryptographic proof [2] that it's the legit owner of the home address it wants to use 🔐✨. The proof is based on the true home address owner knowing the private half of a public/private-key pair, and that pair needs two properties:
- As an input to an irreversible CGA generation function, along with a set of auxiliary CGA parameters, the public key results in the mobile node's home address. 🔑
- Among the CGA parameters fed into the CGA generation function is a modifier that, as an input to an irreversible hash extension function along with the public key, results in a string with a certain minimum number of leading zeroes. Three reserved bits in the home address encode this minimum number. 🎀
The first property locks the home address to the mobile node's public key and, thanks to public-key cryptography, to the private key too 🔒. That means the mobile node can claim the address by proving it knows the private key, which is so iconic. The second property makes brute-force searching for a key pair that passes the first property way more expensive 💅. This matters because a cryptographically generated home address only has 59 bits with cryptographic significance. Without the second property, an attacker could find a suitable key pair in O(2^59) steps, and that is NOT it 💀. With the second property added, the brute-force complexity goes up to O(2^(59+N)) steps, where N is the minimum number of leading zeroes that the result of the hash extension function is required to have 📈.
In practice, a legit mobile node has to brute-force a suitable modifier first, and then use that modifier to run the CGA generation function. An attacker who wants to spoof the mobile node's home address, so-called "IP address stealing" [5], has two options 🕵️♀️. It could generate its own public/private-key pair and brute-force a modifier that, combined with that public key, satisfies the two properties above. Or it could factor the mobile node's public key, deduce the matching private key, and copy the mobile node's modifier without any brute-force search. The mobile node controls the cost either way 🙌. Factoring a public key gets harder as the key gets longer, and the key length is up to the mobile node. The brute-force cost for a modifier goes up with the number of leading zeroes the hash extension result has to have, and the mobile node picks that number too. Downgrading attacks, where an attacker lowers the cost of spoofing a cryptographically generated home address by picking CGA parameters that are weaker than the ones the mobile node used, are therefore impossible 🚫.
The CGA specification [2] requires RSA public and private keys and sets a minimum key length of 384 bits. That requirement was tailored to Secure Neighbor Discovery for IPv6 [13], which was the original CGA application 🌸. Enhanced Route Optimization does not raise the minimum key length. Without downgrading attacks, as explained above, using short keys doesn't weaken home addresses that were generated with longer keys 🦋. Also, extensions to [2] may eventually allow public/private-key classes other than RSA, and those extensions work fine with the CGA application of Enhanced Route Optimization ✨. You still have to pick a key class and length carefully though 🧐. Home addresses are usually pretty stable, so the chosen parameters need to stay secure for what could be a really long home address lifetime ⏳. When RSA keys are used, a minimum key length of 1024 bits is therefore RECOMMENDED 💜.
The CGA generation function ties the interface identifier of a home address to its subnet prefix, but it accepts any subnet prefix. So a node can still generate a home address with a spoofed subnet prefix 🙈. This means the CGA property of a home address does NOT guarantee that the owner can actually be reached at that home address. That gap could be abused in a "return-to-home flooding attack" [5]. Here's how it goes: the attacker uses its own public key to generate a home address with a subnet prefix from a victim network, asks a correspondent node to bind that address to the attacker's current care-of address, starts downloading a large file through the care-of address, and then deregisters the binding or lets it expire. The correspondent node would then send the downloaded packets to the victim network named by the subnet prefix of the spoofed home address 😱. The protocol in this document runs a reachability test for the home address when it's first registered with the correspondent node, and that shuts down return-to-home flooding 🛑.
Verifying the CGA property of a mobile node's home address uses asymmetric public-key cryptography, which is relatively complex next to symmetric cryptography 🧮. Enhanced Route Optimization softens that cost by using symmetric cryptography after the initial public-key-based verification of the home address is done 🪄. Specifically, during the initial correspondent registration, the correspondent node gives the mobile node a permanent home keygen token. The mobile node can then authenticate to the correspondent node during later correspondent registrations using that token. This authentication lets the correspondent node link a later registration back to the original public-key-based verification of the home address 🔗. The permanent home keygen token is never sent in plain text. It's encrypted with the mobile node's public key when first assigned, and it's irreversibly hashed during later correspondent registrations 🔐🫶.
6.2. Care-of Address Ownership 🏡
A secure proof of home address ownership can help with the threat of IP address stealing, but an attacker can still bind a correct home address to a false care-of address. That tricks a correspondent node into redirecting packets, which would otherwise go to the attacker, toward a third party 😤. So if nobody checks that a mobile node is really reachable at its claimed care-of address, one or more correspondent nodes could unknowingly help with a redirection-based flooding attack on a victim the attacker picked 💀.
Redirection-based flooding attacks can target a single node, a link, or a router or other critical network device upstream of a whole network 🌐. So the attacker's spoofed care-of address could be the IP address of a node, a random IP address from a subnet prefix of some particular link, or the IP address of a router or other network device. An attack on a network can hit way more nodes than an attack on one specific node, though neighbors of a victim node on a broadcast link usually get hurt just as much as the victim does 📡.
Making mobile nodes generate care-of addresses the same way they generate home addresses would only help a little against redirection-based flooding 🤷♀️. Sure, it stops an attacker from registering a specific victim node's IP address as its care-of address. But the attacker could still generate a different CGA-based care-of address with the same subnet prefix as the victim's IP address. Flooding packets redirected to that address wouldn't need to be received and processed by any specific node. They'd still hit a whole link or network and do similar damage 😩. So CGA-based care-of addresses don't do much for flooding protection. On top of that, they'd need a computationally expensive, public-key-based ownership proof every single time the care-of address changes 🥵. For all these reasons, Enhanced Route Optimization uses regular IPv6 care-of addresses 🎀.
A common misconception is that a strong proof of home address ownership would stop redirection-based flooding, and that this would make it unnecessary to check a mobile node's reachability at a new care-of address 🙃. This idea may come from the base Mobile IPv6 home registration spec in [1], which calls for authenticating a mobile node with an IPsec security association. It doesn't require that to be backed up by a reachability check at the care-of address. But the reason home registration doesn't have to verify reachability is the administrative relationship between the home agent and the mobile node, NOT the fact that the home agent can securely verify home address ownership or that the registration is IPsec-protected 🧠. That relationship lets the home agent, first, trust that the mobile node's care-of address is correct, and second, quickly identify the mobile node if it starts acting maliciously, for example because malware got in 🦠. Section 15.3 in [1] and Section 1.3.2 in [5] explain these prerequisites 📚.
An administrative relationship between the mobile node and its home agent works out fine when we assume trust. The home agent is a core part of the mobility services a mobile user usually subscribes to, sets up herself or himself, or gets through a business relationship 🤝. A Mobile IPv6 extension [14] uses a shared authentication key that's preconfigured on both the mobile node and the correspondent node. That assumes the same kind of relationship between the mobile node and a correspondent node 🔑. Section 2 of [14] admits this assumption limits where the protocol can be used. Still, it lets the protocol skip the care-of address reachability check, just like home registration does 🙌. Enhanced Router Optimization doesn't make any assumptions about the relationship between mobile and correspondent nodes 🌈. That makes the protocol work in arbitrary scenarios, but it means correspondent nodes must verify a mobile node's reachability at every new care-of address 👑.
6.3. Credit-Based Authorization
okay bestie, Enhanced Route Optimization lets the mobile node and the correspondent node keep talking both ways after a handoff, even before the correspondent node has verified that the mobile node is reachable at its new care-of address 🦋. but that overlap is risky ngl. without protection, it would bring back the redirection-based flooding threat that reachability verification was built to kill 💀. the correspondent node usually doesn't know the round-trip time to the mobile node, and verification can fail because of packet loss, so it must accept a long enough overlap period for verification to finish ✨.
the scary part is that an attacker could trick the correspondent node into sending packets to a victim's IP address 🙈. it could also keep stalling verification by registering again, maybe with a different spoofed care-of address, right before the correspondent node's maximum permitted overlap period runs out. then the correspondent node switches to waiting for verification to complete and stops sending packets. this isn't automatically malicious on the correspondent's side, though, because even a totally legit mobile node might never get verified before its care-of address changes again 🌸. that happens with high mobility on the mobile node's side, or with constant packet loss on the path between them. it's honestly hard for the correspondent node to tell whether the other side is legit under rough conditions or actually up to no good 😭.
Enhanced Route Optimization kills the redirection-based flooding threat even with concurrent verification, and it does it with Credit-Based Authorization 👑. this mechanism manages how much effort the correspondent node spends sending payload packets to a care-of address in UNVERIFIED state, and it's built on three hypotheses 💅:
- a flooding attacker usually wants to dump the work of building and sending flood packets onto someone else. bandwidth is plentiful for lots of attractive victims, so the effort needed to send the huge flood required to knock the victim offline may be more than the attacker can handle itself.
- the attacker can always flood a victim directly by generating bogus packets itself and sending them over. that kind of attack isn't amplified, so the attacker has to have enough capacity to create a flood big enough to take the victim down.
- so the extra work of setting up and coordinating a redirection-based flood only pays off for the attacker if the correspondent node can be tricked into helping with the attack and amplifying it.
so from the attacker's side, a non-amplified redirection-based flood is no more attractive than a plain direct flood, where the attacker just sends bogus packets at the victim itself 🧚. honestly it's even less attractive, because the attacker also has to maintain a mobility management context to coordinate the redirection. so Credit-Based Authorization takes away the motivation for redirection-based flooding by stopping the amplification that could be reached through it, rather than trying to eliminate malicious packet redirection in the first place 🎀. being able to send unrequested packets is just an inherent property of packet-oriented networks, and direct flooding is a threat that comes out of that. direct flooding happens with and without mobility support, so it's a reasonable yardstick for comparing the security of Enhanced Route Optimization to the security of the non-mobile Internet 💜. with Credit-Based Authorization in place, Enhanced Route Optimization meets the goal of a security level comparable to the non-mobile Internet, and that's iconic ✨.
since the person behind a redirection-based flood would be playing the role of a mobile node, Credit-Based Authorization must be enforced on the correspondent node side 🫶. the correspondent node keeps constantly monitoring how much effort the mobile node spends communicating with it. that effort then acts as a limit on how much effort the correspondent node may spend sending payload packets while the mobile node's care-of address is in UNVERIFIED state. this permission to send a limited number of payload packets to an UNVERIFIED care-of address is what lets two-way communication resume right away once the mobile node has registered a new IP address with the correspondent node after a handoff 🌈.
if something that looks like a mobile node is actually an attacker tricking the correspondent node into redirecting payload packets to a victim's IP address, Credit-Based Authorization makes sure the flood stream stops before the correspondent node's effort on generating it goes over the effort the attacker has recently spent itself 💅. so the flood attack is at most as effective as a direct flood, which means it can't produce any amplification. iykyk, that's the whole point 🙌.
another thing about Credit-Based Authorization is that it does not hand out credit while the mobile node's care-of addresses are in UNVERIFIED state 🍓. this needs some justification, because it would technically be possible to give credit no matter what state the care-of address is in. but giving credit for packets received from a care-of address in UNVERIFIED state would open the door to sustained reflection attacks ⚠️. an attacker could make the correspondent node redirect packets meant for the attacker over to a victim's IP address, then keep that flow going toward the victim by continually refilling its credit with packets sent to the correspondent node. even though a redirection-based reflection attack like this wouldn't amplify anything, it could still look tempting to an attacker who wants to start a transport protocol handshake with the correspondent node first (which usually means the attacker has to receive some unguessable data) and then redirect the download to the victim's IP address afterwards 😭. Credit-Based Authorization makes sure the attacker can't pick up any extra credit once the download has been redirected, and that forces the attack to wrap up fast 🏁.
6.4. Time Shifting Attacks
okay so Base Mobile IPv6 limits how long a correspondent registration lasts to 7 minutes 🕰️. this also makes sure the mobile node's reachability at its home and care-of addresses gets reverified regularly ✨. that stops an attacker from exploiting the return routability procedure's vulnerability to eavesdropping when it's only temporarily on the path between the correspondent node and the spoofed home or care-of address. these "time shifting attacks" [5] could otherwise be abused for off-path IP address stealing, return-to-home flooding, or flooding against care-of addresses 💀.
Enhanced Route Optimization skips repeating both the initial home address test and any care-of address test, all to cut down handoff delays and signaling overhead 🚀. this doesn't weaken protection against IP address stealing, because the CGA-based ownership proof required for home addresses already shuts those attacks down 🔒. reachability verification doesn't add any extra protection on that front. on the flip side, limiting reachability verification to just the initial one makes time-shifted, off-path flooding attacks easier to pull off 😬. that's true whether they target home addresses with incorrect prefixes or spoofed care-of addresses, as long as the perpetrator can jump into the exchange before moving somewhere else 🏃♀️.
the decision not to repeat home and care-of address tests was based on the fact that time shifting attacks are already a threat on today's non-mobile Internet 🌍. an attacker can slip onto the path between a victim and a correspondent node, request a stream of packets from the correspondent node on the victim's behalf, and then move to a different location 🦋. most transport protocols don't check an initiator's reachability at its claimed IP address after the initial verification during connection setup. that lets an attacker take part only in connection establishment, then move to an off-path spot, where it can spoof acknowledgments to make it look like it's still at the victim's IP address 👻. so the threat of time shifting already applies to the non-mobile Internet, and that's just the way it is 💅.
we should still be upfront that the time when Enhanced Route Optimization verifies a mobile node's reachability at a home or care-of address might come before any transport layer connection gets set up ⏳. that gives an attacker more time to move away from the path between the correspondent node and the victim, which makes a time shifting attack more practical 🫣. if skipping periodic reachability verification seems too risky, a correspondent node can enforce reruns of the home or care-of address tests by limiting the registration lifetime, or by sending Binding Refresh Request messages to the mobile node 🔁.
6.5. Replay Attacks
so the protocol in this document relies on 16-bit base Mobile IPv6 sequence numbers plus periodic rekeying to dodge replay attacks 🔐. rekeying lets the mobile and correspondent nodes reuse sequence numbers without leaving themselves open to replay attacks ✨. it must be done at least once every 24 hours, because of the maximum permitted binding lifetime for correspondent registrations ⏰. the mobile and correspondent nodes also rekey whenever a rollover in the sequence number space is coming up soon 🔄. this shouldn't happen often, though, since the available sequence numbers are enough for up to 32768 correspondent registrations, each one made up of an early Binding Update message and a complete Binding Update message 🧮. the sequence number space allows an average rate of 22 correspondent registrations per minute without needing to rekey at any point during the 24-hour binding lifetime 💖.
6.6. Resource Exhaustion
okay so a CGA-based home address ownership proof protects against unauthenticated Binding Update messages, but it can also leave a correspondent node open to denial-of-service attacks 🥲. the reason is that it needs computationally expensive public-key cryptography 🔥. Enhanced Route Optimization only uses public-key cryptography for the first correspondent registration and, if and when rekeying is needed 🎯. it is RECOMMENDED that correspondent nodes also track how many processing resources they spend on CGA-based home address ownership verification, and that they reject new correspondent registrations involving public-key cryptography when those resources go over a predefined limit 🛡️. [2] digs deep into how feasible CGA-based resource exhaustion attacks are 📚.
6.7. IP Address Ownership of Correspondent Node 🦋
Okay bestie, so Enhanced Route Optimization lets a mobile node check a Binding Acknowledgment using the CGA property of the correspondent node's IP address, as long as that correspondent node actually has a CGA 🔐✨. The mobile node asks for this by putting a CGA Parameters Request option in the Binding Update it sends to the correspondent node. The correspondent node replies by adding its CGA parameters and signature to the Binding Acknowledgment, using CGA Parameters and Signature options 💅.
Proving that the correspondent node owns its IP address keeps the mobile node from accepting a spoofed Binding Acknowledgment, and from storing the permanent home keygen token that came inside it for later correspondent registrations 🚫. If that happened, it would be a whole denial-of-service situation 😭. The mobile node couldn't run any binding updates with that token, which is giving "stuck forever" energy 💀. To help with this, Enhanced Route Optimization recommends renewing a permanent home keygen token when correspondent registrations keep failing. That way mobile nodes can recover from denial-of-service attacks that use spoofed permanent home keygen tokens 🌸.
This attack is kind of limited by where the attacker has to be 📍. A Binding Update that asks a correspondent node for a permanent home keygen token gets authenticated using the CGA property of the mobile node's home address 🏠. That authentication involves a home address test, which gives the mobile node a home keygen token. The mobile node uses that token to calculate the authenticator on its Binding Update 🔑. The mobile node also expects the returning Binding Acknowledgment to be calculated with that same home keygen token. So an attacker who wants to spoof a Binding Acknowledgment carrying a permanent home keygen token has to eavesdrop on the home address test 👀. That means the attacker has to be on the path from the correspondent node to the mobile node's home agent while the home address test is happening. And if the Binding Update asking for the permanent home keygen token is complete, its authenticator is also calculated using a care-of keygen token 🧩. The attacker would then also need to know that care-of keygen token to make a valid authenticator for the Binding Acknowledgment. To get it, the attacker has to be on the path from the correspondent node to the mobile node's current IP attachment, at the moment the correspondent node sends the care-of keygen token to the mobile node. That happens in a Care-of Test message, or in the Care-of Test option of a Binding Acknowledgment 📬.
Here's the thing though: a mobile node usually doesn't know whether a given correspondent node's IP address is a CGA 🤷♀️. So the mobile node has to be ready to receive a Binding Acknowledgment that has no CGA Parameters and Signature options, even after it sent a Binding Update with a CGA Parameters Request option. That behavior is required, but it can also enable downgrading attacks 😬. In one of these, an attacker sends a Binding Acknowledgment on the correspondent node's behalf with no CGA Parameters and Signature options, claiming the correspondent node's IP address isn't a CGA 🎭. Enhanced Route Optimization deals with this by telling mobile nodes to prefer Binding Acknowledgments that have valid CGA Parameters and Signature options over ones without them 🏆. This protects against downgrading attacks, unless the attacker can intercept the Binding Acknowledgments coming from the correspondent node 🛡️. Since the attacker needs to be on the home agent path at roughly the same time as described above, it might not be able to intercept those Binding Acknowledgments 🤞. Still, an attacker who can intercept them could already run a denial-of-service attack against the mobile node and the correspondent node anyway 🙈. That threat already exists on the non-mobile Internet, and it isn't specific to Enhanced Route Optimization 🌍.
External mechanisms might let the mobile node find out for certain whether a particular correspondent node's IP address is a CGA ✨. If it does, the mobile node can insist on an IP address ownership proof from the correspondent node. In that case, it would throw away any received Binding Acknowledgments that don't include valid CGA Parameters and Signature options 🗑️. One idea for telling standard IPv6 addresses apart from CGAs could be an extension to the Domain Name System 🧚.
7. Protocol Constants and Configuration Variables 🎀
[2] defines a CGA Message Type namespace. CGA applications pick CGA Message Type tags from that namespace to use in signature calculations 🧮. Enhanced Route Optimization uses this one constant, randomly generated CGA Message Type tag 🎲:
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13[1] caps the lifetime of bindings that correspondent nodes set up through the return routability procedure, using MAX_RR_BINDING_LIFETIME ⏳. Enhanced Route Optimization uses this same limit for bindings that are authenticated by proving the mobile node is reachable at its home address 🏡. But if a binding is authenticated through the CGA property of the mobile node's home address, the lifetime gets the more generous constant MAX_CGA_BINDING_LIFETIME 🥳:
MAX_CGA_BINDING_LIFETIME 86400 secondsCredit aging uses two configuration variables to slowly lower a mobile node's credit counter over time 📉. It is RECOMMENDED that a correspondent node uses the following values 💜:
CreditAgingFactor 7/8
CreditAgingInterval 5 seconds8. IANA Considerations 📋
This document defines the following six new mobility options. They must be assigned type values from the mobility option numbering space of [1] 🔢:
CGA Parameters Request mobility option (11)CGA Parameters mobility option (12)Signature mobility option (13)Permanent Home Keygen Token mobility option (14)Care-of Test Init mobility option (15)Care-of Test mobility option (16)
This document also allocates four new status codes for Binding Acknowledgment messages 🌈:
"Permanent home keygen token unavailable" (147)"CGA and signature verification failed" (148)"Permanent home keygen token exists" (149)"Non-null home nonce index expected" (150)
The values for these status codes must all be greater than or equal to 128. That number means the receiving correspondent node rejected the respective Binding Update 🙅♀️.
This document also defines a new 128-bit value under the CGA Message Type namespace [2] 🧁.
9. Acknowledgments 🫶
The authors want to thank Tuomas Aura, Gabriel Montenegro, Pekka Nikander, Mike Roe, Greg O'Shea, and Vesa Torvinen (listed in alphabetical order) for the valuable and interesting discussions about cryptographically generated addresses 💭.
The authors also want to thank Marcelo Bagnulo, Roland Bless, Zhen Cao, Samita Chakrabarti, Greg Daley, Vijay Devarapalli, Mark Doll, Lakshminath Dondeti, Francis Dupont, Lars Eggert, Eric Gray, Manhee Jo, James Kempf, Suresh Krishnan, Tobias Kuefner, Lila Madour, Vidya Narayanan, Mohan Parthasarathy, Alice Qinxia, and Behcet Sarikaya (listed in alphabetical order) for reviewing this document and its predecessors and leaving important comments 🙌.
Finally, the authors want to highlight that [15] pioneered the use of cryptographically generated addresses in Mobile IPv6 route optimization 👑. They also say this document is mostly made up of material from [16], [17], and [18], plus the contributions of those authors 💖.
10. References 📚
10.1. Normative References 🔒
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", IETF BCP 14, RFC 2119, March 1997.
[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447, February 2003.10.2. Informative References 🔍
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[6] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
IPv6", Proceedings of the IEEE Wireless Communications and
Networking Conference, IEEE, April 2006.
[8] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS
Defense Mechanisms", ACM SIGCOMM Computer Communication Review,
Vol. 34, No. 2, ACM Press, April 2004.
[9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension", Work in Progress, May 2004.
[10] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6
(CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,
Vol. 31, No. 2, April 2001.
[11] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Revised papers from the
International Workshop on Security Protocols, Springer-Verlag,
April 2002.
[12] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
in Cryptographically Generated Addresses (CGAs)", Work
in Progress, April 2007.
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
Static Shared Key", RFC 4449, June 2006.
[15] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", Work
in Progress, March 2002.
[16] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying
Cryptographically Generated Addresses to Optimize MIPv6 (CGA-
OMIPv6)", Work Progress, May 2005.
[17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
Updates for Mobile IPv6", Work in Progress, February 2004.
[18] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
"Credit-Based Authorization for Mobile IPv6 Early Binding
Updates", Work in Progress, May 2004.Authors' Addresses 🌷
Jari Arkko
Ericsson Research NomadicLab
FI-02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
EMail: chvogt@tm.uka.de
Wassim Haddad
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2, Canada
EMail: wassim.haddad@ericsson.comFull Copyright Statement ✨
Okay so, legal stuff time, bestie 💅 Copyright (C) The IETF Trust (2007). 🎀 This document is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 💜.
The whole thing is provided "AS IS" 🫶, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim all warranties 😭. That includes, but isn't limited to, any promise that using the information here won't infringe anyone's rights, plus any implied warranties of merchantability or fitness for a particular purpose 🙈.
Intellectual Property 🦋
Lowkey the IETF is staying neutral here 🌸. It doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach 🧚. It also doesn't say whether any license under those rights is available, and it hasn't independently gone looking for any of them 👀. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures sent to the IETF Secretariat are a thing 🍓. So are any assurances of licenses that might be offered, and the results of any attempt to get a general license or permission for implementers or users to use the proprietary rights 🔥. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 💖.
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard ✨. Send that info to the IETF at ietf-ipr@ietf.org 💌. Main character energy for transparency, honestly 👑.
Acknowledgement 🌈
Big thank you moment 🫶: funding for the RFC Editor function is currently provided by the Internet Society 💜⭐.
📦 where this page comes from
- ietf: rfc4866 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms