draft-ietf-hip-rfc5206-bis-09.txt   draft-ietf-hip-rfc5206-bis-10.txt 
Network Working Group T. Henderson, Ed. Network Working Group T. Henderson, Ed.
Internet-Draft University of Washington 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 23, 2016 Ericsson Research NomadicLab Expires: July 26, 2016 Ericsson Research NomadicLab
July 22, 2015 January 23, 2016
Host Mobility with the Host Identity Protocol Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-09 draft-ietf-hip-rfc5206-bis-10
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 23, 2016. This Internet-Draft will expire on July 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 15 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 15
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 17 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . 19 5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 29 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 28
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 30 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative references . . . . . . . . . . . . . . . . . . 31 9.1. Normative references . . . . . . . . . . . . . . . . . . 30
9.2. Informative references . . . . . . . . . . . . . . . . . 32 9.2. Informative references . . . . . . . . . . . . . . . . . 31
Appendix A. Document Revision History . . . . . . . . . . . . . 33 Appendix A. Document Revision History . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC7401] (HIP) supports an architecture
an architecture that decouples the transport layer (TCP, UDP, etc.) that decouples the transport layer (TCP, UDP, etc.) from the
from the internetworking layer (IPv4 and IPv6) by using public/ internetworking layer (IPv4 and IPv6) by using public/private key
private key pairs, instead of IP addresses, as host identities. When pairs, instead of IP addresses, as host identities. When a host uses
a host uses HIP, the overlying protocol sublayers (e.g., transport HIP, the overlying protocol sublayers (e.g., transport layer sockets
layer sockets and Encapsulating Security Payload (ESP) Security and Encapsulating Security Payload (ESP) Security Associations (SAs))
Associations (SAs)) are instead bound to representations of these are instead bound to representations of these host identities, and
host identities, and the IP addresses are only used for packet the IP addresses are only used for packet forwarding. However, each
forwarding. However, each host must also know at least one IP host must also know at least one IP address at which its peers are
address at which its peers are reachable. Initially, these IP reachable. Initially, these IP addresses are the ones used during
addresses are the ones used during the HIP base exchange [RFC7401]. the HIP base exchange.
One consequence of such a decoupling is that new solutions to One consequence of such a decoupling is that new solutions to
network-layer mobility and host multihoming are possible. There are network-layer mobility and host multihoming are possible. There are
potentially many variations of mobility and multihoming possible. potentially many variations of mobility and multihoming possible.
The scope of this document encompasses messaging and elements of The scope of this document encompasses messaging and elements of
procedure for basic network-level host mobility, leaving more procedure for basic network-level host mobility, leaving more
complicated mobility scenarios, multihoming, and other variations for complicated mobility scenarios, multihoming, and other variations for
further study. More specifically: further study. More specifically:
This document defines a generalized LOCATOR_SET parameter for use This document defines a generalized LOCATOR_SET parameter for use
skipping to change at page 7, line 49 skipping to change at page 7, line 49
SPI is all that is required to find the right host context. ESP SPI is all that is required to find the right host context. ESP
rekeying events change the mapping between the HIT pair and SPI, but rekeying events change the mapping between the HIT pair and SPI, but
do not change the IP addresses. do not change the IP addresses.
Consider next a mobility event, in which a host moves to another IP Consider next a mobility event, in which a host moves to another IP
address. Two things must occur in this case. First, the peer must address. Two things must occur in this case. First, the peer must
be notified of the address change using a HIP UPDATE message. be notified of the address change using a HIP UPDATE message.
Second, each host must change its local bindings at the HIP sublayer Second, each host must change its local bindings at the HIP sublayer
(new IP addresses). It may be that both the SPIs and IP addresses (new IP addresses). It may be that both the SPIs and IP addresses
are changed simultaneously in a single UPDATE; the protocol described are changed simultaneously in a single UPDATE; the protocol described
herein supports this. However, simultaneous movement of both hosts, herein supports this. However, elements of procedure to recover from
notification of transport layer protocols of the path change, and simultaneous movement of both hosts are not specified herein. In
procedures for possibly traversing middleboxes are not covered by addition, internal notification of transport layer protocols of the
this document. path change (e.g. to reset congestion control variables), and
elements of procedure for traversing middleboxes including network
address translators are not covered by this document.
3.1.1. Locator 3.1.1. Locator
This document defines a generalization of an address called a This document defines a generalization of an address called a
"locator". A locator specifies a point-of-attachment to the network "locator". A locator specifies a point-of-attachment to the network
but may also include additional end-to-end tunneling or per-host but may also include additional end-to-end tunneling or per-host
demultiplexing context that affects how packets are handled below the demultiplexing context that affects how packets are handled below the
logical HIP sublayer of the stack. This generalization is useful logical HIP sublayer of the stack. This generalization is useful
because IP addresses alone may not be sufficient to describe how because IP addresses alone may not be sufficient to describe how
packets should be handled below HIP. For example, in a host packets should be handled below HIP. For example, in a host
skipping to change at page 16, line 49 skipping to change at page 16, line 49
The "P" bit, when set, has scope over the corresponding Traffic Type. The "P" bit, when set, has scope over the corresponding Traffic Type.
That is, when a "P" bit is set for Traffic Type "2", for example, it That is, when a "P" bit is set for Traffic Type "2", for example, it
means that the locator is preferred for data packets. If there is a means that the locator is preferred for data packets. If there is a
conflict (for example, if the "P" bit is set for an address of Type conflict (for example, if the "P" bit is set for an address of Type
"0" and a different address of Type "2"), the more specific Traffic "0" and a different address of Type "2"), the more specific Traffic
Type rule applies (in this case, "2"). By default, the IP addresses Type rule applies (in this case, "2"). By default, the IP addresses
used in the base exchange are Preferred locators for both signaling used in the base exchange are Preferred locators for both signaling
and user data, unless a new Preferred locator supersedes them. If no and user data, unless a new Preferred locator supersedes them. If no
locators are indicated as preferred for a given Traffic Type, the locators are indicated as preferred for a given Traffic Type, the
implementation may use an arbitrary locator from the set of active implementation may use an arbitrary destination locator from the set
locators. of active locators.
4.2. Locator Type and Locator 4.2. Locator Type and Locator
The following Locator Type values are defined, along with the The following Locator Type values are defined, along with the
associated semantics of the Locator field: associated semantics of the Locator field:
0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291]
(128 bits long). This locator type is defined primarily for non- (128 bits long). This locator type is defined primarily for non-
ESP-based usage. ESP-based usage.
skipping to change at page 17, line 29 skipping to change at page 17, line 29
4.3. UPDATE Packet with Included LOCATOR_SET 4.3. UPDATE Packet with Included LOCATOR_SET
A number of combinations of parameters in an UPDATE packet are A number of combinations of parameters in an UPDATE packet are
possible (e.g., see Section 3.2). In this document, procedures are possible (e.g., see Section 3.2). In this document, procedures are
defined only for the case in which one LOCATOR_SET and one ESP_INFO defined only for the case in which one LOCATOR_SET and one ESP_INFO
parameter is used in any HIP packet. Furthermore, the LOCATOR_SET parameter is used in any HIP packet. Furthermore, the LOCATOR_SET
SHOULD list all of the locators that are active on the HIP SHOULD list all of the locators that are active on the HIP
association (including those on SAs not covered by the ESP_INFO association (including those on SAs not covered by the ESP_INFO
parameter). Any UPDATE packet that includes a LOCATOR_SET parameter parameter). Any UPDATE packet that includes a LOCATOR_SET parameter
SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The
UPDATE MAY also include a HOST_ID parameter (which may be useful for
middleboxes inspecting the HIP messages for the first time). If the
UPDATE includes the HOST_ID parameter, the receiving host MUST verify
that the HOST_ID corresponds to the HOST_ID that was used to
establish the HIP association, and the HIP_SIGNATURE must verify with
the public key assodiated with this HOST_ID parameter. The
relationship between the announced Locators and any ESP_INFO relationship between the announced Locators and any ESP_INFO
parameters present in the packet is defined in Section 5.2. The parameters present in the packet is defined in Section 5.2. This
sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for draft does not support any elements of procedure for sending more
further study; receivers may wish to experiment with supporting such than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE.
a possibility.
5. Processing Rules 5. Processing Rules
This section describes rules for sending and receiving the This section describes rules for sending and receiving the
LOCATOR_SET parameter, testing address reachability, and using LOCATOR_SET parameter, testing address reachability, and using
Credit-Based Authorization (CBA) on UNVERIFIED locators. Credit-Based Authorization (CBA) on UNVERIFIED locators.
5.1. Locator Data Structure and Status 5.1. Locator Data Structure and Status
In a typical implementation, each locator announced in a LOCATOR_SET In a typical implementation, each locator announced in a LOCATOR_SET
skipping to change at page 22, line 29 skipping to change at page 22, line 29
A host typically starts the address-verification procedure by sending A host typically starts the address-verification procedure by sending
a nonce to the new address. For example, when the host is changing a nonce to the new address. For example, when the host is changing
its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD
be random and the value MAY be copied into an ECHO_REQUEST sent in be random and the value MAY be copied into an ECHO_REQUEST sent in
the rekeying UPDATE. However, if the host is not changing its SPI, the rekeying UPDATE. However, if the host is not changing its SPI,
it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent
to the new address. A host MAY also use other message exchanges as to the new address. A host MAY also use other message exchanges as
confirmation of the address reachability. confirmation of the address reachability.
Note that in the case of receiving a LOCATOR_SET in an R1 and
replying with an I2 to the new address in the LOCATOR_SET, receiving
the corresponding R2 is sufficient proof of reachability for the
Responder's preferred address. Since further address verification of
such an address can impede the HIP-base exchange, a host MUST NOT
separately verify reachability of a new Preferred locator that was
received on an R1.
In some cases, it MAY be sufficient to use the arrival of data on a In some cases, it MAY be sufficient to use the arrival of data on a
newly advertised SA as implicit address reachability verification as newly advertised SA as implicit address reachability verification as
depicted in Figure 7, instead of waiting for the confirmation via a depicted in Figure 7, instead of waiting for the confirmation via a
HIP packet. In this case, a host advertising a new SPI as part of HIP packet. In this case, a host advertising a new SPI as part of
its address reachability check SHOULD be prepared to receive traffic its address reachability check SHOULD be prepared to receive traffic
on the new SA. on the new SA.
Mobile host Peer host Mobile host Peer host
prepare incoming SA prepare incoming SA
skipping to change at page 31, line 27 skipping to change at page 30, line 27
9.1. Normative references 9.1. Normative references
[I-D.ietf-hip-rfc5203-bis] [I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-09 Registration Extension", draft-ietf-hip-rfc5203-bis-09
(work in progress), June 2015. (work in progress), June 2015.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-06 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work
in progress), June 2015. in progress), December 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC Henderson, "Host Identity Protocol Version 2 (HIPv2)",
7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<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, DOI 10.17487/ the Host Identity Protocol (HIP)", RFC 7402,
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
[CBA-MIPv6] [CBA-MIPv6]
Vogt, C. and J. Arkko, "Credit-Based Authorization for Vogt, C. and J. Arkko, "Credit-Based Authorization for
Mobile IPv6 Early Binding Updates", February 2005. Mobile IPv6 Early Binding Updates", February 2005.
[I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-12 (work in
progress), June 2015.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, DOI 10.17487/RFC4225, Design Background", RFC 4225, DOI 10.17487/RFC4225,
December 2005, <http://www.rfc-editor.org/info/rfc4225>. December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[SIMPLE-CBA] [SIMPLE-CBA]
Vogt, C. and J. Arkko, "Credit-Based Authorization for Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", February 2006. Concurrent Reachability Verification", February 2006.
Appendix A. Document Revision History Appendix A. Document Revision History
skipping to change at page 33, line 46 skipping to change at page 32, line 46
| | (multihoming) | | | (multihoming) |
| | | | | |
| | State that only one LOCATOR_SET parameter may be sent | | | State that only one LOCATOR_SET parameter may be sent |
| | in an UPDATE packet (according to this draft) | | | in an UPDATE packet (according to this draft) |
| | (multihoming) | | | (multihoming) |
| | | | | |
| | Remove text about cross-family handovers (multihoming) | | | Remove text about cross-family handovers (multihoming) |
| | | | | |
| draft-09 | Add specification text regarding double-jump mobility | | draft-09 | Add specification text regarding double-jump mobility |
| | procedures. | | | procedures. |
| | |
| draft-10 | issue 21: clarified that HI MAY be included in UPDATE |
| | for benefit of middleboxes |
| | |
| | changed one informative reference from RFC 4423-bis to |
| | RFC 7401 |
| | |
| | removed discussion about possible multiple LOCATOR_SET |
| | and ESP_INFO parameters in an UPDATE (per previous |
| | mailing list discussion) |
| | |
| | removed discussion about handling LOCATOR_SET |
| | parameters in packets other than UPDATE (per previous |
| | mailing list discussion) |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
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
Ericsson Research NomadicLab Ericsson Research NomadicLab
 End of changes. 19 change blocks. 
61 lines changed or deleted 71 lines changed or added

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