RFC 3776
Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents 🦋
Part 1 of 9, bestie, more coming 💖
RFC 3776 is a Standards Track document from the Network Working Group, dated June 2004. Its authors are J. Arkko (Ericsson), V. Devarapalli (Nokia Research Center), and F. Dupont (GET/ENST Bretagne). The title block doesn't list any RFCs it obsoletes or updates 👀
Status of this Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice 🎀
Copyright (C) The Internet Society (2004). 🌈
Abstract 🌸
So Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node 🔐 The Mobile IPv6 base document sets out the main requirements these nodes must follow. This document goes deeper into those requirements, shows the packet formats in use, describes suitable configuration procedures, and shows how implementations can process the packets in the right order 💅
Table of Contents 💜
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 401. Introduction ✨
okay so this doc shows how to use IPsec to lock down Mobile IPv6 [7] traffic between mobile nodes and home agents 🔐💖. In Mobile IPv6, a mobile node is always supposed to be reachable at its home address, whether it's chilling on its home link or out exploring somewhere else 🦋. The home address is an IP address the mobile node gets from its home subnet prefix on its home link. While it's home, packets sent to that address get routed to its home link 🏠.
When it's on some foreign link away from home, it's also reachable at a care-of address 🧳. That's an IP address with a subnet prefix from that particular foreign link. The connection between a home address and a care-of address is called a "binding" 💅. While away, the mobile node registers its primary care-of address with a router on its home link and asks that router to become its "home agent" 🎀. It does this by sending a "Binding Update" message to the home agent, and the home agent replies with a "Binding Acknowledgement" message ✨.
Any other nodes talking to a mobile node are "correspondent nodes" 🫶. Mobile nodes can tell correspondent nodes where they currently are, again using Binding Updates and Acknowledgements. There's also a return routability test between the mobile node, home agent, and correspondent node, which authorizes the binding to be set up 👑. Packets between the mobile node and a correspondent node either get tunneled through the home agent, or go direct if the correspondent has a binding for the mobile node's current location 🌸.
Mobile IPv6 tunnels payload packets between the mobile node and home agent in both directions, using IPv6 encapsulation [6]. Wherever those tunnels need to be secured, they get swapped out for IPsec tunnels [2] 🔒.
Mobile IPv6 also supports reconfiguring the home network, where home subnet prefixes can change over time. Mobile nodes learn about new home subnet prefixes through "prefix discovery" 🧚.
This doc is about security for the control traffic between the mobile node and home agent. If that traffic isn't protected, mobile nodes and correspondent nodes are open to man-in-the-middle, hijacking, passive wiretapping, impersonation, and denial-of-service attacks 💀. Third parties can also get hit by denial-of-service attacks, for instance if an attacker could redirect the traffic flowing through the home agent to an innocent third party 😭. These attacks are covered in more detail in Section 15.1 of the Mobile IPv6 base specification [7].
To avoid all this, the base specification uses IPsec Encapsulating Security Payload (ESP) [3] to protect control traffic between the home agent and the mobile node. That control traffic is made up of various messages carried by the Mobility Header protocol in IPv6 [5]. It shows up in these forms:
- Binding Update and Acknowledgement messages exchanged between the mobile node and the home agent, as described in Sections 10.3.1, 10.3.2, 11.7.1, and 11.7.3 of the base specification [7].
- Return routability messages Home Test Init and Home Test that pass through the home agent on their way to a correspondent node, as described in Section 10.4.6 of the base specification [7].
- ICMPv6 messages exchanged between the mobile node and the home agent for prefix discovery, as described in Sections 10.6 and 11.4 of the base specification [7].
The nodes may also optionally protect payload traffic passing through the home agent, as described in Section 5.5 of the base specification [7]. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection support is required 🧠.
The control traffic between the mobile node and home agent needs message authentication, integrity, correct ordering, and anti-replay protection 🛡️. The mobile node and the home agent must have an IPsec security association to protect this traffic. IPsec doesn't provide correct ordering of messages, so ordering is handled by a sequence number in the Binding Update and Binding Acknowledgement messages. The sequence number in the Binding Updates also gives a bit of protection, but it's not perfect. It fails in some scenarios, for example if the Home Agent loses its Binding Cache state 😬. Full protection against replay attacks is only possible when IKE is used.
Be super careful when using IKE [4] to set up security associations for Mobile IPv6 home agents 🚨. The right kinds of addresses have to be used for transporting IKE. This matters because you want to avoid circular dependencies, where a Binding Update triggers the need for an IKE exchange that can't finish until that same Binding Update is complete 🙈.
The Mobile IPv6 base document defines the main requirements that mobile nodes and home agents must follow when securing this traffic. This document goes deeper on those requirements, shows the packet formats in use, describes suitable configuration procedures, and shows how implementations can process the packets in the right order 💅.
We start by showing the required wire formats for protected packets in Section 3. Section 4 describes the rules that associated Mobile IPv6, IPsec, and IKE implementations must observe. Section 5 covers how to configure either manually keyed IPsec security associations or IKE to set them up automatically. Section 6 shows examples of how packets are processed within the nodes 🧚.
All implementations of the Mobile IPv6 mobile node and home agent MUST support at least the formats described in Section 3 and obey the rules in Section 4 👑.
The configuration and processing sections are informative, and should only be considered as one possible way of providing the required functionality 🌈.
Note that where this document says a feature MUST be supported and SHOULD be used, that means all implementations must be capable of using the specified feature. There may still be cases where, for instance, a configuration option disables use of the feature in a particular situation 🫶.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 📖✨.
3. Packet Formats
3.1. Binding Updates and Acknowledgements
When the mobile node is away from home, the BUs it sends to the home agent MUST support at least the following headers, in this order 🧳:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
Mobility header
Binding Update
Alternate Care-of Address option (care-of address)Note that the Alternate Care-of Address option is used to make sure the care-of address is protected by ESP 🔐. The home agent treats the address in this option as the current care-of address for the mobile node. The home address isn't protected by ESP directly, but using a specific home address with a specific security association is required by policy 💅.
The Binding Acknowledgements sent back to the mobile node when it's away from home MUST support at least the following headers, in this order 🎀:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
Mobility header
Binding AcknowledgementWhen the mobile node is at home, the rules above change, because the mobile node can use its home address as its source address 🏠. This usually happens for the de-registration Binding Update when the mobile is heading back home. In this situation, the Binding Updates MUST support at least the following headers, in this order 🌸:
IPv6 header (source = home address,
destination = home agent)
ESP header in transport mode
Mobility header
Binding UpdateThe Binding Acknowledgement messages sent to the home address MUST support at least the following headers, in this order ✨:
IPv6 header (source = home agent,
destination = home address)
ESP header in transport mode
Mobility header
Binding Acknowledgement3.2. Return Routability Signaling 💌
okay bestie, so when the Home Test Init messages get tunneled to the home agent and IPsec is protecting them, they MUST support at least these headers, in this exact order 🎀
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test InitThis format assumes the mobile node's current care-of address is used as the outer header destination address in the security association. As covered in Section 4.3, that means the home agent has to update the destination address whenever the mobile node moves 🦋 The policy entries and security association selectors stay the same though, because the inner packets don't change when the mobile node moves. literally so clean ✨
Note that there are trade-offs between using care-of addresses as the destination addresses and using the home address with an extra Home Address destination option and/or Routing header on the packets 🤔 Why we require support for at least the care-of address case is discussed in Section 7, so go read that if you're curious 🧚
Now the other direction. When the Home Test messages tunneled from the home agent are protected by IPsec, they MUST support at least these headers, also in this order:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home TestThis one is giving "the destination moves with you" energy 🌸 The packets rely on the tunnel destination changing for the mobile node as it moves. The home agent's address stays put, but the mobile node's address changes as it moves, almost like the security association's outer header destination address changed. When the mobile node picks up a new care-of address, it also picks up a new source address for its outgoing tunnel packets. The home agent accepts packets sent like this, because the outer source address in tunnel packets isn't checked under the rules in RFC 2401. (We note, however, that some implementations are known to make source address checks. 👀) If you want the whole story on outer tunnel header source addresses, check Section 5.1.2.1 of RFC 2401 [2].
Also, the home agent requires the packets to be authenticated no matter what the source address does. So the "new" sender has to have the same keys for the security association that it had at the previous location 🔑 That's how the home agent knows it's the same entity even though the addresses keep changing. iconic 💅
The home agent side is a bit more complicated, ngl. The home agent has stored the previous care-of address in its Security Association Database as the outer header destination address. When IKE is in use, the mobile node runs it on top of its current care-of address, and the resulting tunnel-mode security associations use the same addresses that IKE ran over. So for the home agent to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had changed the outer header destination address in the security association used for this protection 😭 This means one security association can be reused across multiple locations, and there's no need for new configuration or re-establishing the IKE phases on every movement. Section 5.2.2 explains the security policy and security association database entries needed to make this work 🫶
3.3. Prefix Discovery 🍓
If IPsec protects prefix discovery, requests for prefixes from the mobile node to the home agent MUST support at least these headers, in this order:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
ICMPv6
Mobile Prefix SolicitationAgain, if IPsec is in use, solicited and unsolicited prefix information advertisements from the home agent to the mobile node MUST support at least these headers, in this order:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
ICMPv6
Mobile Prefix Advertisement3.4. Payload Packets 🧚
If IPsec protects payload packets tunneled to the home agent from the mobile node, we use a format similar to the one in Section 3.2. The difference is that instead of the MobilityHeader, these packets may contain any legal IPv6 protocol(s) 🌈
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Any protocolAnd when the payload packets are tunneled from the home agent to the mobile node with ESP encapsulation, they MUST support at least these headers, in this order:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Any protocol4. Requirements ✨
This section describes mandatory rules for all Mobile IPv6 mobile nodes and home agents. These rules are necessary so that IPsec communications can still work despite movements, so that security is sufficiently guaranteed, and so that packets are processed in the correct order 💜
The rules in the following sections apply only to communications between home agents and mobile nodes. They should not be taken as requirements on how IPsec in general is used by mobile nodes. (not the whole internet, just this relationship 💅)
4.1. Mandatory Support 🔥
The following requirements apply to both home agents and mobile nodes:
- Manual configuration of IPsec security associations MUST be supported. The configuration of the keys is expected to take place out-of-band, for instance at the time the mobile node is configured to use its home agent 🔑
- Automatic key management with IKE [4] MAY be supported. Only IKEv1 is discussed in this document. Other automatic key management mechanisms exist and will appear beyond IKEv1, but this document does not address the issues related to them 🌸
- ESP encapsulation of Binding Updates and Acknowledgements between the mobile node and home agent MUST be supported and MUST be used. no notes, this one is non-negotiable 🫶
- ESP encapsulation of the Home Test Init and Home Test messages tunneled between the mobile node and home agent MUST be supported and SHOULD be used. 🦋
- ESP encapsulation of the ICMPv6 messages related to prefix discovery MUST be supported and SHOULD be used. 🍓
- ESP encapsulation of the payload packets tunneled between the mobile node and home agent MAY be supported and used. 🧚
- If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported for those protocols. 👑
4.2. Policy Requirements 💅
okay so these requirements apply to both home agents and mobile nodes 🎀
- As required in the base specification [7], when a packet destined to the receiving node gets matched against IPsec security policy or selectors of a security association, an address showing up in a
Home Addressdestination option counts as the source address of the packet 🦋
ngl the home address option shows up before the IPsec headers, so Section 11.3.2 of the base specification describes one possible way to handle that. You can run the IPsec policy operations either before the packet has been changed by the Mobile IPv6 rules, or after it's been brought back to its normal form after Mobile IPv6 processing 🧚 Basically, the processing of the Home Address option is treated as a fixed transformation of the packets that doesn't affect IPsec processing ✨
- Similarly, a home address inside a Type 2 Routing header destined to the receiving node counts as the destination address of the packet when it's matched against IPsec security policy or selectors of a security association 🌸
Similar implementation considerations apply to Routing header processing, the same way they were described above for the Home Address destination option 💖
- When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent 🔒 For instance, you can get this by defining the security policy database entries specifically for the tunnel interface. So the policy entries aren't applied to all traffic on the physical interface(s) of the nodes. They're only applied to traffic that enters this tunnel 🫶
- The authentication of mobile nodes MAY be based either on machine or user credentials. Here's the tea: multi-user operating systems usually let all users of a node use any of the IP addresses assigned to that node, which limits how much the home agent can restrict a home address to one particular user in that kind of environment 👑 So where user credentials are used in a multi-user environment, the configuration should authorize all users of the node to control all home addresses assigned to the node 💅
- When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address gets torn down 😭 The security policy entries that were used to protect tunneled traffic between the mobile node and the home agent MUST be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted, depending on how they were created. If they were created dynamically using IKE, they're automatically deleted when they expire. If they were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again 🍓 The security associations protecting Binding Updates and Acknowledgements, and prefix discovery, SHOULD NOT be deleted, because they don't depend on care-of addresses and can be used again 🥹
The following rules apply to mobile nodes 📱
- The mobile node MUST use the
Home Addressdestination option in Binding Updates and Mobile Prefix Solicitations, sent to the home agent from a care-of address 🎀 - When the mobile node receives a changed set of prefixes from the home agent during prefix discovery, it needs to configure new security policy entries, and it may need to configure new security associations. It's outside the scope of this specification to discuss automatic methods for this 🙈
The following rules apply to home agents 🏠
- The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node, again because the home address has to be visible when the policy checks are made 👀
- It's necessary to avoid the possibility that a mobile node could use its security association to send a Binding Update on behalf of another mobile node using the same home agent 🚫 To do this, the security policy database entries MUST unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent when manually keyed IPsec security associations are used. When dynamic keying is used, the security policy database entries MUST unequivocally identify the IKE phase 1 credentials that can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address 🔑 How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used 🧚
- When the set of prefixes advertised by the home agent changes, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this, if new home addresses are required 🌈
4.3. IPsec Protocol Processing 🔐
okay this part is for both home agents and mobile nodes 🫶
- When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode, and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection 💜
Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care is needed when selecting suitable encryption algorithms for ESP, though ⚠️ Currently available integrity protection algorithms are generally considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, though 💀 This is especially problematic when IPsec security associations are configured manually, since the same key is used for a long time 🙈
- Tunnel mode IPsec ESP MUST be supported and SHOULD be used for protecting packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied 🛡️
Note that the return routability procedure involves two message exchanges from the mobile node to the correspondent node. The purpose of these exchanges is to make sure the mobile node is live at the claimed home and care-of addresses 🦋 One of the exchanges is sent directly to and from the correspondent node, while the other is tunneled through the home agent. If an attacker is on the mobile node's link and the mobile node's current link is an unprotected wireless link, the attacker would be able to see both sets of messages and launch attacks based on them (these attacks are discussed further in Section 15.4 of the base specification [7].) One way to prevent the attack is to make sure the packets tunneled through the home agent are encrypted 🔒
Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementation mechanisms 🧚 In the case of IPsec tunnel mode, using IP-in-IP encapsulation followed by IPsec transport mode encapsulation may also be possible ✨
The following rules apply to mobile nodes 📱
- When ESP is used to protect Binding Updates, there is no protection for the care-of address which appears in the IPv6 header outside the area protected by ESP. It's important for the home agent to verify that the care-of address has not been tampered with. If that happened, the attacker would have redirected the mobile node's traffic to another address 😱 To prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register. In that case no Alternate Care-of Address option is needed, as described in Section 3.1 🌸
When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address 💖 The mobile node starts using a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address. Similarly, it starts using the new address as the required destination address of tunneled packets received from the home agent 🦋
The following rules apply to home agents 🏠
- When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations 🌈 The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. Similarly, the home agent starts expecting the new source address in the tunnel packets received from the mobile node 🎀
Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. It should be noted that the use of such an API and the address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec 🔐
⚠️ Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application, may result in security vulnerabilities. Please don't let that happen, bestie 😭💀
4.4. Dynamic Keying ✨
okay bestie, this section is all about dynamic keying 🔑 and it applies to BOTH home agents and mobile nodes 💖 (fr, it's giving "everyone's involved").
The following requirements apply to both home agents and mobile nodes:
- Anti-replay protection: if anti-replay protection is required, dynamic keying MUST be used. IPsec can only give you anti-replay protection when dynamic keying is in use, and that isn't always the case 🙈. IPsec also doesn't guarantee that packets show up in order, only that they haven't been replayed 😤. So the sequence numbers inside the Mobile IPv6 messages are what keep things in order. BUT if the 16 bit Mobile IPv6 sequence number space gets cycled through, or the home agent reboots and forgets its sequence number state, replay and reordering attacks become possible 💀. Dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can team up together to stop those attacks 🛡️.
- IKEv1 preshared secrets: if IKE version 1 is used with preshared secrets in main mode, it picks the shared secret based on the peer's IP address. With Mobile IPv6 though, that address might be a care-of address, and it doesn't tell you which mobile node is trying to contact the home agent 🤷♀️. So if preshared secret authentication is used in IKEv1 between the mobile node and the home agent, then aggressive mode MUST be used. Also, be careful with phase 1 identity selection 👀. When
ID_IPV6_ADDRIdentity Payloads are used, mapping identities to keys isn't unambiguous. (The next version of IKE may not have these limitations 🌸.)
Okay, so main mode and preshared secrets in IKE version 1 are well known to be tricky with dynamic addresses. With static addresses, there hasn't been a problem 🧚. With Mobile IPv6, though, running IKE to the home agent over care-of addresses is a problem even when the home address stays stable 😭. More about using care-of addresses this way is in Section 7 💜.
The following rules apply to mobile nodes:
- Care-of address source: in addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent.
- Home address identity: however, the IPsec security associations with the mobile node's home agent use home addresses. That means the IPsec security associations MUST be requested from the key management protocol using the home address of the mobile node as the client identity.
The security associations for protecting Binding Updates and Acknowledgements are requested for the Mobility header protocol in transport mode, and for specific IP addresses as endpoints. No other selectors are used. Similarly, the security associations for protecting prefix discovery are requested for the ICMPv6 protocol and the specific IP addresses, again without other selectors. Security associations for payload and return routability protection are requested for a specific tunnel interface and either the payload protocol or the Mobility header protocol, in tunnel mode. In this case one requested endpoint is an IP address and the other one is a wildcard, and there are no other selectors 🎀.
- IKEv1 endpoints: if the mobile node has used IKE version 1 to set up security associations with its home agent, it should follow the procedures discussed in Section 11.7.1 and 11.7.3 of the base specification [7] to work out whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established 🔄.
The following rules apply to home agents:
- IKEv1 endpoints (home agent side): if the home agent has used IKE version 1 to set up security associations with the mobile node, it should follow the procedures discussed in Section 10.3.1 and 10.3.2 of the base specification [7] to work out whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established ✨.
5. Example Configurations 🍓
In the following we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries needed to protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home agent 💅.
Section 5.1 introduces the format we use in the description of the SPD and the SAD. Section 5.2 describes how to configure manually keyed IPsec security associations without dynamic keying, and Section 5.3 describes how to use dynamic keying 🧠.
5.1. Format
The format used in the examples is as follows. The SPD description has the format
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>Where <node> represents the name of the node, and <spdentry> has the following format:
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |Where <condition> is a boolean expression about the fields of the IPv6 packet, <sa> is the name of a specific security association, and <pattern> is a specification for a security association to be negotiated via IKE [4]. The SAD description has the format
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>Where <node> represents the name of the node, and <sadentry> has the following format:
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association, <destination> is its destination, <ipsec-proto> is in our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule> is an expression which describes the IPsec selectors, i.e., which fields of the IPv6 packet must have which values 🎯.
We will be using an example mobile node in this section with the home address "home_address_1". The user's identity in this mobile node is "user_1". The home agent's address is "home_agent_1" 🏠.
5.2. Manual Configuration
5.2.1. Binding Updates and Acknowledgements
Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements 💌:
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MHIn the above, "MH" refers to the protocol number for the Mobility Header [7] 🦋.
5.2.2. Return Routability Signaling
In the following we describe the necessary SPD and SAD entries to protect return routability signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. In other words, the higher precedence entries must occur first in the RFC 2401 [2] ordered list of SPD entries 📋.
mobile node SPD OUT:
- IF interface = IPv6 IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MHThe security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves 🚚. It can be initialized to the home address before the mobile node has registered 🌷.
5.2.3. Prefix Discovery
In the following we describe some additional SPD and SAD entries to protect prefix discovery. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent, as IPsec may not have the ability to distinguish between different ICMPv6 types 🙈.
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5.
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA SA6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA SA6
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv65.2.4. Payload Packets ✨
Okay bestie, so there's also an extra, totally optional layer of protection you can add for tunneled payload packets 🎀 It works like the return routability protection we just did, but it needs a different value in the protocol field 💅 The SPD and SAD entries you need are below. The entries protecting Binding Updates and Acknowledgements, plus the ones protecting Home Test Init and Home Test messages, take precedence over these, so they win 👑
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = XNow, if multicast group membership control protocols like MLDv1 [9] or MLDv2 [11] need protecting, those packets may use a link-local address instead of the mobile node's home address 🌸 In that case you can leave source and destination as a wildcard, and the SPD entries will match purely on the interface and the protocol. For both MLDv1 and MLDv2, that protocol is ICMPv6 🧚
Stateful address autoconfiguration protocols such as DHCPv6 [10] run into similar problems 🙈 The same approach works for DHCPv6 too. Quick note: DHCPv6 uses the UDP protocol 🍓
Also, support for multiple layers of encapsulation (like ESP inside ESP) isn't required by RFC 2401 [2], and it's often problematic anyway 😭 So it's smart to avoid setting the protocol X in the entries above to either AH or ESP 🫶
5.3. Dynamic Keying 🌈
In this section we walk through an example configuration that uses IKE to negotiate security associations 💜
5.3.1. Binding Updates and Acknowledgements
Here's what the SPD looks like for protecting Binding Updates and Acknowledgements 🦋
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1We've left out the details of the proposed transforms, plus everything about the authentication method (like certificates), apart from naming the specific identity that has to be used 🎀
We require IKE version 1 to run using the care-of addresses, but it still negotiates IPsec SAs that use home addresses 💅 The extra condition the home agent SPD sets, that the peer phase 1 identity must be "user_1", must be verified by the home agent 👑 The whole point is to make sure an IKE phase 2 negotiation for a given user's home address can not be requested by some other user 🙅♀️ On the mobile node side, we just set our local identity to "user_1" 🫶
Honestly, these checks mean the home agent's configuration is user-specific: every user or home address needs its own configuration entry 😭 You could cut down on the config work by using certificates that have home addresses in the Subject AltName field. But it's not clear that every IKE implementation lets one address carry the IKE negotiations when a different address shows up in the certificates 🤔 And even then, that approach would still need user-specific tasks at the certification authority 💀
5.3.2. Return Routability Signaling
Protection for return routability signaling can be set up in a similar way to what we just did ✨
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1The security association from the home agent to the mobile node uses the current care-of address as its destination 🦋 As we covered earlier, that address gets updated in the SAD as the mobile node moves 🌈 You can write the SPD entries using the home address (like above), as long as the care-of address update in the SAD also happens when the security associations are created 💖
5.3.3. Prefix Discovery
Next up, some extra SPD entries to protect prefix discovery with IKE 🧚 (Heads up: when actual new prefixes get discovered, you may need to enter new manually configured SPD entries to specify the authorization policy for the resulting new home addresses 👀)
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_15.3.4. Payload Packets
Protection for payload packets works much like protection for return routability signaling 🌸 Same as the manually keyed case, these SPD entries have lower priority than the ones above 🎀
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_16. Processing Steps within a Node 🧚
6.1. Binding Update to the Home Agent 🦋
Step 1. First, at the mobile node, the Mobile IPv6 module builds this packet 💅
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding UpdateStep 2. This packet gets matched against the IPsec SPD on the mobile node, and we make a note that IPsec must be applied 👀
Step 3. Next, we add the necessary Mobile IPv6 options, but we don't change the addresses yet. This follows Section 11.3.2 of the base specification [7] 🌈 That gives us:
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding UpdateStep 4. Finally, the IPsec headers get added and the necessary authenticator values get calculated 🔥
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding UpdateHere, spi_a is the SPI value that was either configured manually or agreed upon in an earlier IKE negotiation 💜
Step 5. Right before sending, the addresses in the IPv6 header and the Destination Options header get changed 🎀
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding Update6.2. Binding Update from the Mobile Node ✨
Step 1. Okay, bestie, the home agent gets this packet first. The outer IPv6 header has the care-of address as the source and the home agent as the destination, then comes a Destination Options header with the Home Address option, an ESP header with SPI = spi_a, and finally the Binding Update in the Mobility header. 🦋
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
Mobility header
Binding UpdateStep 2. The Home Address option gets processed first, and that swaps things around. The source becomes the home address and the Home Address option now holds the care-of address. Main character energy 💅
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = spi_a)
Mobility header
Binding UpdateStep 3. Next up is the ESP header, which gets processed and removed. That leaves:
IPv6 header (source = home address,
destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding UpdateStep 4. This packet matches the policy for this security association, which is source = home address, destination = home agent, and proto = MH. It's giving "all checks passed" 🫶
Step 5. Mobile IPv6 processes the Binding Update, and the Binding Update gets delivered to the Mobile IPv6 module. Iconic 👑
Step 6. If there are any security associations in the security association database that protect return routability or payload packets for this mobile node, those security associations get updated with the new care-of address. Everything stays in sync, no cap 🌸
6.3. Binding Acknowledgement to the Mobile Node 💖
Step 1. Mobile IPv6 makes the following packet, with the home agent as the source and the home address as the destination, carrying a Binding Acknowledgement in the Mobility header.
IPv6 header (source = home agent,
destination = home address)
Mobility header
Binding AcknowledgementStep 2. This packet matches the IPsec policy entries, and we remember that IPsec has to be applied. Noted, bestie 🧚
Step 3. Then we add the necessary Route Headers, but we don't change the addresses yet. This is described in Section 9.5.4 of the base specification [7]. The result looks like this:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding AcknowledgementStep 4. Now we apply IPsec:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding AcknowledgementStep 5. Finally, right before the packet goes out, we change the addresses in the IPv6 header and the Routing header. The destination becomes the care-of address, and the Routing header now holds the home address. Glow-up complete ✨
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgement6.4. Binding Acknowledgement from the Home Agent 🌈
Step 1. The mobile node receives this packet, with the home agent as the source and the care-of address as the destination. It has a Routing header holding the home address, an ESP header with SPI = spi_b, and a Binding Acknowledgement.
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = spi_b)
Mobility header
Binding AcknowledgementStep 2. After the Routing header is processed, the packet turns into this:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
Mobility header
Binding AcknowledgementStep 3. Next, the ESP header gets processed, resulting in:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding AcknowledgementStep 4. This packet matches the policy for this security association, which is source = home agent, destination = home address, and proto = MH. Vibes check out 💜
Step 5. The Binding Acknowledgement gets delivered to the Mobile IPv6 module. Done and dusted 🎀
6.5. Home Test Init to the Home Agent 🍓
Step 1. The mobile node builds a Home Test Init message. The IPv6 header has the home address as the source and the correspondent node as the destination, and the Mobility header carries the Home Test Init.
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test InitStep 2. Mobile IPv6 decides this packet should go through the tunnel to the home agent. Tunnel arc unlocked 🚇
Step 3. The packet gets matched against the IPsec policy entries for the interface, and we find that IPsec needs to be applied.
Step 4. Now we add the IPsec tunnel mode headers. Quick note: the source address for the tunnel packet is the care-of address. The result looks like this:
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test InitStep 5. The packet goes directly to the home agent using IPsec encapsulation. Straight to the source, no detours 🫶
6.6. Home Test Init from the Mobile Node 🧚
Step 1. The home agent receives this packet, which has the care-of address as the source and the home agent as the destination. Inside the ESP header with SPI = spi_c sits an inner IPv6 header with the home address as the source and the correspondent node as the destination, plus the Home Test Init.
IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test InitStep 2. IPsec processing runs, and what's left is:
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test InitStep 3. The resulting packet matches the policy required for this security association, so the packet can be processed further. ✨
Step 4. The packet then gets forwarded to the correspondent node. Delivered 💅
6.7. Home Test to the Mobile Node 🦋
Step 1. The home agent gets a Home Test packet from the correspondent node. The source is the correspondent node, the destination is the home address, and the Mobility header carries the Home Test Init.
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test InitStep 2. The home agent figures out that this packet is destined for a mobile node that's away from home, so it decides to tunnel it. Tunnel time 🌸
Step 3. The packet matches the IPsec policy entries for the tunnel interface, and we note that IPsec needs to be applied.
Step 4. IPsec gets applied, which makes a brand new packet. The home agent must keep track of the location of the mobile node, and update the tunnel endpoint address in the security association(s) accordingly. Stay on top of that location, bestie 👑
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test InitStep 5. The packet goes directly to the care-of address using IPsec encapsulation. 🫶
6.8. Home Test from the Home Agent 💜
Step 1. The mobile node receives this packet. The outer header has the home agent as the source and the care-of address as the destination, then comes an ESP header with SPI = spi_d, and inside that is an IPv6 header with the correspondent node as the source and the home address as the destination, plus the Home Test Init.
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test InitStep 2. IPsec gets processed, which leaves:
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test InitStep 3. This matches the policy required for this security association, where source = any and destination = home address. Matched and ready 🍓
Step 4. The packet is handed over to Mobile IPv6 processing. Next stop 🎀
6.9. Prefix Solicitation Message to the Home Agent 🌈
This procedure is similar to the one presented in Section 6.1. Same energy, different message 💖
6.10. Prefix Solicitation Message from the Mobile Node ✨
This procedure is similar to the one presented in Section 6.2. Déjà vu, but make it iconic 👑
6.11. Prefix Advertisement Message to the Mobile Node 🧚
This procedure is similar to the one presented in Section 6.3. Copy, paste, slay 💅
6.12. Prefix Advertisement Message from the Home Agent 🦋
This procedure is similar to the one presented in Section 6.4. Same vibe 🫶
6.13. Payload Packet to the Home Agent 🌸
This procedure is similar to the one presented in Section 6.5. Tunnel, but for payload 🚇
6.14. Payload Packet from the Mobile Node 💜
This procedure is similar to the one presented in Section 6.6. 🔥
6.15. Payload Packet to the Mobile Node 🍓
This procedure is similar to the one presented in Section 6.7. 🙈
6.16. Payload Packet from the Home Agent 🎀
This procedure is similar to the one presented in Section 6.8. Consistency is everything 💅
6.17. Establishing New Security Associations 🌈
Step 1. The mobile node wants to send a Binding Update to the home agent. It has an IPv6 header with the home address as the source and the home agent as the destination, and the Mobility header carries the Binding Update.
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding UpdateStep 2. There's no existing security association to protect this Binding Update, so the mobile node starts IKE. The IKE packets are shown in the examples below. The first one is an IKE packet sent from the mobile node, and the second one comes from the home agent. The examples also show that the phase 1 identity for the mobile node is a FQDN. Identity crisis? Nope, it's an FQDN 🙈
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDii = ID_FQDN mn123.ha.net ...IPv6 header (source = home agent
destination = care-of address)
UDP
IKE
... IDir = ID_FQDN ha.net ...Step 3. IKE phase 1 wraps up, and phase 2 kicks off to request security associations for protecting traffic between the mobile node's home address and the home agent. These addresses get used as selectors. This takes sending and receiving more IKE packets. The example below shows one packet sent by the mobile node and another sent by the home agent. It also shows that the phase 2 identity for the mobile node is the mobile node's home address. Phase 2 is giving selector drama 🔥
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDci = ID_IPV6_ADDR home address ...IPv6 header (source = home agent,
destination = care-of address)
UDP
IKE
... IDcr = ID_IPV6_ADDR home agent ...Step 4. The remaining steps are the same as the ones in Section 6.1. Rewatch that section if you need a refresher 🦋
6.18. Rekeying Security Associations 💖
Step 1. The mobile node and the home agent already have security associations. Either side can decide at any time that the security associations need rekeying, for example because the specified lifetime is almost up. ⏰
Step 2. Mobility header packets sent during rekeying may be protected by the existing security associations. Bodyguards for the messages 🛡️
Step 3. When rekeying finishes, new security associations get established. In practice, there's a window where an old, about-to-expire security association and the newly established one both exist at the same time. The new ones should be used as soon as they become available. Upgrade on the spot 🌸
Step 4. A notification about the deletion of the old security associations arrives. After this, only the new security associations can be used. Old ones are retired 👑
Note that there's no requirement tying the existence of the IPsec and IKE security associations to the existence of bindings. You don't have to delete a security association when a binding is removed, since a new binding might show up soon. Lowkey smart 🧚
Since cryptographic acceleration hardware may only be able to handle a limited number of active security associations, security associations may be deleted via IKE to keep the number of active cryptographic contexts to a minimum. Those deletions should not be interpreted as losing contact with the peer, and they're not a reason to remove a binding. Instead, if more traffic needs to be sent, it's better to bring up another security association to protect it. Hardware has limits, and we respect them 💅✨
6.19. Movements and Dynamic Keying ✨
okay so this section walks through what happens when the mobile node moves around while it's using IKE-based security associations 🚗💨 In the starting state, the mobile node isn't registered anywhere and has no security associations with the home agent yet. Whether the peers can move their IKE endpoints over to new care-of addresses decides how Step 9 and Step 10 play out, so pay attention there 👀
Step 1. The mobile node with home address A moves to care-of address B.
Step 2. The mobile node runs IKE from care-of address B to the home agent and sets up a phase 1. The home agent can only act as the responder here, since it doesn't know where the mobile node is yet 🫶
Step 3. Protected by that phase 1, the mobile node sets up a pair of security associations to protect Mobility Header traffic to and from home address A 🔐
Step 4. The mobile node sends a Binding Update and gets a Binding Acknowledgement back, using the security associations from Step 3 💌
Step 5. The mobile node sets up a pair of security associations for protecting return routability packets. These are in tunnel mode, and their endpoint on the mobile node side is care-of address B. For the sake of this example, this step uses the phase 1 connection from Step 2. Multiple phase 1 connections are also possible 🧚
Step 6. The mobile node uses the security associations from Step 5 to run return routability 🦋
Step 7. The mobile node moves somewhere new and picks up a new care-of address C 🚀
Step 8. The mobile node sends a Binding Update and gets a Binding Acknowledgement back, using the security associations from Step 3. The home agent makes sure the next packets sent over the security associations from Step 5 go to the new care-of address as their destination address. It's like the outer header destination address in the security association changed 🪄
Step 9. If the mobile node and the HA are able to change the IKE endpoints, they switch the address over to C. If they can't, both nodes tear down their phase 1 connections that were built on top of care-of address B and set up a fresh IKE phase 1 on top of care-of address C. This ability to change the IKE phase 1 endpoints is signalled by setting the Key Management Mobility Capability (K) flag [7] in the Binding Update and Binding Acknowledgement messages 💜
Step 10. If a new IKE phase 1 connection got set up after the move, the MN won't be able to receive any notifications that were delivered over the old IKE phase 1 security association 😭 Notifications delivered over the new security association are received and processed normally. If the mobile node and HA were able to update the IKE endpoints, they can keep using the same IKE phase 1 connection 🌸
7. Implementation Considerations 🛠️
7.1. IPsec 🔐
okay so packet formats and header ordering from Section 3 are a must-have, but implementations can also support other formats if they want 💅 The catch is that using formats that aren't required here can mess up how the peer processes your packets (like silently throwing them away 💀), unless someone has checked off-line that the peer supports them. That check can happen at the same time the security association parameters are agreed on. Sometimes basic IPv6 specs call for supporting options not covered here. In those cases the check might not be needed, as long as the peer fully supports the relevant IPv6 specs. Still, this document makes no claims about whether those other formats are valid in the context of Mobile IPv6 🙈 Systems that support Mobile IPv6 have also probably been tested more thoroughly with the required formats, which is nice.
We picked an encapsulation format for return routability and payload packet protection, and it only works if the destination of the IPsec packets sent from the home agent can change as the mobile node moves 🦋 One big reason for this choice is that it gets rid of the twenty four bytes of overhead you'd get when a home address option or routing header is added to the tunneled packet. That overhead wouldn't matter much for return routability packets, but it would add extra overhead if IPsec were protecting the tunneling of payload packets to the home agent. That overhead could be a big deal for real-time traffic 🎀 Shorter packet formats for any traffic need suitable APIs to exist, so we went with requiring support for the shorter packet formats for both payload and return routability packets 💖
To make the care-of address the destination address on the mobile node side, the home agent has to act as if the outer header destination address in the security association to the mobile node changed when the mobile node moved ✨ Implementations get to pick whatever method they like to make that change. Options include calling an API into the IPsec implementation to change the security association parameters, removing the security association and installing a new one, or modifying the packet after it's gone through IPsec processing 🪄 The only real requirement is that after a new binding is registered at the home agent, the next IPsec packets sent on this security association get addressed to the new care-of address 🫶
We picked policy entries that are specific to a tunnel interface. So implementations have to treat the Home Agent - Mobile Node tunnel as its own interface, one that IPsec SPDs can be based on 🌈 Another twist with IPsec processing on a tunnel interface is that it needs access to the BITS implementation before the packet actually goes out 👀
7.2. IKE 🗝️
We decided that a dynamic key management protocol must be able to make an authorization decision for IPsec security association creation with addresses that are different from the ones the key management protocol is running on 💅 We expect this to usually be done by configuring the allowed combinations of phase 1 user identities and home addresses 🧚
When certificate authentication is used, IKE fragmentation can come up. That can happen when certificate chains are used, or even with single certificates if they're large 😬 Lots of firewalls don't handle fragments properly and may drop them. Routers along the path may also discard fragments after the first one, since those usually don't contain full IP headers that can be compared against an access list 🚧 Wherever fragmentation happens, the endpoints won't always be able to set up a security association 💀
Thankfully, a typical Mobile IPv6 deployment uses short certificate chains, since the mobile node is talking directly to its home network 🏠 When the problem does show up, it can be hard to replace the firewalls or routers with gear that handles fragments properly, especially away from home. Storing the peer certificates locally, or getting them some other way, might help 🫶
7.3. Bump-in-the-Stack 🧩
Mobile IPv6 puts high requirements on the so-called Bump-In-The-Stack (BITS) implementation model of IPsec. Since Mobile IPv6-specific changes to the packets are needed before or after IPsec processing, the BITS implementation also has to handle some mobility-related tasks. That can make the implementation more complicated, even if it already does some IP-layer work (like fragmentation) 😅
Specifically, Bump-in-the-Stack implementations may have to deal with the following issues:
- Processing the Home Address destination option and Routing header type 2 into a form suitable for IPsec processing to take place. This is needed, among other things, for the security association and policy lookups. It's pretty straightforward, but the required processing may have a hardware effect in BITS implementations if they use hardware support beyond the cryptographic operations 🔧
- Detecting packets sent between the mobile node and its home agent that use IPv6 encapsulation 👀
- Offering the necessary APIs for updating the IPsec and IKE security association endpoints 🪄
8. IANA Considerations 📋
No IANA actions are necessary based on this document 🌸 IANA actions for the Mobile IPv6 protocol itself have been covered in [7].
9. Security Considerations 🚨
okay this part is SO important 😭 The Mobile IPv6 base specification [7] requires strong security between the mobile node and the home agent 🔐 This memo talks about how that security can be arranged in practice, using IPsec. The security considerations for this are documented in the base specification, including a discussion of what it means to use manual keying versus dynamic keying 💜
10. References 📚
10.1. Normative References 💖
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
- [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
10.2. Informative References 🌈
- [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
11. Acknowledgements 🫶
the authors want to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel Montenegro, Steven Kent, and Santeri Paavolainen for the interesting discussions in this problem space 💖
12. Authors' Addresses 💌
Jari Arkko
Ericsson
02420 Jorvas
Finland
EMail: jari.arkko@ericsson.comVijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
USA
EMail: vijayd@iprg.nokia.comFrancis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
EMail: Francis.Dupont@enst-bretagne.fr13. Full Copyright Statement ✨
okay bestie, this is the legal bit at the very end, and it's giving "we're not responsible if this goes wrong" 💅 but it still matters, so let's get through it 🫶
Copyright is held by The Internet Society (2004) 📝. This document is subject to the rights, licenses and restrictions in BCP 78, and apart from what BCP 78 says, the authors keep all their rights 🦋.
This document and everything in it is provided on an "AS IS" basis 🙈. The contributor, the organization they represent or are sponsored by (if any), The Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied 💀. That includes no warranty that using the information here won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose. Totally no guarantees, babe 😭.
Intellectual Property 🔥
The IETF 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 a license for those rights is available, and it hasn't independently gone looking for any such rights either 🌸. If you want to know how rights work for RFC documents, check BCP 78 and BCP 79 📚.
Copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, and the results of any attempt to get a general license or permission for implementers or users of this specification can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 💜.
The IETF invites anyone to tell it about 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 ✨.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by The Internet Society 👑. And that's a wrap on RFC 3776, bestie 🫶💖
📦 where this page comes from
- ietf: rfc3776 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms