HIP Working Group J. Melen Internet-Draft Ericsson Research Nomadiclab Intended status: Experimental M. Komu Expires: April 30, 2009 HIIT M. Bagnulo Universidad Carlos III de Madrid T. Henderson The Boeing Company October 27, 2008 HIP Mobility and Multihoming Extensions for the Traversal of Network Address Translators draft-melen-hip-nat-mm-00 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 April 30, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines extensions for HIP mobility and multihoming mechanisms to operate in network environments with NAT devices. The Melen, et al. Expires April 30, 2009 [Page 1] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 extensions are based on the ICE protocol that allows two communicating end-hosts to establish a direct communications path with each other even when residing in separate private address realms. The focus of the extensions in this document is on fault- tolerance with symmetric locator pairs, and load-balancing is also discussed. This document also updates RFC5206. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mobility and Multihoming Scenarios . . . . . . . . . . . . . . 4 3.1. End Host detects mobility event . . . . . . . . . . . . . 4 3.2. End Host Detects a Failure in the End-to-end Path . . . . 5 3.3. Routing System Detects a Failure in the End-to-end Path . 6 4. Locator management . . . . . . . . . . . . . . . . . . . . . . 7 5. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Handover Procedures . . . . . . . . . . . . . . . . . . . 8 5.2. E2E Failure Detection Mechanism . . . . . . . . . . . . . 11 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Document Revision History . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Melen, et al. Expires April 30, 2009 [Page 2] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 1. Terminology In the absence of better terms, this document uses the terms Mobile Node (MN) and Corresponding Node (CN) borrowed from Mobile IP terminology even though HIP allows both ends to be mobile even simultaneously. 2. Introduction The protocol extensions defined in this document extend HIP mobility and multihoming to operate in NATted environments. The extensions use combine ICE with HIP to create end-to-end connectivity and global naming for end-hosts located in different private address realms. This document focuses on fault-tolerance with symmetric locator pairs, but also load-balancing is discussed. This document updates [RFC5206]. The extensions in this document assume that the two communicating end-hosts have run successfully the base exchange procedure through a HIP Relay as descibed in [I-D.ietf-hip-nat-traversal]. In other words this document excludes the mechanisms to solve the initial contact problem. This document specifies extensions that allow HIP end-hosts to support end-host mobility and multihoming in NATted environments. The handover procedure is similar to the base exchange with NAT extensions. First, both end-hosts exchange offer and answer, i.e, their locators, using UPDATE messages. Second, the hosts start ICE connectivity checks [I-D.ietf-mmusic-ice] to discover a working address pair. Third, the hosts can use the discovered address pair for data traffic. End-host mobility usually involves a disconnectivity period while a host is moving from a network to another. The delay caused by the disconnectivity period can have negative effects on transport layer traffic. Further, ICE connectivity checks also amplify the delay but are necessary to restore the connectivity. This document proposes some optimizations to reduce the length of the disconnectivity periods. In the case of multihoming, a host first gathers its host candidates from its local network interfaces. Then, it collects server reflexive addresses by varying the source interface in UPDATE exchanges with RELAY server(s) and STUN server(s). 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 [RFC2119]. Melen, et al. Expires April 30, 2009 [Page 3] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 3. Mobility and Multihoming Scenarios This section discusses end-host and site multihoming use cases. We assume that there are two communicating end-hosts that are located behind separate NAT devices. 3.1. End Host detects mobility event 3.1.1. Make-before-break In the make-before-break scenario the mobile node has at least two interfaces that can be simultaneously connected to different networks and can have distinct addresses configured. In the make-before-break scenario the existing security association is updated after the new pair of IP addresses has been detected to be working. As an example, let's consider a 4G phone with multiaccess capabilities. First, the phone is already transmitting data over one active interface. Then, the phone starts to use the other interface, but only after the handover procedure has been completed over the other link. The phone can trigger the handover procedure simultaneously while sending data over the active interface. Figure 1 depicts the make-before-break scenario. +-------+ +-------+ | ISP1 | | ISP2 | +-------+ +-------+ | | | After connctivity checks | | SA is updated from If1 to If2 | | -----------------------> | | | | +-------+ | +--------------|MN host|-------------+ +-------+ host attaches the interface as the link is changed to up Figure 1: Basic make before break 3.1.2. Break-before-make In the break-before-make scenario, the connection to the peer is lost for a while when detaching from old access network and while attaching to new one. In this scenario, there is no data transmitted to the peer until the new attachment procedure has finished. A common example is that the host detaches from one access network and attaches to new one with the same interface. The detachment period may vary from a few milliseconds to hours. In this scenario, there is the possibility that the communication may have to be reinitated Melen, et al. Expires April 30, 2009 [Page 4] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 after the detachment period depending on whether the peer has dropped the previous communication context or not. 3.2. End Host Detects a Failure in the End-to-end Path 3.2.1. Simultaneous End-host Multihoming This section describes a scenario where a mobile host has two network interfaces which it uses simultaneously. The scenario is visualized in Figure 2. +-----------+ +-----------+ | ISP1 | | ISP2 | +-----------+ +-----------+ | | | | | | | | | | | +-------+ | +---------|MN host|--------+ +-------+ Figure 2: Simultaneous End-host Multihoming Once the base exchange has been successfully completed as described in [I-D.ietf-hip-nat-traversal], the MN can gather the candidates for the other interface that was not used during the base exchange. For gathering the candidates, the host may use either an UPDATE exchange with the Relay server in Section 5.1.1 or a STUN server. After gathering the candidates, the MN MAY send an UPDATE packet containing an ICE offer, and the old SPI value in the ESP_INFO MUST be set to zero to denote that the MN creates a new multihoming SA pair that is parallel and independent from the SA pair that was previously created. The MN sends the UPDATE packet listing all candidates in the LOCATOR using a relay of the CN. The UPDATE exchange for setting up new SAs is same as in the case of mobility described in Section 5.1.2. Another configuration would be to use multihoming for fault tolerance. In such a case, there is a primary path and a backup path. The backup path could be a "hot backup" or a "cold backup." In the hot backup case, the multihoming host knows the backup address beforehand and keeps the path up using keepalives as described in section Section 5.2. In the cold backup case, the host detects the failure and only then discover the candidates for the alternative path. The hot backup may cost more because the path needs to be kept alive. The cold backup requires just one SA pair which is then Melen, et al. Expires April 30, 2009 [Page 5] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 changed similarly as in the case of mobility. 3.3. Routing System Detects a Failure in the End-to-end Path In site multihoming, the end-host is not usually aware of the different paths the site has with the rest of the network. A typical configuration for site multihoming using multiple ISPs for outgoing traffic and for redundancy is in Figure 3. If one of the links fail, the traffic is handed over to run over a different link of an ISP. +----------+ +----------+ +----------+ | ISP1 | | ISP2 | ... | ISPn | +----------+ +----------+ +----------+ | | | | | | | +---------------------------------+ | | | | | +----------| NAT with multiple outgoing |-------+ | interfaces | | Multihomed site | +---------------------------------+ | | +-------+ | Host | +-------+ Figure 3: Site multihoming In this scenario, the the host can discover only the public address of the NAT. When a failure occurs, the intrasite routing system will simply reroute to an alternative path without the host noticing it. The result is that the peer of the host starts receiving packets originating from the different transport address that belongs to a new NAT device. The peer learns a new route to the host and can start using it after successful HIP return routability or ICE connectivity checks. To detect the disconnectivity, the host has to periodically send keep-alives through the active connection if no other data is being sent on the security association. The keep-alive interval SHOULD be configurable. When the host has not received a response to keep- alives for a configurable period, it should gather new ICE candidates and send a new ICE offer using an UPDATE packet to the peer. The peer responds to this with an UPDATE packet containing the ICE answer after which both of the end-hosts start the ICE connectivity checks. Melen, et al. Expires April 30, 2009 [Page 6] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 4. Locator management A multihomed HIP node has multiple locators that can have different reachability status. Some of them can be operational/reachable while other may be not. Fault tolerance is a preferred capability of such configuration. In order to provide basic fault tolerance support, a HIP node should be able to perform the following functions: First, the multihomed HIP nodes must be able to convey the locally available locator set to the peer. Second, the nodes should be able to monitor the communication and detect failures. In case that a failure is detected, they must be able to discover alternative working locator pairs and divert the communication through the alternative locator pair. It should be noted that for the provision of basic fault tolerance capabilities, the locators are only used sequentially and not in parallel. This is so, because as long a locator pair is working, the peers stick to that pair for exchanging data packets and they only change the locator pair used when there is a failure. This is different from the general multihoming scenario considered in [RFC5206] since locator pairs are not used in parallel. This particular constraint reduces considerably the possibility of packet reordering and hence the possibility of having problems with the reply protection window due to reordering of packets that travel through different paths. In the general multihoming scenario defined in [RFC5206], a multihomed node is recommended to create different SAs and use different SPIs for interface available for the communication between two multihomed nodes to avoid problems with the anti-replay protection window resulting from reordering packets when using multiple paths simultaneously. While this is required for the general multihoming scenario, this is somewhat expensive approach, because it requires a high number of SAs to be created and it also requires some signaling overhead. Basically in a multihoming scenario where a multihomed node A that has m interfaces is communicating with another multihomed node B that has n interfaces, they need to exchange m+n UPDATE messages to convey all the locator information. This is so, because they need to convey SPI information for each of the interface pairs. Node A does so by sending an n UPDATE messages. While all the overhead and complexity is required when using multiple interface pairs in parallel, this is not the case for a fault tolerant configuration, where the locator pairs will be used sequentially. In order to support fault tolerance, the following behaviour is defined for HIP nodes. Each node conveys the available locator set information to the peer in a single UPDATE message. The Old SPI value of the ESP_INFO parameter are equal to the current SPI value. Each node uses a single SA and a single SPI value for all the locator Melen, et al. Expires April 30, 2009 [Page 7] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 pairs available for the configuration. Only a single locator pair is active, and all the traffic is sent using the active locator pair. Upon the reception of one UPDATE message containing multiple locators with a single SPI value for all the locators, the receiver verifies the locators contained in the UPDATE message. After that, the receiver identifies that it is in the fault tolerance scenario and creates locator pairs using all the received locators and all the locally available locators, irrespectively of the locator to which the UPDATE message was sent. The result is that each of the peers has all the locator pairs available for use in case that a failure occurs. For simultaneous multihoming, an end-host should not assign locators that are assigned in different interfaces to a single SPI value. Instead, the host should acquire an SPI value value for each interface separately. Each end-host conveys the available locator set information to the peer in a separate UPDATE message. Upon the reception of UPDATE message containing multiple locators with a Old SPI value zero and the New SPI non-zero for all the locators, the receiver verifies the locators contained in the UPDATE message and acquire an SPI value value for these locators. The result is that each of the peers has multiple locator pairs available for use to transfer the traffic between the hosts. 5. Packet Processing This section describes general packet sending and processing procedures in the different NAT traversal scenarios. 5.1. Handover Procedures This section describes the handover procedures using NAT traversal techniques. In order to notify the peer nodes of changed locator(s), an end-host MUST execute following steps, summarized below at a high level: 1. UPDATE its location to the Relay Server(s) 2. Update bindings to TURN server(s) 3. Gather new unreflexive, reflexive and relayed-transport candidates 4. Exchange Offer and Answer with its peer nodes 5. Execute connectivity and optionally return-routability checks Melen, et al. Expires April 30, 2009 [Page 8] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 6. Set Preferred bit to zero for all locators. 5.1.1. HIP Relay Server Update and Gathering New Candidates The Relay Client communicates its changes in its locators to its Relay Server. Otherwise, other hosts trying to communicate with the Relay Client may fail to contact it. [I-D.ietf-hip-nat-traversal] recommends that the HIP Relay does not include NAT traversal mode parameter in the base exchange. As a consequence, HIP control plane operates over UDP, but HIP Relay Client and Server do not use ICE for connectivity tests. Therefore, the Relay Client MUST use UPDATE to inform its Relay server(s) on its new locators as defined in [RFC5206] except that the Client follows the UDP encapsulation procedures for type 2 locators as described in [I-D.ietf-hip-nat-traversal]. As an alternative to STUN, host MAY use the UPDATE packet to gather the server reflexive addresses from the Relay server. The Mobile Node sends a UPDATE packet containing REG_REQUEST parameter registering to the Relay service. The Relay acknowledges registration with REG_RESPONSE and REG_FROM parameters. The same procedure is used to update the registration lifetime in [RFC5203]. Figure 4 illustrated address gathering procedure combined with location UPDATE. Mobile Relay Node (MN) | | | | 1. UPDATE(ESP_INFO,LOC,SEQ,REG_REQ) | +-------------------------------------------------->+ | | | 2. UPDATE(ESP_INFO,ACK,REG_RES,REG_FROM,ECHO_REQ) | +<--------------------------------------------------+ | | | 3. UPDATE(ACK, ECHO_RES) | +-------------------------------------------------->+ Figure 4: Updating Relay Server Combined with Gathering Addresses Steps 2 and 3 are repeated for each locator contained in the LOCATOR parameter (LOC in the figure). 5.1.2. Handover Procedure with ICE When there a changes in the locators of the MN, it communicates its new LOCATOR set to its CNs. To reduce the latency of the handover, the MN MAY do this in parallel with updating and gathering new Melen, et al. Expires April 30, 2009 [Page 9] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 candidates from its Relay Server as described in Section 5.1.1. The MN learns its peer reflexive transport locator during the handover procedure and therefore gathering the server reflexive transport locator is not necessary. The details of the handover are End-hosts that have negotiated successfully the ICE-STUN-UDP mode during the base exchange, use the HIP UPDATE packet to exchange the ICE offer and answer when a locator change is detected as illustrated in Figure 5. The UPDATE packet contains a LOCATOR parameter containing unreflexive, reflexive and relayed transport locators of the Mobile Node (MN). In steps 1 and 2, the MN sends the UPDATE packet through the relay server that was previously used for the base exchange. The Corresponding Node (CN) responds to the UPDATE with another UPDATE packet in steps 3 and 4. It contains a LOCATOR parameter listing unreflexive, reflexive and relayed transport locators of the CN. The MN completes the procedure by acknowledging the sequence number in steps 5 and 6. Finally, the end-hosts start the ICE connectivity checks direcly with each other in step 7 as described in [I-D.ietf-hip-nat-traversal]. The end-hosts set up a pair of IPsec SA for each successfully tested address pair. In the case of failure, the end-hosts send a NOTIFY through the relay to each other. Mobile Relay Corresponding Node (MN) | Node (CN) | | | | 1. UPDATE(SEQ,LOC) | 2. UPDATE(SEQ,LOC,RELAY_FROM) | +-------------------------------+------------------------------->| | | | | 4. UPDATE(SEQ,ACK,LOC) | 3. UPDATE(SEQ,ACK,LOC,RELAY_TO)| +<------------------------------+--------------------------------| | | | | 5. UPDATE(ACK) | 6. UPDATE(ACK,RELAY_FROM) | +-------------------------------+------------------------------->| | | | | 7. ICE Connectivity Checks | +<-------------------------------------------------------------->| | | | Figure 5: Handover with ICE 5.1.3. Handover Procedure without ICE End-hosts that have negotiated UDP-ENCAPSULATION mode during the base exchange do not use ICE, but instead follow the procedures in [RFC5206]. However, the LOCATOR parameter may include type 2 locators and MUST be sent over transport layer. The return routability tests are established with or without transport layer Melen, et al. Expires April 30, 2009 [Page 10] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 encapsulation according to the type of the locator being tested. It should be noticed that this mode has limited applicability, i.e., the return routability checks succeed when only the mobile node is behind a NAT. 5.1.4. Connectivity checks After the hosts have exchanged the candidate pairs, they will start the connectivity checks for each candidate pair one at a time in a specific priority order. The connectivity checks proceed sequentially with paces between the checks to avoid network flooding. The pacing of connectivity checks and the priority order are defined in [I-D.ietf-hip-nat-traversal]. In order to recover faster from the data plane disconnectivity, the mobile node MAY initiate a return routability test immediately through its TURN media relay. This allows the mobile node to restore data plane connectivity in parallel with ICE connectivity checks which may take a while to complete. Further, to facilitate faster recovery, successfully tested address pairs MAY be taken into use immediately instead of waiting for checks for all addresses to be completed in regular ICE nomination. 5.2. E2E Failure Detection Mechanism As described in the [I-D.ietf-hip-nat-traversal], the keepalives between HIP end-host and TURN server are STUN Binding Indications. Similarly, the keepalives are STUN Binding Indications for two HIP hosts that have negotiated ICE-STUN-UDP as the nat traversal mode. Keepalives for two HIP hosts operating in UDP-ENCAPSULATION mode use HIP NOTIFY messages as keepalives. Keepalive are send in periods of 20 seconds, but MUST be omitted if some other traffic (e.g. ESP) occupies the corresponding transport-layer connection. The absence of keepalives and ESP packets are used to detect end-to-end or end- to-middle failures according to timeouts based on local policies. 6. Packet Formats TBD. 7. Security Considerations None yet. Melen, et al. Expires April 30, 2009 [Page 11] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 8. Acknowlegements Thanks for Ari Keraenen for comments. 9. Normative References [I-D.ietf-hip-nat-traversal] Komu, M., Henderson, T., Matthews, P., Tschofenig, H., and A. Keraenen, "Basic HIP Extensions for Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-04 (work in progress), July 2008. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. Appendix A. Document Revision History To be removed upon publication +----------+-------------------------------------------------------+ | Revision | Comments | +----------+-------------------------------------------------------+ | draft-00 | Initial version. | +----------+-------------------------------------------------------+ Melen, et al. Expires April 30, 2009 [Page 12] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 Authors' Addresses Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 Email: jan.melen@ericsson.com Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo Finland Phone: +358503841531 Fax: +35896949768 Email: miika@iki.fi URI: http://www.hiit.fi/ Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: +34 91 6249500 Email: marcelo@it.uc3m.es Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA Email: thomas.r.henderson@boeing.com Melen, et al. Expires April 30, 2009 [Page 13] Internet-Draft HIP Mobility Extensions for NAT Traversal October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Melen, et al. Expires April 30, 2009 [Page 14]