Network Working Group P. Eronen Internet-Draft Nokia Expires: August 22, 2005 February 21, 2005 Mobility Protocol Options for IKEv2 (MOPO-IKE) draft-eronen-mobike-mopo-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a mobility and multihoming extension to the IKEv2 protocol. The main purpose of this extension is to update the (outer) addresses associated with IKE and IPsec Security Associations. The extension also includes features that assist in selecting which addresses to use, and verify return routability during and after updates. It is also able to work together with NAT Traversal in some scenarios. Eronen Expires August 22, 2005 [Page 1] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 1. Introduction 1.1 Motivation 1.1.1 Scenario 1: Mobile client The basic MOBIKE scenario is a mobile device such as a laptop that may have several different network interfaces, and wishes to keep a connection to a VPN gateway working while moving. For instance, a user could start from fixed Ethernet in the office, and then disconnect the laptop and move to office wireless LAN. When leaving the office the laptop could start using GPRS, and switch to a different wireless LAN when the user arrives home. MOBIKE provides a way to notify the VPN gateway of the user's current IP address without requiring a new IKE SA (which may require user interaction for authentication). Since the IP address used inside the tunnel (assigned by the VPN gateway using Configuration Payloads) does not change, transport layer connections are not broken. Mobility detection, policy issues such as which interface should be used, and implementation issues -- such as a possible interface (and division of work) between a "mobility and multihoming control module" and "IKE module" inside a host -- are beyond the scope of MOBIKE. 1.1.2 Scenario 2: Mobile client with multihomed gateway The second scenario has again a mobile laptop, but this time the VPN gateway has several network interfaces. MOBIKE provides a mechanism for the gateway to notify the client of its addresses (obviously, the client needs to know at least one address to contact the VPN gateway in the first place) and changes in their availability. MOBIKE also allows the client to determine which of the gateway's addresses can be used when the client changes its own address. This is required since it cannot be assumed that all of the gateway's interfaces are reachable from all networks the client may connect to. The client may also obtain this information in some other way external to MOBIKE, and policy issues about which address should be actually used are beyond the scope of MOBIKE. 1.1.3 Scenario 3: Two multihomed gateways The third scenario has two VPN gateways connecting, for instance, two different sites of a company. Both gateways have several network connections (possible from different ISPs) to provide better Eronen Expires August 22, 2005 [Page 2] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 availability in case of network failures. Here MOBIKE provides a way to inform the other end of alternative addresses, and switch to some other connection if the currently used path fails. The failures may be detected by either using IKE dead peer detection messages, or some external mechanism beyond the scope of MOBIKE. 1.2 Summary of MOPO-IKE Assumptions: o Both the initiator and the responder can have multiple IPv4 and/or IPv6 addresses. It is not assumed that all the paths work; in other words, only some of the initiator's addresses may work with a particular responder address, and vice versa. o It is assumed that the initiator knows at least one of the responder's IP addresses beforehand, and can reach that address from one of its own addresses when the IKE_SA is created. It is not required that this path continues to work during the whole lifetime of the IKE_SA. o Some of the paths between the initiator and the responder may contain NATs or stateful packet filters. The protocol assumes that the initiator can send packets to the responder at any time (or in other words, it is the one "behind" the stateful device), but the reverse is not necessarily true. o Network paths may stop working unexpectedly (causing a need to change to some other path in "break-before-make" fashion), but in some cases, traffic may be moved to a new path while the old path is still working ("make-before-break"). Based on these assumptions, the design goals of MOPO-IKE were to (1) be reasonably simple to implement, especially for nodes whose addresses do not change, (2) be compatible with NAT Traversal, but (3) still be able handle cases where both peers have multiple addresses. The protocol be summarized as follows: o If the responder has other addresses than the one used for initial contact, it can inform the initiator of these when the IKE_SA is created. o The initiator selects which path is used for IPsec SAs, and informs the responder about it. The same path (pair of addresses) Eronen Expires August 22, 2005 [Page 3] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 is used in both initiator-to-responder and responder-to-initiator directions. Making the decision on the initiator side is consistent with how normal IKEv2 works, and using this path also for the responder-to-initiator direction makes sense especially with mobile clients where the client is in a better position to decide which network interface should be used for "downlink" traffic. o When a path used for IPsec SAs is changed, NAT Traversal can be enabled or disabled as needed. o If the responder's set of addresses changes, it can inform the initiator about this. To allow this feature to work even when there is partial connectivity, the initiator can also inform the responder of other than currently used addresses. This feature does not fully work with all types of NATs and stateful packet filters; all other features do. o To support smoother make-before-break, and quicker recovery in case of break-before-make, the initiator can determine whether a path works or not before deciding to move the traffic. o Both the initiator and the responder can optionally verify that the other party can actually receive packets at the claimed address. This "return routability check" can be done immediately after updating the IPsec SAs, or continuously during the connection. o Both the initiator and the responder can have a policy that prevents the use of paths that contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an "attack". 1.3 Security association viewpoint The main purpose of this extension is to modify state associated with IKE_SA and IPsec SAs that is normally initialized when the SA is created, and not changed afterwards. In particular, this extension considers the following state associated with IKE_SA and outbound IPsec SAs (conceptually speaking; an implementation could store this information in some other way as well): Eronen Expires August 22, 2005 [Page 4] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 o IKE_SA * local_address (source address for IKE requests) * local_port (source port for IKE requests, either 500 or 4500) * peer_address (destination address for IKE requests) * peer_port (destination port for IKE requests) o outbound IPsec SAs * local_address (tunnel header source address) * peer_address (tunnel header destination address) * peer_port (destination port if UDP encapsulation is used) * udp_encapsulation flag * send_keepalives flag * automatically_update_peer_address flag Note that both IKE_SA and outbound IPsec SAs are considered to have a single pair of (source,destination) addresses at a time. These are the addresses used for IKE requests (including retransmissions of previous requests) and outbound ESP/AH packets. In addition, the IKE_SA contains additional state specific to this extension. This state is used to to store information about addresses that are not currently active (see Section 2.3 for details). 1.4 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. IPsec Security Association (SA) An ESP or AH Security Association. Path A particular combination of source IP address and destination IP address (and possibly ports?). Eronen Expires August 22, 2005 [Page 5] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 2. Protocol exchanges 2.1 Signaling support for this specification Implementations that support this specification MUST include a MOPO_SUPPORTED notification in the IKE_SA_INIT request and response messages. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, N(MOPO_SUPPORTED), [N(NAT_DETECTION_*_IP)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], N(MOPO_SUPPORTED), [N(NAT_DETECTION_*_IP)] The MOPO_SUPPORTED notification payload is described in Section 3. 2.2 Additional addresses Both the initiator and responder MAY include one or more ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Initiator Responder ----------- ----------- HDR, SK { IDi, [CERT], [IDr], AUTH, SAi2, TSi, TSr, [N(ADDITIONAL_ADDRESS)*], [CP(CFG_REQUEST)] } --> <-- HDR, SK { IDr, [CERT], AUTH, SAr2, TSi, TSr, [N(ADDITIONAL_ADDRESS)*], [CP(CFG_REPLY)] } The recipient stores this information in the "additional_addresses" list, but no other action is taken at this time. Eronen Expires August 22, 2005 [Page 6] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 2.3 Changing path of IPsec SAs This extension is based on the idea that the initiator of the IKE_SA decides what addresses are used in the IPsec SAs. That is, the responder never updates any IPsec SAs without receiving an explicit CHANGE_PATH request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.) The description in this section assumes that the initiator has already decided what the new addresses should be. How this decision is made is beyond the scope of this specification. When this decision has been made, the initiator o Updates the IKE_SA and IPsec SAs with the new addresses, and sets the "pending_update" flag in the IKE_SA. o If NAT Traversal is not enabled, the responder supports NAT Traversal (as indicated by NAT_DETECTION payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal. o When the window size allows, sends an INFORMATIONAL request containing the CHANGE_PATH notification payload (which does not contain any data), and clears the "pending_update" flag. Initiator Responder ----------- ----------- HDR, SK {N(CHANGE_PATH), N(COOKIE2), [N(NAT_DETECTION_*),] [N(NAT_PREVENTION)]} --> o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this CHANGE_PATH request). When processing an INFORMATIONAL request containing the CHANGE_PATH notification, the responder o Compares the Message ID with the latest_update_received counter in the IKE_SA. If latest_update_received is greater than the received Message ID, the reply is sent as usual, but no other action is taken; otherwise, updates the latest_update_received counter. o If the NAT_PREVENTION payload is present, processes it as described in Section 2.7. Eronen Expires August 22, 2005 [Page 7] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 o Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it is not, replies with "HDR, SK {COOKIE2, N(UNACCEPTABLE_PATH)}". o Updates the IP addresses in the IKE_SA and IPsec SAs with the values from the IP header. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. o Replies with an INFORMATION response: Initiator Responder ----------- ----------- <-- HDR, SK { N(COOKIE2), [N(NAT_DETECTION_*)] } When the initiator receives the reply, it o If the response contains the NAT_PREVENTED payload, processes it as described in Section 2.7. o If the response contains an UNACCEPTABLE_PATH notification payload, TBD. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. 2.4 Updating additional addresses As described in Section 2.2, both the initiator and responder can send a list of additional addresses (in addition to the one used for IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH exchange. If this list of addresses changes, a new list can be sent in any INFORMATIONAL exchange request message. When the responder (of the original IKE_SA) receives an INFORMATIONAL request containing ADDITIONAL_ADDRESS payloads, it simply stores the information, but no other action is taken. Initiator Responder ----------- ----------- HDR, SK { N(ADDITIONAL_ADDRESS)+, N(COOKIE2) } --> <-- HDR, SK { N(COOKIE2) } Eronen Expires August 22, 2005 [Page 8] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 When the initiator receives an INFORMATIONAL request containing ADDITIONAL_ADDRESS, it stores the information and also determines whether the currently used path needs to be changed; if it does, the initiator proceeds as described in the previous section. Initiator Responder ----------- ----------- <-- HDR, SK { N(ADDITIONAL_ADDRESS)+, N(COOKIE2) } HDR, SK { N(COOKIE2) } --> If the implementation supports window sizes greater than one, it also has to keep track of the Message ID of the latest update it has received, to avoid the situation where new information is overwritten by older. There is one additional complication: when the responder wants to send a new additional address list, the currently used path may no longer work. In this case, the responder uses the additional address list received from the initiator, the list of its own addresses, and, if necessary, the path testing feature (see Section 2.5) to determine a path that works, updates the addresses in the IKE_SA (but not IPsec SAs), and then sends the INFORMATIONAL request. This is the only time the responder uses the additional address list received from the initiator. Note that both peers can have their own policies about what addresses or paths are acceptable to use. A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. This kind of client does not have to send or process ADDITIONAL_ADDRESS notification payloads. Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_ADDRESS notification payloads. 2.5 Path testing IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, DPD alone does not indicate which of the other paths might work. The path testing feature allows parties to find out what action is required when no responses are received; that is, to find a path (combination of addresses) that still works. It also removes the need configure information about (lack of) routing relationships in the case where not all possible combinations of addresses work. Eronen Expires August 22, 2005 [Page 9] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 MOPO-IKE introduces a new IKEv2 exchange type, PATH_TEST, for testing connectivity. This exchange is not part of any IKE_SA, so it is not cryptographically protected. It also does not result in the responder keeping any state. Initiator Responder ----------- ----------- HDR(0,0), [NAT_DETECTION_*_IP] --> <-- HDR(0,0), [NAT_DETECTION_*_IP] The reason for introducing a new exchange type, instead of using INFORMATIONAL exchanges, is to simplify implementations by allowing MOPO-IKE to work with window size 1. Performing path testing over several different paths is not required if the node has other information that enables it to select which path should be used. In this case, the PATH_TEST exchange can be skipped. Implementations MAY do path testing even if the currently used path is working to e.g. detect when a better but previously unavailable path becomes available, or to speed up recovery in fault situations. Implementations that perform path testing MUST take steps to avoid causing unnecessary congestion. TBD: add some more details here. 2.6 Return routability check Both the initiator and the responder can optionally verify that the other party can actually receive packets at the claimed address. This "return routability check" can be done immediately after updating the IPsec SAs, or continuously during the connection. Any INFORMATIONAL exchange can be used for return routability purposes (with one exception, described below): when a valid response is received, we know the other party can receive packets at the claimed address. To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to all INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST include a COOKIE2 notification payload, and the recipient of an INFORMATIONAL request MUST copy the payload 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. There is one additional issue that must be taken into account. If the destination address in the IKE_SA has been updated after the Eronen Expires August 22, 2005 [Page 10] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 INFORMATIONAL request was sent, then it is possible that the request has been sent to several different addresses. In this case, receiving the INFORMATIONAL response does not tell which address is the working one; thus, a new INFORMATIONAL request needs to be sent. 2.7 NAT prevention IKEv2/IPsec implementations that do not support NAT Traversal can, in fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. Some people feel that this is a problem, since in some sense any modification of the IP addresses could be considered to be an attack. The "NAT prevention" feature allows both the initiator and responder to have a policy that prevents the use of paths that contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an "attack". This specification addresses the issue as follows. 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 message IP header. The NAT_PREVENTION payload is used to guarantee that NATs have not modified the address used in IKE_SA. However, all response messages are still sent to the address and port the corresponding request came from. The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT request. The responder MUST compare the NAT_PREVENTION payload with the values from the IP header. If they do not match, the responder replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any state. If the values do match, the responder initializes (local_address, local_port, peer_address, peer_port) in the to-be-created IKE_SA with values from the IP header. The same applies if neither NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if the responder does not support NAT Traversal. If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but no NAT_PREVENTION payload, the situation is different since the initiator may at this point change from port 500 to 4500. In this case, the responder initializes (local_address, local_port, peer_address, peer_port) from the first IKE_AUTH request. It may also decide to perform a return routability check soon after the IKE_AUTH exchanges have been completed. Eronen Expires August 22, 2005 [Page 11] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 IKEv2 requires that if an IPsec endpoint discovers a NAT between it and its correspondent, it MUST send all subsequent traffic to and from port 4500. 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. NAT_PREVENTION payloads can also be included when changing the path of IPsec SAs (see Section 2.3). TBD: add better description. Eronen Expires August 22, 2005 [Page 12] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 3. Payload formats 3.1 MOPO_SUPPORTED notification payload The MOPO_SUPPORTED notification payload is included in the IKE_SA_INIT messages to indicate that the implementation supports this specification. The Notify Message Type for MOPO_SUPPORTED is TBD-BY-IANA (16396..40959). The Protocol ID field is set to one (1), and SPI Size is set to zero. There is no data associated with this Notify type. 3.2 ADDITIONAL_ADDRESS notification payload Both initiator and responder can include ADDITIONAL_ADDRESS payloads in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; see Section 2.2 and Section 2.4 for more detailed description. The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA (16396..40959). The Protocol ID field is set to one (1), and SPI Size is set to zero. The data associated with this Notify type is either an IPv4 address or an IPv6 address (the type is determined by payload length). 3.3 CHANGE_PATH notification payload This payload is included in INFORMATIONAL exchange requests sent by the initiator of the IKE_SA to update addresses of the IKE_SA and IPsec SAs (see Section 2.3). The Notify Message Type for CHANGE_PATH is TBD-BY-IANA (16396..40959). The Protocol ID field is set to one (1), and SPI Size is set to zero. There is no data associated with this Notify type. 3.4 UNACCEPTABLE_PATH notification payload The responder can include this notification payload in an INFORMATIONAL exchange response to indicate that the address change in the corresponding request message (which contained a CHANGE_PATH notification payload) was not carried out. The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA (40..8191). The Protocol ID field is set to one (1), and SPI Size is set to zero. There is no data associated with this Notify type. Eronen Expires August 22, 2005 [Page 13] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 3.5 COOKIE2 notification payload This payload is included in all INFORMATIONAL exchange messages for return routability check purposes (see Section 2.6). The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen in a way that is unpredictable to the recipient. The Notify Message Type for this message is TBD-BY-IANA (16396..40959). The Protocol ID field is set to one (1), and SPI Size is set to zero. 3.6 NAT_PREVENTION notification payload See Section 2.7 for a description of this payload. The data associated with this notification is the SHA-1 hash [FIPS180-2] of the following data: the IP address and port from which the packet was sent, and the IP address and port to which the packet was sent. The Notify Message Type for this message is TBD-BY-IANA (16396..40959). The Protocol ID field is set to one (1), and SPI Size is set to zero. 3.7 NAT_PREVENTED notification payload See Section 2.7 for a description of this payload. The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191). The Protocol ID field is set to one (1), and SPI Size is set to zero. There is no data associated with this Notify type. Eronen Expires August 22, 2005 [Page 14] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 4. Security considerations The main goal of this specification has been not to reduce any security offered by normal IKEv2. (TO BE WRITTEN: more text is needed here.) The return routability check is not inherently incompatible with NATs; as explained in Section 2.7 IKEv2/IPsec can in fact work across some kind of NATs even without NAT Traversal support. In this specification, "NAT prevention", or integrity protection for the addresses in the IP header, is a separate feature. When NAT Traversal is supported, the peer's address may be updated automatically to allow changes in NAT mappings. The "continued return routability" feature, implemented by the COOKIE2 payload, allows verification of the new address after the change. This limits the duration of any "third party bombing" attack by off-path (relative to the victim) attackers. 5. 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 one new IKEv2 exchange, "PATH_TEST", whose value is to be allocated from the "IKEv2 Exchange Types" namespace. This exchange is described in Section 2.5. This document also defines several new IKEv2 notification payloads whose values are to be allocated from the "IKEv2 Notification Payload Types" namespace. These notification payloads are described in Section 3. 6. Acknowledgements Everyone in MOBIKE WG, especially Jari Arkko, Francis Dupont, Paul Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also borrows many ideas and even some text from [AddrMgmt], [SMOBIKE], [Kivinen], and [Design]. Eronen Expires August 22, 2005 [Page 15] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 7. References 7.1 Normative references [FIPS180-2] National Institute of Standards and Technology, "Specifications for the Secure Hash Standard", Federal Information Processing Standard (FIPS) Publication 180-2, August 2002. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [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. 7.2 Informative references [AddrMgmt] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-06 (work in progress), June 2004. [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-01 (work in progress), June 2004. [Kivinen] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 (work in progress), February 2004. [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", draft-eronen-mobike-simple-00 (work in progress), March 2004. [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. Eronen Expires August 22, 2005 [Page 16] Internet-Draft Mobility Protocol Options for IKEv2 February 2005 Author's Address Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Eronen Expires August 22, 2005 [Page 17] Internet-Draft Mobility Protocol Options for IKEv2 February 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. Eronen Expires August 22, 2005 [Page 18]