IKEv2 Mobility and Multihoming T. Kivinen (mobike) Safenet, Inc. Internet-Draft H. Tschofenig Expires: January 19, 2006 Siemens July 18, 2005 Design of the MOBIKE Protocol draft-ietf-mobike-design-03.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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing extensions for the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). Kivinen & Tschofenig Expires January 19, 2006 [Page 1] Internet-Draft Design of the MOBIKE Protocol July 2005 This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13 5.2 Changing a Preferred Address and Multi-homing Support . . 13 5.2.1 Storing a single or multiple addresses . . . . . . . . 14 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 5.5 Changing addresses or changing the paths . . . . . . . . . 20 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20 5.7 Employing MOBIKE results in other protocols . . . . . . . 23 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 24 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 25 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 5.11 Message Representation . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1 Normative references . . . . . . . . . . . . . . . . . . . 32 10.2 Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . 35 Kivinen & Tschofenig Expires January 19, 2006 [Page 2] Internet-Draft Design of the MOBIKE Protocol July 2005 1. Introduction The purpose of IKEv2 is to mutually authenticate two hosts, establish one or more IPsec Security Associations (SAs) between them, and subsequently manage these SAs (for example, by rekeying or deleting). IKEv2 enables the hosts to share information that is relevant to both the usage of the cryptographic algorithms that should be employed (e.g., parameters required by cryptographic algorithms and session keys) and to the usage of local security policies, such as information about the traffic that should experience protection. IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. This means that, in each host, only one IP address pair is stored for the IKEv2 SA as part of a single IKEv2 protocol session, and, for tunnel mode SAs, the hosts places this single pair in the outer IP headers. Existing documents make no provision to change this pair after an IKE SA is created. There are scenarios where one or both of the IP addresses of this pair may change during an IPsec session. In principle, the IKE SA and all corresponding IPsec SAs could be re-established after the IP address has changed. However, this can be problematic, as the device might be too slow for this task. Moreover, manual user interaction (for example when using SecurID cards) might be required as part of the IKEv2 authentication procedure. Therefore, an automatic mechanism is neeed that updates the IP addresses associated with the IKE SA and the IPsec SAs. MOBIKE provides such a mechanism. The work of the MOBIKE working group and therefore this document is based on the assumption that the mobility and multi-homing extensions are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC2401bis. The document does not aim to neither provide support IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401]. This document is structured as follows. After introducing some important terms in Section 2 a number of relevant usage scenarios are discussed in Section 3. Section 4 discusses the interoperation of MOBIKE with other protocols and processes that may run in the local machine. Finally, Section 5 discusses design considerations affecting the MOBIKE protocol. The document concludes in Section 6 with security considerations. Kivinen & Tschofenig Expires January 19, 2006 [Page 3] Internet-Draft Design of the MOBIKE Protocol July 2005 2. Terminology This section introduces the terminology that is used in this document. Peer: A peer is an IKEv2 endpoint. In addition, a peer implements the MOBIKE extensions, as defined in this and related documents. Available address: An address is said to be available if the following conditions are met: * The address has been assigned to an interface. * If the address is an IPv6 address, we additionally require (a) that the address is valid as defined in RFC 2461 [RFC2461], and (b) that the address is not tentative as defined in RFC 2462 [RFC2462]. In other words, we require the address assignment to be complete. Note that this explicitly allows an address to be optimistic as defined in [I-D.ietf-ipv6-optimistic-dad]. * If the address is an IPv6 address, it is a global unicast or unique site-local address, as defined in [I-D.ietf-ipv6-unique- local-addr]. That is, it is not an IPv6 link-local. Where IPv4 is considered, it is not an RFC 1918 [RFC1918] address. * The address and interface is acceptable for sending and receiving traffic according to a local policy. This definition is taken from [I-D.arkko-multi6dt-failure- detection] . Locally Operational Address: An address is said to be locally operational if it is available and its use is locally known to be possible and permitted. This definition is taken from [I-D.arkko-multi6dt-failure-detection]. Kivinen & Tschofenig Expires January 19, 2006 [Page 4] Internet-Draft Design of the MOBIKE Protocol July 2005 Operational address pair: A pair of operational addresses are said to be an operational address pair, if and only if bidirectional connectivity can be shown between the two addresses. Note that sometimes it is necessary to consider connectivity on a per-flow level between two endpoints needs to be tested. This differentiation might be necessary to address certain Network Address Translation types or specific firewalls. This definition is taken from [I-D.arkko- multi6dt-failure-detection] and adapted for the MOBIKE context. Although it is possible to further differentiate unidirectional and bidirectional operational address pairs, only bidirectional connectivity is relevant to this document and unidirectional connectivity is out of scope. Path: The sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire they might be routed along a different path, for example by load balancers. This definition is taken from [RFC2960] and adapted to the MOBIKE context. Primary Path: The sequence of routers traversed by an IP packet that carries the default source and destination addresses is said to be the Primary Path. This definition is taken from [RFC2960] and adapted to the MOBIKE context. Preferred Address: The IP address of a peer to which MOBIKE and IPsec traffic should be sent by default. A given peer has only one active preferred address at a given point in time, except for the small time period where it switches from an old to a new preferred address. This definition is taken from [I-D.ietf-hip-mm] and adapted to the MOBIKE context. Kivinen & Tschofenig Expires January 19, 2006 [Page 5] Internet-Draft Design of the MOBIKE Protocol July 2005 Peer Address Set: We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set. Such a policy might be created either manually or automatically through interaction with other mechanisms that indicate new available addresses. Terminology regarding NAT types (e.g. Full Cone, Restricted Cone, Port Restricted Cone and Symmetric), can be found in Section 5 of [RFC3489]. For mobility related terminology (e.g. Make-before-break or Break-before-make) see [RFC3753]. Kivinen & Tschofenig Expires January 19, 2006 [Page 6] Internet-Draft Design of the MOBIKE Protocol July 2005 3. Scenarios In this section we discuss three typical usage scenarios for the MOBIKE protocol. 3.1 Mobility Scenario Figure 1 shows a break-before-make mobility scenario where a mobile node changes its point of network attachment. Prior to the change, the mobile node had established an IPsec connection with a security gateway which offered, for example, access to a corporate network. The IKEv2 exchange that facilitated the set up of the IPsec SA(s) took place over the path labeled as 'old path'. The involved packets carried the MN's "old" IP address and were forwarded by the "old" access router (OAR) to the security gateway (GW). When the MN changes its point of network attachment, it obtains a new IP address using statefu address configuration techniques or via the stateless address autoconfiguration mechanism. The goal of MOBIKE, in this scenario, is to enable the MN and the GW to continue using the existing SAs and to avoid setting up a new IKE SA. A protocol exchange, denoted by 'MOBIKE Address Update', enables the peers to update their state as necessary. Note that in a break-before-make scenario the MN obtains the new IP address after it can no longer be reached at the old IP address. In a make-before-break scenario, the MN is, for a given period of time, reachable at both the old and the new IP address. MOBIKE should work in both the above scenarios. Kivinen & Tschofenig Expires January 19, 2006 [Page 7] Internet-Draft Design of the MOBIKE Protocol July 2005 (Initial IKEv2 Exchange) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v Old IP +--+ +---+ v address |MN|------> |OAR| -------------V v +--+ +---+ Old path V v . +----+ v>>>>> +--+ .move | R | -------> |GW| . | | >>>>> | | v +----+ ^ +--+ +--+ +---+ New path ^ ^ New IP |MN|------> |NAR|--------------^ ^ address +--+ +---+ ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ (MOBIKE Address Update) ---> = Path taken by data packets >>>> = Signaling traffic (IKEv2 and MOBIKE) ...> = End host movement Figure 1: Mobility Scenario 3.2 Multihoming Scenario Another MOBIKE usage scenario is depicted in Figure 2. In this scenario, the MOBIKE peers are equipped with multiple interfaces (and multiple IP addresses). Peer A has two interface cards with two IP addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 and IP_B2. Each peer selects one of its IP addresses as the preferred address which is used for subsequent communication. Various reasons, (e.g hardware or network link failures), may require a peer to switch from one interface to another. +------------+ +------------+ | Peer A | *~~~~~~~~~* | Peer B | | |>>>>>>>>>> * Network *>>>>>>>>>>| | | IP_A1 +-------->+ +--------->+ IP_B1 | | | | | | | | IP_A2 +********>+ +*********>+ IP_B2 | | | * * | | +------------+ *~~~~~~~~~* +------------+ ---> = Path taken by data packets >>>> = Signaling traffic (IKEv2 and MOBIKE) ***> = Potential future path through the network (if Peer A and Peer B change their preferred address) Kivinen & Tschofenig Expires January 19, 2006 [Page 8] Internet-Draft Design of the MOBIKE Protocol July 2005 Figure 2: Multihoming Scenario Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available IP addresses at a given point in time. 3.3 Multihomed Laptop Scenario The third scenario we consider is about a laptop, which has multiple interface cards and therefore several ways to connect to the network. It may for example have a fixed Ethernet card, a WLAN interface, a GPRS adaptor, a Bluetooth interface or USB hardware. Not all interfaces are connected to the network at all times for a number of reasons (e.g., cost, availability of certain link layer technologies, user convenience). The mechanism that determines which interfaces are connected to the network at any given point in time is outside the scope of the MOBIKE protocol and, as such, this document. However, as the laptop changes its point of attachment to the network, the set of IP addresses under which the laptop is reachable, changes too. Even if IP addresses change due to interface switching or mobility, the IP address obtained via the configuration payloads within IKEv2 remain unaffected. The IP address obtained via the IKEv2 configuration payloads allow the configuration of the inner IP address of the IPsec tunnel. As such, applications might not detect any change at all. Kivinen & Tschofenig Expires January 19, 2006 [Page 9] Internet-Draft Design of the MOBIKE Protocol July 2005 4. Framework The working group will develop a MOBIKE protocol which needs to perform the following operations: o inform the other peer about the peer address set o inform the other peer about the preferred address o test connectivity along a path and thereby to detect an outage situation o change the preferred address o change the peer address set o Ability to deal with Network Address Translation devices The technical details of these functions are discussed below. Although MOBIKE will have to interact with other mechanisms, the working group is chartered to leave this aspect outside the scope. When a MOBIKE peer initiates a protocol exchange it needs to define a peer address set based on the IP addresses available to it. The peer may want to make this set available to the other peer. The IKEv2 Initiator does not need to indicate which of the addresses in the peer address set is its preferred address. This is because the Initiator has to place its preferred address into the source IP address field of the IP header with the initial message exchange. Additionally, the Initiator expects incoming signaling messages to arrive at this address. The peer address set and the preferred address are defined based on interaction with other components within a host. In some cases, the peer address set may be available before the initial protocol exchange and does not change during the lifetime of the IKE-SA. The preferred address might change due to policy reasons. Section 3 describes three scenarios in which the peer address set is modified (by adding or deleting addresses). In these scenarios the preferred address may change as well. A modification of the peer address set or a change of the preferred address typically is the result of the MOBIKE peer's local policy and by the interaction with other protocols (such as DHCP or IPv6 Neighbor Discovery). Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the IPsec engine using the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create entries in the Security Association (SAD) and Security Policy Kivinen & Tschofenig Expires January 19, 2006 [Page 10] Internet-Draft Design of the MOBIKE Protocol July 2005 Databases (SPD). The IPsec engine may also interact with IKEv2 and MOBIKE daemon using this API. The content of the Security Policy and Security Association Databases determines what traffic is protected with IPsec in which fashion. MOBIKE, on the other hand, receives information from a number of sources that may run both in kernel-mode and in user-mode. Information relevant for MOBIKE might be stored in a database. The contents of such a database, along with the occurrence of events of which the MOBIKE process is notified, form the basis on which MOBIKE decides regarding the set of available addresses, the peer address set, and the preferred address. Policies may also affect the selection process. The a peer address set and the preferred address needs to be available to the other peer. In order to address certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Although a number of address pairs may be available for such tests, the most important is the pair (source address, destination address) of the primary path. This is because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic. If a problem along this primary path is detected (e.g., due to a router failure) it is necessary to switch to a new primary path. In order to be able to do so quickly, it may be helpful to perform connectivity tests of other paths periodically. Such a technique would also help in identifying previously disconnected paths that become operational. Kivinen & Tschofenig Expires January 19, 2006 [Page 11] Internet-Draft Design of the MOBIKE Protocol July 2005 +-------------+ +---------+ |User-space | | MOBIKE | |Protocols | +-->>| Daemon | |relevant for | | | | |MOBIKE | | +---------+ +-------------+ | ^ User Space ^ | ^ ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ Kernel Space v | v _______ | v +-------------+ / \ | +--------------+ |Routing | / Trigger \ | | IPsec | |Protocols |<<-->>| Database |<<-+ +>+ Engine | | | \ / | | (+Databases) | +-----+---+---+ \_______/ | +------+-------+ ^ ^ ^ | ^ | +---------------+-------------+--------+-----+ | v | | | | +-------------+ | | | I | |Kernel-space | | | | I n | +-------->+Protocols +<----+-----+ | | n t v v |relevant for | | v v v t e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e r | Input | +-------------+ | | Outgoing | r f | Packet +<--------------------------+ | Interface | f ==a>|Processing|===============================| Processing |=a> c | | | | c e +----------+ +------------+ e s s ===> = IP packets arriving/leaving a MOBIKE node <-> = control and configuration operations Figure 3: Framework Please note that Figure 3 illustrates an example of how a MOBIKE implementation could work. Hence, it serves illustrative purposes only. Extensions of the PF_KEY interface required by MOBIKE are also within the scope of the working group. Finally, certain optimizations for wireless environments are also covered. Kivinen & Tschofenig Expires January 19, 2006 [Page 12] Internet-Draft Design of the MOBIKE Protocol July 2005 5. Design Considerations This section discusses aspects affecting the design of the MOBIKE protocol. 5.1 Indicating Support for MOBIKE In order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. If one or none of the peers supports MOBIKE, then, whenever an IP address changes, IKEv2 will have to be re-run in order to create a new IKE SA and the respective IPsec SAs. In MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. If these messages are not understood, it is possible that connectivity between the peers is lost. One way to ensure that a peer receives feedback on whether or not its messages are understood by the other peer, is by using IKEv2 messaging for MOBIKE and to mark some messages as "critical". According to the IKEv2 specification, such messages either have to be understood by the receiver, or an error message has to be returned to the sender. A second way to ensure receipt of the above-mentioned feedback is by using Vendor ID payloads that are exchanged during the initial IKEv2 exchange. These payloads would then indicate whether or not a given peer supports the MOBIKE protocol. A third approach would use the Notify payload which is also used for NAT detection (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads). Both a Vendor ID and a Notify payload may be used to indicate the support of certain extensions. Note that a MOBIKE peer could also attempt to execute MOBIKE opportunistically with the critical bit set when an address change has occurred. The drawback of this approach is, however, that an unnecessary MOBIKE message exchange is introduced. Although Vendor ID payloads and Notifications are technically equivalent, Notifications are already used in IKEv2 as a capability negotiation mechanism. Hence, Notifications and Vendor ID payloads are the preferred mechanisms. 5.2 Changing a Preferred Address and Multi-homing Support From MOBIKE's point of view, support for multi-homing is inherently Kivinen & Tschofenig Expires January 19, 2006 [Page 13] Internet-Draft Design of the MOBIKE Protocol July 2005 provided by the fact that it manages a set of peer addresses, rather than a single address. Further, MOBIKE provides mechanisms to change a peer's preferred IP address. Each peer needs to learn the preferred address and the peer address set. 5.2.1 Storing a single or multiple addresses One design decision is whether an IKE-SA should be associated with a single IP address or multiple IP addresses. One option is that a peer can provide a list of addresses to its counterpart which can then be used as destination addresses. Note that MOBIKE does not support load balancing, i.e., only one IP address is set to a preferred address at a time and changing the preferred address typically requires some MOBIKE signaling. Another option is to only communicate one address to the other peer and both peers only use that address when communicating. If this address cannot be used anymore then an address update is sent to the other peer that changes the preferred address. Alternatively, if peer A, for example,provides a peer address set with multiple IP addresses then peer B can recover from a failure of the preferred address without further communication with peer A. That is, if it detects that the primary path does not work anymore it can either switch to a new preferred address locally (i.e., changing the source IP address of outgoing MOBIKE messages) or to try an IP address from A's peer address set (i.e., changing the destination address). If peer B only received a single IP address from peer A for A then peer B can only change its own preferred address. Peer B would have to wait for an address update from peer A with a new IP address in order to fix the problem. The main advantage of storing only a single IP address for the remote peer is that it makes retransmission handling easier. Moreover, it simplifies the recovery procedure. The peer whose IP address changed must start the recovery process and send the new IP address to the other peer. However, connectivity failures along the path are not well addressed with advertising a single IP address. The single IP address approach does not work if both peers change their IP addresses at the same time, for example if both hosts move simultaneously, even though multiple addresses are available to the two peers. The IKEv2 implementation might also require window size to be larger than 1 because the MOBIKE peer needs to be able to send the IP address change notifications before it switches to another address. Depending on the occurrence of return routability checks, retransmissions policies and similar message exchanges a window size Kivinen & Tschofenig Expires January 19, 2006 [Page 14] Internet-Draft Design of the MOBIKE Protocol July 2005 larger than 1 might be required to deal with more than one pending response at the same time. Furthermore, the single IP address approach does not really benefit much from indirect indications as the peer receiving these indications might not be able to fix the situation by itself (e.g., even if a peer receives an ICMP host unreachable message for the old IP address, it cannot try another IP address, since it does not know any). The problems with IP address lists lie mostly in their complexity. Notification and recovery processes are more complicated. Both ends can recover from the IP address changes. However, both peers should not attempt to recover at the same time or nearly the same time as this could cause them to lose connectivity. The MOBIKE protocol is required to prevent this. The previous discussion is independent of the question of how many addresses to send in a single MOBIKE message. A MOBIKE message might be able to carry more than one IP address (with the IP address list approach) or a single address only. A NAT does not change addresses carried inside the MOBIKE message but it can change IP address (and transport layer addresses) in the IP header and Transport Protocol header (if NAT traversal is enabled as part of configuration or dynamically through the NAT discovery mechanism. Furthermore, a MOBIKE message carrying the peer address set could be idempotent (i.e., always resending the full address list) or the protocol may allow add/delete operations to be specified. [I-D.dupont-ikev2- addrmgmt], for example, offers an approach which defines add/delete operations. The same is true for the dynamic address reconfiguration extension for SCTP [I-D.ietf-tsvwg-addip-sctp]. 5.2.2 Indirect or Direct Indication An indication to change the preferred IP address might be either direct or indirect. Direct indication: A direct indication means that the other peer will send an message with the address change. This can, for example, be accomplished by having MOBIKE sending an authenticated address update notification with a different preferred address. Indirect indication: An indirect indication to change the preferred address can be obtained by observing the environment. An indirect indication Kivinen & Tschofenig Expires January 19, 2006 [Page 15] Internet-Draft Design of the MOBIKE Protocol July 2005 might, for example, be the receipt of an ICMP message or information about a link failure. This information should be seen as a hint and should not cause a change of the remote peer's preferred address. Depending on the local policy, MOBIKE may decide to perform a dead-peer detection exchange for the preferred address pair (or another address pair from the peer address set). When a peer detects that the other end started to use a different source IP address than before, it might want to authorize the new preferred address (if not already authorized). Authorization aims to ensure that a particular peer is allowed to use the indicated address. Claiming to be at an arbitrary address without performing a return-routability test or without verifying that the IP address is listed within a certificate opens the door for various denial of service attacks. Hence a peer may also start a connectivity test of this particular address. If more information is available to the MOBIKE daemon then a more intelligent decision regarding the selection of a new primary path can be made. 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection This section discusses the suitability of the IKEv2 dead-peer detection (DPD) mechanism for connectivity tests between address pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but it needs to be investigated whether it can be used for MOBIKE purposes as well. The IKEv2 DPD mechanism involves sending an empty informational exchange packet to a given address of the remote peer. On receipt, the remote peer responds with an acknowledgement. If no acknowledgement is received after a certain timeout period (and after couple of retransmissions), the remote peer is considered to be not reachable at the address in question. On the other hand, receipt of IPsec protected acknowledgement is a guarantee that the other peer is reachable at the address in question. When reusing dead-peer detection in MOBIKE for connectivity tests it seems to be reasonable to try other IP addresses (if they are available) in case of an unsuccessful connectivity test for a given address pair. Dead-peer detection messages using a different address pair should use the same message-id as the original dead-peer detection message (i.e. they are simply retransmissions of the dead- peer detection packet using different destination IP address). If different message-id is used then it violates constraints placed by the IKEv2 specification on the DPD message with regard to the mandatory ACK for each message-id, causing the IKEv2 SA to be deleted. Kivinen & Tschofenig Expires January 19, 2006 [Page 16] Internet-Draft Design of the MOBIKE Protocol July 2005 If MOBIKE strictly follows the guidelines of the dead-peer detection mechanism in IKEv2 then an IKE-SA should be marked as dead and deleted if the connectivity test for all available address pairs fails. Note that this is not in-line with the approach used, for example, in SCTP where a failed connectivity test for an address does not lead to (a) the IP address or IP address pair to be marked as dead and (b) delete state. Connectivity tests will be continued for the address pairs in hope that the problem will recover soon. This comparison with SCTP aims to point at another IETF protocol that aims to address the multi-homing problem (although with a different scope and a different layer). Note that IKEv2 implementations may have a window size of 1, and therefore be unable to initiate a dead-peer detection exchange while another exchange is pending. As a result, all other exchanges are subject to an identical retransmission policy as used for the dead- peer detection. To use a different policy for different message types seems to be reasonable. The dead-peer detection mechanism for the other IP address pairs can also be executed simultaneously if the window size larger than 1, meaning that after the initial timeout period of the preferred address expires, DPD packets are sent simultaneously to all other address pairs. It is necessary to differentiate acknowledgement messages in order to determine which address pair is operational. The source IP address of the acknowledgement can be used for this purpose. The protocol should also be nice to the network, meaning, that when some core link goes down, and a large number of MOBIKE clients notice this, they should not start sending a large number of messages while trying to recover from the problem. This may be particularly unfortunate because packets may be dropped because of congestion in the first place. If MOBIKE clients simultaneously try to test all possible address pairs by executing connectivity tests then the congestion problem only gets worse. Also note that the IKEv2 dead-peer detection is not sufficient for the return routability check. See Section 5.6 for more information. 5.3 Simultaneous Movements MOBIKE does not aim to provide a mobility solution that allows simultaneous movements. Instead, the MOBIKE working group focuses on selected scenarios as described in Section 3. Some of the scenarios assume that one peer has a fixed set of addresses (from which some subset might be in use). Thus it cannot move to an address that is unknown to the other peer. Situations in which both peers move Kivinen & Tschofenig Expires January 19, 2006 [Page 17] Internet-Draft Design of the MOBIKE Protocol July 2005 simultaneously are outside the scope of the MOBIKE WG. MOBIKE has not been chartered to deal with the rendezvous problem, or with the introduction of new entities in the network. Note that if only a single address is stored in the peer address set (instead of an address list) we might end up in the case where it seems that both peers changed their addresses at the same time (e.g., if both nodes change their addresses at the same time). This is something that the MOBIKE protocol must deal with. Three cases can be differentiated: o Two mobile nodes obtain a new address at the same time, and then being unable to tell each other where they are (in a break-before- make scenario). This problem is called the rendezvous problem, and is traditionally solved by introducing another third entity, for example, the home agents (in Mobile IPv4/IPv6) or forwarding agents (in the Host Identity Protocol). Essentially, solving this problem requires the existence of additional infrastructure nodes. o Simultaneous changes to addresses such that at least one of the new addresses is known to the other peer before the change occurred. o No simultaneous changes at all. 5.4 NAT Traversal IKEv2 supports legacy NAT traversal. This feature is known as NAT-T which allows IKEv2 to work even if a NAT along the path between the Initiator and the Responder modifies the source and possibly the destination IP address. With NAPT even the transport protocol identifiers are modified (which then requires UDP encapsulation for exchanged IPsec protected data traffic). Therefore, the MOBIKE daemon needs to obtain to required IP address informationfrom the IP header (if a NAT was detected that modified the IP header) rather than from the protected payload. This problem is not new and is an issues of every mobility protocol where the most important information exchanged is the IP address . One of the goals in the MOBIKE protocol is to securely exchange one or more addresses of the peer address set and to securely set the primary address. If no other protocol is used to securely retrieve the IP address and port information allocated by the NAT then it is Kivinen & Tschofenig Expires January 19, 2006 [Page 18] Internet-Draft Design of the MOBIKE Protocol July 2005 not possible to tackle all attacks against MOBIKE. Section 6 discusses this aspect in more detail. Various approaches to solve the problem have been presented: o Securely retrieving IP address and port information allocated by the NAT using a protocol different from MOBIKE. This approach is outside the scope of the MOBIKE working group since other working groups, such as MIDCOM and NSIS, already deal with this problem. The MOBIKE protocol can benefit from the interaction with these protocols but the interaction with these protocols it outside the scope of this document. o Design a protocol in such a way that NAT boxes are able to inspect (or even participate) in the protocol exchange. This approach was taken with the Host Identity Protocol but is not an option for IKEv2 and MOBIKE since most IKEv2 messages are encrypted with the established IKE SA. This prevents the NAT from learning required information from the protocol exchange in a similar fashion as in HIP. o Disable NAT-T by indicating the desire never to use information from the (unauthenticated) header. While this approach prevents some security problems it effectively disallows the protocol to work in environments with NATs. There is no way to distinguish the whether there is a NAT device along the path that modifies the header information in packets or an adversary mounting an attack. If a NAT is detected during the creation of an IKE SA, that should automatically disable the MOBIKE extensions and use NAT-T. A design question is whether NAT detection capabilities should be enabled only during the initial IKEv2 exchange or also during subsequent message exchanges. If MOBIKE is executed with no NAT along the path when the IKE SA was created, then a NAT which appears after moving to a new network cannot be dealt with if NAT detection is enabled only during the initial exchange. Hence, it is desirable to also support a scenario where a MOBIKE peer moves from a subnet that is not behind a NAT to a network that is. A NAT prevention mechanism can be used to make sure that no adversary can interact with the protocol if no NAT is expected between the Initiator and the Responder. (reference? Explanation?) Whether or not MOBIKE should support NAT traversal is one of the most Kivinen & Tschofenig Expires January 19, 2006 [Page 19] Internet-Draft Design of the MOBIKE Protocol July 2005 important design decisions. 5.5 Changing addresses or changing the paths A design decision is whether it is enough for the MOBIKE protocol to detect dead addresses, or it also needs to detect dead paths. Dead address detection refers to the ability to establish whether or not a given IP address pair is operational. Dead path detection refers to the ability to establish whether or not all possible (local/remote) address pairs are operational (or at least find one such pair). While performing just one address change is simpler, the existence of locally operational addresses is not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent the sent packets from reaching their destination. 5.6 Return Routability Tests Changing the preferred address and subsequently using it for communication is associated with an authorization decision: Is a peer allowed to use this address? Does this peer own this address? Two mechanisms have been proposed in the past to allow a peer to determine the answer to this question: o The addresses a peer is using are part of a certificate. [RFC3554] which is introduced by this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appear in the certificate. o A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done in order provide a certain degree of confidence to the remote peer that local peer is reachable at the indicated address. Without taking an authorization decision a malicious peer can redirect traffic towards a third party or a blackhole. A MOBIKE peer should not use an IP addressed provided by another MOBIKE peer as a primary address without computing the authorization decision. If the addresses are part of the certificate then it is not necessary to execute the weaker return-routability test. The return-routability test is a form of authorization check, although it provides weaker guarantees then the inclusion of the IP address as Kivinen & Tschofenig Expires January 19, 2006 [Page 20] Internet-Draft Design of the MOBIKE Protocol July 2005 part of a certificate. If multiple addresses are communicated to the remote peer then some of these addresses may be already verified even if the primary address is still operational. Another option is to use the [I-D.dupont-mipv6-3bombing] approach which suggests to perform a return routability test only when an address update needs to be sent from some address other than the indicated preferred address. Finally it would be possible not to execute return routability checks at all. In case of indirect change notifications we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check. With a direct notification the authenticated peer may have provided an authenticated IP address. Thus it is would be possible to simply trust the MOBIKE peer to provide a proper IP address. There is no way an adversary can successfully launch an attack by injecting faked addresses since it does not know the IKE SA and the corresponding keying material.A protection against an internal attacker, i.e. the authenticated peer forwarding its traffic to the new address, is not provided. This might be an issue when extensions are added to IKEv2 that do not require authentication of end points (e.g., opportunistic security using anonymous Diffie- Hellman). On the other hand we know the identity of the peer in that case. The identity of the IKEv2 Initiator and the IKEv2 Responder can take various forms: IP address, FQDN, DN, email address alike identifiers, etc. It seems that there it is also a policy issue when to schedule a return routability test. The basic format of the return routability check could be similar to dead-peer detection, but the problem is that if that fails then the IKEv2 specification requires the IKE SA to be deleted. Because of this a different type of exchange is required and thereby avoiding modifications to the IKEv2 specification. There are potential attacks if a return routability check does not include some kind of nonce. The valid end point could send an address update notification for a third party, trying to get all the traffic to be sent there, causing a denial of service attack. If the return routability checks does not contain any cookies or other random information not known to the other end, then that valid node could reply to the return routability checks even when it cannot see the request. This might cause a peer to move the traffic to a location where the original recipient cannot be reached. The IKEv2 NAT-T mechanism does not perform return routability checks. Kivinen & Tschofenig Expires January 19, 2006 [Page 21] Internet-Draft Design of the MOBIKE Protocol July 2005 It simply uses the last seen source IP address used by the other peer as the destination address to send response packets. An adversary can change those IP addresses, and can cause the response packets to be sent to wrong IP address. The situation is self-fixing when the adversary is no longer able to modify packets and the first packet with an unmodified IP address reaches the other peer. Mobility environments make this attack more difficult for an adversary since it requires the adversary to be located somewhere on the individual paths ({CoA1, ..., CoAn} towards the destination IP address) have a shared path or if the adversary is located near the MOBIKE client then it needs to follow the user mobility patterns. With IKEv2 NAT-T, the genuine client can cause third party bombing by redirecting all the traffic pointed to him to third party. As the MOBIKE protocol tries to provide equal or better security than IKEv2 NAT-T mechanism it should protect against these attacks. There may be return routability information available from the other parts of the system too (as shown in Figure 3), but the checks done may have a different quality. There are multiple levels for return routability checks: o None, no tests o A party willing to answer the return routability check is located along the path to the claimed address (). This is the basic form of return routability test. o There is an answer from the tested address, and that answer was authenticated, integrity and replay protected. o There was an authenticated, integrity and replay protected answer from the peer, but it is not guaranteed to originate at the tested address or path to it (because the peer can construct a response without seeing the request). The return routability checks do not protect against 3rd party bombing if the attacker is along the path, as the attacker can forward the return routability checks to the real peer (even if those packets are cryptographically authenticated). If the address to be tested is carried inside the MOBIKE payload, then the adversary cannot forward packets. Thus 3rd party bombings are prevented. Kivinen & Tschofenig Expires January 19, 2006 [Page 22] Internet-Draft Design of the MOBIKE Protocol July 2005 If the reply packet can be constructed without seeing the request packet (for example, if there is no nonce, challenge or similar mechanism to show liveness), then the genuine peer can cause 3rd party bombing, by replying to those requests without seeing them at all. Other levels might only provide a guarantee that there is a node at the IP address which replied to the request. There is no indication as to whether or not the reply is fresh, and whether or not the request may have been transmitted from a different source address. 5.7 Employing MOBIKE results in other protocols If MOBIKE has learned about new locations or verified the validity of a remote address through a return routability check, can this information be useful for other protocols? When considering the basic MOBIKE VPN scenario, the answer is no. Transport and application layer protocols running inside the VPN tunnel are unaware of the outer addresses or their status. Similarly, IP layer tunnel termination at a gateway rather than a host endpoint limits the benefits for "other protocols" that could be informed -- all application protocols at the other side are unaware of IPsec, IKE, or MOBIKE. However, it is conceivable that future uses or extensions of the MOBIKE protocol make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would potentially be useful for SCTP to learn about the new addresses at the same time as MOBIKE. Similarly, various IP layer mechanisms may make use of the fact that a return routability test of a specific type has been performed. However, care should be exercised in all these situations . [I-D.crocker-celp] discusses the use of common locator information pools in a IPv6 multi-homing context; it assumed that both transport and IP layer solutions are be used in order to support multi-homing, and that it would be beneficial for different protocols to coordinate their results in some way, for instance by sharing throughput information of address pairs. This may apply to MOBIKE as well, assuming it co-exists with non-IPsec protocols that are faced with the same or similar multi-homing choices. Nevertheless, all of this is outside the scope of current MOBIKE base protocol design and may be addressed in future work. (so why do you elaborate so much on this stuff?) Kivinen & Tschofenig Expires January 19, 2006 [Page 23] Internet-Draft Design of the MOBIKE Protocol July 2005 5.8 Scope of SA changes Most sections of this document discuss design considerations for updating and maintaining addresses in the database entries that relate to an IKE-SA. However, changing the preferred address also affects the entries of the IPsec SA database. The outer tunnel header addresses (source and destination IP addresses) need to be modified according to the primary path to allow the IPsec protected data traffic to travel along the same path as the MOBIKE packets (if we only consider the IP header information). If the MOBIKE messages and the IPsec protected data traffic travel along a different path then NAT handling is severely complicated. The basic question is then how the IPsec SAs are changed to use the new address pair (the same address pair as the MOBIKE signaling traffic -- the primary path). One option is that when the IKE SA address is changed then automatically all IPsec SAs associated with it are moved along with it to new address pair. Another option is to have a separate exchange to move the IPsec SAs separately. If IPsec SAs should be updated separately then a more efficient format than the notification payload is needed to preserve bandwidth. A notification payload can only store one SPI per payload. A separate payload which would have list of IPsec SA SPIs and new preferred address. If there is a large number of IPsec SAs, those payloads can be quite large unless ranges of SPI values are supported. If we automatically move all IPsec SAs when the IKE SA moves, then we only need to keep track which IKE SA was used to create the IPsec SA, and fetch the IP addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires implementations to keep track which IPsec SAs are created using which IKE SA. If we do allow each IPsec SA address set to be updated separately, then we can support scenarios, where the machine has fast and/or cheap connections and slow and/or expensive connections, and it wants to allow moving some of the SAs to the slower and/or more expensive connection, and prevent the move, for example, of the news video stream from the WLAN to the GPRS link. On the other hand, even if we tie the IKE SA update to the IPsec SA update, then we can create separate IKE SAs for this scenario, e.g., we create one IKE SA which have both links as endpoints, and it is used for important traffic, and then we create another IKE SA which have only the fast and/or cheap connection, which is then used for that kind of bulk traffic. Kivinen & Tschofenig Expires January 19, 2006 [Page 24] Internet-Draft Design of the MOBIKE Protocol July 2005 5.9 Zero Address Set One of the features which is potentially useful is for the peer to announce that it will now disconnect for some time, i.e. it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case the it could send address notification with zero new addresses, which means that it will not have any valid addresses anymore. The responder of that kind of notification would then acknowledge that, and could then temporarily disable all SAs and therefore stop sending traffic. If any of the SAs gets any packets they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, e.g. allow TCP/IP sessions to notice the link is broken. The local policy could then indicate how long the peer should allow remote peers to remain disconnected. From a technical point of view this feature addresses two aspects: o There is no need to transmit IPsec data traffic. IPsec protected data needs to be dropped which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided. o MOBIKE signaling messages are also ignored. The IKE-SA must not be deleted and the suspend functionality (realized with the zero address set) may require the IKE-SA to be tagged with a lifetime value since the IKE-SA should not be kept in alive for an undefined period of time. Note that IKEv2 does not require that the IKE-SA has a lifetime associated with it. In order to prevent the IKE-SA from being deleted the dead-peer detection mechanism needs to be suspended as well. Due to the fact that this extension would be complicated, a first version of the MOBIKE protocol will not provide this feature. 5.10 IPsec Tunnel or Transport Mode Current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behaviour would also be useful, but will be discussed in future documents. Kivinen & Tschofenig Expires January 19, 2006 [Page 25] Internet-Draft Design of the MOBIKE Protocol July 2005 5.11 Message Representation The IP address change notifications can be sent either via an informational exchange already specified in the IKEv2, or via a MOBIKE specific message exchange. Using informational exchange has the main advantage that it is already specified in the IKEv2 and implementations incorporate the functionality already. Another question is the format of the address update notifications. The address update notifications can include multiple addresses, of which some may be IPv4 and some IPv6 addresses. The number of addresses is most likely going to be limited in typical environments (with less than 10 addresses). The format may need to indicate a preference value for each address. The format could either contain a preference number that determines the relative order of the addresses, or it could simply be ordered, according to preference, list of IP addresses. While two addresses can have the same preference value an ordered list avoids this situation. Even if load balancing is currently outside the scope of MOBIKE, future work might include. The selected format needs to be flexible enough to include additional information (e.g. to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As there may arise other information which may have to be tied to an address in the future, a reserved field seems like a prudent design in any case. There are two formats that place IP address lists into a message. One includes each IP address as separate payload (where the payload order indicates the preference value, or the payload itself might include the preference value), or we can put the IP address list as one payload to the exchange, and that one payload will then have internal format which includes the list of IP addresses. Having multiple payloads with each one having carrying one IP address makes the protocol probably easier to parse, as we can already use the normal IKEv2 payload parsing procedures.. It also offers an easy way for the extensions, as the payload probably contains only the type of the IP address (or the type is encoded to the payload type), and the IP address itself, and as each payload already has length associated to it, we can detect if there is any extra data after the IP address. Some implementations might have problems parsing IKEv2 payloads that are longer than a certain threshold, but if the sender sends them in the most preferred first, the receiver can only use the first addresses. Having all IP addresses in one big MOBIKE specified internal format provides more compact encoding, and keeps the MOBIKE implementation Kivinen & Tschofenig Expires January 19, 2006 [Page 26] Internet-Draft Design of the MOBIKE Protocol July 2005 more concentrated to one module. It also avoids problems of packets arriving in an order different from what they were sent. Another choice is which type of payloads to use. IKEv2 already specifies a notify payload. It includes some extra fields (SPI size, SPI, protocol etc), which gives 4 bytes of the extra overhead, and there is the notify data field, which could include the MOBIKE specific data. Another option would be to have a custom payload type, which then includes the information needed for the MOBIKE protocol. MOBIKE might send the full peer address list once one of the IP addresses changes (either addresses are added, removed, the order changes or the preferred address is updated) or an incremental update. Sending incremental updates provides more compact packets (meaning we can support more IP addresses), but on the other hand have more problems in the synchronization and packet reordering cases, i.e., the incremental updates must be processed in order, but for full updates we can simply use the most recent one, and ignore old ones, even if they arrive after the most recent one (IKEv2 packets have message id which is incremented for each packet, thus we know the sending order easily). Note that each peer needs to communicate its peer address set to the other peer. Kivinen & Tschofenig Expires January 19, 2006 [Page 27] Internet-Draft Design of the MOBIKE Protocol July 2005 6. Security Considerations As all the messages are already authenticated by the IKEv2 there is no problem that any attackers would modify the contents of the packets. The IP addresses in the IP header of the packets are not authenticated, thus the protocol defined must take care that they are only used as an indication that something might be different, and that do not cause any direct actions. An attacker can also spoof ICMP error messages in an effort to confuse the peers about which addresses are not working. At worst this causes denial of service and/or the use of non-preferred addresses. One type of attack that needs to be taken care of in the MOBIKE protocol is the "flooding attack" type. See [I-D.ietf-mip6-ro-sec] and [Aur02] for more information about flooding attacks. Kivinen & Tschofenig Expires January 19, 2006 [Page 28] Internet-Draft Design of the MOBIKE Protocol July 2005 7. IANA Considerations This document does not introduce any IANA considerations. Kivinen & Tschofenig Expires January 19, 2006 [Page 29] Internet-Draft Design of the MOBIKE Protocol July 2005 8. Acknowledgments This document is the result of discussions in the MOBIKE working group. The authors would like to thank Jari Arkko, Pasi Eronen, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman for their input. We would like to particularly thank Pasi Eronen for tracking open issues on the MOBIKE mailing list. He helped us to make good progress on the document. Kivinen & Tschofenig Expires January 19, 2006 [Page 30] Internet-Draft Design of the MOBIKE Protocol July 2005 9. Open Issues This document is not yet complete, the following open issues need to be addressed in a future version: o Section 4 needs an example to better illustrate the functionality of MOBIKE o Section 6 requires a more detailed discussion about the potential security vulnerabilities and corresponding countermeasures. o Some text is needed to address the implications of unidirectional connectivity aspect for MOBIKE (see also issue #19). o A discussion about the scalability aspects of connectivity tests would be benefical. o More details are necessary to describe the implications of NAT traversal for MOBIKE. A complete list of issues is available at http://www.vpnc.org/ietf-mobike/issues.html. Kivinen & Tschofenig Expires January 19, 2006 [Page 31] Internet-Draft Design of the MOBIKE Protocol July 2005 10. References 10.1 Normative references [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [I-D.ietf-ipsec-rfc2401bis] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), April 2005. 10.2 Informative References [I-D.arkko-multi6dt-failure-detection] Arkko, J., "Failure Detection and Locator Selection in Multi6", draft-arkko-multi6dt-failure-detection-00 (work in progress), October 2004. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [I-D.dupont-mipv6-3bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), June 2005. [I-D.ietf-mip6-ro-sec] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-ietf-hip-mm-01 (work in progress), February 2005. [I-D.crocker-celp] Crocker, D., "Framework for Common Endpoint Locator Pools", draft-crocker-celp-00 (work in progress), February 2004. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, Kivinen & Tschofenig Expires January 19, 2006 [Page 32] Internet-Draft Design of the MOBIKE Protocol July 2005 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [I-D.ietf-tsvwg-addip-sctp] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-12 (work in progress), June 2005. [I-D.dupont-ikev2-addrmgmt] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-07 (work in progress), May 2005. [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003. [I-D.ietf-ipv6-optimistic-dad] Moore, N., "Optimistic Duplicate Address Detection for IPv6", draft-ietf-ipv6-optimistic-dad-05 (work in progress), February 2005. [I-D.ietf-ipv6-unique-local-addr] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Kivinen & Tschofenig Expires January 19, 2006 [Page 33] Internet-Draft Design of the MOBIKE Protocol July 2005 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV USA, December 2002. Authors' Addresses Tero Kivinen Safenet, Inc. Fredrikinkatu 47 HELSINKI FIN-00100 FI Email: kivinen@safenet-inc.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Kivinen & Tschofenig Expires January 19, 2006 [Page 34] Internet-Draft Design of the MOBIKE Protocol July 2005 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. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kivinen & Tschofenig Expires January 19, 2006 [Page 35]