--- 1/draft-ietf-mobike-protocol-03.txt 2006-02-04 17:24:05.000000000 +0100 +++ 2/draft-ietf-mobike-protocol-04.txt 2006-02-04 17:24:05.000000000 +0100 @@ -1,17 +1,17 @@ MOBIKE Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: April 2, 2006 September 29, 2005 +Expires: April 10, 2006 October 7, 2005 IKEv2 Mobility and Multihoming Protocol (MOBIKE) - draft-ietf-mobike-protocol-03.txt + draft-ietf-mobike-protocol-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,80 +22,80 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 2, 2006. + This Internet-Draft will expire on April 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows hosts to update the (outer) IP addresses associated with IKEv2 and IPsec Security Associations. A mobile 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 currently used one stops working. + instance, the one currently being used stops working. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 - 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 - 3.1 Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 - 3.2 Example Protocol Runs . . . . . . . . . . . . . . . . . . 5 - 3.3 MOBIKE and Network Address Translation (NAT) . . . . . . . 8 - 3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . 9 - 4.1 Signaling Support for MOBIKE . . . . . . . . . . . . . . . 9 - 4.2 Initial Tunnel Header Addresses . . . . . . . . . . . . . 9 - 4.3 Additional Addresses . . . . . . . . . . . . . . . . . . . 9 - 4.4 Changing Addresses in IPsec SAs . . . . . . . . . . . . . 11 - 4.5 Updating Additional Addresses . . . . . . . . . . . . . . 14 - 4.6 Return Routability Check . . . . . . . . . . . . . . . . . 15 - 4.7 Changes in NAT Mappings . . . . . . . . . . . . . . . . . 16 - 4.8 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 - 4.9 Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.10 Failure Recovery and Timeouts . . . . . . . . . . . . . 17 - 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . 19 - 5.1 MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 19 - 5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 19 - 5.3 NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 19 - 5.4 UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 19 - 5.5 UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 20 - 5.6 COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 20 - 5.7 NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 20 - 5.8 UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 20 - 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 - 6.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 21 - 6.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 21 - 6.3 Denial-of-Service Attacks Against Third Parties . . . . . 22 - 6.4 Spoofing Network Connectivity Indications . . . . . . . . 23 - 6.5 Address and Topology Disclosure . . . . . . . . . . . . . 23 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . 25 - 9.2 Informative References . . . . . . . . . . . . . . . . . . 26 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 - A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 27 - Intellectual Property and Copyright Statements . . . . . . . 30 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 + 3.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 8 + 3.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 9 + 4.2. Initial Tunnel Header Addresses . . . . . . . . . . . . . 9 + 4.3. Additional Addresses . . . . . . . . . . . . . . . . . . . 9 + 4.4. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 11 + 4.5. Updating Additional Addresses . . . . . . . . . . . . . . 14 + 4.6. Return Routability Check . . . . . . . . . . . . . . . . . 15 + 4.7. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 15 + 4.8. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 + 4.9. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.10. Failure Recovery and Timeouts . . . . . . . . . . . . . . 17 + 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 18 + 5.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 18 + 5.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 18 + 5.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 18 + 5.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 19 + 5.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 19 + 5.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 19 + 5.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 6.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 20 + 6.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 20 + 6.3. Denial-of-Service Attacks Against Third Parties . . . . . 21 + 6.4. Spoofing Network Connectivity Indications . . . . . . . . 22 + 6.5. Address and Topology Disclosure . . . . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 + Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 + Intellectual Property and Copyright Statements . . . . . . . . . . 30 1. Introduction IKEv2 is used for performing mutual authentication and establishing and maintaining IPsec Security Associations (SAs). In the current specifications, the IPsec and IKE 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. Currently, it is not possible to change these addresses after the IKE_SA has been created. @@ -104,46 +104,45 @@ 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 (entering a code from a token card, for instance). Creating new SAs often also involves expensive - calculations and possibly a large number of roundtrips. Due to these + 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 making it possible for 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 office wireless LAN. When - leaving the office the laptop could start using GPRS, and switch to a - different wireless LAN when the user arrives home. MOBIKE updates - only the outer (tunnel header) addresses of IPsec SAs, and the - addresses and others traffic selectors used inside the tunnel stay - unchanged. Thus, mobility can be (mostly) invisible to applications - and their connections using the VPN. + 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 office wireless LAN. When leaving the office the laptop + could start using GPRS, and switch to a different wireless LAN when + the user arrives home. MOBIKE updates only the outer (tunnel header) + addresses of IPsec SAs, and the addresses and others traffic + selectors used inside the tunnel stay unchanged. Thus, mobility can + be (mostly) invisible to applications and their connections using the + VPN. 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 have 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. 2. 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+"). In some cases, the diagrams also show what payloads defined in [IKEv2] would be typically included in, for instance, the IKE_AUTH exchange. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description. When this document talks about updating the source/destination @@ -163,81 +162,81 @@ 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]. 3. Protocol Overview -3.1 Basic Operation +3.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 have may preferences about which + several factors. First, the parties may have preferences about which interface should be used, due to performance and cost reasons, for instance. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages somewhere 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 remote access VPN + 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 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 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. + 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. 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 + contacting the responder. It also makes sense, especially when the initiator is the 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 also not specific to MOBIKE, but 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 in for both IPv4 and IPv6 [DNA4] [DNA6], - and so on. + Also, 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. - Updating the addresses of IPsec SAs naturally has to take into + 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 mainly intended for site-to-site VPNs where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an attack. -3.2 Example Protocol Runs +3.2. Example Protocol Runs A simple MOBIKE exchange in a mobile scenario is illustrated below: Initiator Responder ----------- ----------- 1) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) @@ -270,22 +269,23 @@ 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 this. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. The responder records the new address, and if so required by policy, performs a return routability check of the address. When this check completes, the responder starts to use the new address as the destination for its outgoing ESP traffic. - Another protocol run in multihoming scenario is illustrated below. - In this scenario the initiator has one address but the responder has + 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) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) @@ -317,96 +317,96 @@ N(COOKIE2) } (This worked, and the initiator requests the peer to switch to new addresses.) 5) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> <-- HDR, SK { N(NAT_DETECTION_*_IP) } -3.3 MOBIKE and Network Address Translation (NAT) +3.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 talks simply about 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 since NATs usually introduce - an asymmetry in the network: only packets coming from the "inside" - cause state to be created. This asymmetry leads to 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). + Nevertheless, there are some limitations because NATs usually + introduce an asymmetry in the network: only packets coming from the + "inside" cause state to be created. This asymmetry leads to + 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 does not fully support the case where the responder's addresses change. "Does not fully support" means that no special effort is made to support this functionality. However, if the alternative is losing connectivity completely, the responder can still attempt to proceed with the change, and depending on, e.g., the exact type of NAT, it may succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. -3.4 Limitations +3.4. Limitations This document focuses on the main scenario outlined in Section 1, and supports only tunnel mode. The base version of the MOBIKE protocol may not cover all potential future use scenarios, such as transport mode, application to securing - SCTP or optimizations desirable in specific circumstances. Future + SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. 4. Protocol Exchanges -4.1 Signaling Support for MOBIKE +4.1. 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). The format of the MOBIKE_SUPPORTED notification is described in Section 5. -4.2 Initial Tunnel Header Addresses +4.2. 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 as follows: If the IKE_SA_INIT request - contains the NAT_DETECTION_*_IP notifications and the responder - supports NAT Traversal, the values are initialized from the IP header - of the first IKE_AUTH request. Otherwise, the values are initialized - from the IP header of the IKE_SA_INIT request. + 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 as follows: If the + IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and + the responder supports NAT Traversal, the values are initialized from + the IP header of the first IKE_AUTH request. Otherwise, the values + are initialized from the IP header of the IKE_SA_INIT request. The addresses are taken from the IKE_AUTH request when NAT Traversal is being used 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). -4.3 Additional Addresses +4.3. 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). Initiator Responder ----------- ----------- HDR, SK { IDi, [CERT], [IDr], AUTH, [CP(CFG_REQUEST)] @@ -421,48 +421,48 @@ [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. 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 + 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 4.4. 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 4.5). 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 4.5. 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 4.5 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 purposes than what is explicitly described in this document. -4.4 Changing Addresses in IPsec SAs +4.4. Changing Addresses in IPsec SAs In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder usually never updates 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 + 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 itself MUST NOT be used to conclude than an update is needed: instead, the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request). 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 @@ -552,50 +552,50 @@ o If necessary, initiates a return routability check for the new initiator address (see Section 4.6) and waits until the check is completed. o Updates the IPsec SAs associated with this IKE_SA with the new addresses. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. - When the initiator receives the reply, it: + 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, since a + 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, - processes it as described in Section 4.8. + it processes the response as described in Section 4.8. o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the current addresses, or disconnect. - o Updates the IPsec SAs associated with this IKE_SA with the new + o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done before sending the request). o If NAT Traversal is supported and NAT detection payloads were - included, enables or disables NAT Traversal. + included, it enables or disables NAT Traversal. There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If - the source address the responder is currently using becomes + 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). -4.5 Updating Additional Addresses +4.5. Updating Additional Addresses As described in Section 4.3, 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/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. The message exchange will look as follows: Initiator Responder ----------- ----------- @@ -626,70 +626,69 @@ 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 + 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. Note that both peers can have their own policies about what addresses are acceptable to use. A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. This kind of client does not have to send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. -4.6 Return Routability Check +4.6. Return Routability Check Both parties can optionally verify that the other party can actually receive packets at the claimed address. This "return routability check" can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. - By default, return routability check SHOULD be done before updating - the IPsec SAs. In environments where the peer is expected to be - well-behaving (many corporate VPNs, for instance), or the address can - be verified by some other means (e.g., the address is included in the - peer's certificate), the return routability check MAY be omitted or - postponed until after the IPsec SAs have been updated. + By default, the return routability check SHOULD be done before + updating the IPsec SAs. 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., the address is + included in the peer's certificate), the return routability check MAY + be omitted or postponed until after the IPsec SAs have been updated. Any INFORMATIONAL exchange can be used for return routability - purposes (with one exception, described below): when a valid response - is received, we know the other party can receive packets at the - claimed address. + purposes, with one exception: 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. 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. -4.7 Changes in NAT Mappings +4.7. 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 internal is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, NAT_DETECTION_*_IP notifications MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the @@ -706,313 +705,313 @@ 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. -4.8 NAT Prohibition +4.8. 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, since in some sense any modification - of the IP addresses can be considered to be an attack. + 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 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 to be an attack. + 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 IKE_SA_INIT request and all INFORMATIONAL requests that contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS notifications) 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 (and in the case of the IKE_SA_INIT exchange, no state is created at the responder). The - response message is sent to the address and port the corresponding - request came from, not the address contained in the NO_NATS_ALLOWED - notification. + 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_DETECTION notification in response to its request, it SHOULD retry the operation several times using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. 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. -4.9 Path Testing +4.9. 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 currenly used path is working to, for example, detect when a - better (but previously unavailable) path becomes available. + the path currently being used is working to, for example, detect when + a better (but previously unavailable) path becomes available. -4.10 Failure Recovery and Timeouts +4.10. 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. 5. Payload Formats -5.1 MOBIKE_SUPPORTED Notify Payload +5.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 TBD-BY-IANA1. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads +5.2. ADDITIONAL_IP4/6_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 4.3 and Section 4.5 for more detailed description. The Notify Message Types for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 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. -5.3 NO_ADDITIONAL_ADDRESSES Notify Payload +5.3. NO_ADDITIONAL_ADDRESSES Notify Payload The NO_ADDITIONAL_ADDRESSES notification can be included in an - INFORMATIONAL exchange request messages to indicate that the exchange + INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 4.5 for more detailed description). The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -5.4 UPDATE_SA_ADDRESSES Notify Payload +5.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 4.4). The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -5.5 UNACCEPTABLE_ADDRESSES Notify Payload +5.5. 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 TBD-BY-IANA6. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -5.6 COOKIE2 Notify Payload +5.6. COOKIE2 Notify Payload This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 4.6). 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 TBD-BY-IANA7. The Protocol ID and SPI Size fields are set to zero. -5.7 NO_NATS_ALLOWED Notify Payload +5.7. NO_NATS_ALLOWED Notify Payload See Section 4.8 for a description of this notification. The data field of this notification contains the following information: the IP address and port from which the packet was sent, and the IP address and port to which the packet was sent. The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. -5.8 UNEXPECTED_NAT_DETECTED Notify Payload +5.8. UNEXPECTED_NAT_DETECTED Notify Payload See Section 4.8 for a description of this notification. The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. 6. Security Considerations The main goals of this specification are to not reduce the security - offered by usual IKEv2 procedures and to counter mobility related + 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. -6.1 Traffic Redirection and Hijacking +6.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, just like 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, since all traffic is protected + 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 believe a new NAT - or a changed NAT binding exists between them. The attack can + 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 update the addresses - appropriately. + 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 of the addresses in the IP header by outsiders. + 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 site-to-site VPN cases, where the administrators may know beforehand that valid NATs are not present, and thus any modification to the packet can be - considered to be an attack. + considered an attack. -6.2 IPsec Payload Protection +6.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 eavesdropped along the way. 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 level of required protection depends on, for instance, the current location of the VPN client. - 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 through paths of varying - security properties at different times. + 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. -6.3 Denial-of-Service Attacks Against Third Parties +6.3. Denial-of-Service Attacks Against Third Parties Traffic redirection may be performed not just to gain access to the - traffic (not very interesting since it is encrypted) or to deny + traffic (not very interesting because it is encrypted) or to deny service to the peers, but also to cause a denial-of-service attack for 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. 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. - Normally such attacks would expire in a short time frame due to the + Normally, such attacks would expire in a short time frame due to the lack of responses (such as transport layer acknowledgements) from the victim. However, as described in [Aura02], malicious participants would typically be able to spoof such acknowledgements and maintain the traffic flow for an extended period of time. For instance, if the attacker opened the TCP stream itself before redirecting it to the victim, the attacker becomes aware of the sequence number space used in this particular session. 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 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 either 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. -6.4 Spoofing Network Connectivity Indications +6.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 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. + 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 + 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. -6.5 Address and Topology Disclosure +6.5. Address and Topology Disclosure MOBIKE address updates and ADDITIONAL_IP4/6_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/MOBIKE and sends ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional information it might not otherwise know. If host A used the cellular connection for the IKEv2/MOBIKE traffic, host B can also see the @@ -1033,22 +1032,22 @@ Furthermore, as described in Section 4.3, 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. However, if MOBIKE is used in some more opportunistic approach, it - can be desirable to limit the information that is sent. The peers - naturally do not have to disclose any addresses they do not want to + 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 4.5, an initiator whose policy is to always use the locally configured responder address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. 7. 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]. @@ -1073,41 +1072,41 @@ This document is a collaborative effort of the entire MOBIKE WG. We would particularly like to thank Jari Arkko, Francis Dupont, Paul Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also incorporates ideas and text from earlier MOBIKE protocol proposals, including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document [Design]. 9. References -9.1 Normative References +9.1. Normative References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), March 2005. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [UDPEncap] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. -9.2 Informative References +9.2. Informative References [AddrMgmt] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-07 (work in progress), May 2005. [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002. @@ -1161,34 +1160,28 @@ [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. -Author's Address - - Pasi Eronen (editor) - Nokia Research Center - P.O. Box 407 - FIN-00045 Nokia Group - Finland - - Email: pasi.eronen@nokia.com - Appendix A. Changelog (This section should be removed by the RFC editor.) + Changes from -03 to -04: + + o Copy-editing done by the RFC editor. + Changes from -02 to -03: o Editorial fixes and clarifications (issues 42 and 43). o Clarified IANA considerations (issue 42). o Added security considerations about address and topology disclosure (issue 42). o Added a suggestion about retransmission timeout (issue 42). @@ -1243,20 +1236,30 @@ o Editorial fixes and small clarifications (issues 21, 25, 26, 29). o Use Protocol ID zero for notifications (issue 30). o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 23). o Use the word "path" only in senses that include the route taken (issue 29). +Author's Address + + Pasi Eronen (editor) + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + Email: pasi.eronen@nokia.com + Intellectual Property Statement 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.