draft-ietf-hip-multihoming-09.txt   draft-ietf-hip-multihoming-10.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: December 2, 2016 Independent Expires: January 25, 2017 Independent
J. Arkko J. Arkko
Ericsson Ericsson
May 31, 2016 July 24, 2016
Host Multihoming with the Host Identity Protocol Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-09 draft-ietf-hip-multihoming-10
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 December 2, 2016. This Internet-Draft will expire on January 25, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10 4.8. Combined Mobility and Multihoming . . . . . . . . . . . . 10
4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11 4.9. Initiating the Protocol in R1, I2, or R2 . . . . . . . . 11
4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12 4.10. Using LOCATOR_SETs across Addressing Realms . . . . . . . 12
4.11. Interaction with Security Associations . . . . . . . . . 13 4.11. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 13
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 15
5.3. Verifying Address Reachability . . . . . . . . . . . . . 17 5.3. Verifying Address Reachability . . . . . . . . . . . . . 17
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 17 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 18 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative references . . . . . . . . . . . . . . . . . . 19 9.1. Normative references . . . . . . . . . . . . . . . . . . 20
9.2. Informative references . . . . . . . . . . . . . . . . . 19 9.2. Informative references . . . . . . . . . . . . . . . . . 21
Appendix A. Document Revision History . . . . . . . . . . . . . 20 Appendix A. Document Revision History . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 22 skipping to change at page 3, line 22
network point-of-attachment. There are potentially many variations network point-of-attachment. There are potentially many variations
of host multihoming possible. [I-D.ietf-hip-rfc5206-bis] specifies of host multihoming possible. [I-D.ietf-hip-rfc5206-bis] specifies
the format of the HIP parameter (LOCATOR_SET parameter) used to the format of the HIP parameter (LOCATOR_SET parameter) used to
convey IP addressing information between peers, the procedures for convey IP addressing information between peers, the procedures for
sending and processing this parameter to enable basic host mobility, sending and processing this parameter to enable basic host mobility,
and procedures for an address verification mechanism. The scope of and procedures for an address verification mechanism. The scope of
this document encompasses messaging and elements of procedure for this document encompasses messaging and elements of procedure for
some basic host multihoming scenarios of interest. some basic host multihoming 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 host multihoming in multihomed IPv6
have been specified by the IETF shim6 working group. The shim6 networks have been specified by the IETF shim6 working group. The
protocol [RFC5533] bears many architectural similarities to HIP but shim6 protocol [RFC5533] bears many architectural similarities to HIP
there are differences in the security model and in the protocol. but 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 [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
skipping to change at page 10, line 39 skipping to change at page 10, line 39
flexible enough to accommodate this choice. flexible enough to accommodate this choice.
-<- SPI1a -- -- SPI2a ->- -<- SPI1a -- -- SPI2a ->-
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.8. Combined Mobility and Multihoming
It looks likely that in the future, many mobile hosts will be It looks likely that in the future, many mobile hosts will be
simultaneously mobile and multihomed, i.e., have multiple mobile simultaneously mobile and multihomed, i.e., have multiple mobile
interfaces. Furthermore, if the interfaces use different access interfaces. Furthermore, if the interfaces use different access
technologies, it is fairly likely that one of the interfaces may technologies, it is fairly likely that one of the interfaces may
appear stable (retain its current IP address) while some other(s) may appear stable (retain its current IP address) while some other(s) may
experience mobility (undergo IP address change). experience mobility (undergo IP address change).
skipping to change at page 18, line 35 skipping to change at page 18, line 35
but the peer has not yet indicated a new Preferred locator. but the peer has not yet indicated a new Preferred locator.
4. If the new Preferred locator has DEPRECATED status and there is 4. If the new Preferred locator has DEPRECATED status and there is
at least one non-deprecated address, the host selects one of the at least one non-deprecated address, the host selects one of the
non-deprecated addresses as a new Preferred locator and non-deprecated addresses as a new Preferred locator and
continues. If the selected address is UNVERIFIED, the address continues. If the selected address is UNVERIFIED, the address
verification procedure described above will apply. verification procedure described above will apply.
6. Security Considerations 6. Security Considerations
No additional security considerations beyond those outlined in This document extends the scope of host mobility solutions defined in
[I-D.ietf-hip-rfc5206-bis] have been identified. [I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a
result, many of the same security considerations for mobility also
pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis]
describes how HIP host mobility is resistant to different types of
impersonation attacks and DoS attacks.
The security considerations for this document are similar to those of
[I-D.ietf-hip-rfc5206-bis] because the strong authentication
capabilities for mobility also carry over to mobility. [RFC4218]
provides a threat analysis for IPv6 multihoming, and the remainder of
this section describes how HIP host multihoming addresses those
threats.
The high-level threats discussed in [RFC4218] involves redirection
attacks for the purposes of packet recording, data manipulation, and
availability. There are a few types of attackers to consider: on-
path attackers, off-path attackers, and malicious hosts.
[RFC4218] also makes the comment that in identifier/locator split
solutions such as HIP, application security mechanisms should be tied
to the identifier, not the locator, and attacks on the identifier
mechanism and on the mechanism binding locators to the identifier are
of concern. This document does not consider the former issue
(application layer security bindings) to be within scope. The latter
issue (locator bindings to identifier) is directly addressed by the
cryptographic protections of the HIP protocol, in that locators
associated to an identifier are listed in HIP packets that are signed
using the identifier key.
Section 3.1 of [RFC4218] lists several classes of security
configurations in use in the Internet. HIP maps to the fourth
(strong identifier) and fifth ("leap-of-faith") categories, the
latter being associated with the optional opportunistic mode of HIP
operation. The remainder of Section 3 describe existing security
problems in the Internet, and comments that the goal of a multihoming
solution is not to solve them specifically but rather not to make any
of them worse. HIP multihoming should not increase the severity of
the identified risks. One concern for both HIP mobility and
multihoming is the susceptibility of the mechanisms to misuse for
flooding based redirections due to a malicious host. The mechanisms
described in [I-D.ietf-hip-rfc5206-bis] for address verification are
important in this regard.
Regarding the new types of threats introduced by multihoming
(Section 4 of [RFC4218]), HIP multihoming should not introduce new
concerns. Classic and premeditated redirection are prevented by the
strong authentication in HIP messages. Third-party denial-of-service
attacks are prevented by the address verification mechanism. Replay
attacks can be avoided via use of replay protection in Encapsulating
Security Payload (ESP) Security Associations (SAs). In addition,
accepting packets from unknown locators is protected by either the
strong authentication in the HIP control packets, or by the ESP-based
encryption in use for data packets.
Finally, the HIP mechanisms are designed to limit the ability to
introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]).
Care is taken in the HIP base exchange to avoid creating state or
performing much work before hosts can authenticate one another. A
malicious host involved in HIP multihoming with another host might
attempt to misuse the mechanisms for multihoming by, for instance,
increasing the state required or inducing a resource limitation
attack by sending too many candidate locators to the peer host.
Therefore, implementations supporting the multihoming extensions
should consider to avoid accepting large numbers of peer locators,
and to rate limit any UPDATE messages being exchanged.
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 19, line 13 skipping to change at page 20, line 29
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-11 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12
(work in progress), May 2016. (work in progress), May 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,
skipping to change at page 19, line 39 skipping to change at page 21, line 7
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, DOI 10.17487/RFC7402, April 2015,
<http://www.rfc-editor.org/info/rfc7402>. <http://www.rfc-editor.org/info/rfc7402>.
9.2. Informative references 9.2. Informative references
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
October 2005, <http://www.rfc-editor.org/info/rfc4218>.
[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, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/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 |
skipping to change at page 20, line 44 skipping to change at page 22, line 44
| | to full mesh of SAs for multihoming. | | | to full mesh of SAs for multihoming. |
| | | | | |
| | issue 5: Improve draft based on recommendations for | | | issue 5: Improve draft based on recommendations for |
| | cross-family handovers in paper by Varjonen et. al. | | | cross-family handovers in paper by Varjonen et. al. |
| | | | | |
| | issue 7: Clarify and distinguish between load | | | issue 7: Clarify and distinguish between load |
| | balancing and fault tolerance use cases. | | | balancing and fault tolerance use cases. |
| | | | | |
| 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 |
| | RFC 4218. |
| | |
| | Clarified comment about applicability of shim6. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
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
EMail: tomhend@u.washington.edu EMail: tomhend@u.washington.edu
Christian Vogt Christian Vogt
Independent Independent
 End of changes. 12 change blocks. 
19 lines changed or deleted 93 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/