--- 1/draft-ietf-mobike-protocol-05.txt 2006-02-04 17:22:05.000000000 +0100 +++ 2/draft-ietf-mobike-protocol-06.txt 2006-02-04 17:22:05.000000000 +0100 @@ -1,17 +1,17 @@ MOBIKE Working Group P. Eronen, Ed. Internet-Draft Nokia -Expires: April 27, 2006 October 24, 2005 +Expires: May 20, 2006 November 16, 2005 IKEv2 Mobility and Multihoming Protocol (MOBIKE) - draft-ietf-mobike-protocol-05.txt + draft-ietf-mobike-protocol-06.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,82 +22,88 @@ 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 27, 2006. + This Internet-Draft will expire on May 20, 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4 - 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4 - 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 - 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9 - 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10 - 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10 - 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 10 - 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11 - 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12 - 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15 - 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 16 - 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 17 - 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 18 - 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 19 - 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20 - 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20 - 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20 - 4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20 - 4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21 - 4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21 - 4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21 - 4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 23 - 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 23 - 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 24 - 5.4. Spoofing Network Connectivity Indications . . . . . . . . 25 - 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 25 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 - Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 29 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . . . . 33 + 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.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.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 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 @@ -152,21 +158,22 @@ 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 unidirectional paths. + 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] @@ -273,49 +280,49 @@ Initiator Responder ----------- ----------- 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) - 2) (IP_I1:500 -> IP_R1:500) + 2) (IP_I1:4500 -> IP_R1:4500) HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED) } --> - <-- (IP_R1:500 -> IP_I1:500) + <-- (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:500 -> IP_R1:500) + 3) (IP_I2:4500 -> IP_R1:4500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> - <-- (IP_R1:500 -> IP_I2:500) + <-- (IP_R1:4500 -> IP_I2:4500) HDR, SK { N(NAT_DETECTION_*_IP) } (Responder verifies that the initiator has given it a correct IP address.) - 4) <-- (IP_R1:500 -> IP_I2:500) + 4) <-- (IP_R1:4500 -> IP_I2:4500) HDR, SK { N(COOKIE2) } - (IP_I2:500 -> IP_R1:500) + (IP_I2:4500 -> IP_R1:4500) HDR, SK { N(COOKIE2) } --> Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform each other that they support MOBIKE. In step 3, the initiator notices a change in its own address, and informs the responder about this by sending an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification. The request is sent using the new IP address. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. Upon receiving the UPDATE_SA_ADDRESSES notification the responder records the new @@ -331,61 +338,61 @@ Initiator Responder ----------- ----------- 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) - 2) (IP_I1:500 -> IP_R1:500) + 2) (IP_I1:4500 -> IP_R1:4500) HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED) } --> - <-- (IP_R1:500 -> IP_I1:500) + <-- (IP_R1:4500 -> IP_I1:4500) HDR, SK { IDr, CERT, AUTH, CP(CFG_REPLY), SAr2, TSi, TSr, N(MOBIKE_SUPPORTED), N(ADDITIONAL_IPV4_ADDRESS) } (The initiator suspects a problem in the currently used address pair, and probes its liveness.) - 3) (IP_I1:500 -> IP_R1:500) + 3) (IP_I1:4500 -> IP_R1:4500) HDR, SK { N(NAT_DETECTION_*_IP) } --> - (IP_I1:500 -> IP_R1:500) + (IP_I1:4500 -> IP_R1:4500) HDR, SK { N(NAT_DETECTION_*_IP) } --> ... (Eventually, the initiator gives up on the current address pair, and tests the other available address pair.) - 4) (IP_I1:500 -> IP_R2:500) + 4) (IP_I1:4500 -> IP_R2:4500) HDR, SK { N(NAT_DETECTION_*_IP) } - <-- (IP_R2:500 -> IP_I1:500) + <-- (IP_R2:4500 -> IP_I1:4500) HDR, SK { N(NAT_DETECTION_*_IP) } (This worked, and the initiator requests the peer to switch to new addresses.) - 5) (IP_I1:500 -> IP_R2:500) + 5) (IP_I1:4500 -> IP_R2:4500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP), N(COOKIE2) } --> - <-- (IP_R2:500 -> IP_I1:500) + <-- (IP_R2:4500 -> IP_I1:4500) HDR, SK { N(NAT_DETECTION_*_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 @@ -443,33 +450,30 @@ payload). The format of the MOBIKE_SUPPORTED notification is described in Section 4. 3.3. Initial Tunnel Header Addresses When an IPsec SA is created, the tunnel header IP addresses (and port, if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The - addresses in the IKE_SA are initialized 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. + addresses in the IKE_SA are initialized from the IP header of the + first IKE_AUTH request. - The addresses are taken from the IKE_AUTH request 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). + The addresses are taken from the IKE_AUTH request because IKEv2 + requires changing from port 500 to 4500 if a NAT is discovered. To + simplify things, implementations that support both this specification + and NAT Traversal MUST change to port 4500 if the correspondent also + supports both, even if no NAT was detected between them (this way, + there is no need to change the ports later if a a NAT is detected on + some other path). 3.4. Additional Addresses Both the initiator and responder MAY include one or more ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Initiator Responder ----------- ----------- @@ -636,56 +640,67 @@ o If an address change has occurred after the request was first sent, no MOBIKE processing is done for the reply message because a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if window size greater than one is in use). o If the response contains the UNEXPECTED_NAT_DETECTED notification, it processes the response as described in Section 3.9. o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, - keep on using the current addresses, or disconnect. + keep on using the previously used addresses, or disconnect. o It updates the IPsec SAs associated with this IKE_SA with the new - addresses (unless this was already done before sending the - request). + addresses (unless this was already done earlier before sending the + request; this is the case when no return routability check was + required). o If NAT Traversal is supported and NAT detection payloads were included, 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 that the responder is currently using becomes unavailable (i.e., sending packets using that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address (in addition to initiating the procedure described in the next section). 3.6. Updating Additional Addresses As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_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). + 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_*_ADDRESS or + When a request containing ADDITIONAL_IP4/6_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 @@ -721,42 +736,42 @@ 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., - the address is included in the peer's certificate), the return - routability check MAY be omitted. + a certificate issued by an authority trusted for this purpose), the + return routability check MAY be omitted. The check can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated. Any INFORMATIONAL exchange can be used for return routability purposes, with one exception (described later in this section): when a valid response is received, we know the other party can receive packets at the claimed address. To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not - match, the IKE_SA MUST be closed. (See also Section 4.6 for the + match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the format of the COOKIE2 notification.) The exception mentioned earlier is as follows: If the same INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), receiving the INFORMATIONAL response does not tell which address is the working one. In this case, a new INFORMATIONAL request needs to be sent to check return routability. 3.8. Changes in NAT Mappings @@ -812,37 +827,39 @@ when NAT Traversal has not been explicitly enabled. This means that MOBIKE without NAT Traversal support will not work if the paths contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered an attack. More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec - SAs (the 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 + 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. If the exchange initiator receives an UNEXPECTED_NAT_DETECTED - 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. + 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. If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any other purpose than possibly logging the information for troubleshooting purposes. 3.10. Path Testing IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has @@ -860,118 +877,160 @@ In MOBIKE, the initiator is responsible for detecting and recovering from most failures. To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate dead peer detection. While no specific timeout lengths are required, it is suggested that responders continue retransmitting IKEv2 requests for at least five minutes before giving up. +3.12. Dead Peer Detection + + MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but + as addresses may change, it is not sufficient to just verify that the + peer is alive, but also that it is synchronized with the address + updates and has not, for instance, ignored an address update due to + failure to complete return routability test. This means that when + there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the + addresses used in those packets and determine that they correspond to + those that should be employed. If they do not, such packets SHOULD + NOT be used as evidence that the peer is able to communicate with + this node and or that the peer has received all address updates. + 4. Payload Formats This specification defines several new IKEv2 Notify payload types. - The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications - are "error types"; the other notifications are "status types". See - [IKEv2] Section 3.10 for a general description of the Notify payload. + See [IKEv2] Section 3.10 for a general description of the Notify + payload. -4.1. MOBIKE_SUPPORTED Notify Payload +4.1. Notify Messages - Error Types + +4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload + + The responder can include this notification in an INFORMATIONAL + exchange response to indicate that the address change in the + corresponding request message (which contained an UPDATE_SA_ADDRESSES + notification) was not carried out. + + The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. + The Protocol ID and SPI Size fields are set to zero. There is no + data associated with this Notify type. + +4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload + + See Section 3.9 for a description of this notification. + + The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. + The Protocol ID and SPI Size fields are set to zero. There is no + data associated with this Notify type. + +4.2. Notify Messages - Status Types + +4.2.1. MOBIKE_SUPPORTED Notify Payload The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification. The Notify Message Type for MOBIKE_SUPPORTED is 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. ADDITIONAL_IP4/6_ADDRESS Notify Payloads +4.2.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 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 IPv4 address or a 16-octet IPv6 address. -4.3. NO_ADDITIONAL_ADDRESSES Notify Payload +4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 3.6 for more detailed description). The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -4.4. UPDATE_SA_ADDRESSES Notify Payload +4.2.4. UPDATE_SA_ADDRESSES Notify Payload This notification is included in INFORMATIONAL exchange requests sent by the initiator to update addresses of the IKE_SA and IPsec SAs (see Section 3.5). The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. -4.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. - -4.6. COOKIE2 Notify Payload +4.2.5. COOKIE2 Notify Payload This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 3.7). If the INFORMATIONAL request includes COOKIE2, the exchange responder MUST copy the notification to the response message. The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder. The Notify Message Type for this message is TBD-BY-IANA7. The Protocol ID and SPI Size fields are set to zero. -4.7. NO_NATS_ALLOWED Notify Payload +4.2.6. NO_NATS_ALLOWED Notify Payload See Section 3.9 for a description of this notification. - The data field of this notification contains the following - information: the IP address from which the packet was sent (4 or 16 - bytes), the port from which the packet was sent (2 bytes, network - byte order), the IP addresss to which the packet was sent (4 or 16 - bytes), and the port to which the packet was sent (2 bytes, network - byte order). The total length of the data field is thus 12 bytes for - IPv4 and 36 bytes for IPv6. The Notify Message Type for this message - is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to - zero. + The Notify Message Type for this message is TBD-BY-IANA8. The + notification data contains the IP addresses and ports from/to which + the packet was sent. For IPv4, the notification data is 12 octets + long and is defined as follows: -4.8. UNEXPECTED_NAT_DETECTED Notify Payload + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Source IPv4 address ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Destination IPv4 address ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Source port ! Destination port ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - See Section 3.9 for a description of this notification. + For IPv6, the notification data is 36 octets long and is defined as + follows: - 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. + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! + ! Source IPv6 address ! + ! ! + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! + ! Destination IPv6 address ! + ! ! + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Source port ! Destination port ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Protocol ID and SPI Size fields are set to zero. 5. Security Considerations The main goals of this specification are to maintain the security offered by usual IKEv2 procedures and to counter mobility-related threats in an appropriate manner. This section describes new security considerations introduced by MOBIKE. See [IKEv2] for security considerations for IKEv2 in general. 5.1. Traffic Redirection and Hijacking @@ -994,24 +1053,25 @@ of these packets, the attackers can lead the peers to believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and will update the addresses appropriately. MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. - Such modifications can only be performed by attackers who are on the - path and capable of modifying the When this notification is used, - communication through NATs and other address translators is - impossible, so it is sent only when not doing NAT Traversal. + When this notification is used, communication through NATs and other + address translators is impossible, so it is sent only when not doing + NAT Traversal. This feature is mainly intended for IPv6 and site-to- + site VPN cases, where the administrators may know beforehand that + NATs are not present. 5.2. IPsec Payload Protection The use of IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up in an incorrect destination or be eavesdropped along the way. However, security associations originally created for the protection of a specific flow between specific addresses may be updated by @@ -1033,28 +1093,26 @@ 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 - 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. + If the attack is launched by an outsider, the traffic flow would + normally stop soon due to the lack of responses (such as transport + layer acknowledgements). However, if the original recipient of the + flow is malicious, it could maintain the traffic flow for an extended + period of time, since it often would be able to send the required + acknowledgements (see [Aura02] for more discussion). It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network, such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. Furthermore, if the attacker's network has ingress filtering, this attack is largely prevented for MOBIKE as well. Consequently, it makes little sense to protect against attacks of similar nature in MOBIKE. However, it still makes sense to limit the amplification capabilities provided to attackers, so that they cannot use stream redirection to send a large number of packets to the @@ -1062,20 +1120,27 @@ 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. + The duration of the attack can also be limited if the victim reports + the unwanted traffic to the originating IPsec tunnel endpoint using + ICMP error messages or INVALID_SPI notifications. As described in + [IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also + doubles as a return routability check if the COOKIE2 notification is + included. + 5.4. Spoofing Network Connectivity Indications Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof link-layer error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof 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. @@ -1145,97 +1210,99 @@ 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. - Notify Message Value - --------------------------- ----- + Notify Messages - Error Types Value + ----------------------------- ----- + UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) + UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) + + Notify Messages - Status Types Value + ------------------------------ ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) - UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) - UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 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, 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]. + 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 + [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. [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. - 8.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. [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), June 2005. - [DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", - draft-ietf-dhc-dna-ipv4-15 (work in progress), - August 2005. + [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting + Network Attachment (DNA) in IPv4", + draft-ietf-dhc-dna-ipv4-17 (work in progress), + October 2005. [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network Attachment in IPv6 - Best Current Practices for - hosts", draft-ietf-dna-hosts-01 (work in progress), - June 2005. + hosts", draft-ietf-dna-hosts-02 (work in progress), + October 2005. [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE - protocol", draft-ietf-mobike-design-02 (work in progress), - February 2005. + protocol", draft-ietf-mobike-design-04 (work in progress), + October 2005. [ICMPAttacks] Gont, F., "ICMP attacks against TCP", - draft-gont-tcpm-icmp-attacks-03 (work in progress), - December 2004. + draft-gont-tcpm-icmp-attacks-05 (work in progress), + October 2005. [Kivinen] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 (work in progress), February 2004. [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. @@ -1258,24 +1325,126 @@ [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. -Appendix A. Changelog +Appendix A. Implementation Considerations + +A.1. Links from SPD Cache to Outbound SAD Entries + + [IPsecArch] Section 4.4.2 says that "For outbound processing, each + SAD entry is pointed to by entries in the SPD-S part of the SPD + cache". The document does not specify how exactly this "pointing" is + done, since this is an implementation detail that does not have to be + standardized. + + However, it is clear that the links between the SPD cache and the SAD + have to be done correctly to ensure that outbound packets are sent + over the right SA. Some implementations are known to have problems + in this area. + + In particular, simply storing the (remote tunnel header IP address, + remote SPI) pair in the SPD cache is not sufficient, since the pair + does not always uniquely identify a single SAD entry. For instance, + two hosts behind the same NAT can accidentally happen to choose the + same SPI value. The situation can also occur when a host is assigned + an IP address previously used by some other host, and the SAs + associated with the old host have not yet been deleted by dead peer + detection. This may lead to packets being sent over the wrong SA or, + if the key management daemon ensures the pair is unique, denying the + creation of otherwise valid SAs. + + Storing the remote tunnel header IP address in the SPD cache may also + complicate the implementation of MOBIKE, since the address can change + during the lifetime of the SA. Thus, we recommend implementing the + links between the SPD cache and the SAD in a way that does not + require modification when the tunnel header IP address is updated by + MOBIKE. + +A.2. Creating Outbound SAs + + When an outbound packet requires IPsec processing but no suitable SA + exists, a new SA will be created. In this case, the host has to + determine (1) who is the right peer for this SA, (2) whether the host + already has an IKE_SA with this peer, and (3) if no IKE_SA exists, + the IP address(es) of the peer for contacting it. + + Neither [IPsecArch] nor MOBIKE specifies how exactly these three + steps are carried out. [IPsecArch] Section 4.4.3.4 says: + + For example, assume that IKE A receives an outbound packet + destined for IP address X, a host served by a security + gateway. RFC 2401 and 2401bis do not specify how A determines + the address of the IKE peer serving X. However, any peer + contacted by A as the presumed representative for X must be + registered in the PAD in order to allow the IKE exchange to be + authenticated. Moreover, when the authenticated peer asserts + that it represents X in its traffic selector exchange, the PAD + will be consulted to determine if the peer in question is + authorized to represent X. + + In step 1, there may be more than one possible peer (e.g., several + security gateways that are allowed to represent X). In step 3, the + host may need to consult a directory such as DNS to determine the + peer IP address(es). + + When performing these steps, implementations may use information + contained in the SPD, the PAD, and possibly some other + implementation-specific databases. Regardless of how exactly the + steps are implemented, it is important to remember that IP addresses + can change, and that an IP address alone does not always uniquely + identify a single IKE peer (for the same reasons as why the + combination of the remote IP address and SPI does not uniquely + identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 + and 2 it may be easier to identify the "right peer" using its + authenticated identity instead of its current IP address. However, + these implementation details are beyond the scope of this + specification. + +Appendix B. Changelog (This section should be removed by the RFC editor.) + 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). + + o Updated acknowledgements list and references. + + Changes from -05 to -06.a: + + o Clarified third-party DoS security considerations (issue 45). + + o Clarified the use of ADDITIONAL_*_ADDRESS/NO_ADDITIONAL_ADDRESSES + notifications and deleting addresses (issues 46 and 58). + + o Better separation of error and status types (issue 59). + + o Changed order of fields in NO_NATS_ALLOWED and provided a bit + diagram (issue 59). + + o Added implementation considerations appendix (issues 51 and 70). + + o Editorial fixes and clarifications (issues 54, 56, 59, 64, 72). + Changes from -04 to -05: o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53, 62, 66, 67, 68, 69). o Ignore data in MOBIKE_SUPPORTED (issue 61). Changes from -03 to -04: o Copy-editing done by the RFC editor.