RFC 4621
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol 🎀
Okay bestie, this is RFC 4621 and it's part 1 of 7, so more is coming! 💖 The title block is giving: it's Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol 🦋, written by T. Kivinen (Safenet, Inc.) and H. Tschofenig (Siemens), dated August 2006. It's Category: Informational 🌸, and the header doesn't list any Obsoletes or Updates lines.
Status of This Memo ✨
Quick vibe check first: this memo is informational only 💜 for the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈.
Copyright Notice 🫶
Copyright (C) The Internet Society (2006).
Abstract 🧚
Okay so MOBIKE is an extension of IKEv2 (the Internet Key Exchange Protocol version 2) 🔥. The whole point is to make managing IKE and IPsec Security Associations way more efficient when a host has multiple IP addresses, or when an IPsec host's addresses change over time (think mobility, like when you walk out of wifi range 📱). These extensions should enable this kind of efficient management.
The document talks about the network entities involved and how IKEv2 signaling relates to information from other protocols. It also records the design decisions for MOBIKE, the background info, and the discussions that happened in the working group 🍓.
Table of Contents 📋
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................271. Introduction ✨
Okay so the purpose of IKEv2 is to mutually authenticate two hosts 🫶, set up one or more IPsec Security Associations (SAs) between them, and then keep managing those SAs (like rekeying them or deleting them) 💅. IKEv2 also lets the hosts share info that matters for both the crypto algorithms they'll use (parameters the algorithms need, plus session keys 🔐) and their local security policies, like which traffic should get protected.
IKEv2 assumes an IKE SA gets created implicitly between the IP address pair that's in use while the IKEv2 SA is being set up. So each host only stores one IP address pair for the IKEv2 SA as part of a single IKEv2 protocol session, and for tunnel mode SAs the host puts that one pair in the outer IP headers 🎀. Existing IPsec docs don't really provide a way to change this pair after an IKE SA is created, except for dynamic address update of Network Address Translation Traversal (NAT-T) 🙈.
Here's the problem: there are scenarios where one or both addresses in that pair can change during an IPsec session 😭. In principle you could just re-establish the IKE SA and all the IPsec SAs after the address changes. But that's a pretty expensive move, and it gets really problematic when the changes happen a lot 💀. Plus, manual user interaction might be needed as part of IKEv2 authentication (for example, with human-operated token cards like SecurID) 🍓. So an automatic mechanism is needed to update the IP addresses tied to the IKE SA and the IPsec SAs, and that's exactly what the MOBIKE protocol provides 👑.
MOBIKE is assumed to work on top of IKEv2 [RFC4306]. Since IKEv2 is built on the IPsec architecture [RFC4301], every protocol developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC 4301 🌸. This document doesn't discuss mobility and multi-homing support for IKEv1 [RFC2409] or for the obsoleted IPsec architecture described in RFC 2401 [RFC2401] 🦋.
Here's the roadmap 🗺️: after some important terms are introduced in Section 2, a bunch of relevant usage scenarios get covered in Section 3. Section 4 describes the scope of the MOBIKE protocol, and Section 5 covers design considerations affecting it. Section 6 digs into the details of the MOBIKE protocol. Finally, Section 7 wraps things up with security considerations 🔥.
2. Terminology ✨
This section introduces the terminology used in this document 💜.
Peer
A peer is an IKEv2 endpoint. On top of that, a peer implements the MOBIKE extensions, defined in [RFC4555] 🧚.
Available address
An address is said to be available if the following conditions are met:
- The address has been assigned to an interface.
- If the address is an IPv6 address, we additionally require (a) that the address is valid as defined in RFC 2461 [RFC2461], and (b) that the address is not tentative as defined in RFC 2462 [RFC2462]. In other words, we require the address assignment to be complete.
- Note that this explicitly allows an address to be optimistic as defined in [RFC4429] ✨.
- If the address is an IPv6 address, it is a global unicast or unique site-local address, as defined in [RFC4193]. That is, it is not an IPv6 link-local address.
- The address and interface is acceptable for sending and receiving traffic according to a local policy.
This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context 🎀.
Locally operational address
An address is said to be locally operational if it is available and its use is locally known to be possible and permitted. This definition is taken from [WIP-Ark06] 💅.
Operational address pair
A pair of operational addresses is said to be an operational address pair if and only if bidirectional connectivity can be shown between the two addresses. Note that sometimes it's necessary to consider connectivity on a per-flow level between two endpoints. That differentiation might be necessary to address certain Network Address Translation types or specific firewalls 🙈. This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context. Although it's possible to further differentiate unidirectional and bidirectional operational address pairs, only bidirectional connectivity is relevant to this document, and unidirectional connectivity is out of scope 🚫.
Path
The path is the sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers 🛣️. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire, they might be routed along a different path, for example, due to load balancing ⚖️. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
Current path
The sequence of routers traversed by an IP packet that carries the default source and destination addresses is said to be the Current Path. This definition is taken from [RFC2960] and adapted to the MOBIKE context 🌈.
Preferred address
The preferred address is the IP address of a peer to which MOBIKE and IPsec traffic should be sent by default. A given peer has only one active preferred address at a given point in time, except for the small time period where it switches from an old to a new preferred address ⏱️. This definition is taken from [WIP-Nik06] and adapted to the MOBIKE context.
Peer address set
We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set 📮. That policy might be created either manually or automatically, through interaction with other mechanisms that indicate new available addresses.
Bidirectional address pair
This is the address pair where traffic can be sent in both directions, simply by reversing the IP addresses. Note that the path of the packets going to each direction might be different 🔁.
Unidirectional address pair
This is the address pair where traffic can only be sent in one direction, and reversing the IP addresses and sending a reply back does not work 🙅.
For mobility-related terminology (e.g., Make-before-break or Break-before-make), see [RFC3753] 🦋.
3. Scenarios 🌟
Alright, in this section we're going to discuss three typical usage scenarios for the MOBIKE protocol 💖. Part 2 picks up right here, so stay tuned bestie! 🫶
3.1. Mobility Scenario ✨
okay so Figure 1 is a break-before-make mobility situation 🦋 A mobile node (MN) switches to a new point of network attachment. Before the switch, the MN had already set up an IPsec connection with a security gateway that, for example, gives it access to a corporate network 💼 The IKEv2 exchange that set up the IPsec SA(s) happened over the path labeled 'old path'. Those packets carried the MN's "old" IP address and went through the "old" access router (OAR) to the security gateway (GW).
When the MN moves, it gets a brand-new IP address using stateful or stateless address configuration 🌸 In this scenario, the MOBIKE goal is to let the MN and the GW keep using the existing SAs, so they don't have to set up a new IKE SA from scratch. A protocol exchange called 'MOBIKE Address Update' lets the peers update their state as needed 💜
Note that in a break-before-make scenario, the MN only gets the new IP address after it can't be reached at the old one anymore 🙈 In a make-before-break scenario, though, the MN is reachable at both the old and the new IP address for a while. MOBIKE should work in both of these scenarios, bestie 💅
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario3.2. Multihoming Scenario 🎀
Next up is Figure 2, and this one is giving multiple interfaces 🤩 Here the MOBIKE peers each have several interfaces, which means several IP addresses too. Peer A has two interface cards with two IP addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 and IP_B2. Each peer picks one of its IP addresses as the preferred address, and that's the one used for ongoing communication. Things like hardware or network link failures can force a peer to hop from one interface to another, so it has to be ready for that 🦋
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
Figure 2: Multihoming ScenarioNote that MOBIKE doesn't aim to do load balancing across multiple IP addresses, so each peer uses only one of the available address pairs at any given moment 🙅♀️ One pair at a time, periodt 💖
3.3. Multihomed Laptop Scenario 💻
Scenario three is all about a laptop with multiple interface cards, so it has several ways to get online 🌈 It might have a fixed Ethernet card, a WLAN interface, a General Packet Radio Service (GPRS) adaptor, a Bluetooth interface, or USB hardware. Not every interface is in use all the time, for a bunch of reasons (cost, network availability, user convenience, you know how it is 🙄). The policies that decide which interfaces are connected to the network at a given time are outside the scope of the MOBIKE protocol, and so, as such, this document ✨ Still, when the laptop changes where it's attached to the network, the set of IP addresses it's reachable at changes too 🧚
In all of these scenarios, even when IP addresses change because of interface switching or mobility, the IP address obtained through the configuration payloads within IKEv2 stays the same 💜 That address is what lets you configure the inner IP address of the IPsec tunnel, so applications might not notice any change at all. Slay 👑
4. Scope of MOBIKE ✨
Making mobility and multihoming actually work takes a lot of different parts working together, like coordinating decisions across different layers, different mobility mechanisms, and IPsec/IKEv2 🧩 Most of those pieces are beyond MOBIKE's scope. MOBIKE only focuses on what two peers need in order to agree at the IKEv2 level (like new message formats and some aspects of their processing) needed for interoperability 🫶
MOBIKE is not trying to be a full mobility protocol, bestie 🙃 There's no support for simultaneous movement or a rendezvous mechanism, and there's no support for route optimization, etc. The design document focuses on tunnel mode. Everything going inside the tunnel is unaffected by changes to the tunnel header's IP address, and that's the mobility feature MOBIKE provides 🦋 So applications running inside a MOBIKE-controlled IPsec tunnel might not detect the movement, since their IP addresses stay constant 💅
The MOBIKE protocol should be able to perform the following operations (not all of which are done explicitly by the current protocol) 📝
- Inform the other peer about the peer address set
- Inform the other peer about the preferred address
- Test connectivity along a path and thereby detect an outage situation
- Change the preferred address
- Change the peer address set
- Ability to deal with Network Address Translation devices
Figure 3 shows an example protocol interaction between a pair of MOBIKE peers 🌸 MOBIKE talks to the packet processing module of the IPsec implementation through an internal API (such as those based on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create entries in the Security Association (SAD) and Security Policy Databases (SPD). The packet processing module of the IPsec implementation may also interact with the IKEv2 and MOBIKE module through this API. The content of the Security Policy and Security Association Databases decides what traffic gets protected with IPsec, and how. MOBIKE, on the other hand, gets information from a number of sources that may run in both kernel-mode and user-mode 👀 Those sources are the basis on which MOBIKE makes decisions about the set of available addresses, the peer address set, and the preferred address. Policies may also affect the selection process 💜
The peer address set and the preferred address need to be made available to the other peer 🎀 To handle certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Even though a bunch of address pairs may be available for these tests, the most important one is the pair (source address, destination address) of the current path. That's because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic 🔥 If a problem is detected along this current path (e.g., due to a router failure), the peers need to switch to a new current path. To be able to do that quickly, it may help to periodically run connectivity tests on the other paths too. That kind of technique also helps identify previously disconnected paths that come back online 🌈
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |
+----------------+
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: FrameworkPlease note that Figure 3 is just one example of how a MOBIKE implementation could work 🙏 It's for illustrative purposes only, so don't treat it as the one true way ✨
5. Design Considerations 🧠
This section talks about the aspects that shape the design of the MOBIKE protocol 💖
5.1. Choosing Addresses 🦋
One of the core parts of MOBIKE is picking the address for the IPsec packets we send 📦 Choosing addresses for the IKEv2 request is a somewhat separate problem. In many cases the two will be the same (and in some design choices they will always be the same, and could even be forced to be the same by design) 💅
5.1.1. Inputs and Triggers 🌸
How address changes get triggered is mostly outside MOBIKE's scope 🙈 The triggers can include changes in the set of addresses, various link-layer indications, failing dead peer detection, and changes in preferences and policies. There are also less reliable sources of information (such as lack of IPsec packets and incoming ICMP packets) that don't trigger any changes directly. Instead, they cause Dead Peer Detection (DPD) to be scheduled earlier, and if it fails, it might cause a change of the preferred address 🧚
These triggers are pretty much the same as for other mobility protocols such as Mobile IP, so they're beyond the scope of MOBIKE 🫶
5.1.2. Connectivity ✨
okay so connectivity can break in two flavors: local failures and path failures 💅 Local failures are problems happening right at one MOBIKE peer, like a sad interface error 😭 Path failures are about an address pair and whatever nodes and links sit along that route, so something in the middle can ruin your whole day. MOBIKE does not support unidirectional address pairs, bestie 🙈 Supporting them would mean ditching the rule that an IKEv2 reply goes back to the address the request came from. MOBIKE chose to only deal with bidirectional address pairs. It treats unidirectional ones as broken and never uses them, but the connection between peers won't die just because they show up, as long as there's at least one bidirectional address pair MOBIKE can actually use 🫶
Also, MOBIKE doesn't really care which path is used 🦋 It can't even tell if a path is one-way working when that same address pair has some other one-way path coming back. Ingress filters can still make those path pairs useless, and when that happens MOBIKE will notice there's no working address pair left 💀
Having both an IPv4 and an IPv6 address is basically a case of partial connectivity, lowkey 🌈 (putting both an IPv4 and an IPv6 address in the same IP header just doesn't work). The big difference is that you already know it's going to be like that. There's no need to go hunting to discover that an IPv4/IPv6 combo doesn't work.
5.1.3. Discovering Connectivity 🔍
To detect connectivity, the MOBIKE protocol needs a way to test it ✨ If a MOBIKE peer gets a reply, it can be sure that a working (bidirectional) address pair exists. If a MOBIKE peer doesn't see a reply after several retransmissions, it may assume that the tested address pair is broken 💔
The connectivity tests have to account for congestion, because the connection failure might be caused by congestion 🚦 The MOBIKE protocol should not make the congestion problem worse by sending a ton of DPD packets. Not the vibe 🙅♀️
5.1.4. Decision Making 👑
One of the main questions when designing MOBIKE was who gets to decide how to fix things when a failure is detected. Like, symmetry vs. asymmetry in decision making ⚖️ If both peers can make decisions (symmetric), they might pick different things, and then your upstream and downstream traffic ends up going different ways, which is chaotic 😩 In the mobility case, the mobile peer should be able to move both upstream and downstream traffic onto some particular interface, and that needs asymmetric decision making, where only one peer decides 🎀
Working with stateful packet filters and NATs is also easier when the same address pair is used in both directions 🧚 And in common cases, only the peer sitting behind the NAT can actually do anything to recover from connectivity problems, because the other peer might not be able to start any connections to the peer behind the NAT. Iconic dependency energy 💜
5.1.5. Suggested Approach 🌸
The working group picked a method where the initiator decides which addresses get used. So the outcome is always the same for both parties, no drama 🫶 It also works best with NATs, since the initiator is most likely the node sitting behind a NAT ✨
5.2. NAT Traversal (NAT-T) 🦋
5.2.1. Background and Constraints 🌈
Another core part of MOBIKE is how it handles different NATs and Network Address Port Translations (NAPTs) 💅 In IKEv2, the tunnel header IP addresses aren't sent inside the IKEv2 payloads, so there's no need for unilateral self-address fixing (UNSAF [RFC3424]) 🙌 The tunnel header IP addresses come from the outer IP header of the IKE packets, which means the NAT has already processed them.
The NAT detection payloads are used to figure out whether the addresses in the IP header got modified by a NAT along the path 🔎 Detecting a NAT typically requires UDP encapsulation of IPsec ESP packets to be enabled, if you want it ✨ MOBIKE is not supposed to change how IKEv2 NAT-T works in particular. Any kind of UNSAF or explicit interaction with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is beyond the scope of the MOBIKE protocol, sorry not sorry 🙈 The MOBIKE protocol will still need to define how MOBIKE and NAT-T get used together.
The NAT-T support should also be optional 💖 If an IKEv2 implementation doesn't implement NAT-T, because it isn't required in some particular environment, then implementing MOBIKE should not require adding NAT-T support either.
Being behind a NAT is actually a property of the address pair, and therefore of the path a packet takes 🛤️ So one peer can have multiple IP addresses, and some of them might be behind a NAT while others aren't. Main character multi-address energy 👑
5.2.2. Fundamental Restrictions 🚫
There are some cases MOBIKE just can't handle 😭 One of them is when the party "outside" a symmetric NAT changes its address to something the other peer doesn't know about, and the old address has stopped working. That party can't send a packet with the new addresses to the peer, because the NAT doesn't have the necessary state. And since the party behind the NAT doesn't know the new IP address, it can't cause the NAT state to be created either. Stuck, bestie.
This case could be solved with some rendezvous mechanism outside IKEv2, but that is beyond the scope of MOBIKE. Not our problem to solve here 🙅♀️
5.2.3. Moving behind a NAT and Back 🔄
The MOBIKE protocol should provide a mechanism so that a peer that isn't initially behind a NAT can move behind one when a new preferred address is selected 🦋 The same effect might be achieved by changing the address pair, if more than one path is available (e.g., in the case of a multi-homed host). MOBIKE only has an impact when the currently selected address pair causes MOBIKE packets to traverse a NAT.
Similarly, the MOBIKE protocol provides a mechanism to detect when a NATed path changes to a non-NATed path when the address pair changes ✨
Since we only use one address pair at a time, the MOBIKE peer is effectively either behind a NAT or not, but every address change can flip that situation 🌀 Because of this, and because the initiator always chooses the addresses, it's enough to send keepalive packets only to that one address pair 💜
Enabling NAT-T involves a few different things 🎀 One is enabling UDP encapsulation of ESP packets. Another is changing the IKE SA ports from port 500 to port 4500. We don't want to do unnecessary UDP encapsulation unless there's really a NAT between the peers, so UDP encapsulation should only be enabled when we actually detect a NAT. On the other hand, since all implementations supporting NAT-T must be able to respond on port 4500 all the time, it's simpler from a protocol point of view to switch the port numbers from 500 to 4500 right away, as soon as we detect that the other end supports NAT-T 🧚 That way, we don't have to change ports after we later detect a NAT, which would have caused complications.
If we only changed the port after detecting a NAT, the responder wouldn't be able to use the IKE and IPsec SAs right away once their address changes to something behind a NAT 😩 Instead, it would have to wait for the next packet from the initiator to see which IP and port numbers got used after the initiator switched its port from 500 to 4500. The responder also couldn't send anything to the initiator until the initiator had sent something to the responder first. So if we do the port number change immediately after IKE_SA_INIT and before the IKE_AUTH phase, then we get rid of this problem 🥳
5.2.4. Responder behind a NAT 🏠
MOBIKE can work when the responder is behind a static NAT, but the initiator would need to know all the possible addresses the responder can move to 🗺️ So the responder can't move to an address the initiator doesn't know about, in case the initiator also moves behind a NAT.
If the responder is behind a NAPT, it might need to talk to the NAT to create a mapping so the initiator can connect to it 🔓 Those external firewall pinhole opening mechanisms are beyond the scope of MOBIKE.
And if the responder is behind a NAPT, finding the port numbers the responder uses is outside the scope of MOBIKE too 🙈
5.2.5. NAT Prevention 🛡️
One new feature MOBIKE creates is NAT prevention, and it's giving protection 💅 If we detect a NAT between the peers, we don't allow that address pair to be used. This can protect IP addresses in cases where the configuration knows there's no NAT between the nodes (for example, IPv6, or a fixed site-to-site VPN). It avoids any chance of on-path attackers modifying addresses in headers.
This feature means we authenticate the IP addresses and detect whether they were changed. Since this happens on purpose to break connectivity when a NAT is detected, and it's decided by the configuration, there's no need for UNSAF processing ✨
5.2.6. Suggested Approach 🫶
The working group decided that MOBIKE uses the NAT-T mechanisms from the IKEv2 protocol as much as possible 🌷 But they changed the dynamic address update (see [RFC4306], Section 2.23, second to last paragraph) for IKEv2 packets to "MUST NOT" 🙅♀️ That's because it would break path testing using IKEv2 packets (see Section 6.2). The working group also decided to only send keepalives to the current address pair 💖
5.3. Scope of SA Changes ✨
okay so most of this doc is about keeping addresses fresh in the database entries tied to an IKE SA 🦋. But changing the preferred address also hits the IPsec SA database, and that's a whole thing. The outer tunnel header addresses (source and destination IP addresses) need to be changed to match the current path, so the IPsec protected data traffic follows the same path as the MOBIKE packets 🛣️. If the MOBIKE messages and the IPsec protected data traffic travel different paths, then NAT handling gets severely complicated 💀.
So the big question is how the IPsec SAs get switched over to the new address pair (the same one the MOBIKE signaling traffic uses). Option one: whenever the IKE SA address changes, every IPsec SA attached to it gets moved along automatically to the new pair. Option two: a separate exchange just for moving IPsec SAs ✨.
If we go with separate updates, we need something more efficient than the Notify payload to save bandwidth. A Notify payload can only hold one Security Parameter Index (SPI) per payload. A separate payload could carry a list of IPsec SA SPIs plus the new preferred address. With a lot of IPsec SAs, those payloads get huge unless lists of ranges of SPI values are supported 😭.
But if we auto-move all IPsec SAs when the IKE SA moves, then we only need to remember which IKE SA created each IPsec SA, and grab the IP addresses from that IKE SA. No need to store IP addresses per IPsec SA! Note that IKEv2 [RFC4306] already requires implementations to keep track of which IPsec SAs are created using which IKE SA 🧠.
If we do let each IPsec SA's address set update separately, we can support a scenario where a machine has fast and/or cheap connections plus slow and/or expensive ones. It can move some SAs onto the slower or pricier link and block the move of others, like keeping the news video stream from jumping from the WLAN to the GPRS link 📺.
On the flip side, even if we tie IKE SA updates to IPsec SA updates, we can create separate IKE SAs for this. For example, we could create one IKE SA with both links as endpoints, used for important traffic, and then another IKE SA with only the fast and/or cheap connection, used for that kind of bulk traffic 🚀.
The working group decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created, one for each set of IPsec SAs needed 🎀.
5.4. Zero Address Set Functionality 💤
One feature that's potentially useful is when the peer announces that it's about to disconnect for some time, i.e., it won't be reachable at all. Think a laptop going into suspend mode 💻😴. It could send an address notification with zero new addresses, which would mean it doesn't have any valid addresses anymore. The responder would acknowledge that notification and could then temporarily disable all SAs, and therefore stop sending traffic. If any of the SAs get packets, they're simply dropped. This could also include some kind of ACK spoofing to keep TCP/IP sessions alive (or just setting the TCP/IP keepalives and timeouts large enough not to cause problems), or it could be left to the applications, e.g., letting TCP/IP sessions notice if the link is broken 🌸.
The local policy could then indicate how long the peer should allow remote peers to remain disconnected.
From a technical point of view, this would provide the following two features:
- There is no need to transmit IPsec data traffic. IPsec-protected data can be dropped, which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided.
- MOBIKE signaling messages are also ignored. The IKE SA must not be deleted, and the suspend functionality (realized with the zero address set) may require the IKE SA to be tagged with a lifetime value, since the IKE SA should not be kept alive for an undefined period of time. Note that IKEv2 does not require that the IKE SA has a lifetime associated with it. In order to prevent the IKE SA from being deleted, the dead-peer detection mechanism needs to be suspended as well.
Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature 🙅♀️.
5.5. Return Routability Check 🔁
Changing the preferred address and then using it for communication is tied to an authorization decision: is a peer allowed to use this address? Does this peer own this address? Two mechanisms have been proposed to let a peer answer those questions:
- The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appearing in it 📜.
- A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done to give the remote peer a certain degree of confidence that the local peer is reachable at the indicated address.
Without taking an authorization decision, a malicious peer can redirect traffic toward a third party or a black hole 😈.
A MOBIKE peer should not use an IP address provided by another MOBIKE peer as a current address without computing the authorization decision. If the addresses are part of the certificate, then it is not necessary to execute the return routability check. The return routability check is a form of authorization check, although it provides weaker guarantees than including the IP address as part of a certificate. If multiple addresses are communicated to the remote peer, then some of these addresses may already be verified ✅.
Finally, it would be possible not to execute return routability checks at all. In the case of indirect change notifications (i.e., something we notice from the network, not from the peer directly), we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check. With a direct notification (i.e., notification from the other end directly), the authenticated peer may have provided an authenticated IP address (i.e., inside the IKE encrypted and authenticated payload; see Section 5.2.5). Thus, it would be possible to simply trust the MOBIKE peer to provide a proper IP address. In this case, protection against an internal attacker (i.e., the authenticated peer forwarding its traffic to the new address) would not be provided. On the other hand, we know the identity of the peer in that case. There might be problems when extensions are added to IKEv2 that do not require authentication of end points (e.g., opportunistic security using anonymous Diffie-Hellman).
There's also a policy question about when to schedule a return routability check. Before moving traffic? After moving traffic? 🤔
The basic format of the return routability check could be similar to dead-peer detection, but potential attacks are possible if a return routability check does not include some kind of nonce. In these attacks, the valid end point could send an address update notification for a third party, trying to get all the traffic sent there, causing a denial-of-service attack 💥. If the return routability check does not contain any nonce or other random information not known to the other peer, then the other peer could reply to the return routability checks even when it cannot see the request. This might cause a peer to move the traffic to a location where the original recipient cannot be reached.
The IKEv2 NAT-T mechanism does not perform return routability checks. It simply uses the last seen source IP address used by the other peer as the destination address to which response packets are sent. An adversary can change those IP addresses and cause the response packets to be sent to a wrong IP address. The situation fixes itself when the adversary is no longer able to modify packets and the first packet with an unmodified IP address reaches the other peer. Mobility environments make this attack more difficult for an adversary, since the attack requires the adversary to be located somewhere on the individual paths ({CoA1, ..., CoAn} towards the destination IP address), to have a shared path, or, if the adversary is located near the MOBIKE client, to follow the user's mobility patterns. With IKEv2 NAT-T, the genuine client can cause third-party bombing by redirecting all the traffic pointed at it to a third party. As the MOBIKE protocol tries to provide equal or better security than the IKEv2 NAT-T mechanism, it should protect against these attacks 🛡️.
There may be return routability information available from other parts of the system too (as shown in Figure 3), but the checks done may have a different quality. There are multiple levels for return routability checks:
- None; no tests.
- A party willing to answer the return routability check is located along the path to the claimed address. This is the basic form of return routability check.
- There is an answer from the tested address, and that answer was authenticated and integrity- and replay-protected.
- There was an authenticated and integrity- and replay-protected answer from the peer, but it is not guaranteed to originate at the tested address or path to it (because the peer can construct a response without seeing the request).
The return routability checks do not protect against third-party bombing if the attacker is along the path, as the attacker can forward the return routability checks to the real peer (even if those packets are cryptographically authenticated).
If the address to be tested is carried inside the MOBIKE payload, then the adversary cannot forward packets. Thus, third-party bombings are prevented (see Section 5.2.5).
If the reply packet can be constructed without seeing the request packet (for example, if there is no nonce, challenge, or similar mechanism to show liveness), then the genuine peer can cause third-party bombing by replying to those requests without seeing them at all 😱.
Other levels might only provide a guarantee that there is a node at the IP address that replied to the request. There is no indication as to whether or not the reply is fresh or whether or not the request may have been transmitted from a different source address.
5.5.1. Employing MOBIKE Results in Other Protocols ✨
okay so here's a big question 🤔 if MOBIKE figures out new locations or double-checks that a remote address is legit through a return routability check, can that info help other protocols? when we look at the basic MOBIKE VPN scenario, the answer is no 💀 transport and application layer protocols running inside the VPN tunnel are literally unaware of the outer addresses or their status 🙈
similarly, IP-layer tunnel termination at a gateway instead of a host endpoint kinda limits the perks for "other protocols" that could be informed. like, all the application protocols on the other side have no idea IPsec, IKE, or MOBIKE even exist 😭
however, it's conceivable that future uses or extensions of MOBIKE could make sharing this info super useful 🦋 for instance, if transport mode MOBIKE and SCTP were made to work together, it would potentially be useful for SCTP dynamic address reconfiguration [WIP-Ste06] to learn about the new addresses at the same time as MOBIKE. similarly, various IP-layer mechanisms may make use of the fact that a return routability check of a specific type has been performed. however, care should be exercised in all these situations 🫶
[WIP-Cro04] discusses the use of common locator information pools in an IPv6 multi-homing context. it assumes that both transport and IP-layer solutions are used to support multi-homing, and that it would be beneficial for different protocols to coordinate their results in some way, for instance, by sharing throughput information of address pairs. this may apply to MOBIKE as well, assuming it coexists with non-IPsec protocols that are faced with the same or similar multi-homing choices 🌈
nevertheless, all of this is outside the scope of the current MOBIKE base protocol design and may be addressed in future work ✨
5.5.2. Return Routability Failures 💀
okay, so if the return routability check fails, we need to tear down the IKE SA if we're using INFORMATIONAL exchanges from IKEv2 to send return routability checks. on the other hand, return routability checks can only fail permanently if there was an attack by the other end. so tearing down the IKE SA is a suitable action in that case 🔥
there are some cases where the return routability check temporarily fails, and we need to think about those too 🥺 in the first case, there's no attacker, but the selected address pair stops working immediately after the address update, before the return routability check.
what happens is that the initiator does the normal address update, and it succeeds. then the responder starts a return routability check. if the address pair has already broken down by then, the responder will never get the reply to the return routability check back. the responder might still be using the old IP address pair, which could still work 🤷♀️
the initiator might still be seeing traffic from the responder, but it's using the old address pair. the initiator should detect that this traffic is not using the latest address pair, and after a while it should start dead peer detection on the current address pair. if that fails, it should find a new working address pair and update addresses to that. the responder should notice that the address pair was updated after the return routability check started, and change the ongoing return routability check to use the new address pair. the result of that return routability check needs to be discarded, because it can't be trusted: the packets were retransmitted to a different IP address. so normally the responder starts a new return routability check afterward with the new address pair 💅
the second case is where there's an attacker along the path modifying the IP addresses. the peers will detect this as NAT and will enable NAT-T recovery of changes in the NAT mappings. if the attacker is along the path long enough for the return routability check to succeed, then the normal recovery of changes in the NAT mappings will take care of the problem 🫠 if the attacker disappears before the return routability check is finished, but after the update, we have a case similar to the last one. the only difference is that now the dead peer detection started by the initiator will succeed, because the responder will reply to the addresses in the headers, not the current address pair. the initiator will then detect that the NAT mappings have changed, and it will fix the situation by doing an address update 🔧
the important thing for both of these cases is that the initiator needs to see that the responder is both alive and synchronized with initiator address pair updates. that means it's not enough that the responder is sending traffic to an initiator; it must also be using the correct IP addresses before the initiator can believe it's alive and synchronized. from the implementation point of view, this means the initiator must not consider packets having wrong IP addresses as packets that prove the other end is alive. in other words, they do not reset the dead peer detection timers 🚫⏱️
5.5.3. Suggested Approach 🎀
the working group selected IKEv2 INFORMATIONAL exchanges as a return routability check, but included a random cookie to prevent redirection by an authenticated attacker 🔐 return routability checks are performed by default before moving the traffic. however, these tests are optional. nodes may also perform these tests on their own initiative at other times 🌸
it's worth noting that the return routability check in MOBIKE is different from Mobile IPv6 [RFC3775], which doesn't do return routability operations between the mobile node and its home agent at all 👀
5.6. IPsec Tunnel or Transport Mode 🚇
the current MOBIKE design is focused only on the VPN type usage and tunnel mode. transport mode behavior would also be useful and might be discussed in future documents 🧚
6. Protocol Details 💜
6.1. Indicating Support for MOBIKE 📣
in order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. if one of the peers doesn't support MOBIKE, then, whenever an IP address changes, IKEv2 has to be re-run to create a new IKE SA and the respective IPsec SAs 😩 in MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. if these messages aren't understood, connectivity between the peers could be lost 🙃
one way to make sure a peer gets feedback on whether its messages are understood is to use IKEv2 messaging for MOBIKE and mark some messages as "critical". according to the IKEv2 specification, either such messages have to be understood by the receiver, or an error message has to be returned to the sender 📨
a second way to get that feedback is by using Vendor ID payloads exchanged during the initial IKEv2 exchange. these payloads would then indicate whether or not a given peer supports the MOBIKE protocol 🏷️
a third approach would use the Notify payload to indicate support of the MOBIKE extension. these Notify payloads are also used for indicating NAT traversal support (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads) 🗺️
both a Vendor ID and a Notify payload may be used to indicate the support of certain extensions 🍓
note that a MOBIKE peer could also attempt to execute MOBIKE opportunistically with the critical bit set when an address change has occurred. the drawback of this approach, however, is that an unnecessary message exchange is introduced 🙈
although Vendor ID payloads and Notify payloads are technically equivalent, Notify payloads are already used in IKEv2 as a capability negotiation mechanism. so Notify payloads are used in MOBIKE to indicate support of the MOBIKE protocol 💖
also, since the information about MOBIKE support isn't needed during the IKE_SA_INIT exchange, the indication of support is done inside the IKE_AUTH exchange. the reason is the need to keep IKE_SA_INIT messages as small as possible so that they don't get fragmented 📏 IKEv2 lets the responder do stateless processing of the first IKE_SA_INIT packet and request a cookie from the other end if it's under attack. requiring the responder to be able to reassemble initial IKE_SA_INIT packets would not allow fully stateless processing of those initial packets, so that's a no-go 🙅♀️
6.2. Path Testing and Window size 🛣️
okay, so IKEv2 has a window of outgoing messages, and the sender isn't allowed to violate that window. meaning that if the window is full, the sender cannot send packets. this can cause some complications for path testing 😵💫 another complication from IKEv2 is that once the message is created and sent to the other end, it can't be modified in its future retransmissions. this makes it impossible to know which packet actually reached the other end first. we can't use IP headers to figure that out, because if the responder gets retransmissions of a packet it has already processed and replied to (and those replies might have been lost due to a unidirectional address pair), it will retransmit the previous reply using the new address pair of the request. because of this, the responder might have already used the IP address information from the header of the previous packet, and the reply ending up at the initiator could have a different address pair 🌀
another complication comes from NAT-T. the current IKEv2 document says that if NAT-T is enabled, the node not behind NAT SHOULD detect if the IP address changes in incoming authenticated packets and update the remote peer's addresses accordingly. this works fine with NAT-T, but it causes some complications in MOBIKE, because MOBIKE needs the ability to probe other address pairs without breaking the old one 😤
one approach to fix this would be to add a completely new protocol that sits outside the IKE SA message ID limitations (window code), outside the identical retransmission requirements, and outside the dynamic address updating of NAT-T 🆕
another approach is to make the protocol so that it doesn't violate window restrictions and doesn't require changing the packet on retransmissions, and to change the dynamic address updating of NAT-T to "MUST NOT" for IKE SA packets if MOBIKE is used. to not violate window restrictions, the addresses of the currently ongoing exchange need to be changed to test different paths. to not require the packet to be changed after it's first sent, the protocol has to restart from the beginning in case the packet was retransmitted to different addresses (because the sender doesn't know which packet the responder got first, i.e., which IP addresses it used) 🔁
the working group decided to use normal IKEv2 exchanges for path testing and to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets. a new protocol outside of IKEv2 was not adopted 💅✨
6.3. Message Presentation ✨
okay so bestie, the IP address change notifications can be sent either through an informational exchange that's already specified in IKEv2, or through a MOBIKE-specific message exchange 🦋 the informational exchange is lowkey the move because it's already in IKEv2, so implementations can already pull the functionality in with zero extra work 💅
next up is the format of the address update notifications. these can include multiple addresses, and some of them may be IPv4 while others are IPv6 🌈 the number of addresses is most likely going to be limited in typical environments (with less than 10 addresses) 🎀 the format may need to indicate a preference value for each address. it could either contain a preference number that sets the relative order of the addresses, or it could simply be an ordered list of IP addresses. if you use preference numbers then two addresses can end up with the same preference value, but an ordered list avoids that whole situation 🙈
load balancing is currently outside the scope of MOBIKE 🌸 however, future work might add support for it, so the selected format needs to be flexible enough to hold extra information in future versions of the protocol (e.g., to enable load balancing). this may be done with a reserved field that can later be used to store additional information. other information may need to be tied to an address in the future too, so a reserved field seems like a prudent design either way 🧚
there are two basic formats for putting IP address lists into a message:
- each IP address gets its own payload. the payload order can indicate the preference order, or the payload itself might include the preference number.
- the whole IP address list goes into one payload for the exchange, and that one payload has an internal format that holds the list of IP addresses.
having multiple payloads, each one carrying one IP address, makes the protocol probably easier to parse, since we can already use the normal IKEv2 payload parsing procedures 🫶 it also offers an easy way to do extensions, because the payload probably contains only the type of the IP address (or the type is encoded in the payload type) and the IP address itself. each payload already has a length field associated with it, so we can detect if there is any extra data after the IP address. some implementations might have problems parsing more than a certain number of IKEv2 payloads, but if the sender sends them with the most preferred first, the receiver can only use the first addresses it was willing to parse. that's giving careful design energy 👑
having all IP addresses in one big MOBIKE-specified internal format gives a more compact encoding and keeps the MOBIKE implementation more concentrated in one module 🍓
another choice is which type of payload to use. IKEv2 already specifies a Notify payload. it includes some extra fields (SPI size, SPI, protocol, etc.), which adds 4 bytes of extra overhead, and there is the notification data field, which could include the MOBIKE-specific data 💜
another option would be a custom payload type, which would then include the information needed for the MOBIKE protocol ✨
the working group decided to use IKEv2 Notify payloads and to put only one data item per notify. there will be one Notify payload for each item to be sent 🔥
the Notify payload choice is the final call, so every address item rides in its own Notify payload.
6.4. Updating Address Set 🦋
because the initiator decides all address updates, the initiator needs to know all the addresses used by the responder 👑 the responder also needs that list in case it moves to an address the initiator doesn't know about, since it then needs to send an address update notification to the initiator. it might also need to try different addresses for the initiator 🌈
MOBIKE could send the whole peer address list every time any of the IP addresses change (addresses are added or removed, the order changes, or the preferred address is updated), or it could send an incremental update 💅 sending incremental updates gives more compact packets (meaning we can support more IP addresses), but on the other hand this approach has more problems with synchronization and packet reordering. incremental updates must be processed in order, but for full updates we can simply use the most recent one and ignore old ones, even if they arrive after the most recent one (IKEv2 packets have a message ID that is incremented for each packet, so it's easy to know the sending order) 🧚
the working group decided to use a protocol format where both ends send a full list of their addresses to the other end, and that list overwrites the previous list. to support NAT-T, the IP addresses of the received packet are considered as one address of the peer, even when they are not present in the list 🎀
7. Security Considerations 💀
okay this section is so important bestie, pls read it fr 😭
as all the packets are already authenticated by IKEv2, there is no risk that any attacker would undetectedly modify the contents of the packets 🔒 the IP addresses in the IP header of the packets are NOT authenticated though, so the protocol defined has to make sure they are only used as an indication that something might be different, and that they do not cause any direct actions, except when doing NAT traversal 🙈
an attacker can also spoof ICMP error messages to confuse the peers about which addresses aren't working. at worst, this causes denial of service and/or the use of non-preferred addresses 💔
one type of attack that needs to be taken care of in the MOBIKE protocol is the bombing attack type. see [RFC4225] and [Aur02] for more information about flooding attacks 🌊
see the security considerations section of [RFC4555] for more information about security considerations of the actual protocol 🔐
8. Acknowledgements 🫶
this document is the result of discussions in the MOBIKE working group. the authors would like to thank Jari Arkko, Pasi Eronen, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen Stillman for their input 💖
we would like to particularly thank Pasi Eronen for tracking open issues on the MOBIKE mailing list. he helped us make good progress on the document 👑
9. References 📚
9.1. Normative references
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.9.2. Informative References
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las
Vegas, NV USA, December 2002.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
E. Nordmark, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", Work in
Progress, June 2006.
[WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator
Pools", Work in Progress, February 2004.
[WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with
the Host Identity Protocol", Work in Progress,
June 2006.
[WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Work in Progress,
June 2006.
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Davies, "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, June 2006.Authors' Addresses 🎀
Tero Kivinen
Safenet, Inc.
Fredrikinkatu 47
HELSINKI FI-00100
FI
EMail: kivinen@safenet-inc.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.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 💅
okay so the IETF is being super neutral here 🫶 It takes no position on whether any Intellectual Property Rights or other rights someone might claim over the tech in this doc are valid, how far they reach, or whether any license under them is even available. It also doesn't claim it went hunting for those rights itself 🕵️♀️ If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 💖
The IETF also invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬 bestie, you literally just email them 💌
Acknowledgement 🌸
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🙌✨
📦 where this page comes from
- ietf: rfc4621 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms