RFC 4877
Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
RFC 4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture 🦋
Okay bestie, so this is RFC 4877 💖 It's a Standards Track doc from the Network Working Group, published in April 2007. The main authors are V. Devarapalli at Azaire Networks and F. Dupont at CELAR. It updates RFC 3776 (it doesn't obsolete anything), and it's basically the guide for protecting Mobile IPv6 signaling with IPsec and IKEv2 🔐✨
Status of This Memo 🎀
This doc 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 IETF Trust (2007).
Abstract 🧚
This doc describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. That's the whole vibe ✨
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 10
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 12
6.2. Return Routability Messages . . . . . . . . . . . . . . . 13
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 14
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 15
7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 16
7.2.2. Return Routability Messages . . . . . . . . . . . . . 17
7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Security Association Negotiation Using IKEv2 . . . . . . . 18
7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
8. The Use of EAP Authentication . . . . . . . . . . . . . . . . 21
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 241. Introduction ✨
okay so RFC 3776 explains how IPsec (the version from RFC 2401 [11]) gets used with Mobile IPv6 [2] to protect the signaling messages 🔐 It also shows examples of Security Policy Database and Security Association Database entries you can use to protect Mobile IPv6 signaling messages.
The IPsec architecture got a glow-up in RFC 4301 [5] 💅 One big change is that the selector list now includes the Mobility Header message type. That changes how you set up security policies and security associations for protecting mobility header messages. Instead of checking whether a mobility header message is being sent on a tunnel interface between the mobile node and the home agent (the way RFC 3776 did it), you can tell the messages apart by their type value, which is so much easier 🙈 The revised IPsec architecture also treats ICMP message type and code as selectors. That means you can protect Mobile Prefix Discovery messages without applying the same security associations to every ICMPv6 message 🦋
This doc talks about new requirements for the home agent and the mobile node so they can use the revised IPsec architecture and IKEv2. Section 4 lists the requirements. Sections 6 and 7 describe the required Security Policy Database (SPD) and Security Association Database (SAD) entries 🌈
The Internet Key Exchange (IKE) protocol also got substantially revised and simplified [4] 🫶 Section 7.3 of this doc explains how IKEv2 can set up security associations for Mobile IPv6.
Using EAP within IKEv2 is allowed to authenticate the mobile node to the home agent. That's covered in Section 8. There's also a method for dynamically configuring a home address from the home agent using the Configuration Payload in IKEv2, and that's in Section 9 🧚
2. Terminology 📖
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 [1] 💜
3. Packet Formats 📦
The mobile node and the home agent MUST support the packet formats defined in Section 3 of RFC 3776 🎀
If the mobile node reverse tunnels all traffic, including the Mobile IPv6 signaling messages it exchanges with the home agent, then the Home Address Option isn't required in the messages sent to the home agent. Here's what the binding update looks like in tunnel mode 👀
IPv6 hdr (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 hdr (source = home address,
destination = home agent)
Mobility Header
Binding Update
Alternate Care-of Address option (care-of address)And this is the binding acknowledgement sent to the mobile node when it's away from the home link 🏠✨
IPv6 hdr (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 hdr (source = home agent,
destination = home address)
Mobility Header
Binding AcknowledgementThe packet formats for tunneled mobile prefix discovery messages are super similar to the tunneled Binding Update and Binding Acknowledgment. The only difference is that the home address is the source address in the inner IP header 🍓
Support for the tunneled packet format above is optional on both the mobile node and the home agent 🌸
4. Requirements 🔥
This section lays out the mandatory rules and requirements for all Mobile IPv6 mobile nodes and home agents. The goal is for IPsec, with IKEv2 as the key management protocol, to protect traffic between the mobile node and the home agent. A lot of these requirements are repeated from RFC 3776 so this doc stands on its own and is complete 💖
4.1. General Requirements 💅
- RFC 3775 states that manual configuration of IPsec security associations MUST be supported, and automated key management MAY be supported. This doc doesn't make any recommendations about supporting manual IPsec configuration or dynamic IPsec configuration. It only describes using manually created IPsec security associations, and using IKEv2 as the automated IPsec key management protocol for protecting Mobile IPv6 signaling messages 🔐
- ESP encapsulation for Binding Updates and Binding Acknowledgements MUST be supported and used 🦋
- ESP encapsulation in tunnel mode for the Home Test Init (HoTi) and Home Test (HoT) messages tunneled between the mobile node and the home agent MUST be supported and SHOULD be used 🧚
- ESP encapsulation of the ICMPv6 messages related to mobile prefix discovery MUST be supported and SHOULD be used 🌈
- ESP encapsulation of the payload packets tunneled between the mobile node and the 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 🔥
- The home agent and the mobile node MAY support authentication using EAP in IKEv2, as described in Section 8 👑
- The home agent and the mobile node MAY support remote configuration of the home address, as described in Section 9. When the home agent gets a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it must reply with a valid home address for the mobile node. The home agent can pick a home address from a local database or from a DHCPv6 server on the home link 🫶
4.2. Policy Requirements 🎀
okay so this section is all about how the security policy database gets set up on the home agent and the mobile node. it's giving "get the rules right or everything breaks" 💅
- okay so RFC 3776 needed security policies configured per interface so you could tell mobility header messages sent to the home agent apart from the ones tunneled through the home agent to the correspondent node 🫣 but since the Mobility Header message type is a selector now, it's super easy to tell HoTi and HoT messages apart from other mobility header messages ✨ so per-interface config is not required for protecting mobility header messages anymore. ngl that's such a glow up 🌸 also heads up, without per-interface policies, payload packet protection is limited to packets originating or terminating at the home address. and traffic using a link local address inside the Mobile IP tunnel can't get IPsec protection without per-interface security policies 💀
- the home agent MUST be able to stop a mobile node from using its security association to send a Binding Update on behalf of another mobile node 🙅♀️ with manual IPsec configuration, the home agent MUST be able to verify that a security association was created for a particular home address. with dynamic keying, the home agent MUST be able to verify that the identity presented in the
IKE_AUTHexchange is allowed to create security associations for a particular home address. - the home agent uses the Peer Authorization Database (PAD) [5] to store per-mobile node state 🗂️ the per-mobile node state stores the information used to authenticate the mobile node, plus the authorization info that ties the mobile node's identity to its home address. this lets the home agent stop a mobile node from creating IPsec security associations for another mobile node's home address. with dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address 🧚
- as required in the base specification [2], when a packet destined to the receiving node is matched against IPsec security policy or selectors of a security association, an address appearing in a Home Address destination option is considered as the source address of the packet.
note that the home address option appears before IPsec headers. Section 11.3.2 of the base specification describes one possible implementation approach for this: the IPsec policy operations can be performed at the time when the packet has not yet been modified per Mobile IPv6 rules, or has been brought back to its normal form after Mobile IPv6 processing. so the processing of the Home Address option is seen as a fixed transformation of the packets that does not affect IPsec processing 🧠
- similarly, a home address within a Type 2 Routing header destined to the receiving node is considered as the destination address of the packet, when a packet is matched against IPsec security policy or selectors of a security association.
similar implementation considerations apply to the Routing header processing as were described above for the Home Address destination option.
- 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 is torn down 🏠 the security policy entries that were used for protecting tunneled traffic between the mobile node and the home agent SHOULD 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 the security associations were created dynamically using IKE, they are 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, Binding Acknowledgements and Mobile Prefix Discovery messages SHOULD NOT be deleted, since they don't depend on care-of addresses and can be used again.
- the mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations when transport mode IPsec protection is used, so the home address is visible when the IPsec policy checks are made 👀
- the home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node when transport mode IPsec protection is used, again because the home address needs to be visible when the policy checks are made 💖
4.3. IPsec Protocol Processing Requirements ⚡
this part lists the requirements for IPsec processing at the home agent and the mobile node. buckle up 🎢
- the home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector.
- the home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector.
- the home agent MUST be able to tell apart HoTi messages sent to itself (when it's acting as a Correspondent Node) and those sent to Correspondent Nodes (when it's acting as a home agent), based on the destination address of the packet 🧭
- when securing Binding Updates, Binding Acknowledgements, and Mobile Prefix Discovery messages, both the mobile node and the home agent MUST support the use of the Encapsulating Security Payload (ESP) [6] 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. the use of the sequence number in the ESP header to provide anti-replay protection is optional, because the sequence numbers in the Binding Updates already provide anti-replay protection. however, the anti-replay protection fails if the home agent loses the binding cache state, for example due to a reboot 😱 since the IPsec security association state can also be assumed to be lost, ESP cannot provide anti-replay protection in this case. complete anti-replay protection can only be provided by the use of a dynamic keying mechanism, like IKEv2.
support for protecting these messages using ESP in tunnel mode is optional.
- tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. a non-null encryption transform and a non-null authentication algorithm MUST be applied 🔐
- when ESP is used to protect Binding Updates, there is no protection for the care-of address that 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. as a result, 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 to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register.
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.
- 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 to expect 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. one such API is described in [12]. 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. this is a big deal, bestie, so don't skip it 🚨
4.4. Dynamic Keying Requirements 🦋
this section covers the requirements for using a dynamic key management protocol on the mobile node and the home agent. Section 7.3 describes the use of IKEv2 as the dynamic key management protocol 🗝️
- the mobile node MUST use its care-of address as the source address in protocol exchanges when using dynamic keying.
- the mobile node and the home agent MUST create security associations based on the home address, so that the security associations survive changes in care-of address 🫶 when using IKEv2 as the key exchange protocol, the home address should be carried as the initiator IP address in the
TSipayload during theCREATE_CHILD_SAexchange [4]. - if the mobile node has used IKEv2 to establish security associations with its home agent, it should follow the procedures discussed in Sections 11.7.1 and 11.7.3 of the base specification [2] to determine whether the IKE endpoints can be moved, or if the SAs, including the IKEv2 SA, have to be re-established.
- if the home agent has used IKEv2 to establish 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 [2] to determine whether the IKE endpoints can be moved, or if the SAs, including the IKEv2 SA, have to be re-established. 🎀
5. Selector Granularity Considerations ✨
okay so IPsec implementations are still compatible with this document even if they don't support fine-grain selectors like the Mobility Header message type and ICMPv6 message type 💅. But ngl, those implementations are not compliant with RFC 4301 [5], so that's a whole vibe check 🙈. Some implementations might only do coarse-grain selectors for forwarded traffic (so just addresses, and sometimes the protocol field) 🧚. Finer selectors give you better control because the protection only kicks in when it's actually needed, so the examples in this document always use the finest granularity 💜.
Here are the different ways to set up IPsec policies for protecting Mobile IPv6 messages 🦋:
- The IPsec implementations on the mobile node and the home agent support fine-grain selectors, including the Mobility Header message type. This is the case assumed in the IPsec SPD and SAD examples in this document 👑.
- The IPsec implementations only support selectors at a protocol level. Such an implementation can only identify mobility header traffic and can't tell the individual mobility header messages apart 😭. In this case, the protection of Return Routability Messages uses a setup similar to the regular payload packets sent to the correspondent node, with the protocol selector set to Mobility Header. All tunneled Mobility Header messages will be protected 🫶.
- The third case is where the protocol selector isn't available in the IPsec implementation 💀. Here, all traffic sent by the mobile node that is reverse tunneled through the home agent is protected using ESP in tunnel mode. This case also applies when the mobile node, for privacy reasons, tunnels all traffic to the home agent 🌸. That includes Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, and all traffic exchanged between the mobile node and the correspondent node. This case uses an IPsec tunnel mode SA with the protocol selector set to 'any' 🍓.
The third case, where all tunneled traffic is protected, comes with some extra things to think about 🌈:
- If there is just one IPsec SA protecting all traffic, then the SA MUST fulfill the requirements for protecting the Return Routability messages, which require confidentiality protection 🔥. If the third case is being used for privacy reasons, there can also be separate tunnel mode SPD entries for protecting the Return Routability messages with a higher priority in the SPD, so the SPD entry with the higher priority gets applied first ✨.
- The receipt of a Binding Update from the new care-of address updates the tunnel endpoint of the IPsec SA as described in Section 4.3. Since that Binding Update arrives through the same tunnel interface that needs updating, special care should be taken on the home agent to make sure the Binding Update is not dropped 😭. This can be achieved either by performing the source address check on the outer IPv6 header after the binding update is processed, or by having exception handling that checks the inner packet for a Binding Update when the source address match on the outer source address fails 🦋. Typical IPsec processing does not check the outer source address when the originator of the packet has already been authenticated 💅.
6. Manual Configuration 🎀
This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages 💖. These SPD and SAD entries are only example configurations 🧚. A particular mobile node implementation and home agent implementation could configure different SPD and SAD entries, as long as they provide the required security of the Mobile IPv6 signaling messages 🫶.
For the examples in this document, we're assuming a mobile node with home address "home_address_1", primary care-of address "care_of_address_1", a home agent with address "home_agent_1", and a user of the mobile node with identity "user_1" 👑. If the home address of the mobile node changes, the SPD and SAD entries need to be re-created or updated for the new home address 😭.
The Peer Authorization Database is not used when manual IPsec configuration is used for setting up security associations for protecting Mobile IPv6 signaling messages 💅.
6.1. Binding Updates and Acknowledgements 🦋
Here are the SPD and SAD entries on the mobile node and the home agent that protect Binding Updates and Acknowledgements 💜.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = MH &
local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN)
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = MH &
local_mh_type = BAck & remote_mh_type = BU
Then use SA SA2 (OUT) and SA1 (IN)
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU6.2. Return Routability Messages 🌸
Here are the SPD and SAD entries on the mobile node and the home agent that protect Return Routability messages 🧚.
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN)
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
home agent SPD-S:
- IF remote_address = home_address_1 & local_address = any &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA SA4 (OUT) and SA3 (IN)
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi6.3. Mobile Prefix Discovery Messages 🍓
Here are the SPD and SAD entries used to protect Mobile Prefix Discovery messages 🔥.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = ICMPv6 &
local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN)
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = ICMPv6 &
local_icmp6_type = MPA & remote_icmp6_type = MPS
Then use SA SA6 (OUT) and SA5 (IN)
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS6.4. Payload Packets 💖
Regular payload traffic between the mobile node and the correspondent node, tunneled through the home agent, can be protected by IPsec if required 🌈. The mobile node and the home agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] apply here 🫶.
7. Dynamic Configuration 🧚
This section describes using IKEv2 to set up the required security associations 👑.
7.1. Peer Authorization Database Entries 🦋
Here's what PAD entries look like on the mobile node and the home agent 💜. These PAD entries are only example configurations. Note that the PAD is a logical concept, so a particular mobile node and home agent can implement the PAD in an implementation-specific way 🎀. The PAD state may also be spread across various databases in a specific implementation ✨.
mobile node PAD:
- IF remote_identity = home_agent_identity_1
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address home_agent_1
home agent PAD:
- IF remote_identity = user_1
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for remote address home_address_1The list of authentication mechanisms in the examples above isn't exhaustive 🙈. There could be other credentials used for authentication stored in the PAD 💅.
In the case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address 🔥.
7.2. Security Policy Database Entries 💅
The following sections describe the security policy entries on the mobile node and the home agent 🌸. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries, as long as they provide the required security of the Mobile IPv6 signaling messages 🦋.
In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1, the primary care-of address of the mobile node is assumed to be care_of_address_1, and the IPv6 address of the Home Agent is assumed to be home_agent_1 🍓.
7.2.1. Binding Updates and Acknowledgements 💌
okay so this is the SPD entries for protecting Binding Updates and Acknowledgements 🔐 the mobile node and the home agent each need their own entry, and they're basically mirror images of each other, so it's giving symmetry ✨
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport modein these examples the mobile node's home address isn't always around 🥺 like, it might not have one configured yet, and that's totally fine. the second it gets a new home address, it must either add that address to the matching SPD entries or make brand new SPD entries for it 🫶
the home agent should have named SPD entries for each mobile node, based on who the mobile node is 🎀 the identity lives in the "Name" selector in the SPD [5]. the home address the mobile node shows during IKE negotiation gets saved as the remote IP address in the resulting IPsec security associations. but here's the tea: if the mobile node dynamically configures a home agent and a home address, the home agent might have no clue which mobile nodes it's supposed to be serving 💀 so it cannot have per-mobile-node SPD entries. instead, it should have generic SPD entries that stop mobility header traffic needing IPsec protection from sneaking past the IPsec filters 🚫 and once a mobile node authenticates to the home agent and sets up a home address, the proper SPD entries get created for that mobile node. main character behaviour ✨
quick bonus detail 🦋 the Mobility Header message type gets negotiated by putting it in the most significant eight bits of the 16-bit local "port" selector during the IKEv2 exchange. for more on that, check [5]. also, the TSi and TSr payloads in the examples above have a whole bunch of other selectors besides home_address_1, but we only show the ones that matter for Mobile IPv6 so it doesn't get too long 💅
7.2.2. Return Routability Messages 🌸
so these are the SPD entries on the mobile node and the home agent for protecting the Return Routability messages 🔮
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1home agent SPD-S:
- IF local_address = any & remote_address = home_address_1 &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA ESP tunnel modewhen the mobile node's care-of address changes, both the mobile node and the home agent have to update their SPD entries 🔄 the home agent finds out about the new care-of address when it gets a Binding Update from the mobile node. the home agent is always paying attention, bestie 👀
7.2.3. Mobile Prefix Discovery Messages 🧚
these are the SPD entries on the mobile node and the home agent for protecting Mobile Prefix Discovery messages 💜
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & local_icmp6_type = MPS &
remote_icmp6_type = MPA
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & local_icmp6_type = MPA &
remote_icmp6_type = MPS
Then use SA ESP transport modein these examples the home address might not be around all the time, same as before 🙈 when the mobile node gets a new home address, it must add that address to the corresponding SPD entries 🎀
and again, the TSi and TSr payloads will have lots of other selectors besides home_address_1, but they're not shown here for brevity 💖
7.2.4. Payload Packets 🍓
these are the SPD entries on the mobile node and the home agent for when payload traffic between the mobile node and its Correspondent Node needs protecting ✨ they look a lot like the entries for Return Routability messages, but they have a lower priority than all the entries above. basically, the signaling stuff goes first, always 👑
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X
Then use SA ESP tunnel mode7.3. Security Association Negotiation Using IKEv2 🔑
okay so Mobile IPv6 signaling messages are usually started by the mobile node 🚀 whenever it moves and picks up a new care-of address, it sends a Binding Update to the home agent. that's the whole vibe.
the mobile node kicks off an IKEv2 protocol exchange if the required security associations aren't already there. for mutual authentication, one option is a shared secret between the mobile node and the home agent 🤝 the home agent uses the mobile node's identity to figure out which shared secret goes with it. but if a public-key-based mechanism is available, it should be the preferred mechanism for mutual authentication 🔐 (public keys are literally the iconic choice).
if they're using a shared secret, the mobile node uses it to generate the AUTH payload in the IKE_AUTH exchange. if it's using a public-key-based mechanism instead, it uses its private key to make that AUTH payload 🗝️
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}the mobile node always includes its identity in the IDi payload during the IKE_AUTH exchange 🪪 there are a few different identity types it could use to introduce itself to the home agent:
- Home Address - the mobile node could use its statically configured home address as its identity. in that case, the ID Type field is set to
ID_IPV6_ADDR. - FQDN - the mobile node can use a Fully Qualified Domain Name as the identifier, and it sets the ID Type field to
ID_FQDN. - RFC 822 identifier - if the mobile node uses an RFC 822 identifier [9], it sets the ID Type field to
ID_RFC822_ADDR.
that list isn't exhaustive, so there could be other identities out there too 🌈
during the IKE_AUTH exchange, the mobile node puts the home address and the right selectors into the TSi (Traffic Selector-initiator) payload 🎯 that's how it negotiates IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. the mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement, so both messages can share the same pair of IPsec security associations. big brain move 🧠✨
after the IKE_AUTH exchange wraps up, the mobile node starts CREATE_CHILD_SA exchanges to negotiate extra security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages, and (optionally) payload traffic 💅 the CREATE_CHILD_SA exchanges are protected by the IKEv2 security associations that were created during the IKE_SA_INIT exchange. and if a correspondent node that's also a mobile node starts the return routability exchange, then the home agent is the one that starts the CREATE_CHILD_SA exchange to negotiate security associations for protecting Return Routability messages 🔄
it's super important that these security associations are created based on the mobile node's home address, so they survive a care-of address change 🛡️ which means the mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange, so the IPsec security associations get created for the home address 🏠
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}when PKI-based authentication is used between the mobile node and the home agent, the identity the mobile node presents in the IDi payload MUST match the identity in the certificate the home agent gets 🪪 the home agent uses the identity in the IDi payload to look up the policy and the certificate that go with that mobile node. and if the mobile node presents its home address in the IDi payload, then the home agent MUST verify that the home address matches the address in an iPAddress field in the SubjectAltName extension [8].
now here's a little aside 👀 when the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. according to RFC 4306 [4], the IP header fields in IKEv2 messages are ignored, and they're only used in the IP headers for IKEv2 messages sent as replies 🤓
7.4. Movements and Dynamic Keying 🦋
okay this one's about what happens when the mobile node moves and its care-of address changes 🚗💨 the IKEv2 SA might not be valid anymore in that case. RFC 3775 defines a mechanism that's based on successfully exchanging Binding Update and Binding Acknowledgement messages, so that's the move 🙌
the mobile node sets up the IKE SA with the home agent using its primary care-of address. the IKE SA endpoints get updated on the home agent when it receives the Binding Update from the mobile node's new care-of address 📬 and on the mobile node, they get updated when it sends the Binding Update to the home agent, or when it receives the Binding Acknowledgement sent by the home agent. this ability to change IKE endpoints gets indicated by setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages 🏳️🌈
but if the mobile node or the home agent doesn't support this capability, and it has no other way to update the addresses, then an IKEv2 exchange MUST be initiated to re-establish a new IKE SA 💀 no shortcuts, periodt 💅
8. The Use of EAP Authentication ✨
Okay so, besides public key signatures and shared secrets, you can also use EAP [10] with IKEv2 to authenticate the mobile node to the home agent 🔐
Here's how it starts. The mobile node says "I want EAP!" by including the IDi payload and leaving out the AUTH payload in the first message of the IKE_AUTH exchange. If the home agent is up for an extensible authentication method, it replies with an EAP payload. No security associations get made until the next IKE_AUTH exchange, after EAP authentication succeeds. EAP adds at least two round trips to the IKE negotiation, and the exact number depends on which EAP method you pick 🫶
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP }
.
.
.
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi,
TSr}Now, the identity in the IDi field might not be the mobile node's actual identity when EAP is in play 👀 It could be a made-up identity that's only there for AAA routing and picking the right EAP method. The real identity might also be tucked inside EAP where the home agent can't see it. IKEv2 doesn't allow an EAP Identity Request/Response exchange, but EAP methods can swap identities internally. So if that happens, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent gets that identity is out of scope for this doc, so don't come looking for it here 🙈
Some EAP methods, when used with IKEv2, generate a shared key on both the mobile node and the home agent once EAP authentication succeeds. That key then generates the AUTH payloads in the later IKEv2 messages. If the key is used for AUTH payloads, it MUST NOT be used for any other purpose. The gory details are in [4] 💅
Also, EAP between the mobile node and the home agent might mean the home agent has to contact an authorization server, like the AAA Home server on the home link, to authenticate the mobile node. Check out [7] for more info 🧚
9. Dynamic Home Address Configuration 🏠
The mobile node can dynamically configure its own home address by putting a Configuration Payload in the IKE_AUTH exchange and asking for an address from the home link. The mobile node should include a zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. It MAY also include multiple instances of INTERNAL_IP6_ADDRESS if it wants multiple home addresses assigned by the home agent 🌸
When the home agent gets a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY carries the prefix length of the home prefix, plus a 128-bit home address. The home agent could use a local database, or it could contact a DHCPv6 server on the home link to allocate the address. The home address stays allocated for as long as the IKEv2 security association between the mobile node and the home agent exists. If that IKEv2 SA gets rekeyed, the home address lifetime gets extended too ⭐
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2,
TSi, TSr}The mobile node could suggest a home address it wants in the CFG_REQUEST. That might be one it got before, or one it auto-configured from the IPv6 prefix on the home link. The home agent can let the mobile node keep the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY to that same address. If the home agent wants the mobile node on a different home address, it sends the new one in the INTERNAL_IP6_ADDRESS attribute of the CFG_REPLY. In that case, the Mobile Node MUST stop using its old home address and start using the newly allocated one 🔄
If the home agent can't allocate a home address during the IKE_AUTH exchange, it MUST send a Notify Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile node gets that Notify Payload, it SHOULD terminate the IKE_AUTH exchange. After that, the mobile node should start a new IKE_SA_INIT and IKE_AUTH exchange, and try to auto-configure a home address as described in [13]. The mobile node MAY also switch to another home agent. The new home agent address can come from a home agent list received during an earlier home agent discovery phase. If that list is empty or unavailable, the mobile node can try a fresh home agent discovery instead 🧭
And if the mobile node wants a DNS server from the home link, it can ask for one by including an INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload 📬
10. Security Considerations 🔒
This part is serious business, bestie, so read it carefully 🚨
This document describes how IPsec can be used to secure Mobile IPv6 signaling messages. For security considerations about using IPsec with Mobile IPv6, see RFC 3775 [2].
A misbehaving mobile node could create IPsec security associations for a home address that belongs to another mobile node 😬 So the home agent should check whether a particular mobile node is authorized to use a home address before creating IPsec security associations for it. If the home address was assigned as described in Section 9, the home agent MUST associate the home address with the identity used in IKE negotiation. The home agent MAY also store the assigned home address in the SPD entries created for the mobile node.
The use of EAP for authenticating the mobile node to the home agent is described in Section 8. Security considerations for using EAP with IKEv2 are described in [4] 💜
11. Acknowledgements 🫶
The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve Bellovin, Kilian Weniger, and Vijay Gurbani for reviewing the document 🎀
Many of the requirements listed in Section 4 are copied from RFC 3776, so the authors of RFC 3776 get a shoutout too 👑
12. References 📚
12.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
- [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
12.2. Informative References
- [7] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress, September 2006.
- [8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
- [9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
- [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Work in Progress, September 2006.
- [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", Work in Progress, December 2006.
Authors' Addresses 🖊️
Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
EMail: vijay.devarapalli@azairenet.com
Francis Dupont
CELAR
EMail: Francis.Dupont@fdupont.frFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💼
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4877 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms