RFC 4555
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE) 🦋
Okay bestie, this one is from the Network Working Group 💅 It was published in June 2006 as RFC 4555, and the main author is P. Eronen, Ed. from Nokia 🌸 The category is Standards Track, so this is an actual protocol spec, not a vibes doc. The title block I was given doesn't list anything it obsoletes or updates, so I'm not making any up 🙈
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it asks 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 (2006).
Abstract 🦋
Okay so MOBIKE is a mobility and multihoming extension to Internet Key Exchange (IKEv2) 🔥 It lets the IP addresses tied to IKEv2 and tunnel mode IPsec Security Associations change, which is honestly iconic. A mobile Virtual Private Network (VPN) client can use MOBIKE to keep its connection to the VPN gateway alive while it moves from one address to another 🚗💨 It's also useful for a multihomed host that wants to shift traffic to a different interface if the one it's using stops working, like, fr fr 🫶
Table of Contents 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 311. Introduction 💖
1.1. Motivation
IKEv2 handles mutual authentication, and it also sets up and maintains IPsec Security Associations (SAs) 🔐 In the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec SAs get created implicitly between the IP addresses used when the IKE_SA is established 📍 Those addresses then become the outer (tunnel header) addresses for tunnel mode IPsec packets (transport mode IPsec SAs are beyond the scope of this document). Right now you can't change these addresses once the IKE_SA exists, which is the whole problem 😭
These addresses can change in real life 🌸 Mobility is the big example: a host switches its point of network attachment and gets a new IP address. Multihoming is the other one, where a host wants to switch to a different interface if the one it's on stops working for some reason.
You could solve this by making brand-new IKE and IPsec SAs whenever the addresses change, but that's not always ideal 🙃 Sometimes creating a new IKE_SA needs a human to authenticate, like typing in a code from a token card. Making new SAs is also expensive to calculate and can take a ton of round-trips. So the spec needs a way to update the IP addresses of existing IKE and IPsec SAs, and MOBIKE, described in this document, is that mechanism ✨
The main scenario is a remote access VPN user moving from one address to another without re-establishing every security association with the VPN gateway 💼 Picture this: you start on fixed Ethernet at the office, then unplug the laptop and move to the office's wireless LAN. When you leave the office, the laptop could start using General Packet Radio Service (GPRS), and when you get home, it could switch to the home wireless LAN 🏠 MOBIKE only updates the outer (tunnel header) addresses of IPsec SAs. The addresses and other traffic selectors used inside the tunnel stay the same, so mobility can be (mostly) invisible to the apps and connections running over the VPN 🦋
MOBIKE also covers messier setups, where the VPN gateway has several network interfaces too 🌈 Those interfaces could hook into different networks or ISPs, they might be a mix of IPv4 and IPv6 addresses, and the addresses can change over time. And both parties could be VPN gateways relaying traffic for other parties, which is a lot of main character energy 👑
1.2. Scope and Limitations
This document focuses on the main scenario above and only supports tunnel mode IPsec SAs 🎀
The mobility support in MOBIKE lets both parties move, but it doesn't give you a "rendezvous" mechanism. That means no simultaneous movement of both parties, and no discovering addresses when the IKE_SA is first set up 🙈 So MOBIKE works best when the address of at least one endpoint is pretty stable and can be found with existing mechanisms, like DNS (see Section 3.1) 🔍
MOBIKE lets both parties be multihomed, but only one pair of addresses gets used for an SA at a time. Load balancing is beyond the scope of this spec 🚫⚖️
MOBIKE follows the IKEv2 practice where a response message goes to the same address and port the request came from. So MOBIKE doesn't work over address pairs that only give you unidirectional connectivity, which is a hard no 💀
Network Address Translators (NATs) bring extra limitations on top of the ones above. Check Section 2.3 for the details 🧚
The base version of MOBIKE doesn't cover every future use case, like transport mode, securing SCTP, or optimizations that might be wanted in certain situations. Future extensions might be defined later to handle more requirements 🌸 For more info and the reasoning behind these limits, check out the MOBIKE design document [Design] 📖
1.3. Terminology and Notation
When messages with IKEv2 payloads get described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign means a payload can be repeated one or more times (for instance, "FOO+") 🧩 Some diagrams also show which existing IKEv2 payloads would normally be included in the exchanges, just to give you context. Those payloads are only for illustration, so go to [IKEv2] for the authoritative description 💅
When this document talks about updating the source/destination addresses of an IPsec SA, it means updating the IPsec-related state so that outgoing Encapsulating Security Payload (ESP)/Authentication Header (AH) packets use those addresses in the tunnel header 📦 Depending on how the nominal divisions between the Security Association Database (SAD), Security Policy Database (SPD), and Peer Authorization Database (PAD) described in [IPsecArch] are actually implemented, an implementation might have several different places that need updating 🫠
In this document, the term "initiator" means the party who originally started the first IKE_SA (in a series of possibly several rekeyed IKE_SAs), and "responder" is the other peer 🤝 During the lifetime of the IKE_SA, both parties can start INFORMATIONAL or CREATE_CHILD_SA exchanges, and in that case the terms "exchange initiator" and "exchange responder" get used 💜 The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) isn't used in this document 🚫
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 [KEYWORDS] 🔑
2. Protocol Overview 🌈
2.1. Basic Operation 💖
okay so MOBIKE lets both parties have several addresses, which means there are up to N*M pairs of IP addresses that could potentially be used 🫶 picking the right pair is not random 💅 a few things go into it. first, the parties might have preferences about which interface to use, for stuff like performance and cost 💸. second, some pairs just won't work at all because of incompatible IP versions, outages in the network, problems on the local link at either end, and so on 😭
MOBIKE keeps it simple 👑: the party that initiated the IKE_SA (the "client" in a remote access VPN scenario) is in charge of deciding which address pair gets used for the IPsec SAs, and it's also responsible for collecting the info it needs to make that call (like figuring out which pairs work and which don't). The other party (the "gateway" in a remote access VPN scenario) just tells the initiator which addresses it has. It doesn't update the IPsec SAs until the initiator sends it a message to do so. This applies to the addresses in the IPsec SAs. In the IKE_SA case, the exchange initiator can decide which addresses are used.
Making the decision at the initiator is totally consistent with how normal IKEv2 works, since the initiator decides which addresses it uses when contacting the responder. It also makes a lot of sense when the initiator is a mobile node, because it's in a better spot to decide which of its network interfaces should carry upstream and downstream traffic 🦋
The nitty gritty of exactly how the initiator decides, what info goes into the decision, how that info gets collected, how preferences factor in, and when a decision needs to change is mostly out of MOBIKE's scope 🙈 not because it's unimportant (it's literally going to be crucial in any real system), but MOBIKE only cares about these details to the extent they show up in the IKEv2/IPsec messages between peers, since those need to be standardized so everyone can interoperate.
Lots of these issues aren't MOBIKE-specific. They come up with existing hosts in dynamic environments or with mobility protocols like Mobile IP [MIP4] [MIP6]. A bunch of mechanisms already exist or are being developed to deal with them. For instance, link-layer and IP-layer mechanisms can track the status of connectivity within the local link [RFC2461], and movement detection is being specified for both IPv4 and IPv6 in [DNA4], [DNA6], and so on ✨
Updating the addresses of IPsec SAs has to take several security considerations into account, and MOBIKE has two features for that 🔥 First, a "return routability" check can verify the addresses the peer provides. This makes it harder to flood third parties with huge amounts of traffic 😤 Second, a "NAT prohibition" feature makes sure IP addresses haven't been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is enabled only when NAT Traversal is not used.
2.2. Example Protocol Exchanges 🎀
here's a simple MOBIKE exchange in a mobile scenario. the notation is based on [IKEv2], Section 1.2, and the source/destination IP addresses and ports are shown for each packet. IP_I1, IP_I2, IP_R1, and IP_R2 are the IP addresses used by the initiator and the responder 🌸
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
(Initiator gets information from lower layers that its attachment
point and address have changed.)
3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(Responder verifies that the initiator has given it a correct IP
address.)
4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) }
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2) } -->Step 1 is the normal IKE_INIT exchange 🧚 In step 2, the peers let each other know they support MOBIKE. In step 3, the initiator notices its own address has changed and tells the responder by sending an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification. The request goes out using the new IP address, and at this point the initiator also starts using that new address as the source address in its own outgoing ESP traffic. When the responder gets the UPDATE_SA_ADDRESSES notification, it records the new address and, if policy requires it, does a return routability check on it. Once that check (step 4) completes, the responder starts using the new address as the destination for its outgoing ESP traffic 💜
Another protocol run in a multihoming scenario is illustrated below. In this one, the initiator has one address but the responder has two 🍓
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair
and probes its liveness.)
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
...
(Eventually, the initiator gives up on the current address pair and
tests the other available address pair.)
4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(This worked, and the initiator requests the peer to switch to new
addresses.)
5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }2.3. MOBIKE and Network Address Translation (NAT) 🌈
In some MOBIKE scenarios, the network may have NATs or stateful packet filters in it (for brevity, the rest of this document simply describes NATs 🙈). The NAT Traversal feature specified in [IKEv2] lets IKEv2 work through NATs in many cases, and MOBIKE can use that functionality. When the addresses used for IPsec SAs change, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.
BUT there are some limitations, because NATs usually introduce an asymmetry into the network: only packets coming from the "inside" create state. That asymmetry puts restrictions on what MOBIKE can do 😬 For example, say both peers have only a single address and the initiator is behind a NAT. If the responder's address changes, it needs to send a packet to the initiator using its new address. However, if the NAT is the common "restricted cone" type (see [STUN] for one description of different NAT types), that's not possible. The NAT will drop packets sent from the new address, unless the initiator has previously sent a packet to that address, which it can't do until it knows the address 💀
For simplicity, MOBIKE doesn't try to handle every possible NAT-related scenario 🫶 Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT. The case where the responder's addresses change is not fully supported, meaning no special effort is made to support it. Responders may also be unaware of the NATs, or of specific types of NATs, they are behind. However, when a change happens that will cause a loss of connectivity, MOBIKE responders will still attempt to inform the initiator of the change. Depending on things like the exact type of NAT, that may or may not succeed. Analyzing exactly when this will or won't work is not done in this document 🍓
3. Protocol Exchanges ✨
3.1. Initial IKE Exchange 🦋
The initiator is responsible for finding a working pair of addresses so the initial IKE exchange can be carried out. Any information from MOBIKE extensions is only available later, once the exchange has progressed far enough. Exactly how the addresses for the initial exchange are discovered is beyond the scope of this specification. Typical sources of that info include local configuration and DNS 💖
If either or both peers have multiple addresses, some combinations may not work. So the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request 🔥
3.2. Signaling Support for MOBIKE 🎀
Implementations that want to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload) 👑
The format of the MOBIKE_SUPPORTED notification is described in Section 4 🧚
3.3. Initial Tunnel Header Addresses ✨
okay so when an IPsec SA gets created 💖, the tunnel header IP addresses (and the port too, if you're doing UDP encapsulation 🦋) come from the IKE_SA, not from the IP header of the IKEv2 message asking for the IPsec SA. The addresses in the IKE_SA get initialized from the IP header of the first IKE_AUTH request.
The addresses come from IKE_AUTH because IKEv2 has to switch from port 500 to 4500 if a NAT gets discovered 🙈. To keep things simple, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them. That way, nobody has to change ports later if a NAT shows up on some other path. Main character energy for ports 🎀.
3.4. Additional Addresses 🌸
Both the initiator and responder MAY include one or more ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange (or, if there are multiple IKE_AUTH exchanges, in the message containing the SA payload). Here "ADDITIONAL_*_ADDRESS" means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS notification.
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }The recipient stores this information, but no other action is taken at this time.
Both peers keep a set of addresses for the other side (logically tied to the IKE_SA), but they use that info for slightly different reasons, so it's worth noting 🧚.
The initiator uses the set of responder addresses as an input to its address selection policy 🗺️. It may, at some later point, decide to move the IPsec traffic to one of these addresses, using the procedure in Section 3.5. The responder normally doesn't use the set of initiator addresses for anything. Those addresses only come into play when the responder's own addresses change (see Section 3.6).
The set of addresses available to the peers can change during the lifetime of the IKE_SA. The procedure for updating this info is in Section 3.6 💜.
Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses the responder receives will be incorrect 😭. This means the procedure for changing responder addresses in Section 3.6 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any purpose other than what is explicitly described either in this document or in a future specification that updates it. Hands off the address list, bestie 🫶.
3.5. Changing Addresses in IPsec SAs 🦋
In MOBIKE, the initiator decides which addresses are used in the IPsec SAs. The responder doesn't normally update any IPsec SAs unless it gets an explicit UPDATE_SA_ADDRESSES request from the initiator. (As described below, the responder can update the IKE_SA in some circumstances 👀.)
Why the initiator wants to change addresses is mostly outside the scope of MOBIKE 🤷♀️. Typical triggers include info from lower layers, like IP address changes or link-down indications. Some of that info can be unreliable. For instance, ICMP messages could be spoofed by an attacker 💀. Unreliable info SHOULD be treated only as a hint that something might be wrong, and the initiator SHOULD trigger Dead Peer Detection (that is, send an INFORMATIONAL request) to check whether the current path is still usable.
Changing addresses can also be triggered by events within IKEv2. At least the following events can cause the initiator to re-evaluate its local address selection policy, which might lead to changing the addresses 🔥:
- An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working.
- An INFORMATIONAL request containing an
ADDITIONAL_IP4_ADDRESS,ADDITIONAL_IP6_ADDRESS, orNO_ADDITIONAL_ADDRESSESnotification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the address currently in use. - An
UNACCEPTABLE_ADDRESSESnotification is received as a response to an address update request (described below). - The initiator receives a
NAT_DETECTION_DESTINATION_IPnotification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 3.8 for the more detailed description).
The rest of this section assumes the initiator has already decided what the new addresses should be. Once that decision is made, the initiator:
- Updates the IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA.
- Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless the initiator's policy requires a return routability check before updating the IPsec SAs, and that check hasn't been done for this responder address yet).
- If the IPsec SAs were updated in the previous step: if NAT Traversal is not enabled, the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, it enables NAT Traversal. That means UDP encapsulation of outgoing ESP packets and sending NAT-Keepalive packets 🌈.
- If there are outstanding IKEv2 requests (requests for which the initiator hasn't received a reply yet), it keeps retransmitting them using the addresses in the IKE_SA (the new addresses).
- When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification (which doesn't contain any data), and clears the "pending_update" flag. The request looks like this:
Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->- If a new address change occurs while waiting for the response, it starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request). Restart energy 🔄.
When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder:
- Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one. If the responder uses a window size greater than one, requests can arrive out of order 🌀. If a newer one has arrived, a normal response message (described below) is sent, but no other action is taken.
- If the
NO_NATS_ALLOWEDnotification is present, processes it as described in Section 3.9. - Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it isn't, it replies with a message containing the
UNACCEPTABLE_ADDRESSESnotification (and possibly COOKIE2) 🚫. - Updates the IP addresses in the IKE_SA with the values from the IP header. (Using the address from the IP header is consistent with normal IKEv2, and lets IKEv2 work with NATs without needing unilateral self-address fixing [UNSAF] 🧠.)
- Replies with an INFORMATIONAL response:
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }- If necessary, initiates a return routability check for the new initiator address (see Section 3.7) and waits until the check is completed.
- Updates the IPsec SAs associated with this IKE_SA with the new addresses.
- If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal.
When the initiator receives the reply:
- If an address change has occurred since the request was first sent, no MOBIKE processing is done for the reply, because a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if a window size greater than one is in use) 🙃.
- If the response contains the
UNEXPECTED_NAT_DETECTEDnotification, the initiator processes the response as described in Section 3.9. - If the response contains an
UNACCEPTABLE_ADDRESSESnotification, the initiator MAY select another address and retry the exchange, keep using the previously used addresses, or disconnect. - It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier, before sending the request; that happens when no return routability check was required).
- If NAT Traversal is supported and NAT detection payloads were included, the initiator enables or disables NAT Traversal.
There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request 🚨. If the source address the responder is currently using becomes unavailable (meaning sending packets from that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address. It can do this in addition to starting the procedure described in the next section ✨.
3.6. Updating Additional Addresses 💅
okay so remember in Section 3.4 how both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange? 💖 that info can get updated later too! you send an INFORMATIONAL exchange request with either one or more ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. 🦋
if the exchange initiator only has a single IP address, that address goes in the IP header and the message has the NO_ADDITIONAL_ADDRESSES notification. if it has several, one goes in the IP header and the rest go in the ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. 🌸
the new list totally replaces the old one. no separate add and delete ops, bestie! every time these notifications get used, the whole list gets sent again. 🫶
the message exchange looks like this:
Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
<-- HDR, SK { [N(COOKIE2)] }when a request with an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification comes in, the exchange responder does the following. 🔥
- It figures out whether it has already gotten a newer request to update the addresses. (If a window size greater than one is used, requests can arrive out of order 🙈.) If it has, it sends a response, but the address set doesn't get updated.
- If the
NO_NATS_ALLOWEDnotification is there, it processes it as described in Section 3.9. - It updates the set of peer addresses based on the IP header and the
ADDITIONAL_IP4_ADDRESS,ADDITIONAL_IP6_ADDRESS, andNO_ADDITIONAL_ADDRESSESnotifications. - It sends a response.
the initiator MAY include these notifications in the same request as UPDATE_SA_ADDRESSES. ✨
if the request to update the addresses gets retransmitted using several different source addresses, a new INFORMATIONAL request MUST be sent. no shortcuts here, babe! 💅
there's one extra plot twist 👀: when the responder wants to update the address set, the addresses currently in use might stop working. in that case, the responder uses the additional address list it got from the initiator, plus its own list of addresses, to figure out which addresses to use for sending the INFORMATIONAL request. this is the only time the responder uses the additional address list from the initiator. 🧚
both peers can have their own policies about which addresses are acceptable, and some kinds of policies can make implementation simpler. for example, if the responder has a single fixed address, it doesn't need to process the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring unrecognized status notifications, as already required in [IKEv2]). and if the initiator has a policy saying only the responder address from local configuration is acceptable, it doesn't have to send its own additional addresses to the responder (since the responder doesn't need them except when changing its own address). 🍓
3.7. Return Routability Check 🦋
both parties can optionally check that the other party can actually receive packets at the claimed address. by default, this "return routability check" SHOULD be performed. 💖 in environments where the peer is expected to be well-behaved (many corporate VPNs, for instance), or where the address can be verified some other way (e.g., a certificate issued by an authority trusted for this purpose), the return routability check MAY be omitted. 🌈
the check can happen before the IPsec SAs get updated, right after they get updated, or continuously during the connection. by default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated. ✨
any INFORMATIONAL exchange can be used for return routability purposes, with one exception (described later in this section). when a valid response comes back, we know the other party can receive packets at the claimed address. 🫶
now, to make sure the peer can't generate the correct INFORMATIONAL response without seeing the request, a new payload gets added to INFORMATIONAL messages. the sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if it's included, the recipient of the INFORMATIONAL request MUST copy the notification as-is to the response. 🔐 when processing the response, the original sender MUST verify that the value is the same one it sent. if the values don't match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the format of the COOKIE2 notification.) 💀
here's the exception I mentioned: if the same INFORMATIONAL request has been sent to several different addresses (meaning the destination address in the IKE_SA got updated after the request was first sent), receiving the INFORMATIONAL response doesn't tell you which address is the working one. in that case, a new INFORMATIONAL request needs to be sent to check return routability. 🙈
3.8. Changes in NAT Mappings 🌸
IKEv2 does Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA. 🍓
in MOBIKE, these messages can also be used to detect whether NAT mappings have changed (for example, if the keepalive interval is too long, or the NAT box gets rebooted). more specifically, if both peers support this specification and NAT Traversal, the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications MAY be included in any INFORMATIONAL request. if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified). 🧚
when the initiator is behind a NAT (as detected earlier using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications), it SHOULD include these notifications in DPD messages. it should also compare the received NAT_DETECTION_DESTINATION_IP notifications with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). if the values don't match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. 👀 if the initiator suspects the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES right away. this saves one roundtrip if the NAT mapping really did change. 🦋
heads up though: this approach to detecting NAT mapping changes may cause an extra address update when the IKE_SA gets rekeyed. that's because the NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security Parameter Indexes (SPIs), which change when rekeying happens. this unnecessary update is harmless, though. 🫶
when MOBIKE is in use, the dynamic updates (specified in [IKEv2], Section 2.23), where the peer address and port get updated from the last valid authenticated packet, work in a slightly different way. the host not behind a NAT MUST NOT use these dynamic updates for IKEv2 packets, but MAY use them for ESP packets. this means an INFORMATIONAL exchange that doesn't contain UPDATE_SA_ADDRESSES won't cause any changes, so it can be used for, e.g., testing whether a particular path works. 🔥
3.9. NAT Prohibition 🙅♀️
basic IKEv2/IPsec without NAT Traversal support may work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. that's because the IKEv2 integrity checksum doesn't cover the addresses in the IP header. some people see this as a problem, since in a way any change to the IP addresses can be treated as an attack. 💀
this specification deals with that by protecting the IP addresses when NAT Traversal hasn't been explicitly enabled. this means MOBIKE without NAT Traversal support won't work if the paths contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. this feature is mainly meant for IPv6 and site-to-site VPN cases, where administrators may know ahead of time that NATs aren't present, so any change to the packet can be treated as an attack. 🛡️
more specifically, when NAT Traversal isn't enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all INFORMATIONAL requests that contain any of these notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED notification. the exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. if they don't match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent. the response message goes to the address and port the corresponding request came from, not to the address contained in the NO_NATS_ALLOWED notification. 🎀
if the exchange initiator gets an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. same deal if the initiator gets UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange: it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request. this makes sure an attacker who can only modify a single packet doesn't leave a path unused for no reason. 💪 the exact number of retries isn't specified in this document because it doesn't affect interoperability. still, since the IKE message will also get rejected if the attacker modifies the integrity checksum field, a reasonable number would be the number of retries used for normal retransmissions. 🧮
if an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any purpose other than possibly logging the information for troubleshooting. 🙈
3.10. Path Testing 🗺️
IKEv2 Dead Peer Detection lets the peers detect whether the path currently in use has stopped working. however, if either peer has several addresses, Dead Peer Detection alone doesn't tell you which of the other paths might work. 🧐
if its address selection policy requires it, the initiator can use normal IKEv2 INFORMATIONAL request/response messages to test whether a certain path works. implementations MAY do path testing even when the path currently in use is working, for example to detect when a better (but previously unavailable) path shows up. 🌟
3.11. Failure Recovery and Timeouts 🌧️
in MOBIKE, the initiator is responsible for detecting and recovering from most failures. 👑
to give the initiator enough time to detect an error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to start Dead Peer Detection. no specific timeout lengths are required, but it's suggested that responders keep retransmitting IKEv2 requests for at least five minutes before giving up. ⏳💖
3.12. Dead Peer Detection 💖
Okay bestie, MOBIKE uses the same Dead Peer Detection method as normal IKEv2 💅 But addresses can change, so checking that the peer is alive isn't enough. You also need to know it's synced with the address updates and didn't, like, ignore one because its return routability test never finished 🙈 So when incoming IPsec packets show up, MOBIKE nodes SHOULD inspect the addresses in those packets and make sure they match the ones that should be in use 🔍 If they don't match, those packets SHOULD NOT count as evidence that the peer can talk to this node and or that the peer has received all address updates 🚫
4. Payload Formats ✨
This spec adds several brand new IKEv2 Notify payload types 🎀 For the general rundown on the Notify payload, check out [IKEv2], Section 3.10 💌
4.1. Notify Messages - Error Types 🚨
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload 🙅♀️
The responder can include this one in an INFORMATIONAL exchange response to say the address change in the request (the one carrying an UPDATE_SA_ADDRESSES notification) was not carried out 💀
The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The Protocol ID and SPI Size fields are set to zero. There's no data with this Notify type 🫶
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload 👀
See Section 3.9 for the full tea on this notification ☕
The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The Protocol ID and SPI Size fields are set to zero. No data goes with this Notify type either 🌸
4.2. Notify Messages - Status Types 📣
4.2.1. MOBIKE_SUPPORTED Notify Payload 🦋
The MOBIKE_SUPPORTED notification gets included in the IKE_AUTH exchange to show that the implementation supports this spec 🙌
The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol ID and SPI Size fields are set to zero. The notification data field MUST be left empty (zero-length) when sending, and its contents (if any) MUST be ignored when received. This lets future versions of the protocol use the field 🔮
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify Payloads 🌍
Both parties can include ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and INFORMATIONAL exchange request messages. See Section 3.4 and Section 3.6 for the deeper dive 🤿
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The Protocol ID and SPI Size fields are set to zero. The data for these Notify types is either a four-octet IPv4 address or a 16-octet IPv6 address 🧃
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 🙅
The NO_ADDITIONAL_ADDRESSES notification can go in an INFORMATIONAL exchange request message to say the exchange initiator doesn't have any addresses beyond the one used in the exchange (see Section 3.6 for more detail) 🤷♀️
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The Protocol ID and SPI Size fields are set to zero. There's no data with this Notify type 💤
4.2.4. UPDATE_SA_ADDRESSES Notify Payload 🔄
This notification is included in INFORMATIONAL exchange requests sent by the initiator to update the addresses of the IKE_SA and the IPsec SAs (see Section 3.5). It's giving "address glow-up" 💅✨
The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The Protocol ID and SPI Size fields are set to zero. There's no data with this Notify type 🌷
4.2.5. COOKIE2 Notify Payload 🍪
This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 3.7). If the INFORMATIONAL request includes COOKIE2, the exchange responder MUST copy the notification to the response message 🫢
The data for this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder. The Notify Message Type for this message is 16401. The Protocol ID and SPI Size fields are set to zero 🔐
4.2.6. NO_NATS_ALLOWED Notify Payload 🚫🌐
See Section 3.9 for the details on this notification 📖
The Notify Message Type for this message is 16402. The notification data contains the IP addresses and ports from and to which the packet was sent. For IPv4, the notification data is 12 octets long and looks like this:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For IPv6, the notification data is 36 octets long and looks like this:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Protocol ID and SPI Size fields are set to zero 🧸
5. Security Considerations 🔐
Okay, this part is serious but also iconic 😤 The main goals here are to keep the security that normal IKEv2 procedures give you and to handle mobility-related threats properly 🛡️ This section covers the new security considerations that MOBIKE brings in. For the general IKEv2 security stuff, see [IKEv2] 📚
5.1. Traffic Redirection and Hijacking 🕵️♀️
MOBIKE payloads that update addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This means nobody except the participants can, for instance, send a control message to change the addresses 🙅♀️
However, just like with normal IKEv2, the actual IP addresses in the IP header are not covered by integrity protection. So a NAT between the parties (or an attacker pretending to be a NAT) can modify the addresses and make incorrect tunnel header (outer) IP addresses get used for IPsec SAs 😬 The damage from this attack is mostly limited to denial of service, since all traffic is protected by IPsec 🧱
This attack can only be pulled off by on-path attackers that can modify IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By changing the IP header of these packets, the attackers can trick the peers into thinking a new NAT or a changed NAT binding exists between them 🎭 The attack can keep going as long as the attacker stays on the path and keeps modifying the IKEv2 messages. Once that's no longer the case, the IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually notice that the intended traffic isn't getting through, and will update the addresses appropriately 🔁
MOBIKE introduces the NO_NATS_ALLOWED notification, which is used to detect modification, by outsiders, of the addresses in the IP header 🕵️ When this notification is used, communication through NATs and other address translators is impossible, so it's sent only when NAT Traversal isn't happening. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know ahead of time that NATs aren't present 🏢
5.2. IPsec Payload Protection 🎀
Using IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up at an incorrect destination or be subject to eavesdropping 🙈
However, security associations originally created to protect a specific flow between specific addresses may be updated by MOBIKE later on. This has to be taken into account if the (outer) IP address of the peer was used when deciding what kind of IPsec SAs the peer is allowed to create 🧐
For instance, the level of required protection might depend on the current location of the VPN client, or access might be allowed only from certain IP addresses 📍
It is recommended that security policies for peers that are allowed to use MOBIKE get configured in a way that accounts for a single security association being used at different times through paths with different security properties 🌈
This is especially critical for traffic selector authorization. The (logical) Peer Authorization Database (PAD) contains the information IKEv2 uses when deciding what kind of IPsec SAs a peer is allowed to create. This process is described in [IPsecArch], Section 4.4.3. When a peer requests the creation of an IPsec SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic selectors. See also [Clarifications] for a more extensive discussion 📝
It's important to note that simply sending IKEv2 packets from some particular address does not automatically mean permission to create IPsec SAs with that address in the traffic selectors 🙅♀️ However, some implementations are known to use policies where simply being reachable at some address X implies a temporary permission to create IPsec SAs for address X. Here, "being reachable" usually means the ability to send (or spoof) IP packets with source address X and receive (or eavesdrop) packets sent to X 👀
Using this kind of policy or extension with MOBIKE may need special care to enforce the temporary nature of the permission. For example, when the peer moves to some other address Y (and is no longer reachable at X), it might be necessary to close IPsec SAs with traffic selectors matching X. However, these interactions are beyond the scope of this document 🫠
5.3. Denial-of-Service Attacks against Third Parties 💥
okay so redirecting traffic isn't only about snooping on people or knocking their connection offline 😤 attackers can also aim it at a totally innocent third party 🎯 like, a high-speed TCP session or a multimedia stream gets rerouted to a victim host and that host's communications just tank 😭
The attacker could be an outsider, or even one of the IKEv2 peers 🫣 in normal VPN setups, a misbehaving peer is pretty easy to handle as long as the authentication from the initial IKEv2 negotiation can be traced back to a real person who can be held responsible 🔍 but that might not work in every scenario, especially with opportunistic approaches to security 🥲
if an outsider does it, the flow usually dies quickly because nothing comes back, like transport layer acknowledgements 🪦 but if the original recipient is evil 😈 they can keep the flow going for ages, since they can totally send those acknowledgements themselves (see [Aura02] for more discussion) 🍿
btw, [Bombing] shows that without ingress filtering in the attacker's network, you can already do this just by sending spoofed packets from the attacker straight to the victim 🙄 and if the attacker's network does have ingress filtering, this is largely prevented for MOBIKE too 🛡️ so it doesn't really make sense to protect MOBIKE against similar attacks 🤷♀️ BUT it's still worth limiting the amplification attackers get 📈 so they can't use stream redirection to blast a huge number of packets at the victim by only sending a few packets themselves 💥
this spec includes return routability tests to shrink how long any "third party bombing" attack can last 🎀 when the attacker is off-path (relative to the victim) 🙅♀️ the tests are authenticated messages the peer has to respond to 🔐 and they can happen before the address change takes effect, right after it, or even periodically during the session ⏰ the tests carry unpredictable data 🎲 so only someone who has the keys associated with the IKE SA and has seen the request packet can respond properly 🗝️
the attack can also get cut short if the victim reports the unwanted traffic back to the originating IPsec tunnel endpoint using ICMP error messages or INVALID_SPI notifications 📣 as [IKEv2], Section 2.21 describes, this SHOULD trigger a liveness test ✅ and that liveness test doubles as a return routability check if the COOKIE2 notification is included 💅
5.4. Spoofing Network Connectivity Indications 🎭
attackers can fake all sorts of indications from lower layers and the network 😵💫 trying to confuse the peers about which addresses are working and which aren't 🙃 like spoofing link-layer error messages so the parties move their traffic somewhere else, or even disconnect 📴 or spoofing info about network attachments, router discovery, and address assignments so they think they have Internet connectivity when they really don't 🌐❌
this can lead to use of non-preferred addresses or even denial of service 😩
MOBIKE doesn't have any protection of its own for indications from other parts of the protocol stack 🙅♀️ but those vulnerabilities can be mitigated with techniques specific to the other parts of the stack, like validation of ICMP errors [ICMPAttacks], link layer security, or using [SEND] to protect IPv6 Router and Neighbor Discovery 🔒
ultimately, MOBIKE depends on IKEv2 messages actually getting delivered to figure out which paths can be used 📬 if IKEv2 messages sent using a particular source and destination address reach the recipient and a reply comes back, MOBIKE will usually consider the path working ✅ but if no reply arrives even after retransmissions, MOBIKE will suspect the path is broken 💔 so an attacker who can consistently control the delivery or non-delivery of IKEv2 messages in the network can influence which addresses actually get used 🕹️
5.5. Address and Topology Disclosure 👀
MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications reveal info about which networks the peers are connected to 🗺️
for example, picture host A with two network interfaces: a cellular connection and a wired Ethernet connection to a company LAN 🏢 if host A now contacts host B using IKEv2 and sends ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B learns stuff it otherwise wouldn't know 🫢 if host A used the cellular connection for the IKEv2 traffic, host B can also see the company LAN address (and maybe even guess that host A belongs to an employee of that company) 🕵️♀️ if host A used the company LAN to make the connection, host B can see that host A has a subscription from this particular cellular operator 📶
these extra addresses can also reveal way more accurate location info than a single address does 📍 say host A uses its cellular connection for IKEv2 traffic, but also sends an ADDITIONAL_IP4_ADDRESS notification containing an IP address for, like, a wireless LAN at a particular coffee shop ☕ host B can now make a much better guess at where A is than it ever could from the cellular IP address alone 😳
and as described in Section 3.4, some of the addresses could also be private addresses behind a NAT 🧱
in lots of environments, disclosing address info is no big deal (and honestly it can't be avoided if the hosts want to use those addresses for IPsec traffic) 💁♀️ for instance, a remote access VPN client could consider the corporate VPN gateway trustworthy enough for this 🏰 plus, the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are sent encrypted, so eavesdroppers can't see the addresses (unless, of course, they get used later for sending IKEv2/IPsec traffic) 🔐
BUT if MOBIKE is used in a more opportunistic way, it can be a good idea to limit what gets sent 🤏 peers don't have to disclose any addresses they don't want to use for IPsec traffic 🙌 and as noted in Section 3.6, an initiator whose policy is to always use the locally configured responder address doesn't have to send any ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS payloads 🎀
6. IANA Considerations 📚
this document doesn't create any new namespaces for IANA to maintain 🙅♀️ but it does need new values in namespaces that were defined in the IKEv2 base specification [IKEv2] 🧩
it defines several new IKEv2 notifications, and their values were allocated from the "IKEv2 Notify Message Types" namespace 🏷️
Notify Messages - Error Types Value
----------------------------- -----
UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED 41
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES 16400
COOKIE2 16401
NO_NATS_ALLOWED 16402these notifications are described in Section 4 ✨
7. Acknowledgements 🫶
this document is a collaborative effort of the entire MOBIKE WG 💜 we'd especially like to thank Jari Arkko, Tuomas Aura, Marcelo Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami Vaarala 🌸 this document also pulls in ideas and text from earlier MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], plus the MOBIKE design document [Design] 🌈
8. References 🧚
8.1. Normative References 📖
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
8.2. Informative References 📝
- [AddrMgmt] Dupont, F., "Address Management for IKE version 2", Work in Progress, November 2005.
- [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002.
- [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", Work in Progress, December 2005.
- [Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", Work in Progress, February 2006.
- [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
- [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Work in Progress, October 2005.
- [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", Work in Progress, January 2006.
- [ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2005.
- [Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress, February 2004.
- [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-IKE)", Work in Progress, February 2005.
- [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", Work in Progress, March 2004.
- [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
- [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
Appendix A. Implementation Considerations 🔧
A.1. Links from SPD Cache to Outbound SAD Entries 🧚
okay so [IPsecArch], Section 4.4.2, says that "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache". 💅 The document doesn't spell out how exactly this "pointing" is done, because it's an implementation detail that doesn't have to be standardized. that's giving "you do you" energy 🫶
BUT ngl the links between the SPD cache and the SAD have to be done correctly so outbound packets go over the right SA. 😭 Some implementations are known to have problems in this area, so pls be careful bestie 🔥
Here's the tea. Storing just the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient 💀 because that pair doesn't always uniquely identify a single SAD entry. For example, two hosts behind the same NAT can accidentally pick the same SPI value. 🙈 It can also happen when a host gets an IP address that some other host used before, and the SAs for the old host haven't been deleted by Dead Peer Detection yet. the result? Packets could get sent over the wrong SA or, if the key management daemon makes sure the pair is unique, it could deny the creation of SAs that are otherwise valid. not the vibe 😩
Storing the remote tunnel header IP address in the SPD cache can also make MOBIKE harder to implement, since the address can change during the lifetime of the SA. 🦋 So we recommend building the links between the SPD cache and the SAD in a way that doesn't need to be modified when MOBIKE updates the tunnel header IP address. main character energy for your code 👑
A.2. Creating Outbound SAs 🌸
When an outbound packet needs IPsec processing but no suitable SA exists, a new SA gets created. 🎀 In this case the host has to figure out (1) who the right peer is for this SA, (2) whether the host already has an IKE_SA with that peer, and (3) if no IKE_SA exists, the IP address(es) of the peer to contact it. it's a whole checklist, bestie 📝
Neither [IPsecArch] nor MOBIKE specifies exactly how these three steps are carried out. [IPsecArch], Section 4.4.3.4, says:
For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X.
In step 1 there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). 🧚 In step 3 the host may need to check a directory such as DNS to find the peer IP address(es). 🔍
When doing these steps, implementations may use information in the SPD, the PAD, and possibly some other implementation-specific databases. ✨ Regardless of how the steps are implemented, it's important to remember that IP addresses can change, and that an IP address alone doesn't always uniquely identify a single IKE peer. (it's the same reason the remote IP address plus SPI combo doesn't uniquely identify an outbound IPsec SA, see Appendix A.1 🙃) So in steps 1 and 2, it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. 🫶 These implementation details are beyond the scope of this specification, so you get to make those calls 💖
Author's Address 🖊️
Pasi Eronen (editor)
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
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 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 provided by the IETF Administrative Support Activity (IASA). 💜🌈
📦 where this page comes from
- ietf: rfc4555 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms