From c25ef47702748e8746492123628d5e831582cbbf Mon Sep 17 00:00:00 2001 From: Martin Willi Date: Wed, 20 Jun 2007 10:12:11 +0000 Subject: [PATCH] added MOBIKE rfc --- doc/standards/rfc4555.txt | 1851 +++++++++++++++++++++++++++++++++++++ 1 file changed, 1851 insertions(+) create mode 100644 doc/standards/rfc4555.txt diff --git a/doc/standards/rfc4555.txt b/doc/standards/rfc4555.txt new file mode 100644 index 000000000..9b2a58978 --- /dev/null +++ b/doc/standards/rfc4555.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group P. Eronen, Ed. +Request for Comments: 4555 Nokia +Category: Standards Track June 2006 + + + IKEv2 Mobility and Multihoming Protocol (MOBIKE) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes the MOBIKE protocol, a mobility and + multihoming extension to Internet Key Exchange (IKEv2). MOBIKE + allows the IP addresses associated with IKEv2 and tunnel mode IPsec + Security Associations to change. A mobile Virtual Private Network + (VPN) client could use MOBIKE to keep the connection with the VPN + gateway active while moving from one address to another. Similarly, + a multihomed host could use MOBIKE to move the traffic to a different + interface if, for instance, the one currently being used stops + working. + + + + + + + + + + + + + + + + + + + + + +Eronen Standards Track [Page 1] + +RFC 4555 MOBIKE Protocol June 2006 + + +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 . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + +Eronen Standards Track [Page 2] + +RFC 4555 MOBIKE Protocol June 2006 + + +1. Introduction + +1.1. Motivation + + IKEv2 is used for performing mutual authentication, as well as + establishing and maintaining IPsec Security Associations (SAs). In + the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec + SAs are created implicitly between the IP addresses that are used + when the IKE_SA is established. These IP addresses are then used as + the outer (tunnel header) addresses for tunnel mode IPsec packets + (transport mode IPsec SAs are beyond the scope of this document). + Currently, it is not possible to change these addresses after the + IKE_SA has been created. + + There are scenarios where these IP addresses might change. One + example is mobility: a host changes its point of network attachment + and receives a new IP address. Another example is a multihoming host + that would like to change to a different interface if, for instance, + the currently used interface stops working for some reason. + + Although the problem can be solved by creating new IKE and IPsec SAs + when the addresses need to be changed, this may not be optimal for + several reasons. In some cases, creating a new IKE_SA may require + user interaction for authentication, such as entering a code from a + token card. Creating new SAs often involves expensive calculations + and possibly a large number of round-trips. For these reasons, a + mechanism for updating the IP addresses of existing IKE and IPsec SAs + is needed. The MOBIKE protocol described in this document provides + such a mechanism. + + The main scenario for MOBIKE is enabling a remote access VPN user to + move from one address to another without re-establishing all security + associations with the VPN gateway. For instance, a user could start + from fixed Ethernet in the office and then disconnect the laptop and + move to the office's wireless LAN. When the user leaves the office, + the laptop could start using General Packet Radio Service (GPRS); + when the user arrives home, the laptop could switch to the home + wireless LAN. MOBIKE updates only the outer (tunnel header) + addresses of IPsec SAs, and the addresses and other traffic selectors + used inside the tunnel stay unchanged. Thus, mobility can be + (mostly) invisible to applications and their connections using the + VPN. + + + + + + + + + +Eronen Standards Track [Page 3] + +RFC 4555 MOBIKE Protocol June 2006 + + + MOBIKE also supports more complex scenarios where the VPN gateway + also has several network interfaces: these interfaces could be + connected to different networks or ISPs, they may be a mix of IPv4 + and IPv6 addresses, and the addresses may change over time. + Furthermore, both parties could be VPN gateways relaying traffic for + other parties. + +1.2. Scope and Limitations + + This document focuses on the main scenario outlined above and + supports only tunnel mode IPsec SAs. + + The mobility support in MOBIKE allows both parties to move, but does + not provide a "rendezvous" mechanism that would allow simultaneous + movement of both parties or discovery of the addresses when the + IKE_SA is first established. Therefore, MOBIKE is best suited for + situations where the address of at least one endpoint is relatively + stable and can be discovered using existing mechanisms such as DNS + (see Section 3.1). + + MOBIKE allows both parties to be multihomed; however, only one pair + of addresses is used for an SA at a time. In particular, load + balancing is beyond the scope of this specification. + + MOBIKE follows the IKEv2 practice where a response message is sent to + the same address and port from which the request was received. This + implies that MOBIKE does not work over address pairs that provide + only unidirectional connectivity. + + Network Address Translators (NATs) introduce additional limitations + beyond those listed above. For details, refer to Section 2.3. + + The base version of the MOBIKE protocol does not cover all potential + future use scenarios, such as transport mode, application to securing + SCTP, or optimizations desirable in specific circumstances. Future + extensions may be defined later to support additional requirements. + Please consult the MOBIKE design document [Design] for further + information and rationale behind these limitations. + +1.3. Terminology and Notation + + When messages containing IKEv2 payloads are described, optional + payloads are shown in brackets (for instance, "[FOO]"), and a plus + sign indicates that a payload can be repeated one or more times (for + instance, "FOO+"). To provide context, some diagrams also show what + existing IKEv2 payloads would typically be included in the exchanges. + These payloads are shown for illustrative purposes only; see [IKEv2] + for an authoritative description. + + + +Eronen Standards Track [Page 4] + +RFC 4555 MOBIKE Protocol June 2006 + + + When this document describes updating the source/destination + addresses of an IPsec SA, it means updating 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 Security Association + Database (SAD), Security Policy Database (SPD), and Peer + Authorization Database (PAD) described in [IPsecArch] are actually + implemented, an implementation can have several different places that + have to be updated. + + In this document, the term "initiator" means the party who originally + initiated the first IKE_SA (in a series of possibly several rekeyed + IKE_SAs); "responder" is the other peer. During the lifetime of the + IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA + exchanges; in this case, the terms "exchange initiator" and "exchange + responder" are used. The term "original initiator" (which in [IKEv2] + refers to the party who started the latest IKE_SA rekeying) is not + 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 + + MOBIKE allows both parties to have several addresses, and there are + up to N*M pairs of IP addresses that could potentially be used. The + decision of which of these pairs to use has to take into account + several factors. First, the parties may have preferences about which + interface should be used due to, for instance, performance and cost + reasons. Second, the decision is constrained by the fact that some + of the pairs may not work at all due to incompatible IP versions, + outages in the network, problems at the local link at either end, and + so on. + + MOBIKE solves this problem by taking a simple approach: the party + that initiated the IKE_SA (the "client" in a remote access VPN + scenario) is responsible for deciding which address pair is used for + the IPsec SAs and for collecting the information it needs to make + this decision (such as determining which address pairs work or do not + work). The other party (the "gateway" in a remote access VPN + scenario) simply tells the initiator what addresses it has, but does + not update the IPsec SAs until it receives a message from the + initiator to do so. This approach applies to the addresses in the + IPsec SAs; in the IKE_SA case, the exchange initiator can decide + which addresses are used. + + + +Eronen Standards Track [Page 5] + +RFC 4555 MOBIKE Protocol June 2006 + + + Making the decision at the initiator is consistent with how normal + IKEv2 works: the initiator decides which addresses it uses when + contacting the responder. It also makes sense, especially when the + initiator is a mobile node: it is in a better position to decide + which of its network interfaces should be used for both upstream and + downstream traffic. + + The details of exactly how the initiator makes the decision, what + information is used in making it, how the information is collected, + how preferences affect the decision, and when a decision needs to be + changed are largely beyond the scope of MOBIKE. This does not mean + that these details are unimportant: on the contrary, they are likely + to be crucial in any real system. However, MOBIKE is concerned with + these details only to the extent that they are visible in IKEv2/IPsec + messages exchanged between the peers (and thus need to be + standardized to ensure interoperability). + + Many of these issues are not specific to MOBIKE, but are common with + the use of existing hosts in dynamic environments or with mobility + protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms + already exist or are being developed to deal with these issues. For + instance, link-layer and IP-layer mechanisms can be used to track the + status of connectivity within the local link [RFC2461]; movement + detection is being specified for both IPv4 and IPv6 in [DNA4], + [DNA6], and so on. + + Naturally, updating the addresses of IPsec SAs has to take into + account several security considerations. MOBIKE includes two + features designed to address these considerations. First, a "return + routability" check can be used to verify the addresses provided by + the peer. This makes it more difficult to flood third parties with + large amounts of traffic. Second, a "NAT prohibition" feature + ensures that IP addresses have not 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 + + A simple MOBIKE exchange in a mobile scenario is illustrated below. + The notation is based on [IKEv2], Section 1.2. In addition, the + source/destination IP addresses and ports are shown for each packet: + here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by + the initiator and the responder. + + + + + + + + +Eronen Standards Track [Page 6] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 inform + each other that they support MOBIKE. In step 3, the initiator + notices a change in its own address, and informs the responder about + + + +Eronen Standards Track [Page 7] + +RFC 4555 MOBIKE Protocol June 2006 + + + this by sending an INFORMATIONAL request containing the + UPDATE_SA_ADDRESSES notification. The request is sent using the new + IP address. At this point, it also starts to use the new address as + a source address in its own outgoing ESP traffic. Upon receiving the + UPDATE_SA_ADDRESSES notification, the responder records the new + address and, if it is required by policy, performs a return + routability check of the address. When this check (step 4) + completes, the responder starts to use the new address as the + destination for its outgoing ESP traffic. + + Another protocol run in a multihoming scenario is illustrated below. + In this scenario, 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.) + + + + + + + + + + +Eronen Standards Track [Page 8] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 contain NATs or stateful + packet filters (for brevity, the rest of this document simply + describes NATs). The NAT Traversal feature specified in [IKEv2] + allows IKEv2 to work through NATs in many cases, and MOBIKE can + leverage this functionality: when the addresses used for IPsec SAs + are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as + needed. + + Nevertheless, there are some limitations because NATs usually + introduce an asymmetry into the network: only packets coming from the + "inside" cause state to be created. This asymmetry leads to + + + +Eronen Standards Track [Page 9] + +RFC 4555 MOBIKE Protocol June 2006 + + + restrictions on what MOBIKE can do. To give a concrete example, + consider a situation where both peers have only a single address, and + the initiator is behind a NAT. If the responder's address now + changes, it needs to send a packet to the initiator using its new + address. However, if the NAT is, for instance, of the common + "restricted cone" type (see [STUN] for one description of different + NAT types), this is 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 cannot do until it knows the + address). + + For simplicity, MOBIKE does not attempt to handle all possible NAT- + related scenarios. Instead, MOBIKE assumes that if NATs are present, + the initiator is the party "behind" the NAT, and the case where the + responder's addresses change is not fully supported (meaning that no + special effort is made to support this functionality). Responders + may also be unaware of NATs or specific types of NATs they are + behind. However, when a change has occurred that will cause a loss + of connectivity, MOBIKE responders will still attempt to inform the + initiator of the change. Depending on, for instance, the exact type + of NAT, it may or may not succeed. However, analyzing the exact + circumstances when this will or will not 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 that the initial IKE exchange can be carried out. Any information + from MOBIKE extensions will only be available later, when the + exchange has progressed far enough. Exactly how the addresses used + for the initial exchange are discovered is beyond the scope of this + specification; typical sources of information include local + configuration and DNS. + + If either or both of the peers have multiple addresses, some + combinations may not work. Thus, 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 wish 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). + + + + +Eronen Standards Track [Page 10] + +RFC 4555 MOBIKE Protocol June 2006 + + + The format of the MOBIKE_SUPPORTED notification is described in + Section 4. + +3.3. Initial Tunnel Header Addresses + + When an IPsec SA is created, the tunnel header IP addresses (and + port, if doing UDP encapsulation) are taken from the IKE_SA, not the + IP header of the IKEv2 message requesting the IPsec SA. The + addresses in the IKE_SA are initialized from the IP header of the + first IKE_AUTH request. + + The addresses are taken from the IKE_AUTH request because IKEv2 + requires changing from port 500 to 4500 if a NAT is discovered. To + simplify things, 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 (this way, + there is no need to change the ports later if a NAT is detected on + some other path). + +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 (in case of 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. + + Although both the initiator and responder maintain a set of peer + addresses (logically associated with the IKE_SA), it is important to + note that they use this information for slightly different purposes. + + + +Eronen Standards Track [Page 11] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 + described in Section 3.5. The responder normally does not use the + set of initiator addresses for anything: the addresses are used only + 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 information + is described 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 received by the + responder will be incorrect. This means the procedure for changing + responder addresses described 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 other purpose than what is + explicitly described either in this document or a future + specification updating it. + +3.5. Changing Addresses in IPsec SAs + + In MOBIKE, the initiator decides what addresses are used in the IPsec + SAs. That is, the responder does not normally update any IPsec SAs + without receiving an explicit UPDATE_SA_ADDRESSES request from the + initiator. (As described below, the responder can, however, update + the IKE_SA in some circumstances.) + + The reasons why the initiator wishes to change the addresses are + largely beyond the scope of MOBIKE. Typically, triggers include + information received from lower layers, such as changes in IP + addresses or link-down indications. Some of this information can be + unreliable: for instance, ICMP messages could be spoofed by an + attacker. Unreliable information SHOULD be treated only as a hint + that there might be a problem, and the initiator SHOULD trigger Dead + Peer Detection (that is, send an INFORMATIONAL request) to determine + if 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, possibly leading to changing the + addresses. + + o 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. + + + + + +Eronen Standards Track [Page 12] + +RFC 4555 MOBIKE Protocol June 2006 + + + o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, + ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification 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 currently used address. + + o An UNACCEPTABLE_ADDRESSES notification is received as a response + to address update request (described below). + + o The initiator receives a NAT_DETECTION_DESTINATION_IP notification + that does not match the previous UPDATE_SA_ADDRESSES response (see + Section 3.8 for a more detailed description). + + The description in the rest of this section assumes that the + initiator has already decided what the new addresses should be. When + this decision has been made, the initiator: + + o Updates the IKE_SA with the new addresses, and sets the + "pending_update" flag in the IKE_SA. + + o 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 the check has + not been done for this responder address yet). + + o If the IPsec SAs were updated in the previous step: If NAT + Traversal is not enabled, and 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, enables NAT Traversal (that is, enables + UDP encapsulation of outgoing ESP packets and sending of NAT- + Keepalive packets). + + o If there are outstanding IKEv2 requests (requests for which the + initiator has not yet received a reply), continues retransmitting + them using the addresses in the IKE_SA (the new addresses). + + o When the window size allows, sends an INFORMATIONAL request + containing the UPDATE_SA_ADDRESSES notification (which does not + contain any data), and clears the "pending_update" flag. The + request will be as follows: + + + + + + + + + + +Eronen Standards Track [Page 13] + +RFC 4555 MOBIKE Protocol June 2006 + + + Initiator Responder + ----------- ----------- + HDR, SK { N(UPDATE_SA_ADDRESSES), + [N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP)], + [N(NO_NATS_ALLOWED)], + [N(COOKIE2)] } --> + + o If a new address change occurs while waiting for the response, + starts again from the first step (and ignores responses to this + UPDATE_SA_ADDRESSES request). + + When processing an INFORMATIONAL request containing the + UPDATE_SA_ADDRESSES notification, the responder: + + o 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, it is possible that requests are + received out of order). If it has, a normal response message + (described below) is sent, but no other action is taken. + + o If the NO_NATS_ALLOWED notification is present, processes it as + described in Section 3.9. + + o Checks that the (source IP address, destination IP address) pair + in the IP header is acceptable according to local policy. If it + is not, replies with a message containing the + UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). + + o 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 allows IKEv2 to work with NATs without needing + unilateral self-address fixing [UNSAF].) + + o Replies with an INFORMATIONAL response: + + Initiator Responder + ----------- ----------- + <-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP)], + [N(COOKIE2)] } + + o If necessary, initiates a return routability check for the new + initiator address (see Section 3.7) and waits until the check is + completed. + + o Updates the IPsec SAs associated with this IKE_SA with the new + addresses. + + + +Eronen Standards Track [Page 14] + +RFC 4555 MOBIKE Protocol June 2006 + + + o If NAT Traversal is supported and NAT detection payloads were + included, enables or disables NAT Traversal. + + When the initiator receives the reply: + + o If an address change has occurred after the request was first + sent, no MOBIKE processing is done for the reply message because a + new UPDATE_SA_ADDRESSES is going to be sent (or has already been + sent, if window size greater than one is in use). + + o If the response contains the UNEXPECTED_NAT_DETECTED notification, + the initiator processes the response as described in Section 3.9. + + o If the response contains an UNACCEPTABLE_ADDRESSES notification, + the initiator MAY select another addresses and retry the exchange, + keep on using the previously used addresses, or disconnect. + + o It updates the IPsec SAs associated with this IKE_SA with the new + addresses (unless this was already done earlier before sending the + request; this is the case when no return routability check was + required). + + o 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 that the responder is currently using becomes + unavailable (i.e., sending packets using that source address is no + longer possible), the responder is allowed to update the IPsec SAs to + use some other address (in addition to initiating the procedure + described in the next section). + +3.6. Updating Additional Addresses + + As described in Section 3.4, both the initiator and responder can + send a list of additional addresses in the IKE_AUTH exchange. This + information can be updated by sending an INFORMATIONAL exchange + request message that contains either one or more + ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the + NO_ADDITIONAL_ADDRESSES notification. + + If the exchange initiator has only a single IP address, it is placed + in the IP header, and the message contains the + NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has + several addresses, one of them is placed in the IP header, and the + rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. + + + + +Eronen Standards Track [Page 15] + +RFC 4555 MOBIKE Protocol June 2006 + + + The new list of addresses replaces the old information (in other + words, there are no separate add/delete operations; instead, the + complete list is sent every time these notifications are used). + + The message exchange will look as follows: + + Initiator Responder + ----------- ----------- + HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], + [N(NO_ADDITIONAL_ADDRESSES)], + [N(NO_NATS_ALLOWED)], + [N(COOKIE2)] } --> + + <-- HDR, SK { [N(COOKIE2)] } + + When a request containing an ADDITIONAL_IP4_ADDRESS, + ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is + received, the exchange responder: + + o Determines whether it has already received a newer request to + update the addresses (if a window size greater than one is used, + it is possible that the requests are received out of order). If + it has, a response message is sent, but the address set is not + updated. + + o If the NO_NATS_ALLOWED notification is present, processes it as + described in Section 3.9. + + o Updates the set of peer addresses based on the IP header and the + ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and + NO_ADDITIONAL_ADDRESSES notifications. + + o Sends a response. + + The initiator MAY include these notifications in the same request as + UPDATE_SA_ADDRESSES. + + If the request to update the addresses is retransmitted using several + different source addresses, a new INFORMATIONAL request MUST be sent. + + There is one additional complication: when the responder wants to + update the address set, the currently used addresses may no longer + work. In this case, the responder uses the additional address list + received from the initiator, and the list of its own addresses, to + determine which addresses to use for sending the INFORMATIONAL + request. This is the only time the responder uses the additional + address list received from the initiator. + + + + +Eronen Standards Track [Page 16] + +RFC 4555 MOBIKE Protocol June 2006 + + + Note that both peers can have their own policies about what addresses + are acceptable to use, and certain types of policies may simplify + implementation. For instance, if the responder has a single fixed + address, it does not need to process the ADDITIONAL_IP4_ADDRESS and + ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring + unrecognized status notifications, as already required in [IKEv2]). + Furthermore, if the initiator has a policy saying that only the + responder address specified in local configuration is acceptable, it + does not have to send its own additional addresses to the responder + (since the responder does not need them except when changing its own + address). + +3.7. Return Routability Check + + Both parties can optionally verify 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 the address can be verified by some other means (e.g., + a certificate issued by an authority trusted for this purpose), the + return routability check MAY be omitted. + + The check can be done before updating the IPsec SAs, immediately + after updating them, 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 is received, we know the other party can receive + packets at the claimed address. + + To ensure that the peer cannot generate the correct INFORMATIONAL + response without seeing the request, a new payload is added to + INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY + include a COOKIE2 notification, and if included, the recipient of an + 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 as sent. If the values do not + match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the + format of the COOKIE2 notification.) + + + + + + + + + +Eronen Standards Track [Page 17] + +RFC 4555 MOBIKE Protocol June 2006 + + + The exception mentioned earlier is as follows: If the same + INFORMATIONAL request has been sent to several different addresses + (i.e., the destination address in the IKE_SA has been updated after + the request was first sent), receiving the INFORMATIONAL response + does not tell which address is the working one. In this case, a new + INFORMATIONAL request needs to be sent to check return routability. + +3.8. Changes in NAT Mappings + + IKEv2 performs 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 if NAT mappings + have changed (for example, if the keepalive interval is too long, or + the NAT box is rebooted). More specifically, if both peers support + both 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 + and 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 do not 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 that the NAT mapping has changed, it MAY also skip + the detection step and send UPDATE_SA_ADDRESSES immediately. This + saves one roundtrip if the NAT mapping has indeed changed. + + Note that this approach to detecting NAT mapping changes may cause an + extra address update when the IKE_SA is rekeyed. This is because the + NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security + Parameter Indexes (SPIs), which change when performing rekeying. + This unnecessary update is harmless, however. + + When MOBIKE is in use, the dynamic updates (specified in [IKEv2], + Section 2.23), where the peer address and port are updated from the + last valid authenticated packet, work in a slightly different + fashion. The host not behind a NAT MUST NOT use these dynamic + updates for IKEv2 packets, but MAY use them for ESP packets. This + ensures that an INFORMATIONAL exchange that does not contain + UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be + used for, e.g., testing whether a particular path works. + + + + +Eronen Standards Track [Page 18] + +RFC 4555 MOBIKE Protocol June 2006 + + +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. This is because the IKEv2 integrity checksum does not + cover the addresses in the IP header. This may be considered a + problem in some circumstances, because in some sense any modification + of the IP addresses can be considered an attack. + + This specification addresses the issue by protecting the IP addresses + when NAT Traversal has not been explicitly enabled. This means that + MOBIKE without NAT Traversal support will not 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 + intended for IPv6 and site-to-site VPN cases, where the + administrators may know beforehand that NATs are not present, and + thus any modification to the packet can be considered an attack. + + More specifically, when NAT Traversal is not 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 the following 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 do not match, a response containing an + UNEXPECTED_NAT_DETECTED notification is sent. The response message + is sent to the address and port that the corresponding request came + from, not to the address contained in the NO_NATS_ALLOWED + notification. + + If the exchange initiator receives an UNEXPECTED_NAT_DETECTED + notification in response to its INFORMATIONAL request, it SHOULD + retry the operation several times using new INFORMATIONAL requests. + Similarly, if the initiator receives 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 ensures that an + attacker who is able to modify only a single packet does not + unnecessarily cause a path to remain unused. The exact number of + retries is not specified in this document because it does not affect + interoperability. However, because the IKE message will also be + rejected if the attacker modifies the integrity checksum field, a + reasonable number here would be the number of retries that is being + used for normal retransmissions. + + + + + + +Eronen Standards Track [Page 19] + +RFC 4555 MOBIKE Protocol June 2006 + + + If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange + responder MUST NOT use the contents of the NO_NATS_ALLOWED + notification for any other purpose than possibly logging the + information for troubleshooting purposes. + +3.10. Path Testing + + IKEv2 Dead Peer Detection allows the peers to detect if the currently + used path has stopped working. However, if either of the peers has + several addresses, Dead Peer Detection alone does not tell which of + the other paths might work. + + If required by its address selection policy, the initiator can use + normal IKEv2 INFORMATIONAL request/response messages to test whether + a certain path works. Implementations MAY do path testing even if + the path currently being used is working to, for example, detect when + a better (but previously unavailable) path becomes available. + +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 the error, the responder + SHOULD use relatively long timeout intervals when, for instance, + retransmitting IKEv2 requests or deciding whether to initiate Dead + Peer Detection. While no specific timeout lengths are required, it + is suggested that responders continue retransmitting IKEv2 requests + for at least five minutes before giving up. + +3.12. Dead Peer Detection + + MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but + as addresses may change, it is not sufficient to just verify that the + peer is alive, but also that it is synchronized with the address + updates and has not, for instance, ignored an address update due to + failure to complete return routability test. This means that when + there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the + addresses used in those packets and determine that they correspond to + those that should be employed. If they do not, such packets SHOULD + NOT be used as evidence that the peer is able to communicate with + this node and or that the peer has received all address updates. + + + + + + + + + +Eronen Standards Track [Page 20] + +RFC 4555 MOBIKE Protocol June 2006 + + +4. Payload Formats + + This specification defines several new IKEv2 Notify payload types. + See [IKEv2], Section 3.10, for a general description of the Notify + payload. + +4.1. Notify Messages - Error Types + +4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload + + The responder can include this notification in an INFORMATIONAL + exchange response to indicate that the address change in the + corresponding request message (which contained 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 is no data + associated with this Notify type. + +4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload + + See Section 3.9 for a description of this notification. + + The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The + Protocol ID and SPI Size fields are set to zero. There is no data + associated with this Notify type. + +4.2. Notify Messages - Status Types + +4.2.1. MOBIKE_SUPPORTED Notify Payload + + The MOBIKE_SUPPORTED notification is included in the IKE_AUTH + exchange to indicate that the implementation supports this + specification. + + 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 this notification is received. This allows + the field to be used by future versions of this protocol. + +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 more detailed description. + + + +Eronen Standards Track [Page 21] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 associated + with 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 be included in an + INFORMATIONAL exchange request message to indicate that the exchange + initiator does not have addresses beyond the one used in the exchange + (see Section 3.6 for more detailed description). + + The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The + Protocol ID and SPI Size fields are set to zero. There is no data + associated 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 addresses of the IKE_SA and IPsec SAs (see + Section 3.5). + + The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The + Protocol ID and SPI Size fields are set to zero. There is no data + associated 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 associated with 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 a description of this notification. + + The Notify Message Type for this message is 16402. The notification + data contains the IP addresses and ports from/to which the packet was + sent. For IPv4, the notification data is 12 octets long and is + defined as follows: + + + +Eronen Standards Track [Page 22] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 is defined as + follows: + + 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. + + + + + + + + + + + + + + + + + + + + + +Eronen Standards Track [Page 23] + +RFC 4555 MOBIKE Protocol June 2006 + + +5. Security Considerations + + The main goals of this specification are to maintain the security + offered by usual IKEv2 procedures and to counter mobility-related + threats in an appropriate manner. This section describes new + security considerations introduced by MOBIKE. See [IKEv2] for + security considerations for IKEv2 in general. + +5.1. Traffic Redirection and Hijacking + + MOBIKE payloads relating to updating addresses are encrypted, + integrity protected, and replay protected using the IKE_SA. This + assures that no one except the participants can, for instance, give a + control message to change the addresses. + + However, as with normal IKEv2, the actual IP addresses in the IP + header are not covered by the integrity protection. This means that + a NAT between the parties (or an attacker acting as a NAT) can modify + the addresses and cause incorrect tunnel header (outer) IP addresses + to be used for IPsec SAs. The scope of this attack is limited mainly + to denial of service because all traffic is protected using IPsec. + + This attack can only be launched by on-path attackers that are + capable of modifying IKEv2 messages carrying NAT detection payloads + (such as Dead Peer Detection messages). By modifying the IP header + of these packets, the attackers can lead the peers to believe a new + NAT or a changed NAT binding exists between them. The attack can + continue as long as the attacker is on the path, modifying the IKEv2 + messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms + designed to detect NAT mapping changes will eventually recognize that + the intended traffic is not getting through, and will update the + addresses appropriately. + + MOBIKE introduces the NO_NATS_ALLOWED notification that 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 is sent only when not doing + NAT Traversal. This feature is mainly intended for IPv6 and site-to- + site VPN cases, where the administrators may know beforehand that + NATs are not present. + +5.2. IPsec Payload Protection + + The use of IPsec protection on payload traffic protects the + participants against disclosure of the contents of the traffic, + should the traffic end up in an incorrect destination or be subject + to eavesdropping. + + + + +Eronen Standards Track [Page 24] + +RFC 4555 MOBIKE Protocol June 2006 + + + However, security associations originally created for the protection + of 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, are configured in a manner that takes into account + that a single security association can be used at different times + through paths of varying security properties. + + This is especially critical for traffic selector authorization. The + (logical) Peer Authorization Database (PAD) contains the information + used by IKEv2 when determining 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 is important to note that simply sending IKEv2 packets using some + particular address does not automatically imply a 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 policies or extensions 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 + + Traffic redirection may be performed not just to gain access to the + traffic or to deny service to the peers, but also to cause a denial- + of-service attack on a third party. For instance, a high-speed TCP + session or a multimedia stream may be redirected towards a victim + host, causing its communications capabilities to suffer. + + + +Eronen Standards Track [Page 25] + +RFC 4555 MOBIKE Protocol June 2006 + + + The attackers in this threat can be either outsiders or even one of + the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers + can be easily dealt with if the authentication performed in the + initial IKEv2 negotiation can be traced to persons who can be held + responsible for the attack. This may not be the case in all + scenarios, particularly with opportunistic approaches to security. + + If the attack is launched by an outsider, the traffic flow would + normally stop soon due to the lack of responses (such as transport + layer acknowledgements). However, if the original recipient of the + flow is malicious, it could maintain the traffic flow for an extended + period of time, since it often would be able to send the required + acknowledgements (see [Aura02] for more discussion). + + It should also be noted, as shown in [Bombing], that without ingress + filtering in the attacker's network, such attacks are already + possible simply by sending spoofed packets from the attacker to the + victim directly. Furthermore, if the attacker's network has ingress + filtering, this attack is largely prevented for MOBIKE as well. + Consequently, it makes little sense to protect against attacks of + similar nature in MOBIKE. However, it still makes sense to limit the + amplification capabilities provided to attackers, so that they cannot + use stream redirection to send a large number of packets to the + victim by sending just a few packets themselves. + + This specification includes return routability tests to limit the + duration of any "third party bombing" attacks by off-path (relative + to the victim) attackers. The tests are authenticated messages that + the peer has to respond to, and can be performed before the address + change takes effect, immediately afterwards, or even periodically + during the session. The tests contain unpredictable data, and only + someone who has the keys associated with the IKE SA and has seen the + request packet can properly respond to the test. + + The duration of the attack can also be limited if the victim reports + the unwanted traffic to the originating IPsec tunnel endpoint using + ICMP error messages or INVALID_SPI notifications. As described in + [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which + also doubles as a return routability check if the COOKIE2 + notification is included. + +5.4. Spoofing Network Connectivity Indications + + Attackers may spoof various indications from lower layers and the + network in an effort to confuse the peers about which addresses are + or are not working. For example, attackers may spoof link-layer + error messages in an effort to cause the parties to move their + traffic elsewhere or even to disconnect. Attackers may also spoof + + + +Eronen Standards Track [Page 26] + +RFC 4555 MOBIKE Protocol June 2006 + + + information related to network attachments, router discovery, and + address assignments in an effort to make the parties believe they + have Internet connectivity when, in reality, they do not. + + This may cause use of non-preferred addresses or even denial of + service. + + MOBIKE does not provide any protection of its own for indications + from other parts of the protocol stack. These vulnerabilities can be + mitigated through the use of techniques specific to the other parts + of the stack, such as validation of ICMP errors [ICMPAttacks], link + layer security, or the use of [SEND] to protect IPv6 Router and + Neighbor Discovery. + + Ultimately, MOBIKE depends on the delivery of IKEv2 messages to + determine which paths can be used. If IKEv2 messages sent using a + particular source and destination addresses reach the recipient and a + reply is received, MOBIKE will usually consider the path working; if + no reply is received even after retransmissions, MOBIKE will suspect + the path is broken. An attacker who can consistently control the + delivery or non-delivery of the IKEv2 messages in the network can + thus 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 information about which + networks the peers are connected to. + + For example, consider a 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 + receives additional information it might not otherwise know. If host + A used the cellular connection for the IKEv2 traffic, host B can also + see the company LAN address (and perhaps further guess that host A is + used by 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 additional addresses can also disclose more accurate location + information than just a single address. Suppose that host A uses its + cellular connection for IKEv2 traffic, but also sends an + ADDITIONAL_IP4_ADDRESS notification containing an IP address + corresponding to, say, a wireless LAN at a particular coffee shop + location. It is likely that host B can now make a much better guess + at A's location than would be possible based on the cellular IP + address alone. + + + +Eronen Standards Track [Page 27] + +RFC 4555 MOBIKE Protocol June 2006 + + + Furthermore, as described in Section 3.4, some of the addresses could + also be private addresses behind a NAT. + + In many environments, disclosing address information is not a problem + (and indeed it cannot be avoided if the hosts wish to use those + addresses for IPsec traffic). For instance, a remote access VPN + client could consider the corporate VPN gateway sufficiently + trustworthy for this purpose. Furthermore, the + ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are + sent encrypted, so the addresses are not visible to eavesdroppers + (unless, of course, they are later used for sending IKEv2/IPsec + traffic). + + However, if MOBIKE is used in some more opportunistic approach, it + can be desirable to limit the information that is sent. Naturally, + the peers do not have to disclose any addresses they do not want to + use for IPsec traffic. Also, as noted in Section 3.6, an initiator + whose policy is to always use the locally configured responder + address does not have to send any ADDITIONAL_IP4_ADDRESS/ + ADDITIONAL_IP6_ADDRESS payloads. + +6. IANA Considerations + + This document does not create any new namespaces to be maintained by + IANA, but it requires new values in namespaces that have been defined + in the IKEv2 base specification [IKEv2]. + + This document defines several new IKEv2 notifications whose values + have been 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 16402 + + These notifications are described in Section 4. + + + + + +Eronen Standards Track [Page 28] + +RFC 4555 MOBIKE Protocol June 2006 + + +7. Acknowledgements + + This document is a collaborative effort of the entire MOBIKE WG. We + would particularly 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 incorporates ideas and text from earlier + MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen], + [MOPO], and [SMOBIKE], and 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. + + + + + + +Eronen Standards Track [Page 29] + +RFC 4555 MOBIKE Protocol June 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. + + + + + + + + +Eronen Standards Track [Page 30] + +RFC 4555 MOBIKE Protocol June 2006 + + +Appendix A. Implementation Considerations + +A.1. Links from SPD Cache to Outbound SAD Entries + + [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 does not specify how exactly this "pointing" is + done, since this is an implementation detail that does not have to be + standardized. + + However, it is clear that the links between the SPD cache and the SAD + have to be done correctly to ensure that outbound packets are sent + over the right SA. Some implementations are known to have problems + in this area. + + In particular, simply storing the (remote tunnel header IP address, + remote SPI) pair in the SPD cache is not sufficient, since the pair + does not always uniquely identify a single SAD entry. For instance, + two hosts behind the same NAT can accidentally happen to choose the + same SPI value. The situation can also occur when a host is assigned + an IP address previously used by some other host, and the SAs + associated with the old host have not yet been deleted by Dead Peer + Detection. This may lead to packets being sent over the wrong SA or, + if the key management daemon ensures the pair is unique, denying the + creation of otherwise valid SAs. + + Storing the remote tunnel header IP address in the SPD cache may also + complicate the implementation of MOBIKE, since the address can change + during the lifetime of the SA. Thus, we recommend implementing the + links between the SPD cache and the SAD in a way that does not + require modification when the tunnel header IP address is updated by + MOBIKE. + +A.2. Creating Outbound SAs + + When an outbound packet requires IPsec processing but no suitable SA + exists, a new SA will be created. In this case, the host has to + determine (1) who is the right peer for this SA, (2) whether the host + already has an IKE_SA with this peer, and (3) if no IKE_SA exists, + the IP address(es) of the peer for contacting it. + + Neither [IPsecArch] nor MOBIKE specifies how exactly these three + steps are carried out. [IPsecArch], Section 4.4.3.4, says: + + + + + + + + +Eronen Standards Track [Page 31] + +RFC 4555 MOBIKE Protocol June 2006 + + + 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 consult a directory such as DNS to determine the + peer IP address(es). + + When performing these steps, implementations may use information + contained in the SPD, the PAD, and possibly some other + implementation-specific databases. Regardless of how exactly the + steps are implemented, it is important to remember that IP addresses + can change, and that an IP address alone does not always uniquely + identify a single IKE peer (for the same reasons as why the + combination of the remote IP address and SPI does not uniquely + identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 + and 2 it may be easier to identify the "right peer" using its + authenticated identity instead of its current IP address. However, + these implementation details are beyond the scope of this + specification. + +Author's Address + + Pasi Eronen (editor) + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + EMail: pasi.eronen@nokia.com + + + + + + + + + + + + + +Eronen Standards Track [Page 32] + +RFC 4555 MOBIKE Protocol June 2006 + + +Full 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). + + + + + + + +Eronen Standards Track [Page 33] +