draft-ietf-hip-multihoming-11.txt   draft-ietf-hip-multihoming-12.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: March 12, 2017 Independent Expires: April 13, 2017 Independent
J. Arkko J. Arkko
Ericsson Ericsson
September 8, 2016 October 10, 2016
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-11 draft-ietf-hip-multihoming-12
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 35 skipping to change at page 1, line 35
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 March 12, 2017. This Internet-Draft will expire on April 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Multiple Addresses . . . . . . . . . . . . . . . . . . . 5 4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
4.3. Multiple Security Associations . . . . . . . . . . . . . 6 4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6
4.4. Host Multihoming for Fault Tolerance . . . . . . . . . . 7 4.2.2. Multiple Security Associations . . . . . . . . . . . 6
4.5. Host Multihoming for Load Balancing . . . . . . . . . . . 8 4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7
4.6. Site Multihoming . . . . . . . . . . . . . . . . . . . . 9 4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9
4.7. Dual Host Multihoming . . . . . . . . . . . . . . . . . . 10 4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10
4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10 4.2.6. Dual Host Multihoming . . . . . . . . . . . . . . . . 10
4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11 4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11
4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12 4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11
4.11. Interaction with Security Associations . . . . . . . . . 13 4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Interaction with Security Associations . . . . . . . . . 13
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14
5.3. Verifying Address Reachability . . . . . . . . . . . . . 17 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16
5.3. Verifying Address Reachability . . . . . . . . . . . . . 18
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative references . . . . . . . . . . . . . . . . . . 20 9.1. Normative references . . . . . . . . . . . . . . . . . . 21
9.2. Informative references . . . . . . . . . . . . . . . . . 21 9.2. Informative references . . . . . . . . . . . . . . . . . 22
Appendix A. Document Revision History . . . . . . . . . . . . . 22 Appendix A. Document Revision History . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [RFC7401] (HIP) supports an architecture The Host Identity Protocol [RFC7401] (HIP) supports an architecture
that decouples the transport layer (TCP, UDP, etc.) from the that decouples the transport layer (TCP, UDP, etc.) from the
internetworking layer (IPv4 and IPv6) by using public/private key internetworking layer (IPv4 and IPv6) by using public/private key
pairs, instead of IP addresses, as host identities. When a host uses pairs, instead of IP addresses, as host identities. When a host uses
HIP, the overlying protocol sublayers (e.g., transport layer sockets HIP, the overlying protocol sublayers (e.g., transport layer sockets
and Encapsulating Security Payload (ESP) Security Associations (SAs)) and Encapsulating Security Payload (ESP) Security Associations (SAs))
are instead bound to representations of these host identities, and are instead bound to representations of these host identities, and
skipping to change at page 3, line 38 skipping to change at page 3, line 38
transport format [RFC7402], this document largely assumes the use of transport format [RFC7402], this document largely assumes the use of
ESP and leaves other transport formats for further study. ESP and leaves other transport formats for further study.
Finally, making underlying IP multihoming transparent to the Finally, making underlying IP multihoming transparent to the
transport layer has implications on the proper response of transport transport layer has implications on the proper response of transport
congestion control, path MTU selection, and Quality of Service (QoS). congestion control, path MTU selection, and Quality of Service (QoS).
Transport-layer mobility triggers, and the proper transport response Transport-layer mobility triggers, and the proper transport response
to a HIP multihoming address change, are outside the scope of this to a HIP multihoming address change, are outside the scope of this
document. document.
This specification relies on implementing Section 4 (LOCATOR_SET
Parameter Format) and Section 5 (Processing Rules) of
[I-D.ietf-hip-rfc5206-bis] as a starting point for this
implementation.
2. Terminology and Conventions 2. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms used in this document are defined in The following terms used in this document are defined in
[I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred [I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred
locator, and Credit Based Authorization. locator, and Credit Based Authorization.
skipping to change at page 5, line 45 skipping to change at page 6, line 5
host, newly-learned addresses of the peer must be verified before put host, newly-learned addresses of the peer must be verified before put
into active service, and addresses removed by the peer are put into a into active service, and addresses removed by the peer are put into a
deprecated state. Under limited conditions described in deprecated state. Under limited conditions described in
[I-D.ietf-hip-rfc5206-bis], an UNVERIFIED address may be used. [I-D.ietf-hip-rfc5206-bis], an UNVERIFIED address may be used.
With this background, we next describe additional protocol to With this background, we next describe additional protocol to
facilitate scenarios in which one or both hosts have multiple IP facilitate scenarios in which one or both hosts have multiple IP
addresses available. Increasingly, this is the common case with addresses available. Increasingly, this is the common case with
network-connected hosts on the Internet. network-connected hosts on the Internet.
4.2. Multiple Addresses 4.2. Usage Scenarios
4.2.1. Multiple Addresses
Hosts may have multiple IP addresses within different address Hosts may have multiple IP addresses within different address
families (IPv4 and IPv6) and scopes available to support HIP families (IPv4 and IPv6) and scopes available to support HIP
messaging and HIP-enabled SAs. The multiple addresses may be on a messaging and HIP-enabled SAs. The multiple addresses may be on a
single or multiple network interfaces. It is outside of the scope of single or multiple network interfaces. It is outside of the scope of
this document to specify how a host decides which of possibly this document to specify how a host decides which of possibly
multiple addresses may be used to support a HIP association. Some IP multiple addresses may be used to support a HIP association. Some IP
addresses may be held back from usage due to privacy, security, or addresses may be held back from usage due to privacy, security, or
cost considerations. cost considerations.
skipping to change at page 6, line 29 skipping to change at page 6, line 39
or via the LOCATOR_SET parameter. or via the LOCATOR_SET parameter.
To support mobility, as described in the HIP mobility specification To support mobility, as described in the HIP mobility specification
[I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP [I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP
UPDATE packet. To support multihoming, the LOCATOR_SET may also be UPDATE packet. To support multihoming, the LOCATOR_SET may also be
sent in R1, I2, or R2 packets defined in the HIP protocol sent in R1, I2, or R2 packets defined in the HIP protocol
specification [RFC7401]. The reason to consider to send LOCATOR_SET specification [RFC7401]. The reason to consider to send LOCATOR_SET
parameters in the base exchange packets is to convey all usable parameters in the base exchange packets is to convey all usable
addresses for fault-tolerance or load balancing considerations. addresses for fault-tolerance or load balancing considerations.
4.3. Multiple Security Associations 4.2.2. Multiple Security Associations
When multiple addresses are available between peer hosts, a question When multiple addresses are available between peer hosts, a question
that arises is whether to use one or multiple SAs. The intent of that arises is whether to use one or multiple SAs. The intent of
this specification is to support different use cases but to leave the this specification is to support different use cases but to leave the
policy decision to the hosts. policy decision to the hosts.
When one host has n addresses and the other host has m addresses, it When one host has n addresses and the other host has m addresses, it
is possible to set up as many as (n * m) SAs in each direction. In is possible to set up as many as (n * m) SAs in each direction. In
such a case, every combination of source and destination IP address such a case, every combination of source and destination IP address
would have a unique SA, and the possibility of reordering of would have a unique SA, and the possibility of reordering of
skipping to change at page 7, line 15 skipping to change at page 7, line 23
For fault tolerance, it is more likely that a single SA can be used For fault tolerance, it is more likely that a single SA can be used
and multiple IP addresses associated with that SA, and the and multiple IP addresses associated with that SA, and the
alternative addresses used only upon failure detection of the alternative addresses used only upon failure detection of the
addresses in use. Techniques for path failure detection are outside addresses in use. Techniques for path failure detection are outside
the scope of this specification. An implementation may use ICMP the scope of this specification. An implementation may use ICMP
interactions, reachability checks, or other means to detect the interactions, reachability checks, or other means to detect the
failure of a locator. failure of a locator.
In summary, whether and how a host decides to leverage additional In summary, whether and how a host decides to leverage additional
addresses in a load-balancing or fault-tolerant manner is outside the addresses in a load-balancing or fault-tolerant manner is outside the
scope of the specification. However, in general, this document scope of the specification (although the academic literature on
recommends that for fault tolerance, it is likely sufficient to use a multipath TCP schedulers may provide guidance on how to design such a
single SA pair for all addresses, and for load balancing, to support policy). However, in general, this document recommends that for
a different SA pair for all active paths being balanced across. fault tolerance, it is likely sufficient to use a single SA pair for
all addresses, and for load balancing, to support a different SA pair
for all active paths being balanced across.
4.4. Host Multihoming for Fault Tolerance 4.2.3. Host Multihoming for Fault Tolerance
A (mobile or stationary) host may have more than one interface or A (mobile or stationary) host may have more than one interface or
global address. The host may choose to notify the peer host of the global address. The host may choose to notify the peer host of the
additional interface or address by using the LOCATOR_SET parameter. additional interface or address by using the LOCATOR_SET parameter.
The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet,
or may be conveyed, after the base exchange completes in an UPDATE or may be conveyed, after the base exchange completes in an UPDATE
packet. packet.
When more than one locator is provided to the peer host, the host MAY When more than one locator is provided to the peer host, the host MAY
indicate which locator is preferred (the locator on which the host indicate which locator is preferred (the locator on which the host
skipping to change at page 7, line 49 skipping to change at page 8, line 11
association in a multihoming configuration may have both a preferred association in a multihoming configuration may have both a preferred
peer locator and a preferred local locator. The host should try to peer locator and a preferred local locator. The host should try to
use the peer's preferred locator unless policy or other circumstances use the peer's preferred locator unless policy or other circumstances
prevent such usage. A preferred local locator may be overridden if prevent such usage. A preferred local locator may be overridden if
source address selection rules on the destination address (peer's source address selection rules on the destination address (peer's
preferred locator) suggest the use of a different source address. preferred locator) suggest the use of a different source address.
Although the protocol may allow for configurations in which there is Although the protocol may allow for configurations in which there is
an asymmetric number of SAs between the hosts (e.g., one host has two an asymmetric number of SAs between the hosts (e.g., one host has two
interfaces and two inbound SAs, while the peer has one interface and interfaces and two inbound SAs, while the peer has one interface and
one inbound SA), it is RECOMMENDED that inbound and outbound SAs be one inbound SA), it is suggested that inbound and outbound SAs be
created pairwise between hosts. When an ESP_INFO arrives to rekey a created pairwise between hosts. When an ESP_INFO arrives to rekey a
particular outbound SA, the corresponding inbound SA should be also particular outbound SA, the corresponding inbound SA should be also
rekeyed at that time. rekeyed at that time. Section 4.3 discusses the interaction between
addresses and security associations in more detail.
Consider the case of two hosts, one single-homed and one multihomed. Consider the case of two hosts, one single-homed and one multihomed.
The multihomed host may decide to inform the single-homed host about The multihomed host may decide to inform the single-homed host about
its other address(es). It may choose to do so as follows. its other address(es). It may choose to do so as follows.
If the multihomed host wishes to convey the additional address(es) If the multihomed host wishes to convey the additional address(es)
for fault tolerance, it should include all of its addresses in for fault tolerance, it should include all of its addresses in
Locator records, indicating the Traffic Type, Locator Type, and Locator records, indicating the Traffic Type, Locator Type, and
Preferred Locator for each address. If it wishes to bind any Preferred Locator for each address. If it wishes to bind any
particular address to an existing SPI, it may do so by using a particular address to an existing SPI, it may do so by using a
Locator of Type 1 as specified in the HIP mobility specification Locator of Type 1 as specified in the HIP mobility specification
[I-D.ietf-hip-rfc5206-bis]. It does not need to rekey the existing [I-D.ietf-hip-rfc5206-bis]. It does not need to rekey the existing
SA or request additional SAs at this time. SA or request additional SAs at this time.
Figure 1 illustrates this scenario. Figure 1 illustrates this scenario. Note that the conventions for
message parameter notations in figures (use of parentheses and
brackets) is defined in Section 2.2 of [RFC7401].
Multi-homed Host Peer Host Multi-homed Host Peer Host
UPDATE(LOCATOR_SET, SEQ) UPDATE(LOCATOR_SET, SEQ)
-----------------------------------> ----------------------------------->
UPDATE(ACK) UPDATE(ACK)
<----------------------------------- <-----------------------------------
Figure 1: Basic Multihoming Scenario Figure 1: Basic Multihoming Scenario
In this scenario, the peer host associates the multiple addresses In this scenario, the peer host associates the multiple addresses
with the SA pair between it and the multihomed host. It may also with the SA pair between it and the multihomed host. It may also
undergo address verification procedures to transition the addresses undergo address verification procedures to transition the addresses
to ACTIVE state. For inbound data traffic, it may choose to use the to ACTIVE state. For inbound data traffic, it may choose to use the
addresses along with the SPI as selectors. For outbound data addresses along with the SPI as selectors. For outbound data
traffic, it must choose among the available addresses of the traffic, it must choose among the available addresses of the
multihomed host, considering the state of address verification multihomed host, considering the state of address verification
[I-D.ietf-hip-rfc5206-bis] of each address, and also considering [I-D.ietf-hip-rfc5206-bis] of each address, and also considering
available information about whether an address is in a working state. available information about whether an address is in a working state.
4.5. Host Multihoming for Load Balancing 4.2.4. Host Multihoming for Load Balancing
A multihomed host may decide to set up new SA pairs corresponding to A multihomed host may decide to set up new SA pairs corresponding to
new addresses, for the purpose of load balancing. The decision to new addresses, for the purpose of load balancing. The decision to
load balance and the mechanism for splitting load across multiple SAs load balance and the mechanism for splitting load across multiple SAs
is out of scope of this document. The scenario can be supported by is out of scope of this document. The scenario can be supported by
sending the LOCATOR_SET parameter with one or more ESP_INFO sending the LOCATOR_SET parameter with one or more ESP_INFO
parameters to initiate new ESP SAs. To do this, the multihomed host parameters to initiate new ESP SAs. To do this, the multihomed host
sends a LOCATOR_SET with an ESP_INFO, indicating the request for a sends a LOCATOR_SET with an ESP_INFO, indicating the request for a
new SA by setting the OLD SPI value to zero, and the NEW SPI value to new SA by setting the OLD SPI value to zero, and the NEW SPI value to
the newly created incoming SPI. A Locator Type of "1" is used to the newly created incoming SPI. A Locator Type of "1" is used to
skipping to change at page 9, line 36 skipping to change at page 10, line 5
UPDATEs associate them correctly with the destination address used in UPDATEs associate them correctly with the destination address used in
the packet carrying the UPDATE. When processing inbound LOCATOR_SETs the packet carrying the UPDATE. When processing inbound LOCATOR_SETs
that establish new security associations on an interface with that establish new security associations on an interface with
multiple addresses, a host uses the destination address of the UPDATE multiple addresses, a host uses the destination address of the UPDATE
containing the LOCATOR_SET as the local address to which the containing the LOCATOR_SET as the local address to which the
LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may
send UPDATEs with the same (locator) IP address to different peer send UPDATEs with the same (locator) IP address to different peer
addresses -- this has the effect of creating multiple inbound SAs addresses -- this has the effect of creating multiple inbound SAs
implicitly affiliated with different peer source addresses. implicitly affiliated with different peer source addresses.
4.6. Site Multihoming 4.2.5. Site Multihoming
A host may have an interface that has multiple globally routable IP A host may have an interface that has multiple globally routable IP
addresses. Such a situation may be a result of the site having addresses. Such a situation may be a result of the site having
multiple upper Internet Service Providers, or just because the site multiple upper Internet Service Providers, or just because the site
provides all hosts with both IPv4 and IPv6 addresses. The host provides all hosts with both IPv4 and IPv6 addresses. The host
should stay reachable at all or any subset of the currently available should stay reachable at all or any subset of the currently available
global routable addresses, independent of how they are provided. global routable addresses, independent of how they are provided.
This case is handled the same as if there were different IP This case is handled the same as if there were different IP
addresses, described above in Section 4.4 and Section 4.5. Note that addresses, described above in Section 4.2.3 and Section 4.2.4. Note
a single interface may have addresses corresponding to site that a single interface may have addresses corresponding to site
multihoming while the host itself may also have multiple network multihoming while the host itself may also have multiple network
interfaces. interfaces.
Note that a host may be multihomed and mobile simultaneously, and Note that a host may be multihomed and mobile simultaneously, and
that a multihomed host may want to protect the location of some of that a multihomed host may want to protect the location of some of
its interfaces while revealing the real IP address of some others. its interfaces while revealing the real IP address of some others.
This document does not presently additional site multihoming This document does not presently additional site multihoming
extensions to HIP; such extensions are for further study. extensions to HIP; such extensions are for further study.
4.7. Dual Host Multihoming 4.2.6. Dual Host Multihoming
Consider the case in which both hosts are multihomed and would like Consider the case in which both hosts are multihomed and would like
to notify the peer of an additional address after the base exchange to notify the peer of an additional address after the base exchange
completes. It may be the case that both hosts choose to simply completes. It may be the case that both hosts choose to simply
announce the second address in a LOCATOR_SET parameter using an announce the second address in a LOCATOR_SET parameter using an
UPDATE message exchange. It may also be the case that one or both UPDATE message exchange. It may also be the case that one or both
hosts decide to ask for new SA pairs to be created using the newly hosts decide to ask for new SA pairs to be created using the newly
announced address. In the case that both hosts request this, the announced address. In the case that both hosts request this, the
result will be a full mesh of SAs as depicted in Figure 3. In such a result will be a full mesh of SAs as depicted in Figure 3. In such a
scenario, consider that host1, which used address addr1a in the base scenario, consider that host1, which used address addr1a in the base
skipping to change at page 10, line 46 skipping to change at page 11, line 16
host1 < > addr1a <---> addr2a < > host2 host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<- ->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair) addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair) addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair) addr1b <---> addr2b (fourth SA pair)
Figure 3: Dual Multihoming Case in which Each Host Uses LOCATOR_SET Figure 3: Dual Multihoming Case in which Each Host Uses LOCATOR_SET
to Add a Second Address to Add a Second Address
4.8. Combined Mobility and Multihoming 4.2.7. Combined Mobility and Multihoming
It looks likely that in the future, many mobile hosts will be Mobile hosts may be simultaneously mobile and multihomed, i.e., have
simultaneously mobile and multihomed, i.e., have multiple mobile multiple mobile interfaces. Furthermore, if the interfaces use
interfaces. Furthermore, if the interfaces use different access different access technologies, it is fairly likely that one of the
technologies, it is fairly likely that one of the interfaces may interfaces may appear stable (retain its current IP address) while
appear stable (retain its current IP address) while some other(s) may some other(s) may experience mobility (undergo IP address change).
experience mobility (undergo IP address change).
The use of LOCATOR_SET plus ESP_INFO should be flexible enough to The use of LOCATOR_SET plus ESP_INFO should be flexible enough to
handle most such scenarios, although more complicated scenarios have handle most such scenarios, although more complicated scenarios have
not been studied so far. not been studied so far.
4.9. Initiating the Protocol in R1, I2, or R2 4.2.8. Initiating the Protocol in R1, I2, or R2
A Responder host MAY include a LOCATOR_SET parameter in the R1 packet A Responder host MAY include a LOCATOR_SET parameter in the R1 packet
that it sends to the Initiator. This parameter MUST be protected by that it sends to the Initiator. This parameter MUST be protected by
the R1 signature. If the R1 packet contains LOCATOR_SET parameters the R1 signature. If the R1 packet contains LOCATOR_SET parameters
with a new Preferred locator, the Initiator SHOULD directly set the with a new Preferred locator, the Initiator SHOULD directly set the
new Preferred locator to status ACTIVE without performing address new Preferred locator to status ACTIVE without performing address
verification first, and MUST send the I2 packet to the new Preferred verification first, and MUST send the I2 packet to the new Preferred
locator. The I1 destination address and the new Preferred locator locator. The I1 destination address and the new Preferred locator
may be identical. All new non-preferred locators must still undergo may be identical. All new non-preferred locators must still undergo
address verification once the base exchange completes. It is also address verification once the base exchange completes. It is also
skipping to change at page 12, line 38 skipping to change at page 13, line 17
HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have
some advantages when a host prefers not to divulge additional some advantages when a host prefers not to divulge additional
locators until after the I2 is successfully processed. locators until after the I2 is successfully processed.
When the LOCATOR_SET parameter is sent in an UPDATE packet, then the When the LOCATOR_SET parameter is sent in an UPDATE packet, then the
receiver will respond with an UPDATE acknowledgment. When the receiver will respond with an UPDATE acknowledgment. When the
LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base
exchange retransmission mechanism will confirm its successful exchange retransmission mechanism will confirm its successful
delivery. delivery.
4.10. Using LOCATOR_SETs across Addressing Realms 4.2.9. Using LOCATOR_SETs across Addressing Realms
It is possible for HIP associations to use these mechanisms to It is possible for HIP associations to use these mechanisms to
migrate their HIP associations and security associations from migrate their HIP associations and security associations from
addresses in the IPv4 addressing realm to IPv6 or vice versa. It may addresses in the IPv4 addressing realm to IPv6 or vice versa. It may
be possible for a state to arise in which both hosts are only using be possible for a state to arise in which both hosts are only using
locators in different addressing realms, but in such a case, some locators in different addressing realms, but in such a case, some
type of mechanism for interworking between the different realms must type of mechanism for interworking between the different realms must
be employed; such techniques are outside the scope of the present be employed; such techniques are outside the scope of the present
text. text.
4.11. Interaction with Security Associations 4.3. Interaction with Security Associations
A host may establish any number of security associations (or SPIs) A host may establish any number of security associations (or SPIs)
with a peer. The main purpose of having multiple SPIs with a peer is with a peer. The main purpose of having multiple SPIs with a peer is
to group the addresses into collections that are likely to experience to group the addresses into collections that are likely to experience
fate sharing, or to perform load balancing. fate sharing, or to perform load balancing.
A basic property of HIP SAs is that the inbound IP address is not A basic property of HIP SAs is that the inbound IP address is not
used to lookup the incoming SA. However, the use of different source used to lookup the incoming SA. However, the use of different source
and destination addresses typically leads to different paths, with and destination addresses typically leads to different paths, with
different latencies in the network, and if packets were to arrive via different latencies in the network, and if packets were to arrive via
skipping to change at page 13, line 47 skipping to change at page 14, line 21
5. Processing Rules 5. Processing Rules
Basic processing rules for the LOCATOR_SET parameter are specified in Basic processing rules for the LOCATOR_SET parameter are specified in
[I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming- [I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming-
specific rules. specific rules.
5.1. Sending LOCATOR_SETs 5.1. Sending LOCATOR_SETs
The decision of when to send a LOCATOR_SET, and which addresses to The decision of when to send a LOCATOR_SET, and which addresses to
include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis] include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis]
recommends that a host should send a LOCATOR_SET whenever it recommends that a host "send a LOCATOR_SET whenever it recognizes a
recognizes a change of its IP addresses in use on an active HIP change of its IP addresses in use on an active HIP association, and
association, and assumes that the change is going to last at least (when it) assumes that the change is going to last at least for a few
for a few seconds. It is possible to delay the exposure of seconds." It is possible to delay the exposure of additional
additional locators to the peer, and to send data from previously locators to the peer, and to send data from previously unannounced
unannounced locators, as might arise in certain mobility or locators, as might arise in certain mobility or multihoming
multihoming situations. situations.
When a host decides to inform its peers about changes in its IP When a host decides to inform its peers about changes in its IP
addresses, it has to decide how to group the various addresses with addresses, it has to decide how to group the various addresses with
SPIs. The grouping should consider also whether middlebox SPIs. If hosts are deployed in an operational environment in which
interaction requires sending the same LOCATOR_SET in separate UPDATEs HIP-aware NATs and firewalls (that may perform parameter inspection)
on different paths. Since each SPI is associated with a different exist, and different such devices may exist on different paths, hosts
Security Association, the grouping policy may also be based on ESP may take that knowledge into consideration about how addresses are
anti-replay protection considerations. In the typical case, simply grouped, and may send the same LOCATOR_SET in separate UPDATEs on the
basing the grouping on actual kernel level physical and logical different paths. However, more detailed guidelines about how to
interfaces may be the best policy. Grouping policy is outside of the operate in the presence of such HIP-aware NATs and firewalls is a
scope of this document. topic for further study. Since each SPI is associated with a
different Security Association, the grouping policy may also be based
on ESP anti-replay protection considerations. In the typical case,
simply basing the grouping on actual kernel level physical and
logical interfaces may be the best policy. Grouping policy is
outside of the scope of this document.
Locators corresponding to tunnel interfaces (e.g. IPsec tunnel Locators corresponding to tunnel interfaces (e.g. IPsec tunnel
interfaces or Mobile IP home addresses) or other virtual interfaces interfaces or Mobile IP home addresses) or other virtual interfaces
MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid
announcing such locators as preferred locators if more direct paths announcing such locators as preferred locators if more direct paths
may be obtained by instead preferring locators from non-tunneling may be obtained by instead preferring locators from non-tunneling
interfaces if such locators provide a more direct path to the HIP interfaces if such locators provide a more direct path to the HIP
peer. peer.
Hosts MUST NOT announce broadcast or multicast addresses in [I-D.ietf-hip-rfc5206-bis] specifies that hosts MUST NOT announce
LOCATOR_SETs. Link-local addresses MAY be announced to peers that broadcast or multicast addresses in LOCATOR_SETs. Link-local
are known to be neighbors on the same link, such as when the IP addresses MAY be announced to peers that are known to be neighbors on
destination address of a peer is also link-local. The announcement the same link, such as when the IP destination address of a peer is
of link-local addresses in this case is a policy decision; link-local also link-local. The announcement of link-local addresses in this
addresses used as Preferred locators will create reachability case is a policy decision; link-local addresses used as Preferred
problems when the host moves to another link. In any case, link- locators will create reachability problems when the host moves to
local addresses MUST NOT be announced to a peer unless that peer is another link. In any case, link-local addresses MUST NOT be
known to be on the same link. announced to a peer unless that peer is known to be on the same link.
Once the host has decided on the groups and assignment of addresses Once the host has decided on the groups and assignment of addresses
to the SPIs, it creates a LOCATOR_SET parameter that serves as a to the SPIs, it creates a LOCATOR_SET parameter that serves as a
complete representation of the addresses and associated SPIs intended complete representation of the addresses and associated SPIs intended
for active use. We now describe a few cases introduced in Section 4. for active use. We now describe a few cases introduced in Section 4.
We assume that the Traffic Type for each locator is set to "0" (other We assume that the Traffic Type for each locator is set to "0" (other
values for Traffic Type may be specified in documents that separate values for Traffic Type may be specified in documents that separate
the HIP control plane from data plane traffic). Other mobility and the HIP control plane from data plane traffic). Other mobility and
multihoming cases are possible but are left for further multihoming cases are possible but are left for further
experimentation. experimentation.
skipping to change at page 19, line 4 skipping to change at page 19, line 26
This document extends the scope of host mobility solutions defined in This document extends the scope of host mobility solutions defined in
[I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a [I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a
result, many of the same security considerations for mobility also result, many of the same security considerations for mobility also
pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis] pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis]
describes how HIP host mobility is resistant to different types of describes how HIP host mobility is resistant to different types of
impersonation attacks and DoS attacks. impersonation attacks and DoS attacks.
The security considerations for this document are similar to those of The security considerations for this document are similar to those of
[I-D.ietf-hip-rfc5206-bis] because the strong authentication [I-D.ietf-hip-rfc5206-bis] because the strong authentication
capabilities for mobility also carry over to end-host multihoming. capabilities for mobility also carry over to end-host multihoming.
[RFC4218] provides a threat analysis for IPv6 multihoming, and the [RFC4218] provides a threat analysis for IPv6 multihoming, and the
remainder of this section describes how HIP host multihoming remainder of this section first describes how HIP host multihoming
addresses those threats. addresses those previously described threats, and then discusses some
additional security considerations.
The high-level threats discussed in [RFC4218] involve redirection The high-level threats discussed in [RFC4218] involve redirection
attacks for the purposes of packet recording, data manipulation, and attacks for the purposes of packet recording, data manipulation, and
availability. There are a few types of attackers to consider: on- availability. There are a few types of attackers to consider: on-
path attackers, off-path attackers, and malicious hosts. path attackers, off-path attackers, and malicious hosts.
[RFC4218] also makes the comment that in identifier/locator split [RFC4218] also makes the comment that in identifier/locator split
solutions such as HIP, application security mechanisms should be tied solutions such as HIP, application security mechanisms should be tied
to the identifier, not the locator, and attacks on the identifier to the identifier, not the locator, and attacks on the identifier
mechanism and on the mechanism binding locators to the identifier are mechanism and on the mechanism binding locators to the identifier are
skipping to change at page 19, line 50 skipping to change at page 20, line 24
(Section 4 of [RFC4218]), HIP multihoming should not introduce new (Section 4 of [RFC4218]), HIP multihoming should not introduce new
concerns. Classic and premeditated redirection are prevented by the concerns. Classic and premeditated redirection are prevented by the
strong authentication in HIP messages. Third-party denial-of-service strong authentication in HIP messages. Third-party denial-of-service
attacks are prevented by the address verification mechanism. Replay attacks are prevented by the address verification mechanism. Replay
attacks can be avoided via use of replay protection in Encapsulating attacks can be avoided via use of replay protection in Encapsulating
Security Payload (ESP) Security Associations (SAs). In addition, Security Payload (ESP) Security Associations (SAs). In addition,
accepting packets from unknown locators is protected by either the accepting packets from unknown locators is protected by either the
strong authentication in the HIP control packets, or by the ESP-based strong authentication in the HIP control packets, or by the ESP-based
encryption in use for data packets. encryption in use for data packets.
Finally, the HIP mechanisms are designed to limit the ability to The HIP mechanisms are designed to limit the ability to introduce DoS
introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]). on the mechanisms themselves (Section 7 of [RFC4218]). Care is taken
Care is taken in the HIP base exchange to avoid creating state or in the HIP base exchange to avoid creating state or performing much
performing much work before hosts can authenticate one another. A work before hosts can authenticate one another. A malicious host
malicious host involved in HIP multihoming with another host might involved in HIP multihoming with another host might attempt to misuse
attempt to misuse the mechanisms for multihoming by, for instance, the mechanisms for multihoming by, for instance, increasing the state
increasing the state required or inducing a resource limitation required or inducing a resource limitation attack by sending too many
attack by sending too many candidate locators to the peer host. candidate locators to the peer host. Therefore, implementations
Therefore, implementations supporting the multihoming extensions supporting the multihoming extensions should consider to avoid
should consider to avoid accepting large numbers of peer locators, accepting large numbers of peer locators, and to rate limit any
and to rate limit any UPDATE messages being exchanged. UPDATE messages being exchanged.
The exposure of a host's IP addresses through HIP mobility and
multihoming extensions may raise the following privacy concern. The
administrator of a host may be trying to hide its location in some
context through the use of a VPN or other virtual interfaces.
Similar privacy issues also arise in other frameworks such as WebRTC
and are not specific to HIP. Implementations SHOULD provide a
mechanism to allow the host administrator to block the exposure of
selected addresses or address ranges.
Finally, some implementations of VPN tunneling have experienced
instances of 'leakage' of flows that were intended to have been
protected by a security tunnel but are instead sent in the clear,
perhaps because some of the addresses used fall outside of the range
of addresses configured for the tunnel in the security policy or
association database. Implementers are advised to take steps to
ensure that the usage of multiple addresses between hosts does not
cause accidental leakage of some data session traffic outside of the
ESP-protected envelope.
7. IANA Considerations 7. IANA Considerations
This document has no requests for IANA actions. This document has no requests for IANA actions.
8. Authors and Acknowledgments 8. Authors and Acknowledgments
This document contains content that was originally included in This document contains content that was originally included in
RFC5206. Pekka Nikander and Jari Arkko originated RFC5206, and RFC5206. Pekka Nikander and Jari Arkko originated RFC5206, and
Christian Vogt and Thomas Henderson (editor) later joined as co- Christian Vogt and Thomas Henderson (editor) later joined as co-
skipping to change at page 20, line 37 skipping to change at page 21, line 31
Melen for many improvements to the document. Concepts from a paper Melen for many improvements to the document. Concepts from a paper
on host multihoming across address families, by Samu Varjonen, Miika on host multihoming across address families, by Samu Varjonen, Miika
Komu, and Andrei Gurtov, contributed to this revised version. Komu, and Andrei Gurtov, contributed to this revised version.
9. References 9. References
9.1. Normative references 9.1. Normative references
[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-12 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-13
(work in progress), May 2016. (work in progress), September 2016.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
skipping to change at page 22, line 51 skipping to change at page 23, line 51
| | | | | |
| draft-09 | Update author affiliations, IPR boilerplate to | | draft-09 | Update author affiliations, IPR boilerplate to |
| | trust200902, and one stale reference. | | | trust200902, and one stale reference. |
| | | | | |
| draft-10 | Improve security considerations section by reviewing | | draft-10 | Improve security considerations section by reviewing |
| | RFC 4218. | | | RFC 4218. |
| | | | | |
| | Clarified comment about applicability of shim6. | | | Clarified comment about applicability of shim6. |
| | | | | |
| draft-11 | Editorial improvements based on last call comments. | | draft-11 | Editorial improvements based on last call comments. |
| | |
| draft-12 | Added section about locator privacy concerns to the |
| | Security Considerations section. |
| | |
| | Added section about relationship to split tunnel |
| | issues to the Security Considerations section. |
| | |
| | Editorial improvements based on last call comments. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
University of Washington University of Washington
Campus Box 352500 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
 End of changes. 32 change blocks. 
92 lines changed or deleted 136 lines changed or added

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