draft-ietf-hip-rfc5206-bis-06.txt   draft-ietf-hip-rfc5206-bis-07.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft The Boeing Company Internet-Draft University of Washington
Obsoletes: 5206 (if approved) C. Vogt Obsoletes: 5206 (if approved) C. Vogt
Intended status: Standards Track J. Arkko Intended status: Standards Track J. Arkko
Expires: January 16, 2014 Ericsson Research NomadicLab Expires: May 16, 2015 Ericsson Research NomadicLab
July 15, 2013 November 12, 2014
Host Mobility with the Host Identity Protocol Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-06 draft-ietf-hip-rfc5206-bis-07
Abstract Abstract
This document defines mobility extensions to the Host Identity This document defines mobility extensions to the Host Identity
Protocol (HIP). Specifically, this document defines a general Protocol (HIP). Specifically, this document defines a general
"LOCATOR_SET" parameter for HIP messages that allows for a HIP host "LOCATOR_SET" parameter for HIP messages that allows for a HIP host
to notify peers about alternate addresses at which it may be reached. to notify peers about alternate addresses at which it may be reached.
This document also defines elements of procedure for mobility of a This document also defines elements of procedure for mobility of a
HIP host -- the process by which a host dynamically changes the HIP host -- the process by which a host dynamically changes the
primary locator that it uses to receive packets. While the same primary locator that it uses to receive packets. While the same
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 16, 2014. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 7 skipping to change at page 2, line 26
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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 . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 10 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11 Rekey) . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Using LOCATOR_SETs across Addressing Realms . . . . . 12 3.2.3. Using LOCATOR_SETs across Addressing Realms . . . . . 11
3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 12 3.3. Other Considerations . . . . . . . . . . . . . . . . . . 12
3.3.1. Address Verification . . . . . . . . . . . . . . . . . 12 3.3.1. Address Verification . . . . . . . . . . . . . . . . 12
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 13 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 12
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14
4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . . 14 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 14
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 16 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 16 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 16
4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17 4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 17 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Locator Data Structure and Status . . . . . . . . . . . . 17 5.1. Locator Data Structure and Status . . . . . . . . . . . . 17
5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . . 18 5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 18
5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . . 20 5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 20
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 22 5.4. Verifying Address Reachability . . . . . . . . . . . . . 22
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 23 5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 24 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 24
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 24 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 26 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 29 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 29
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 30 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative references . . . . . . . . . . . . . . . . . . . 31 9.1. Normative references . . . . . . . . . . . . . . . . . . 31
9.2. Informative references . . . . . . . . . . . . . . . . . . 32 9.2. Informative references . . . . . . . . . . . . . . . . . 31
Appendix A. Document Revision History . . . . . . . . . . . . . . 32 Appendix A. Document Revision History . . . . . . . . . . . . . 33
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
skipping to change at page 5, line 29 skipping to change at page 4, line 45
to a HIP mobility or multihoming address change, are outside the to a HIP mobility or multihoming address change, are outside the
scope of this document. scope of this document.
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].
LOCATOR_SET. The name of a HIP parameter containing zero or more LOCATOR_SET. The name of a HIP parameter containing zero or more
Locator fields. This parameter's name is distinguished from the Locator fields.
Locator fields embedded within it by the use of all capital
letters.
Locator. A name that controls how the packet is routed through the Locator. A name that controls how the packet is routed through the
network and demultiplexed by the end host. It may include a network and demultiplexed by the end host. It may include a
concatenation of traditional network addresses such as an IPv6 concatenation of traditional network addresses such as an IPv6
address and end-to-end identifiers such as an ESP SPI. It may address and end-to-end identifiers such as an ESP SPI. It may
also include transport port numbers or IPv6 Flow Labels as also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address. demultiplexing context, or it may simply be a network address.
Address. A name that denotes a point-of-attachment to the network. Address. A name that denotes a point-of-attachment to the network.
The two most common examples are an IPv4 address and an IPv6 The two most common examples are an IPv4 address and an IPv6
skipping to change at page 30, line 46 skipping to change at page 30, line 42
4. A HIP host attempts to steal a non-HIP host's session. A HIP 4. A HIP host attempts to steal a non-HIP host's session. A HIP
host could spoof the non-HIP host's IP address during the base host could spoof the non-HIP host's IP address during the base
exchange or set the non-HIP host's IP address as its preferred exchange or set the non-HIP host's IP address as its preferred
address via an UPDATE. Other possibilities exist, but a simple address via an UPDATE. Other possibilities exist, but a simple
solution is to prevent the use of HIP address check information solution is to prevent the use of HIP address check information
to influence non-HIP sessions. to influence non-HIP sessions.
7. IANA Considerations 7. IANA Considerations
This document defines a LOCATOR_SET parameter for the Host Identity The following changes to the "Host Identity Protocol (HIP)
Protocol [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in Parameters" registries are requested.
Section 4 with a Type of 193.
This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message The existing Parameter Type of 'LOCATOR' (value 193) should be
Type as defined in the Host Identity Protocol specification renamed to 'LOCATOR_SET' and the reference should be updated from
RFC5206 to this specification.
[I-D.ietf-hip-rfc5201-bis]. This parameter is defined in Section 5.3 The existing Notify Message Type of 'LOCATOR_TYPE_UNSUPPORTED' (value
with a value of 46. 46) should have its reference updated from RFC5206 to this
specification.
8. Authors and Acknowledgments 8. Authors and Acknowledgments
Pekka Nikander and Jari Arkko originated this document, and Christian Pekka Nikander and Jari Arkko originated this document, and Christian
Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Vogt and Thomas Henderson (editor) later joined as co-authors. Greg
Perkins contributed the initial draft of the security section. Petri Perkins contributed the initial draft of the security section. Petri
Jokela was a co-author of the initial individual submission. Jokela was a co-author of the initial individual submission.
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, Jan Melen, The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, Jan Melen,
Baris Boyvat, and Samu Varjonen for many improvements to the Baris Boyvat, and Samu Varjonen for many improvements to the
document. document.
9. References 9. References
9.1. Normative references 9.1. Normative references
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol [I-D.ietf-hip-rfc5201-bis]
Architecture", Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
draft-ietf-hip-rfc4423-bis-05 (work in "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
progress), September 2012. hip-rfc5201-bis-14 (work in progress), October 2013.
[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-12 (work in
progress), June 2013.
[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-03 (work in
progress), July 2013.
[I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
Identity Protocol (HIP) Rendezvous
Extension", draft-ietf-hip-rfc5204-bis-02
(work in progress), September 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs [I-D.ietf-hip-rfc5202-bis]
to Indicate Requirement Levels", BCP 14, Jokela, P., Moskowitz, R., and J. Melen, "Using the
RFC 2119, March 1997. Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-05 (work in progress), November 2013.
[RFC3484] Draves, R., "Default Address Selection [I-D.ietf-hip-rfc5204-bis]
for Internet Protocol version 6 (IPv6)", Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
RFC 3484, February 2003. Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work
in progress), June 2014.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Addressing Architecture", RFC 4291, Requirement Levels", BCP 14, RFC 2119, March 1997.
February 2006.
[RFC4303] Kent, S., "IP Encapsulating Security [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Payload (ESP)", RFC 4303, December 2005. Architecture", RFC 4291, February 2006.
9.2. Informative references 9.2. Informative references
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based [CBA-MIPv6]
Authorization for Mobile IPv6 Early Vogt, C. and J. Arkko, "Credit-Based Authorization for
Binding Updates", Work in Progress, Mobile IPv6 Early Binding Updates", February 2005.
February 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., [I-D.ietf-hip-rfc4423-bis]
Montenegro, G., and E. Nordmark, "Mobile Moskowitz, R. and M. Komu, "Host Identity Protocol
IP Version 6 Route Optimization Security Architecture", draft-ietf-hip-rfc4423-bis-08 (work in
Design Background", RFC 4225, progress), April 2014.
December 2005.
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Authorization for Concurrent Reachability Nordmark, "Mobile IP Version 6 Route Optimization Security
Verification", Work in Progress, Design Background", RFC 4225, December 2005.
February 2006.
[SIMPLE-CBA]
Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", February 2006.
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 from RFC5206 xml (unchanged). | | draft-00 | Initial version from RFC5206 xml (unchanged). |
| | |
| draft-01 | Remove multihoming-specific text; no other changes. | | draft-01 | Remove multihoming-specific text; no other changes. |
| | |
| draft-02 | Update references to point to -bis drafts; no other | | draft-02 | Update references to point to -bis drafts; no other |
| | changes. | | | changes. |
| draft-03 | issue 4: add make before break use case | | | |
| | issue 6: peer locator exposure policies | | draft-03 | issue 4: add make before break use case |
| | issue 10: rename LOCATOR to LOCATOR_SET | | | |
| | issue 14: use of UPDATE packet's IP address | | | issue 6: peer locator exposure policies |
| | |
| | issue 10: rename LOCATOR to LOCATOR_SET |
| | |
| | issue 14: use of UPDATE packet's IP address |
| | |
| draft-04 | Document refresh; no other changes. | | draft-04 | Document refresh; no other changes. |
| | |
| draft-05 | Document refresh; no other changes. | | draft-05 | Document refresh; no other changes. |
| | |
| draft-06 | Document refresh; no other changes. | | draft-06 | Document refresh; no other changes. |
| | |
| draft-07 | Document refresh; IANA considerations updated. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Thomas R. Henderson (editor) Thomas R. Henderson (editor)
The Boeing Company University of Washington
P.O. Box 3707 Campus Box 352500
Seattle, WA Seattle, WA
USA USA
EMail: thomas.r.henderson@boeing.com EMail: tomhend@u.washington.edu
Christian Vogt Christian Vogt
Ericsson Research NomadicLab Ericsson Research NomadicLab
Hirsalantie 11 Hirsalantie 11
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone:
EMail: christian.vogt@ericsson.com EMail: christian.vogt@ericsson.com
Jari Arkko Jari Arkko
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 40 5079256 Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
 End of changes. 28 change blocks. 
111 lines changed or deleted 104 lines changed or added

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