Network Working Group P. Eronen Internet-Draft Nokia Expires: September 27, 2004 H. Tschofenig Siemens March 29, 2004 Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE) draft-eronen-mobike-simple-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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 September 27, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes how existing NAT Traversal functionality could be leveraged to better support mobility and multihoming for IKEv2. The purpose is not to specify a finished solution, but rather to provide input for discussions in the MOBIKE WG. In particular, this draft raises questions to what extent the complexity present in the two other MOBIKE protocol proposals is actually necessary. These questions are not answered in this document, but are to be discussed in the MOBIKE WG. Eronen & Tschofenig Expires September 27, 2004 [Page 1] Internet-Draft SMOBIKE March 2004 1. Introduction IKEv2 NAT Traversal, defined in [4] and [5], allows IPsec to work through NATs. The main functional components of NAT Traversal are the following: o Presence of NAT is detected during the IKEv2 IKE_SA_INIT exchange using NAT_DETECTION_SOURCE_IP and NET_DETECTION_DESTINATION_IP Notify payloads. o ESP packets are encapsulated in UDP. o The peer behind the NAT sends NAT-keepalive packets to keep NAT mappings alive if no normal traffic has been sent for some time. o The peer that is not behind the NAT dynamically updates the other peer's address to recover from changes in NAT mappings. That is, IKEv2 and ESP packets are sent to the IP address and port from which the last valid authenticated packet from the other end was received. The last functionality also allows a form of mobility: in typical corporate VPN gateway scenario, the client can move (that is, change its IP address) while keeping the VPN connection up as long as it was behind a NAT when the IKEv2 SA was originally established. This is because from the gateways point of view, a change in the client's IP address is indistinguishable from a change in NAT mappings. Figure 1 shows the standard VPN scenario where the mobility enhancements of IPsec could be deployed. In this scenario the IKEv2 initiator establishes an IPsec tunnel to the VPN GW. After the tunnel establishment the the IKEv2 initiator changes its IP address. Several reasons could be responsible for this address change, such as interface switching, DHCP lease time expiry, IPv6 privacy extensions, or mobility. In Figure 1 we focus on the mobility case. As a result the SAD entries have to be updated on both nodes (typically via extensions to the PF_KEY interface). No update for the IKE-SA is required since it is not bound to an IP address. A NAT might be along the path between the two IKEv2 peers. Eronen & Tschofenig Expires September 27, 2004 [Page 2] Internet-Draft SMOBIKE March 2004 Initial IKEv2 Exchange +-----------+ +--------+ (1) | IKEv2 | | App. | +-/////////----->+ Responder +<--------->+ Server | / | (VPN GW) | | | / +-----+-----+ +--------+ / ^ | | IKEv2 signaling / | | IPsec data traffic v v (2) +------+-----+ +------+-----+ | IKEv2 |Movement | IKEv2 | | Initiator |........>| Initiator | | VPN client | | VPN client | +------------+ +------------+ Figure 1: Mobility in VPN scenario It might be worth noting that mobility and static multi-homing are different with respect to their requirements. This draft is also applicable to static multi-homing to a large extent. This document specifies how this existing functionality can be leveraged to better support mobility and multihoming. This is done by allowing the use of dynamic address updates and/or UDP encapsulation even when no NATs are detected. The main purpose of this draft is not to specify a finished solution, but rather to provide input for discussions in the MOBIKE WG. In particular, this draft tries to present a simpler alternative to the two other proposals, [1] and [6], and raises questions to what extent the complexity in the other two proposals is actually necessary. Furthermore, the authors believe that ability to work together with NATs is a required functionality. 2. SMOBIKE Protocol 2.1 Indicating support for SMOBIKE Implementations that support SMOBIKE indicate this by including a Vendor ID payload in the IKE_SA_INIT exchange (first two messages). The value for this payload is 30DB45C6 AF1CA28C DAC08C30 9CE062C5 (MD5 hash of the string "draft-eronen-mobike-simple"). 2.2 Enabling dynamic address updates In NAT Traversal, the peer that is not behind the NAT dynamically Eronen & Tschofenig Expires September 27, 2004 [Page 3] Internet-Draft SMOBIKE March 2004 updates the other peer's address to recover from changes in NAT mappings. That is, IKEv2 and ESP packets are sent to the IP address and port from which the last valid authenticated packet from the other end was received. By sending the USE_DYNAMIC_ADDRESS_UPDATES Notify payload, a peer can instruct the other peer to dynamically update its address even when no NAT is present. Note that this enables just dynamic address updates, but does not automatically mean UDP encapsulation. 2.3 Changing addresses The procedure when changing address depends on how UDP encapsulation is used. Note that the same procedure applies to both a mobile host moving to another address, and a multihomed host switching to another interface. If the host does not support UDP encapsulation (perhaps it is disabled by configuration), just start using the new address. If the host is currently using UDP encapsulation, and wants to keep on using it, just starting using the new address. If the host is unsure whether the current setting of UDP encapsulation is the right one for the new address, perform a new NAT detection. If the current setting of UDP encapsulation is the right one, it is sufficient to just start using the new address; the other party will update the address when it receives an authenticated packet. If there are no ESP packets to send, the host can send an empty IKEv2 Informational exchange. In some cases, it may be necessary to either turn on UDP encapsulation (when moving to behind a NAT), or turn it off (when moving back to clear). A host can request a new NAT detection by sending an Informational exchange with NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads. These payloads are processed the same way as in initial IKE_SA_INIT exchange. 2.4 UDP encapsulation without NATs There are cases when UDP encapsulation is needed even when no NATs are present. A typical example would be a stateful firewall that performs similar filtering as a "symmetric" NAT [8], but does not change the IP addresses (and therefore is not detected by Eronen & Tschofenig Expires September 27, 2004 [Page 4] Internet-Draft SMOBIKE March 2004 NAT_DETECTION payloads). A host can be configured to always use UDP encapsulation, or it can guess that UDP encapsulation might be needed if it does not receive any ESP packets. In some mobile or ad hoc networks UDP encapsulation could be always used since a route change in the network might cause packets to traverse a NAT even without end-host mobility. The host can then force the use of UDP encapsulation by including a USE_UDP_ENCAPSULATION Notify payload in the same message as NAT_DETECTION payloads. 3. Analysis This section presents a short analysis of how SMOBIKE handles different mobility and multihoming cases. 1. One or both of the parties are mobile and/or multi-homed. No NATs (or stateful firewalls) are present. SMOBIKE works fine, except in some variations of simultaneous address change (see below). This case is typical in multihoming situations: e.g. a multihomed host talking to a single-homed host, or two multihomed gateways/hosts talking to each other. The only case where SMOBIKE does not work is if (a) both parties change addresses simultaneously and (b) disable their old addresses before the other party has received the update. In this case, neither of the parties knows the current address of the other party, so they cannot communicate. 2. One party is stationary, single-homed, and not behind a NAT. The other party is be mobile and/or multihomed, and sometimes behind a NAT (or stateful firewall). SMOBIKE handles this as well. UDP encapsulation can also be switched off when it is not needed. This case is the typical case of a mobile client talking to a single-homed VPN gateway. 3. Both parties are mobile and/or multihomed, and there is a "full cone" NAT (see [8] for a description of different NAT types) between them. This case could be made to work (except for the special case simultaneous address change described above). Eronen & Tschofenig Expires September 27, 2004 [Page 5] Internet-Draft SMOBIKE March 2004 4. Both parties are mobile and/or multihomed, and there is a "restricted cone", "port restricted cone" or "symmetric" NAT [8], or a stateful firewall, between them. This case does not work. The NAT (or firewall) blocks the address updates sent by the party outside the NAT. Assuming that simultaneous mobility is not very important, this analysis would seem to indicate that more complex solutions are justified only if they not only handle cases #1-#3, but also improve case #4. Not handling case #2 would in our opinion be a serious deficiency. SMOBIKE does not support moving traffic to a new address before the host is able to send packets using the new address as a source address. Other than that, SMOBIKE works for both "break-before-make" (host breaks its old connection before the new connection is fully established) and "make-before-break" (both connections work for a while during mobility) situations. 4. Security Considerations In the current version, this section lists only the most important points about this protocol. Just like normal IKEv2 NAT Traversal, SMOBIKE does not send the IP addresses inside IKEv2 payloads, only in the IP header. These addresses are not integrity protection and not authenticated. Protecting these addresses would render the protocol incompatible with NAT Traversal. This problem is already known from other areas such as Mobile IP NAT traversal. This leads to two possible problems, also known as "transient pseudo-NAT attack" and "third party bombing". In the "transient pseudo-NAT attack" [3], an attacker intercepts authenticated packets and changes their source IP address (and port). As a consequence the recipient will start using the incorrect peer address, and send IPsec protected data traffic to this address. If the adversary provides an address which is a blackhole then traffic sent to this address will be dropped. This represents a denial of service attack. Obviously, an attacker who can modify packets between the parties could also change e.g. the ICV field, causing the packets to be dropped. Also, the situation is self-fixing: when an unmodified packet gets through, the address is updated back to the correct one. In "third party bombing" [2], a valid peer redirects its traffic to some third party with the intent of flooding the victim with large Eronen & Tschofenig Expires September 27, 2004 [Page 6] Internet-Draft SMOBIKE March 2004 amounts of traffic. For this attack to continue, the attacker has to keep sending traffic with spoofed IP address, because otherwise dead peer detection will fix the situation. Even if the MOBIKE extensions had more complex return routability checks, the attacker could claim not to support them, and use normal IKEv2 NAT Traversal for the attack instead. A regular IKEv2 dead peer exchange will also detect third party bombing. Both attacks require that the adversary is along the data path. Note that unlike, for instance, in standard Mobile IP, IPsec protects the transmitted payloads from eavesdropping and modification, and thus the consequences of traffic redirection are different. It might be worth mentioning that a truly secure NAT traversal can be accomplished only if the client can determine which NAT devices are actually authorized to modify the addresses, and communicate with them in secure fashion to determine the current mappings. This requires a protocol for communicating with the NAT, such as NSIS. A detailed discussion of these approaches is far beyond the scope of this document. 5. IANA Considerations Two new Notify payloads, USE_DYNAMIC_ADDRESS_UPDATES and USE_UDP_ENCAPSULATION. 6. Acknowledgments This draft obviously borrows many ideas from Tero Kivinen and Francis Dupont, although it ended up looking a bit different than their work. References [1] Dupont, F., "Address Management for IKE version 2", draft-dupont-ikev2-addrmgmt-04 (work in progress), February 2004. [2] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), February 2004. [3] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", draft-dupont-transient-pseudonat-03 (work in progress), February 2004. [4] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. Stenberg, "UDP Encapsulation of IPsec Packets", Eronen & Tschofenig Expires September 27, 2004 [Page 7] Internet-Draft SMOBIKE March 2004 draft-ietf-ipsec-udp-encaps-08 (work in progress), February 2004. [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. [6] Kivinen, T., "MOBIKE protocol", draft-kivinen-mobike-protocol-00 (work in progress), February 2004. [7] Kivinen, T., "Design of the MOBIKE protocol", draft-kivinen-mobike-design-00 (work in progress), February 2004. [8] 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. Authors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Eronen & Tschofenig Expires September 27, 2004 [Page 8] Internet-Draft SMOBIKE March 2004 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 IETF's procedures with respect to rights in IETF 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 (2004). 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 & Tschofenig Expires September 27, 2004 [Page 9]