--- 1/draft-ietf-hip-multihoming-05.txt 2015-07-22 18:15:02.616236866 -0700 +++ 2/draft-ietf-hip-multihoming-06.txt 2015-07-22 18:15:02.660237943 -0700 @@ -1,20 +1,20 @@ Network Working Group T. Henderson, Ed. Internet-Draft University of Washington Intended status: Standards Track C. Vogt -Expires: July 16, 2015 J. Arkko +Expires: January 23, 2016 J. Arkko Ericsson Research NomadicLab - January 12, 2015 + July 22, 2015 Host Multihoming with the Host Identity Protocol - draft-ietf-hip-multihoming-05 + draft-ietf-hip-multihoming-06 Abstract This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on July 16, 2015. + This Internet-Draft will expire on January 23, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,83 +55,81 @@ Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 - 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 + 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Host Multihoming . . . . . . . . . . . . . . . . . . . . 5 - 4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . 6 4.3. Dual host multihoming . . . . . . . . . . . . . . . . . . 7 4.4. Combined Mobility and Multihoming . . . . . . . . . . . . 8 4.5. Initiating the Protocol in R1 or I2 . . . . . . . . . . . 8 - 4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 10 - 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 - 5.1. Address Verification . . . . . . . . . . . . . . . . . . 10 + 4.6. Using LOCATOR_SETs across Addressing Realms . . . . . . . 9 + 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Address Verification . . . . . . . . . . . . . . . . . . 9 5.2. Preferred Locator . . . . . . . . . . . . . . . . . . . . 10 5.3. Interaction with Security Associations . . . . . . . . . 10 - 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13 + 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 12 6.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 14 6.3. Verifying Address Reachability . . . . . . . . . . . . . 16 - 6.4. Changing the Preferred Locator . . . . . . . . . . . . . 17 + 6.4. Changing the Preferred Locator . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. Normative references . . . . . . . . . . . . . . . . . . 18 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 9. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative references . . . . . . . . . . . . . . . . . . 17 10.2. Informative references . . . . . . . . . . . . . . . . . 18 - Appendix A. Document Revision History . . . . . . . . . . . . . 20 + Appendix A. Document Revision History . . . . . . . . . . . . . 19 1. Introduction and Scope The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/ private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP - addresses are the ones used during the HIP base exchange - [I-D.ietf-hip-rfc5201-bis]. + addresses are the ones used during the HIP base exchange [RFC7401]. One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. Basic host mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case in which a host has a single address and changes its network point- of-attachment while desiring to preserve the HIP-enabled security association. Host multihoming is somewhat of a dual case to host mobility, in that a host may simultaneously have more than one network point-of-attachment. There are potentially many variations of host multihoming possible. The scope of this document encompasses messaging and elements of procedure for some basic host multihoming scenarios of interest. Another variation of multihoming that has been heavily studied is site multihoming. Solutions for site multihoming in IPv6 networks have been specified by the IETF shim6 working group. The shim6 protocol [RFC5533] bears many architectural similarities to HIP but there are differences in the security model and in the protocol. While HIP can potentially be used with transports other than the ESP - transport format [I-D.ietf-hip-rfc5202-bis], this document largely - assumes the use of ESP and leaves other transport formats for further - study. + transport format [RFC7402], this document largely assumes the use of + ESP and leaves other transport formats for further study. There are a number of situations where the simple end-to-end readdressing functionality defined herein is not sufficient. These include the initial reachability of a multihomed host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the network, such as a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis]. Such functionality is out of the scope of this document. Finally, making underlying IP multihoming transparent to the transport layer has implications on the proper @@ -170,28 +168,27 @@ such as which locators to choose when more than one pair is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming on transport protocols and ESP anti-replay windows. 4. Protocol Overview In this section, we briefly introduce a number of usage scenarios for HIP multihoming. These scenarios assume that HIP is being used with - the ESP transform [I-D.ietf-hip-rfc5202-bis], although other - scenarios may be defined in the future. To understand these usage - scenarios, the reader should be at least minimally familiar with the - HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for - the (relatively) uninitiated reader, it is most important to keep in - mind that in HIP the actual payload traffic is protected with ESP, - and that the ESP SPI acts as an index to the right host-to-host - context. + the ESP transform [RFC7402], although other scenarios may be defined + in the future. To understand these usage scenarios, the reader + should be at least minimally familiar with the HIP protocol + specification [RFC7401]. However, for the (relatively) uninitiated + reader, it is most important to keep in mind that in HIP the actual + payload traffic is protected with ESP, and that the ESP SPI acts as + an index to the right host-to-host context. The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange. The readdressing protocol is an asymmetric protocol where a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets @@ -397,24 +394,23 @@ <----------------------------------- (process normally) Figure 4: LOCATOR_SET Inclusion in I2 The I1 and I2 may be arriving from different source addresses if the LOCATOR_SET parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for - instance, the example in Appendix A of [I-D.ietf-hip-rfc5201-bis]. - As a solution, the Responder's puzzle indexing mechanism must be - flexible enough to accommodate the situation when R1 includes a - LOCATOR_SET parameter. + instance, the example in Appendix A of [RFC7401]. As a solution, the + Responder's puzzle indexing mechanism must be flexible enough to + accommodate the situation when R1 includes a LOCATOR_SET parameter. 4.6. Using LOCATOR_SETs across Addressing Realms It is possible for HIP associations to migrate to a state in which both parties are only using locators in different addressing realms. For example, the two hosts may initiate the HIP association when both are using IPv6 locators, then one host may loose its IPv6 connectivity and obtain an IPv4 address. In such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text. @@ -452,22 +448,22 @@ 5.3. Interaction with Security Associations This document uses the HIP LOCATOR_SET protocol parameter, specified in [I-D.ietf-hip-rfc5206-bis]), that allows the hosts to exchange information about their locator(s) and any changes in their locator(s). The logical structure created with LOCATOR_SET parameters has three levels: hosts, Security Associations (SAs) indexed by Security Parameter Indices (SPIs), and addresses. The relation between these levels for an association constructed as - defined in the base specification [I-D.ietf-hip-rfc5201-bis] and ESP - transform [I-D.ietf-hip-rfc5202-bis] is illustrated in Figure 5. + defined in the base specification [RFC7401] and ESP transform + [RFC7402] is illustrated in Figure 5. -<- SPI1a -- -- SPI2a ->- host1 < > addr1a <---> addr2a < > host2 ->- SPI2a -- -- SPI1a -<- Figure 5: Relation between Hosts, SPIs, and Addresses (Base Specification) In Figure 5, host1 and host2 negotiate two unidirectional SAs, and each host selects the SPI value for its inbound SA. The addresses @@ -802,56 +799,61 @@ of the security section, and Petri Jokela was a co-author of the initial individual submission. The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. 10. References 10.1. Normative references - [I-D.ietf-hip-rfc5201-bis] - Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, - "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- - hip-rfc5201-bis-20 (work in progress), October 2014. - - [I-D.ietf-hip-rfc5202-bis] - Jokela, P., Moskowitz, R., and J. Melen, "Using the - Encapsulating Security Payload (ESP) Transport Format with - the Host Identity Protocol (HIP)", draft-ietf-hip- - rfc5202-bis-07 (work in progress), September 2014. - [I-D.ietf-hip-rfc5206-bis] Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with - the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-07 - (work in progress), December 2014. + the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09 + (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ + RFC2119, March 1997, + . [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. + Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/ + RFC3484, February 2003, + . + + [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. + Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC + 7401, DOI 10.17487/RFC7401, April 2015, + . + + [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the + Encapsulating Security Payload (ESP) Transport Format with + the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/ + RFC7402, April 2015, + . 10.2. Informative references [I-D.ietf-hip-rfc4423-bis] Moskowitz, R. and M. Komu, "Host Identity Protocol - Architecture", draft-ietf-hip-rfc4423-bis-09 (work in - progress), October 2014. + Architecture", draft-ietf-hip-rfc4423-bis-12 (work in + progress), June 2015. [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) - Rendezvous Extension", draft-ietf-hip-rfc5204-bis-05 (work - in progress), December 2014. + Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work + in progress), June 2015. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming - Shim Protocol for IPv6", RFC 5533, June 2009. + Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, + June 2009, . Appendix A. Document Revision History To be removed upon publication +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ | draft-00 | Initial version with multihoming text imported from | | | RFC5206. |