draft-ietf-hip-rfc5206-bis-01.txt   draft-ietf-hip-rfc5206-bis-02.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research NomadicLab Internet-Draft Ericsson Research NomadicLab
Obsoletes: 5206 (if approved) T. Henderson, Ed. Obsoletes: 5206 (if approved) T. Henderson, Ed.
Intended status: Standards Track The Boeing Company Intended status: Standards Track The Boeing Company
Expires: April 21, 2011 C. Vogt Expires: September 15, 2011 C. Vogt
J. Arkko J. Arkko
Ericsson Research NomadicLab Ericsson Research NomadicLab
October 18, 2010 March 14, 2011
Host Mobility with the Host Identity Protocol Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-01 draft-ietf-hip-rfc5206-bis-02
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" parameter for HIP messages that allows for a HIP host to "LOCATOR" parameter for HIP messages that allows for a HIP host to
notify peers about alternate addresses at which it may be reached. 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 42 skipping to change at page 1, line 42
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 April 21, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 8 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9 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 LOCATORs across Addressing Realms . . . . . . . 11 3.2.3. Using LOCATORs across Addressing Realms . . . . . . . 11
3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . 12 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 12
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 13 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14
4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 14 4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 14
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 15 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 . . . . . . . . . . . 16 4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 17
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 16 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Locator Data Structure and Status . . . . . . . . . . . . 16 5.1. Locator Data Structure and Status . . . . . . . . . . . . 17
5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 18 5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 18
5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 19 5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 20
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 21 5.4. Verifying Address Reachability . . . . . . . . . . . . . . 22
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 22 5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 23
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 23 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 24
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 23 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 24
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 25 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 28 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 29
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 29 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative references . . . . . . . . . . . . . . . . . . . 30 9.1. Normative references . . . . . . . . . . . . . . . . . . . 31
9.2. Informative references . . . . . . . . . . . . . . . . . . 30 9.2. Informative references . . . . . . . . . . . . . . . . . . 32
Appendix A. Document Revision History . . . . . . . . . . . . . . 31 Appendix A. Document Revision History . . . . . . . . . . . . . . 32
1. Introduction and Scope 1. Introduction and Scope
The Host Identity Protocol [RFC4423] (HIP) supports an architecture The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports
that decouples the transport layer (TCP, UDP, etc.) from the an architecture that decouples the transport layer (TCP, UDP, etc.)
internetworking layer (IPv4 and IPv6) by using public/private key from the internetworking layer (IPv4 and IPv6) by using public/
pairs, instead of IP addresses, as host identities. When a host uses private key pairs, instead of IP addresses, as host identities. When
HIP, the overlying protocol sublayers (e.g., transport layer sockets a host uses HIP, the overlying protocol sublayers (e.g., transport
and Encapsulating Security Payload (ESP) Security Associations (SAs)) layer sockets and Encapsulating Security Payload (ESP) Security
are instead bound to representations of these host identities, and Associations (SAs)) are instead bound to representations of these
the IP addresses are only used for packet forwarding. However, each host identities, and the IP addresses are only used for packet
host must also know at least one IP address at which its peers are forwarding. However, each host must also know at least one IP
reachable. Initially, these IP addresses are the ones used during address at which its peers are reachable. Initially, these IP
the HIP base exchange [RFC5201]. addresses are the ones used during the HIP base exchange
[I-D.ietf-hip-rfc5201-bis].
One consequence of such a decoupling is that new solutions to One consequence of such a decoupling is that new solutions to
network-layer mobility and host multihoming are possible. 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 scenarios and other variations for further study. More complicated scenarios and other variations for further study. More
specifically: specifically:
This document defines a generalized LOCATOR parameter for use in This document defines a generalized LOCATOR parameter for use in
skipping to change at page 4, line 48 skipping to change at page 4, line 49
change in the preferred IP address used to reach a host. In change in the preferred IP address used to reach a host. In
particular, message flows to enable successful host mobility, particular, message flows to enable successful host mobility,
including address verification methods, are defined herein. including address verification methods, are defined herein.
However, while the same LOCATOR parameter is intended to support However, while the same LOCATOR parameter is intended to support
host multihoming (parallel support of a number of addresses), and host multihoming (parallel support of a number of addresses), and
experimentation is encouraged, detailed elements of procedure for experimentation is encouraged, detailed elements of procedure for
host multihoming are out of scope. host multihoming are out of scope.
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 [RFC5202], this document largely assumes the use of transport format [I-D.ietf-hip-rfc5202-bis], this document largely
ESP and leaves other transport formats for further study. assumes the use of ESP and leaves other transport formats for further
study.
There are a number of situations where the simple end-to-end There are a number of situations where the simple end-to-end
readdressing functionality is not sufficient. These include the readdressing functionality is not sufficient. These include the
initial reachability of a mobile host, location privacy, simultaneous initial reachability of a mobile host, location privacy, simultaneous
mobility of both hosts, and some modes of NAT traversal. In these mobility of both hosts, and some modes of NAT traversal. In these
situations, there is a need for some helper functionality in the situations, there is a need for some helper functionality in the
network, such as a HIP rendezvous server [RFC5204]. Such network, such as a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis].
functionality is out of the scope of this document. We also do not Such functionality is out of the scope of this document. We also do
consider localized mobility management extensions (i.e., mobility not consider localized mobility management extensions (i.e., mobility
management techniques that do not involve directly signaling the management techniques that do not involve directly signaling the
correspondent node); this document is concerned with end-to-end correspondent node); this document is concerned with end-to-end
mobility. Making underlying IP mobility transparent to the transport mobility. Making underlying IP mobility transparent to the transport
layer has implications on the proper response of transport congestion layer has implications on the proper response of transport congestion
control, path MTU selection, and Quality of Service (QoS). 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 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
skipping to change at page 6, line 12 skipping to change at page 6, line 17
authorizes the peer to receive a certain amount of data at the new authorizes the peer to receive a certain amount of data at the new
locator before the result of such verification is known. locator before the result of such verification is known.
3. Protocol Model 3. Protocol Model
This section is an overview; more detailed specification follows this This section is an overview; more detailed specification follows this
section. section.
3.1. Operating Environment 3.1. Operating Environment
The Host Identity Protocol (HIP) [RFC5201] is a key establishment and The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key
parameter negotiation protocol. Its primary applications are for establishment and parameter negotiation protocol. Its primary
authenticating host messages based on host identities, and applications are for authenticating host messages based on host
establishing security associations (SAs) for the ESP transport format identities, and establishing security associations (SAs) for the ESP
[RFC5202] and possibly other protocols in the future. transport format [I-D.ietf-hip-rfc5202-bis] and possibly other
protocols in the future.
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | Key | | HIP | | Key | | | | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | | | | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | | | | Process | | | | Process | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| ^ | | ^ | | ^ | | ^ |
| | | | | | | | | | | |
skipping to change at page 7, line 32 skipping to change at page 7, line 37
Figure 2 depicts a layered architectural view of a HIP-enabled stack Figure 2 depicts a layered architectural view of a HIP-enabled stack
using the ESP transport format. In HIP, upper-layer protocols using the ESP transport format. In HIP, upper-layer protocols
(including TCP and ESP in this figure) are bound to Host Identity (including TCP and ESP in this figure) are bound to Host Identity
Tags (HITs) and not IP addresses. The HIP sublayer is responsible Tags (HITs) and not IP addresses. The HIP sublayer is responsible
for maintaining the binding between HITs and IP addresses. The SPI for maintaining the binding between HITs and IP addresses. The SPI
is used to associate an incoming packet with the right HITs. The is used to associate an incoming packet with the right HITs. The
block labeled "MH" is introduced below. block labeled "MH" is introduced below.
Consider first the case in which there is no mobility or multihoming, Consider first the case in which there is no mobility or multihoming,
as specified in the base protocol specification [RFC5201]. The HIP as specified in the base protocol specification
base exchange establishes the HITs in use between the hosts, the SPIs [I-D.ietf-hip-rfc5201-bis]. The HIP base exchange establishes the
to use for ESP, and the IP addresses (used in both the HIP signaling HITs in use between the hosts, the SPIs to use for ESP, and the IP
packets and ESP data packets). Note that there can only be one such addresses (used in both the HIP signaling packets and ESP data
set of bindings in the outbound direction for any given packet, and packets). Note that there can only be one such set of bindings in
the only fields used for the binding at the HIP layer are the fields the outbound direction for any given packet, and the only fields used
exposed by ESP (the SPI and HITs). For the inbound direction, the for the binding at the HIP layer are the fields exposed by ESP (the
SPI is all that is required to find the right host context. ESP SPI and HITs). For the inbound direction, the SPI is all that is
rekeying events change the mapping between the HIT pair and SPI, but required to find the right host context. ESP rekeying events change
do not change the IP addresses. the mapping between the HIT pair and SPI, but 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, simultaneous movement of both hosts,
notification of transport layer protocols of the path change, and notification of transport layer protocols of the path change, and
procedures for possibly traversing middleboxes are not covered by procedures for possibly traversing middleboxes are not covered by
skipping to change at page 8, line 27 skipping to change at page 8, line 33
tunneling scenarios. Locators may simply be traditional network tunneling scenarios. Locators may simply be traditional network
addresses. The format of the locator fields in the LOCATOR parameter addresses. The format of the locator fields in the LOCATOR parameter
is defined in Section 4. is defined in Section 4.
3.1.2. Mobility Overview 3.1.2. Mobility Overview
When a host moves to another address, it notifies its peer of the new When a host moves to another address, it notifies its peer of the new
address by sending a HIP UPDATE packet containing a LOCATOR address by sending a HIP UPDATE packet containing a LOCATOR
parameter. This UPDATE packet is acknowledged by the peer. For parameter. This UPDATE packet is acknowledged by the peer. For
reliability in the presence of packet loss, the UPDATE packet is reliability in the presence of packet loss, the UPDATE packet is
retransmitted as defined in the HIP protocol specification [RFC5201]. retransmitted as defined in the HIP protocol specification
The peer can authenticate the contents of the UPDATE packet based on [I-D.ietf-hip-rfc5201-bis]. The peer can authenticate the contents
the signature and keyed hash of the packet. of the UPDATE packet based on the signature and keyed hash of the
packet.
When using ESP Transport Format [RFC5202], the host may at the same When using ESP Transport Format [I-D.ietf-hip-rfc5202-bis], the host
time decide to rekey its security association and possibly generate a may at the same time decide to rekey its security association and
new Diffie-Hellman key; all of these actions are triggered by possibly generate a new Diffie-Hellman key; all of these actions are
including additional parameters in the UPDATE packet, as defined in triggered by including additional parameters in the UPDATE packet, as
the base protocol specification [RFC5201] and ESP extension defined in the base protocol specification [I-D.ietf-hip-rfc5201-bis]
[RFC5202]. and ESP extension [I-D.ietf-hip-rfc5202-bis].
When using ESP (and possibly other transport modes in the future), When using ESP (and possibly other transport modes in the future),
the host is able to receive packets that are protected using a HIP the host is able to receive packets that are protected using a HIP
created ESP SA from any address. Thus, a host can change its IP created ESP SA from any address. Thus, a host can change its IP
address and continue to send packets to its peers without necessarily address and continue to send packets to its peers without necessarily
rekeying. However, the peers are not able to send packets to these rekeying. However, the peers are not able to send packets to these
new addresses before they can reliably and securely update the set of new addresses before they can reliably and securely update the set of
addresses that they associate with the sending host. Furthermore, addresses that they associate with the sending host. Furthermore,
mobility may change the path characteristics in such a manner that mobility may change the path characteristics in such a manner that
reordering occurs and packets fall outside the ESP anti-replay window reordering occurs and packets fall outside the ESP anti-replay window
for the SA, thereby requiring rekeying. for the SA, thereby requiring rekeying.
3.2. Protocol Overview 3.2. Protocol Overview
In this section, we briefly introduce a number of usage scenarios for In this section, we briefly introduce a number of usage scenarios for
HIP host mobility. These scenarios assume that HIP is being used HIP host mobility. These scenarios assume that HIP is being used
with the ESP transform [RFC5202], although other scenarios may be with the ESP transform [I-D.ietf-hip-rfc5202-bis], although other
defined in the future. To understand these usage scenarios, the scenarios may be defined in the future. To understand these usage
reader should be at least minimally familiar with the HIP protocol scenarios, the reader should be at least minimally familiar with the
specification [RFC5201]. However, for the (relatively) uninitiated HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for
reader, it is most important to keep in mind that in HIP the actual the (relatively) uninitiated reader, it is most important to keep in
payload traffic is protected with ESP, and that the ESP SPI acts as mind that in HIP the actual payload traffic is protected with ESP,
an index to the right host-to-host context. More specification and that the ESP SPI acts as an index to the right host-to-host
details are found later in Section 4 and Section 5. context. More specification details are found later in Section 4 and
Section 5.
The scenarios below assume that the two hosts have completed a single The scenarios below assume that the two hosts have completed a single
HIP base exchange with each other. Both of the hosts therefore have HIP base exchange with each other. Both of the hosts therefore have
one incoming and one outgoing SA. Further, each SA uses the same one incoming and one outgoing SA. Further, each SA uses the same
pair of IP addresses, which are the ones used in the base exchange. pair of IP addresses, which are the ones used in the base exchange.
The readdressing protocol is an asymmetric protocol where a mobile The readdressing protocol is an asymmetric protocol where a mobile
host informs a peer host about changes of IP addresses on affected host informs a peer host about changes of IP addresses on affected
SPIs. The readdressing exchange is designed to be piggybacked on SPIs. The readdressing exchange is designed to be piggybacked on
existing HIP exchanges. The majority of the packets on which the existing HIP exchanges. The majority of the packets on which the
skipping to change at page 10, line 31 skipping to change at page 10, line 40
parameter to the peer host in an UPDATE message. The UPDATE parameter to the peer host in an UPDATE message. The UPDATE
message also contains an ESP_INFO parameter containing the values message also contains an ESP_INFO parameter containing the values
of the old and new SPIs for a security association. In this of the old and new SPIs for a security association. In this
case, the OLD SPI and NEW SPI parameters both are set to the case, the OLD SPI and NEW SPI parameters both are set to the
value of the preexisting incoming SPI; this ESP_INFO does not value of the preexisting incoming SPI; this ESP_INFO does not
trigger a rekeying event but is instead included for possible trigger a rekeying event but is instead included for possible
parameter-inspecting middleboxes on the path. The LOCATOR parameter-inspecting middleboxes on the path. The LOCATOR
parameter contains the new IP address (Locator Type of "1", parameter contains the new IP address (Locator Type of "1",
defined below) and a locator lifetime. The mobile host waits for defined below) and a locator lifetime. The mobile host waits for
this UPDATE to be acknowledged, and retransmits if necessary, as this UPDATE to be acknowledged, and retransmits if necessary, as
specified in the base specification [RFC5201]. specified in the base specification [I-D.ietf-hip-rfc5201-bis].
2. The peer host receives the UPDATE, validates it, and updates any 2. The peer host receives the UPDATE, validates it, and updates any
local bindings between the HIP association and the mobile host's local bindings between the HIP association and the mobile host's
destination address. The peer host MUST perform an address destination address. The peer host MUST perform an address
verification by placing a nonce in the ECHO_REQUEST parameter of verification by placing a nonce in the ECHO_REQUEST parameter of
the UPDATE message sent back to the mobile host. It also the UPDATE message sent back to the mobile host. It also
includes an ESP_INFO parameter with the OLD SPI and NEW SPI includes an ESP_INFO parameter with the OLD SPI and NEW SPI
parameters both set to the value of the preexisting incoming SPI, parameters both set to the value of the preexisting incoming SPI,
and sends this UPDATE (with piggybacked acknowledgment) to the and sends this UPDATE (with piggybacked acknowledgment) to the
mobile host at its new address. The peer MAY use the new address mobile host at its new address. The peer MAY use the new address
skipping to change at page 14, line 10 skipping to change at page 14, line 41
When a host has multiple locators, the peer host must decide which to When a host has multiple locators, the peer host must decide which to
use for outbound packets. It may be that a host would prefer to use for outbound packets. It may be that a host would prefer to
receive data on a particular inbound interface. HIP allows a receive data on a particular inbound interface. HIP allows a
particular locator to be designated as a Preferred locator and particular locator to be designated as a Preferred locator and
communicated to the peer (see Section 4). communicated to the peer (see Section 4).
4. LOCATOR Parameter Format 4. LOCATOR Parameter Format
The LOCATOR parameter is a critical parameter as defined by The LOCATOR parameter is a critical parameter as defined by
[RFC5201]. It consists of the standard HIP parameter Type and Length [I-D.ietf-hip-rfc5201-bis]. It consists of the standard HIP
fields, plus zero or more Locator sub-parameters. Each Locator sub- parameter Type and Length fields, plus zero or more Locator sub-
parameter contains a Traffic Type, Locator Type, Locator Length, parameters. Each Locator sub-parameter contains a Traffic Type,
Preferred locator bit, Locator Lifetime, and a Locator encoding. A Locator Type, Locator Length, Preferred locator bit, Locator
LOCATOR containing zero Locator fields is permitted but has the Lifetime, and a Locator encoding. A LOCATOR containing zero Locator
effect of deprecating all addresses. fields is permitted but has the effect of deprecating all addresses.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P| | Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 15 skipping to change at page 20, line 4
are possible but are left for further experimentation. are possible but are left for further experimentation.
1. Host mobility with no multihoming and no rekeying. The mobile 1. Host mobility with no multihoming and no rekeying. The mobile
host creates a single UPDATE containing a single ESP_INFO with a host creates a single UPDATE containing a single ESP_INFO with a
single LOCATOR parameter. The ESP_INFO contains the current single LOCATOR parameter. The ESP_INFO contains the current
value of the SPI in both the OLD SPI and NEW SPI fields. The value of the SPI in both the OLD SPI and NEW SPI fields. The
LOCATOR contains a single Locator with a "Locator Type" of "1"; LOCATOR contains a single Locator with a "Locator Type" of "1";
the SPI must match that of the ESP_INFO. The Preferred bit the SPI must match that of the ESP_INFO. The Preferred bit
SHOULD be set and the "Locator Lifetime" is set according to SHOULD be set and the "Locator Lifetime" is set according to
local policy. The UPDATE also contains a SEQ parameter as usual. local policy. The UPDATE also contains a SEQ parameter as usual.
This packet is retransmitted as defined in the HIP protocol This packet is retransmitted as defined in the HIP protocol
specification [RFC5201]. The UPDATE should be sent to the peer's specification [I-D.ietf-hip-rfc5201-bis]. The UPDATE should be
preferred IP address with an IP source address corresponding to sent to the peer's preferred IP address with an IP source address
the address in the LOCATOR parameter. corresponding to the address in the LOCATOR parameter.
2. Host mobility with no multihoming but with rekeying. The mobile 2. Host mobility with no multihoming but with rekeying. The mobile
host creates a single UPDATE containing a single ESP_INFO with a host creates a single UPDATE containing a single ESP_INFO with a
single LOCATOR parameter (with a single address). The ESP_INFO single LOCATOR parameter (with a single address). The ESP_INFO
contains the current value of the SPI in the OLD SPI and the new contains the current value of the SPI in the OLD SPI and the new
value of the SPI in the NEW SPI, and a KEYMAT Index as selected value of the SPI in the NEW SPI, and a KEYMAT Index as selected
by local policy. Optionally, the host may choose to initiate a by local policy. Optionally, the host may choose to initiate a
Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter.
The LOCATOR contains a single Locator with "Locator Type" of "1"; The LOCATOR contains a single Locator with "Locator Type" of "1";
the SPI must match that of the NEW SPI in the ESP_INFO. the SPI must match that of the NEW SPI in the ESP_INFO.
skipping to change at page 26, line 31 skipping to change at page 27, line 31
the peer via a TCP connection and the end-to-end round-trip time does the peer via a TCP connection and the end-to-end round-trip time does
not exceed 500 milliseconds. Alternative credit-aging algorithms may not exceed 500 milliseconds. Alternative credit-aging algorithms may
use other parameter values or different parameters, which may even be use other parameter values or different parameters, which may even be
dynamically established. dynamically established.
6. Security Considerations 6. Security Considerations
The HIP mobility mechanism provides a secure means of updating a The HIP mobility mechanism provides a secure means of updating a
host's IP address via HIP UPDATE packets. Upon receipt, a HIP host host's IP address via HIP UPDATE packets. Upon receipt, a HIP host
cryptographically verifies the sender of an UPDATE, so forging or cryptographically verifies the sender of an UPDATE, so forging or
replaying a HIP UPDATE packet is very difficult (see [RFC5201]). replaying a HIP UPDATE packet is very difficult (see
Therefore, security issues reside in other attack domains. The two [I-D.ietf-hip-rfc5201-bis]). Therefore, security issues reside in
we consider are malicious redirection of legitimate connections as other attack domains. The two we consider are malicious redirection
well as redirection-based flooding attacks using this protocol. This of legitimate connections as well as redirection-based flooding
can be broken down into the following: attacks using this protocol. This can be broken down into the
following:
Impersonation attacks Impersonation attacks
- direct conversation with the misled victim - direct conversation with the misled victim
- man-in-the-middle attack - man-in-the-middle attack
DoS attacks DoS attacks
- flooding attacks (== bandwidth-exhaustion attacks) - flooding attacks (== bandwidth-exhaustion attacks)
skipping to change at page 27, line 37 skipping to change at page 28, line 37
the attacker tricks its victim into initiating the connection over an the attacker tricks its victim into initiating the connection over an
incorrect routing path (e.g., by acting as a router or using spoofed incorrect routing path (e.g., by acting as a router or using spoofed
DNS entries). DNS entries).
The HIP extensions defined in this specification change the situation The HIP extensions defined in this specification change the situation
in that they introduce an ability to redirect a connection (like in that they introduce an ability to redirect a connection (like
IPv6), both before and after establishment. If no precautionary IPv6), both before and after establishment. If no precautionary
measures are taken, an attacker could misuse the redirection feature measures are taken, an attacker could misuse the redirection feature
to impersonate a victim's peer from any arbitrary location. The to impersonate a victim's peer from any arbitrary location. The
authentication and authorization mechanisms of the HIP base exchange authentication and authorization mechanisms of the HIP base exchange
[RFC5201] and the signatures in the UPDATE message prevent this [I-D.ietf-hip-rfc5201-bis] and the signatures in the UPDATE message
attack. Furthermore, ownership of a HIP association is securely prevent this attack. Furthermore, ownership of a HIP association is
linked to a HIP HI/HIT. If an attacker somehow uses a bug in the securely linked to a HIP HI/HIT. If an attacker somehow uses a bug
implementation or weakness in some protocol to redirect a HIP in the implementation or weakness in some protocol to redirect a HIP
connection, the original owner can always reclaim their connection connection, the original owner can always reclaim their connection
(they can always prove ownership of the private key associated with (they can always prove ownership of the private key associated with
their public HI). their public HI).
MitM attacks are always possible if the attacker is present during MitM attacks are always possible if the attacker is present during
the initial HIP base exchange and if the hosts do not authenticate the initial HIP base exchange and if the hosts do not authenticate
each other's identities. However, once the opportunistic base each other's identities. However, once the opportunistic base
exchange has taken place, even a MitM cannot steal the HIP connection exchange has taken place, even a MitM cannot steal the HIP connection
anymore because it is very difficult for an attacker to create an anymore because it is very difficult for an attacker to create an
UPDATE packet (or any HIP packet) that will be accepted as a UPDATE packet (or any HIP packet) that will be accepted as a
skipping to change at page 28, line 47 skipping to change at page 29, line 47
amplification in the number and size of the redirected packets. As a amplification in the number and size of the redirected packets. As a
result, the combination of a reachability check and credit-based result, the combination of a reachability check and credit-based
authorization lowers a HIP redirection-based flooding attack to the authorization lowers a HIP redirection-based flooding attack to the
level of a direct flooding attack in which the attacker itself sends level of a direct flooding attack in which the attacker itself sends
the flooding traffic to the victim. the flooding traffic to the victim.
6.2.2. Memory/Computational-Exhaustion DoS Attacks 6.2.2. Memory/Computational-Exhaustion DoS Attacks
We now consider whether or not the proposed extensions to HIP add any We now consider whether or not the proposed extensions to HIP add any
new DoS attacks (consideration of DoS attacks using the base HIP new DoS attacks (consideration of DoS attacks using the base HIP
exchange and updates is discussed in [RFC5201]). A simple attack is exchange and updates is discussed in [I-D.ietf-hip-rfc5201-bis]). A
to send many UPDATE packets containing many IP addresses that are not simple attack is to send many UPDATE packets containing many IP
flagged as preferred. The attacker continues to send such packets addresses that are not flagged as preferred. The attacker continues
until the number of IP addresses associated with the attacker's HI to send such packets until the number of IP addresses associated with
crashes the system. Therefore, there SHOULD be a limit to the number the attacker's HI crashes the system. Therefore, there SHOULD be a
of IP addresses that can be associated with any HI. Other forms of limit to the number of IP addresses that can be associated with any
memory/computationally exhausting attacks via the HIP UPDATE packet HI. Other forms of memory/computationally exhausting attacks via the
are handled in the base HIP document [RFC5201]. HIP UPDATE packet are handled in the base HIP document
[I-D.ietf-hip-rfc5201-bis].
A central server that has to deal with a large number of mobile A central server that has to deal with a large number of mobile
clients may consider increasing the SA lifetimes to try to slow down clients may consider increasing the SA lifetimes to try to slow down
the rate of rekeying UPDATEs or increasing the cookie difficulty to the rate of rekeying UPDATEs or increasing the cookie difficulty to
slow down the rate of attack-oriented connections. slow down the rate of attack-oriented connections.
6.3. Mixed Deployment Environment 6.3. Mixed Deployment Environment
We now assume an environment with both HIP and non-HIP aware hosts. We now assume an environment with both HIP and non-HIP aware hosts.
Four cases exist. Four cases exist.
skipping to change at page 29, line 46 skipping to change at page 30, line 47
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 parameter for the Host Identity This document defines a LOCATOR parameter for the Host Identity
Protocol [RFC5201]. This parameter is defined in Section 4 with a Protocol [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in
Type of 193. Section 4 with a Type of 193.
This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message
Type as defined in the Host Identity Protocol specification Type as defined in the Host Identity Protocol specification
[RFC5201]. This parameter is defined in Section 5.3 with a value of
46. [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in Section 5.3
with a value of 46.
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, and Jan The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan
Melen for many improvements to the document. Melen for many improvements to the document.
9. References 9. References
9.1. Normative references 9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-hip-rfc4423-bis] Moskowitz, R., "Host Identity Protocol
Requirement Levels", BCP 14, RFC 2119, March 1997. Architecture",
draft-ietf-hip-rfc4423-bis-02 (work in
progress), February 2011.
[RFC3484] Draves, R., "Default Address Selection for Internet [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
Protocol version 6 (IPv6)", RFC 3484, February 2003. T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in
progress), March 2011.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P.,
Architecture", RFC 4291, February 2006. and J. Melen, "Using the Encapsulating
Security Payload (ESP) Transport Format
with the Host Identity Protocol (HIP)",
draft-ietf-hip-rfc5202-bis-00 (work in
progress), September 2010.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host
RFC 4303, December 2005. Identity Protocol (HIP) Rendezvous
Extension", draft-ietf-hip-rfc5204-bis-01
(work in progress), March 2011.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC2119] Bradner, S., "Key words for use in RFCs
(HIP) Architecture", RFC 4423, May 2006. to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. [RFC3484] Draves, R., "Default Address Selection
Henderson, "Host Identity Protocol", RFC 5201, for Internet Protocol version 6 (IPv6)",
April 2008. RFC 3484, February 2003.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC4291] Hinden, R. and S. Deering, "IP Version 6
Encapsulating Security Payload (ESP) Transport Format Addressing Architecture", RFC 4291,
with the Host Identity Protocol (HIP)", RFC 5202, February 2006.
April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol [RFC4303] Kent, S., "IP Encapsulating Security
(HIP) Rendezvous Extension", RFC 5204, April 2008. Payload (ESP)", RFC 4303, December 2005.
9.2. Informative references 9.2. Informative references
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based
Mobile IPv6 Early Binding Updates", Work in Progress, Authorization for Mobile IPv6 Early
February 2005. Binding Updates", Work in Progress,
February 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and [RFC4225] Nikander, P., Arkko, J., Aura, T.,
E. Nordmark, "Mobile IP Version 6 Route Optimization Montenegro, G., and E. Nordmark, "Mobile
Security Design Background", RFC 4225, December 2005. IP Version 6 Route Optimization Security
Design Background", RFC 4225,
December 2005.
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based
Concurrent Reachability Verification", Work Authorization for Concurrent Reachability
in Progress, February 2006. Verification", Work in Progress,
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 |
| | changes. |
+----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research NomadicLab Ericsson Research NomadicLab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com EMail: pekka.nikander@nomadiclab.com
 End of changes. 40 change blocks. 
143 lines changed or deleted 170 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/