--- 1/draft-ietf-mobike-protocol-06.txt 2006-02-04 17:16:33.000000000 +0100 +++ 2/draft-ietf-mobike-protocol-07.txt 2006-02-04 17:16:33.000000000 +0100 @@ -1,17 +1,17 @@ MOBIKE Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: May 20, 2006 November 16, 2005 +Expires: June 23, 2006 December 20, 2005 IKEv2 Mobility and Multihoming Protocol (MOBIKE) - draft-ietf-mobike-protocol-06.txt + draft-ietf-mobike-protocol-07.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,88 +22,89 @@ 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 May 20, 2006. + This Internet-Draft will expire on June 23, 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 tunnel mode 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 one currently being used stops working. + allows the IP addresses associated with IKEv2 and tunnel mode IPsec + Security Associations to change. 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 one currently being used stops working. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 5 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 7 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 10 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 11 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 11 - 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11 + 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 12 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 12 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 13 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 16 - 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17 + 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 18 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.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 21 - 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 21 - 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21 - 4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 21 - 4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . 21 - 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 22 - 4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 22 - 4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 22 - 4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 22 - 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 . . . . . . . . . . . . . 26 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 - Appendix A. Implementation Considerations . . . . . . . . . . . . 30 - A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 30 - A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31 - Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 32 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . . . . 36 + 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 21 + 3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 21 + 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 22 + 4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 22 + 4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . 22 + 4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . 22 + 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 22 + 4.2.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . 22 + 4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS + Notify Payloads . . . . . . . . . . . . . . . . . . . 22 + 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . 23 + 4.2.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . 23 + 4.2.5. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . 23 + 4.2.6. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . 23 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 25 + 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 25 + 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 26 + 5.4. Spoofing Network Connectivity Indications . . . . . . . . 27 + 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 . . . . . . . . . . . . . . . . . . 30 + Appendix A. Implementation Considerations . . . . . . . . . . . . 31 + A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31 + A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 32 + Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 33 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 + Intellectual Property and Copyright Statements . . . . . . . . . . 37 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, 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 @@ -114,25 +115,25 @@ 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 also 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. + 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 leaving the office the laptop could start using GPRS; when the user arrives home, the laptop could switch the 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, @@ -147,44 +148,43 @@ 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 discovering the addresses when the - IKE_SA is first established. This implies that 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). + 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. 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. - - Readers are encouraged to consult the MOBIKE design document [Design] - for further information and rationale behind these limitations. + 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. @@ -247,74 +247,78 @@ 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). - 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. + 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 Runs A simple MOBIKE exchange in a mobile scenario is illustrated below: Initiator Responder ----------- ----------- 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, - N(NAT_DETECTION_*_IP) --> + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, - N(NAT_DETECTION_*_IP) + 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_*_IP) } --> + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } --> <-- (IP_R1:4500 -> IP_I2:4500) - HDR, SK { N(NAT_DETECTION_*_IP) } + 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) } --> @@ -332,68 +336,76 @@ 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_*_IP) --> + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, - N(NAT_DETECTION_*_IP) + 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_IPV4_ADDRESS) } + N(ADDITIONAL_IP4_ADDRESS) } (The initiator suspects a problem in the currently used address pair, and probes its liveness.) - 3) (IP_I1:4500 -> IP_R1:4500) - HDR, SK { N(NAT_DETECTION_*_IP) } --> + HDR, SK { N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } --> (IP_I1:4500 -> IP_R1:4500) - HDR, SK { N(NAT_DETECTION_*_IP) } --> + 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_*_IP) } + HDR, SK { N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } <-- (IP_R2:4500 -> IP_I1:4500) - HDR, SK { N(NAT_DETECTION_*_IP) } + 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_*_IP), + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP), N(COOKIE2) } --> <-- (IP_R2:4500 -> IP_I1:4500) - HDR, SK { N(NAT_DETECTION_*_IP), + 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 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. @@ -407,30 +419,29 @@ 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. 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. + support the case where the responder's addresses change, 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 @@ -512,21 +523,21 @@ 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 usually never updates any IPsec SAs + 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 @@ -536,25 +547,25 @@ 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. - o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or - NO_ADDITIONAL_ADDRESS notifications is received. This means the - peer's addresses may have changed. This is particularly important - if the announced set of address no longer contains the currently - used address. + 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 address 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 @@ -581,24 +592,24 @@ 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: Initiator Responder ----------- ----------- HDR, SK { N(UPDATE_SA_ADDRESSES), - [N(NAT_DETECTION_*_IP)], + [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 @@ -615,21 +626,22 @@ 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_*_IP)], + <-- 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. o If NAT Traversal is supported and NAT detection payloads were @@ -663,85 +675,89 @@ 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/ - 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. + 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/6_ADDRESS notifications. 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). + rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications. + 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 ADDITIONAL_IP4/6_ADDRESS or - NO_ADDITIONAL_ADDRESSES notification is received, the exchange - responder: + 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 - ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications. + 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. 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 need to process ADDITIONAL_*_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). + 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. @@ -775,36 +791,38 @@ 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, NAT_DETECTION_*_IP + 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 - NAT_DETECTION_*_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. + 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 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 @@ -829,28 +847,29 @@ 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/6_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. + 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. @@ -931,21 +950,22 @@ 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. 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/6_ADDRESS Notify Payloads +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. 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 @@ -1080,25 +1100,24 @@ 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 at different times through paths of varying security properties. 5.3. Denial-of-Service Attacks Against Third Parties Traffic redirection may be performed not just to gain access to the - 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. + traffic 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. If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport @@ -1159,61 +1178,64 @@ 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 ADDITIONAL_IP4/6_ADDRESS notifications - reveal information about which networks the peers are connected to. + 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/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 - 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. + 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/MOBIKE traffic, but also sends an + 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. 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/ - 6_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). + 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/6_ADDRESS payloads. + 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 are to be allocated from the "IKEv2 Notify Message Types" namespace. @@ -1235,21 +1257,21 @@ These notifications are described in Section 4. 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, Lakshminath Dondeti, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, Sami Vaarala, and Hannes Tschofenig. This document also incorporates - ideas and text from earlier MOBIKE protocol proposals, including + 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", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. @@ -1402,20 +1424,24 @@ 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. Appendix B. Changelog (This section should be removed by the RFC editor.) + Changes from -06 to -07: + + o Editorial fixes from AD evaluation. + Changes from -06.a to -06: o Clarified text about certificates and omitting RR (issue 54). o Take initial addresses from IKE_AUTH even when not doing NAT-T (issue 60). o Added text about dead peer detection (issue 71). o Fixed port numbers in examples (issue 73).