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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/