< draft-nikander-hip-mm-00.txt   draft-nikander-hip-mm-01.txt >
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft J. Arkko Internet-Draft J. Arkko
Expires: December 16, 2003 P. Jokela Expires: June 28, 2004 Ericsson Research Nomadic Lab
Ericsson Research Nomadic Lab December 29, 2003
June 17, 2003
End-Host Mobility and Multi-Homing with Host Identity Protocol End-Host Mobility and Multi-Homing with Host Identity Protocol
draft-nikander-hip-mm-00.txt draft-nikander-hip-mm-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2003. This Internet-Draft will expire on June 28, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document specifies end-host mobility and multi-homing mechanisms This document specifies basic end-host mobility and multi-homing
for the Host Identity Protocol. mechanisms for the Host Identity Protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . 7 4. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Location privacy . . . . . . . . . . . . . . . . . . . . . . 7 4.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . . 7
3.3 End-host multi-homing . . . . . . . . . . . . . . . . . . . 7 4.2 End-host multi-homing . . . . . . . . . . . . . . . . . . . . 7
3.4 Site multi-homing . . . . . . . . . . . . . . . . . . . . . 8 4.3 Site multi-homing . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Combined mobility and multi-homing . . . . . . . . . . . . . 8 4.4 Combined mobility and multi-homing . . . . . . . . . . . . . . 8
3.6 Network renumbering . . . . . . . . . . . . . . . . . . . . 8 4.5 Network renumbering . . . . . . . . . . . . . . . . . . . . . 8
3.7 Combined all . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Overview of HIP basic mobility and multi-homing
4. Overview of HIP mobility and multi-homing functionality . . 9 functionality . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 IP addresses assigned to a node . . . . . . . . . . . . . . 9 5.1 Informing the peer about multiple or changed address(es) . . . 9
4.2 Informing the peer about multiple or changed address(es) . . 9 5.2 Address verification . . . . . . . . . . . . . . . . . . . . . 10
4.3 Address verification . . . . . . . . . . . . . . . . . . . . 10 5.3 Address data structure and status . . . . . . . . . . . . . . 11
4.4 Forwarding Agents . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1 Address leases from an Forwarding Agent . . . . . . . . . . 11 6.1 Initiating the protocol in NES . . . . . . . . . . . . . . . . 13
4.4.2 Recovering from forwarding agent crashes . . . . . . . . . . 12 6.2 Initiating the protocol in R1 or I2 . . . . . . . . . . . . . 13
4.5 Security Associations . . . . . . . . . . . . . . . . . . . 12 6.3 Explicit address check . . . . . . . . . . . . . . . . . . . . 15
5. Protocol overview . . . . . . . . . . . . . . . . . . . . . 13 7. Parameter and packet formats . . . . . . . . . . . . . . . . . 16
5.1 Acquiring an address lease from a Forwarding Agent . . . . . 13 7.1 REA parameter . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Renewing an address lease . . . . . . . . . . . . . . . . . 14 7.2 Modified NES_INFO parameter . . . . . . . . . . . . . . . . . 17
5.3 Readdressing and address status . . . . . . . . . . . . . . 14 7.3 NES packet with included REA . . . . . . . . . . . . . . . . . 18
6. Protocol definition . . . . . . . . . . . . . . . . . . . . 16 7.4 R1 and I2 packets with included REA . . . . . . . . . . . . . 18
6.1 Packet formats . . . . . . . . . . . . . . . . . . . . . . . 16 8. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.1 REA - the HIP readdress packet . . . . . . . . . . . . . . . 16 8.1 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2 AC and ACR - the HIP Address Check and Address Check 8.2 Handling received REAs . . . . . . . . . . . . . . . . . . . . 20
Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3 Verifying address reachability . . . . . . . . . . . . . . . . 21
6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets . . . . . . 20 8.4 Changing the preferred address . . . . . . . . . . . . . . . . 22
6.2 Requesting Address Leases . . . . . . . . . . . . . . . . . 21 9. Policy considerations . . . . . . . . . . . . . . . . . . . . 23
6.3 Providing address Leases . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.4 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.5 Handling received REAs at end hosts . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. Policy considerations . . . . . . . . . . . . . . . . . . . 23 Normative references . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . 24 Informative references . . . . . . . . . . . . . . . . . . . . 28
8.1 Why does the foreign agent may require a puzzle solution? . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
8.2 Attacker masquerading as a FA . . . . . . . . . . . . . . . 24 A. Changes from previous versions . . . . . . . . . . . . . . . . 29
8.3 Location privacy . . . . . . . . . . . . . . . . . . . . . . 25 A.1 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 B. Implementation experiences . . . . . . . . . . . . . . . . . . 30
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 31
Normative references . . . . . . . . . . . . . . . . . . . . 28
Informative references . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
A. Site multi-homing . . . . . . . . . . . . . . . . . . . . . 31
A.1 A host connected to a multi-homed site . . . . . . . . . . . 31
A.2 Transit providers with NATs . . . . . . . . . . . . . . . . 31
B. Implementation experiences . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 33
1. Introduction 1. Introduction
This document specifies how the Host Identity Protocol [3] (HIP) This document specifies an extension to the Host Identity Protocol
provides simple and efficient means for nodes to communicate while [3] (HIP). The extension provides a simple and efficient means for
being multi-homed, mobile, or simultanously mobile and multi-homed. hosts to keep their communications on-going while having multiple IP
Additionally, HIP allows communications even when the multi-homing or addresses, either at the same time or one after another. That is,
mobility causes a change in the IP version that is available in the the extension provides basic support for multi-homing, mobility, and
network. simultaneous multi-homing and mobility. Additionally, the extension
allows communications to continue even when multi-homing or mobility
causes a change of the IP version that is available in the network;
that is, if one of the communicating hosts has both IPv4 and IPv6
connectivity, either directly or through a proxy,the other host can
alternate between IPv4 and IPv6 without any effects on the upper
layer protocols.
More specifically, the Host Identity Protocol [3] (HIP) defines a This document does not specify any rendezvous or proxy services.
mechanism that decouples the transport layer from the internetworking Those are subject to other specifications . Hence, this document
layer, and introduces a new Host Identity namespace. When a host alone does not necessarily allow two mobile hosts to communicate,
uses HIP, the transport layer sockets and IPsec Security Associations unless they have other means for initial rendezvous and solving the
are not bound to IP addresses but to Host Identifiers. This document simultaneous movement problem.
specifies how the mapping from Host Identifiers to IP addresses can
be extended from a static one-to-one mapping into a dynamic
one-to-many mapping. This enables end-host mobility and
multi-homing. Additionally, this document introduces the concept of
Forwarding Agents. A Forwarding Agents provides Mobile IP Home Agent
like functionality for HIP enabled mobility.
In practice, the HIP base exchange creates a pair of IPsec Security The Host Identity Protocol [3] (HIP) defines a mechanism that
Associations (SA) between any communicating pair of HIP enabled decouples the transport layer (TCP, UDP, etc) from the
nodes. These SAs are not bound to IP addresses but to Host internetworking layer (IPv4 and IPv6), and introduces a new Host
Identifiers (public keys). However, the hosts must also know at Identity namespace. When a host uses HIP, the transport layer sockets
least one IP address where their peers are reachable. Initially this and IPsec Security Associations are not bound to IP addresses but to
IP address is the one used during the HIP base exchange. Host Identifiers. This document specifies how the mapping from Host
Identifiers to IP addresses can be extended from a static one-to-one
mapping into a dynamic one-to-many mapping, thereby enabling end-host
mobility and multi-homing.
Since the SAs are not bound to IP addresses, the nodes are able to In practice, the HIP base exchange [3]creates a pair of IPsec
receive IPsec protected HIP packets from any address. Thus, a node Security Associations (SA) between a pair of HIP enabled hosts.
can change its IP address and continue to send packets to its peers. These SAs are not bound to IP addresses, but to the Host Identifiers
However, the peers are not able to send replies before they can (public keys) used to create them. However, the hosts must also know
reliably and securely update the sending node's address(es). at least one IP address where their peers are reachable. Initially
these IP addresses are the ones used during the HIP base exchange.
This document specifies a mechanism that allow a HIP node to update Since the SAs are not bound to IP addresses, the host are able to
its address(es) to its peers. The address update is implemented with receive packets that protected using a HIP created ESP SA from any
a new HIP packet type, the HIP Readdress (REA) packet. Due to the address. Thus, a host can change its IP address and continue to send
danger of flooding attacks (see [4]), the peer must always check the packets to its peers. However, the peers are not able to replys
reachability of the node before it can use the new addresses. The before they can reliably and securely update the set of addresses
reachability check is implemented with a pair of new HIP packet that they associate with the sending host.
types, HIP Address Check (AC) and HIP Address Check Reply (ACR). In
addition to initiating and reachbility check, an AC packet may also This document specifies a mechanism that allows a HIP host to update
act as an acknowledgement for a preceding REA packet. the set of addresses that its peers associate with it. The address
update is implemented with new HIP parameter types. Due to the danger
of flooding attacks (see [4]), the peers must always check the
reachability of the host at a new address before it can use the new
addresses. The reachability check is implemented by the challenger
creating a new SPI, announcing the new SPI, and waiting for traffic
on the new SPI. In addition to initiating the reachability check,
announcing the new SPI also acts as an acknowledgement for a
preceding address change.
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 node, location privacy, end-host and initial reachability of a mobile host, location privacy, end-host and
site multi-homing with legacy hosts, and NAT traversal. In these site multi-homing with legacy hosts, and 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. In this document we describe mechanisms for initial network. This document does not address those needs.
reachability, multi-homing, recovering from simultaneous movements,
and combining mobility and multi-homing. Some of these functions
require an additional node in the network, which has been given the
name of Forwarding Agent. As a special case, a Forwarding Agent can
act as a lightweight Rendezvous server as defined in [3].
2. Conventions used in this document 2. Conventions used in this document
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 RFC2119 [1]. document are to be interpreted as described in RFC2119 [1].
3. Usage scenarios 3. Terminology
Preferred address An address that a host prefers to receive data.
New preferred address A new preferred address sent by a host to its
peers. The reachability of the new preferred address often needs
to be verified before it can be taken into use. Consequently,
there may simultaneously be an active preferred address, being
used, and a new preferred address, whose reachability is being
verified.
Interface A logical concept used to group IP addresses together. If a
host announces multiple interface, each interface will be
associated with a different incoming Security Association.
4. Usage scenarios
In this section we briefly introduce a number of usage scenarios In this section we briefly introduce a number of usage scenarios
where the HIP mobility and multi-homing facility is useful. To where the HIP mobility and multi-homing facility is useful. To
understand these usage scenarios, the reader should be at least understand these usage scenarios, the reader should be at least
minimally familiar with the HIP protocol specification [3]. However, minimally familiar with the HIP protocol specification [3]. However,
for the (relatively) uninitiated reader it is most important to keep for the (relatively) uninitiated reader it is most important to keep
in mind that in HIP the actual payload traffic is protected with ESP, in mind that in HIP the actual payload traffic is protected with ESP,
and that the ESP SPI acts as an index to the right host-to-host and that the ESP SPI acts as an index to the right host-to-host
context. context.
3.1 End-host mobility 4.1 End-host mobility
A mobile IP host must change its IP address according to A mobile IP host must change its IP address according to
connectivity. The change of an IP address might be needed due to a connectivity. The change of an IP address might be needed due to a
change in the advertised IPv6 prefixes on the link, a reconnected PPP change in the advertised IPv6 prefixes on the link, a reconnected PPP
link, a new DHCP lease, or an actual movement to another subnet. In link, a new DHCP lease, or an actual movement to another subnet. In
order to maintain its communication context, the host must inform its order to maintain its communication context, the host must inform its
peers about the new IP address. peers about the new IP address.
Although HIP enables ESP and the upper layer to be independent of the Although HIP enables ESP and the upper layer to be independent of the
internetworking layer, there still needs to be a mapping of the internetworking layer, there still needs to be a mapping of the
pseudo-IP addresses used in the upper stack (LSI and HIT) to a real pseudo-IP addresses used in the upper stack (LSI and HIT) to a real
IP address. Thus, from the functional point of view, it is IP address. Thus, from the functional point of view, it is
sufficient that the peer nodes learn the new IP address. The upper sufficient that the peer host learn the new IP address. The upper
layer protocols need to know about the address and connectivity layer protocols need to know about the address and connectivity
change only for QoS and similar purposes. In most cases, they need change only for QoS and other similar purposes. In most cases, they
not to know. do not need to know.
3.2 Location privacy
To protect its privacy, an IP host may want to keep its actual IP
address private. Since HIP insulates the upper layer from the IP
address, this can be accomplished by simple address rewriting at an
privacy protecting node.
Note that a mobile node may want to keep its location private. In
that case, it informs its real address to the privacy protecting node
and not to the actual peers.
Full location privacy falls beyond this document.
3.3 End-host multi-homing 4.2 End-host multi-homing
A host may have multiple interfaces, and it is desired that it can A host may have multiple interfaces, and it is desirable that it can
stay reachable through all of the currently available interfaces. It stay reachable through all or any subset of the currently available
is expected that the set of available interfaces may change interfaces. It is expected that the set of available interfaces may
dynamically, and that there may be policies associated with the usage change dynamically, and that there may be policies associated with
of the different interfaces. For instance, the host may have a fast the usage of the different interfaces. For instance, the host may
but low range wireless interface and a slow high range interface. have a fast but low range wireless interface and a slow high range
The host may generally prefer to use the fast interface, but it may interface. The host may generally prefer to use the fast interface,
be available only some of the time. but it may not be always available.
Note that a host may be multi-homed and mobile simultaneously, and Note that a host may be multi-homed and mobile simultaneously, and
that a multi-homed host may want to protect the location of some of that a multi-homed host may want to protect the location of some of
its interface while revealing the IP address of some others. its interfaces while revealing the real IP address of some others.
3.4 Site multi-homing 4.3 Site multi-homing
A host may have an interface that has multiple globally reachable IP A host may have an interface that has multiple globally reachable IP
addresses. Such a situation may be a result of the site having addresses. Such a situation may be a result of the site having
multiple upper Internet Service Providers, or just because the site multiple upper Internet Service Providers, or just because the site
provides all nodes with both IPv4 and IPv6 addresses. It is provides all host with both IPv4 and IPv6 addresses. It is desirable
desirable that the host can stay reachable with all currently that the host can stay reachable with all or any subset of the
available globally routable addresses, independent on how they are currently available globally routable addresses, independent on how
provided. they are provided.
Note that a single interface may experience site multi-homing while Note that a single interface may experience site multi-homing while
the host itself may have multiple interfaces. the host itself may have multiple interfaces.
3.5 Combined mobility and multi-homing 4.4 Combined mobility and multi-homing
It looks likely that in the future many of the mobile nodes will be It looks likely that in the future many mobile hosts will be
simultaneously mobile and multi-homing, i.e., have multiple mobile simultaneously mobile and multi-homed, i.e., have multiple mobile
interfaces. Furthermore, if the interfaces use different access interfaces. Furthermore, if the interfaces use different access
technology, it is fairly likely that one of the interfaces may appear technologies, it is fairly likely that one of the interfaces may
stable (retain its current IP address) while some other(s) may appear stable (retain its current IP address) while some other(s) may
experience mobility (undergo IP address change). experience mobility (undergo IP address change).
3.6 Network renumbering 4.5 Network renumbering
It is expected that IPv6 networks will be renumbered much more often It is expected that IPv6 networks will be renumbered much more often
than most IPv4 networks are. From an end-host point of view, network than most IPv4 networks are. From an end-host point of view, network
renumber is similar to mobility. renumber is similar to mobility.
3.7 Combined all 5. Overview of HIP basic mobility and multi-homing functionality
It is desirable that a host may simultaneously have multiple active
interfaces, be mobile (on any or all of its interfaces), utilize
multiple globally reachable addresses (on any or all of its
interfaces), and protect its location privacy (on any or all of its
interfaces).
4. Overview of HIP mobility and multi-homing functionality
HIP mobility and multi-homing is fundamentally based on the HIP HIP mobility and multi-homing is fundamentally based on the HIP
architecture [4], where the transport and internetworking layers are architecture [4], where the transport and internetworking layers are
insulated from each other with the new host identity layer. In the insulated from each other with the new host identity protocol layer.
HIP architecure, the transport layer sockets are bound to the Host In the HIP architecture, the transport layer sockets are bound to the
Identifiers (through HIT or LSI in the case of legacy APIs), and the Host Identifiers (through HIT or LSI in the case of legacy APIs), and
Host Identifiers are translated to the actual IP address. the Host Identifiers are translated to the actual IP address.
In the base HIP protocol specification [3], it is defined how two In the HIP base protocol specification [3], it is defined how two
hosts exchange their Host Identifiers and establish a pair of ESP hosts exchange their Host Identifiers and establish a pair of ESP
Security Associations (SA). The ESP SAs are then used to carry the Security Associations (SA). The ESP SAs are then used to carry the
actual payload data between the two hosts, by wrapping TCP, UDP, and actual payload data between the two hosts, by wrapping TCP, UDP, and
other upper layer headers into transport mode ESP payloads. The IP other upper layer packets into transport mode ESP payloads. The IP
header, carrying the ESP header, uses actual IP addresses in the header, carrying the ESP header, uses the actual IP addresses in the
network. network.
In the base specification, hosts use the same IP addresses for nodes The base specification does not contain any mechanisms for changing
that were used during the base HIP exchange. This specification the IP addresses that were used during the base HIP exchange. Hence,
defines the way how IP addresses can be changed during the in order to remain connected any systems that implement only the
communication. space specification and nothing else must retain the ability to
receive packets at their primary IP address; that is, those systems
4.1 IP addresses assigned to a node cannot change the IP address they are using without causing loss of
connectivity.
A host can have multiple IP addresses. It may have many interfaces
that are assigned IP addresses or it may have multiple addresses
assigned to one interface. There may also be multiple IP addresses in
function of time: the node may changes its topological location in
the network, or its network may change addresses.
The interfaces are logical objects. A host may claim to have any 5.1 Informing the peer about multiple or changed address(es)
number of interfaces, as long as a single IP address does not appear
to be bound to more than one interface. The purpose of the
interfaces is to group the addresses into collections that are likely
to experience fate sharing. For example, if the host needs to change
its addresses on interface2, it is likely that both address21 and
address22 will simultaneously become obsolete.
4.2 Informing the peer about multiple or changed address(es) This document specifies a new HIP protocol parameter, the REA
parameter (see Section 7.1), that allows the hosts to exchange
information about their IP address(es), and any changes in their
address(es). The logical structure created with REA parameters has
three levels: hosts, interfaces, and addresses. This is illustrated
in Figure 1.
To be able to use effectively multiple addresses assigned to the host address11
and update addresses that change during the communication with /
another node, a HIP protocol packet, the REA packet (see Section interface1 - address12
6.1.1), is specified. The logical structure created with REA packets /
has three levels: hosts, interfaces, and addresses. This is / address21
illustrated in Figure 1. host -- interface2 <
\ address22
\
interface3 - address31
\
address32
address11 Figure 1
/ In this document, the interfaces are considered to be logical
interface1 - address12 objects. A host may claim to have any number of interfaces. The
/ purpose of the interfaces is to group the addresses into collections
/ address21 that are likely to experience fate sharing. For example, if the host
host -- interface2 < needs to change its addresses on interface2, it is likely that both
\ address22 address21 and address22 will simultaneously become obsolete. Note,
\ however, that especially in the case of site multi-homing one of the
interface3 - address31 addresses may become unreachablewhile the other one still works. In
\ the typical case, however, this does not require the host to inform
address32 its peers about the situation, since even the non-working address
still logically exists.
Figure 1 All addresses on a single interface share an SA. Each interface has
its own SA. In the usual case, the latencies experienced on distinct
interfaces may be considerably different. Hence, if multiple
interfaces were to share an SA, it would become fairly likely that
some of the packets would be discarded due to appearing to have been
received outside of the ESP reordering window.
A single REA payload handles only one interface. To signal While it would be possible to share an SA between multiple
simultaneously changes on several interfaces, it is necessary to send interfaces, there would be no benefit from it. As the interfaces are
several consequtive REA payloads. The packet structure supports logical objects, and as the hosts are free to create new interface as
this. demand and to move addresses between interfaces as they will, a
conforming host may claim that two physical interfaces are in fact
one logical one, thereby allowing the two interfaces to share an SA.
4.3 Address verification An address may appear on more than one interface. This creates no
ambiguity since each interface must have a different SPI, and since
the receiver will ignore the IP addresses anyway.
When a HIP host receives a group of IP addresses from another HIP A single REA parameter contains data only about one interface. To
host in a REA, it does not necessarily know for sure whether the signal simultaneously changes on several interfaces, it is necessary
other host is actually reachable at the claimed addresses. In fact, to send several REA parameters. The packet structure supports this.
if the other HIP host is not fully trusted, it may be giving a bogus
address with the intention of causing packet flood towards the given
address [8]. Thus, before the HIP host can actually use a new
address, it must first check that the peer is reachable at the new
address. This is implemented with the HIP Address Check (AC) and
Address Check Reply (ACR) packets.
To acknowledge that it has received the REA, and to initiate an If the REA parameter is send in a NES packet and the sender wants to
address check, the HIP host receiving a REA immediately sends an AC receive an acknowledgement, it must explicitly indicate so.
to all addresses mentioned in the REA. Otherwise the recipient of the REA parameter may consider the REA as
informational, and act only when it needs to activate a new address.
In a typical implementation, an address consists of the actual 5.2 Address verification
bitpattern used in the IP source and destination fields, a lifetime,
and a status. The status is used to track the reachability of the
address.
4.4 Forwarding Agents When a HIP host receives a group of IP addresses from another HIP
host in a REA, it does not necessarily know whether the other host is
actually reachable at the claimed addresses. In fact, a
maliciouspeer host may be intentionally giving a bogus addresses in
order to cause a packet flood towards the given address [7]. Thus,
before the HIP host can actually use a new address, it must first
check that the peer is reachable at the new address. This is
implemented by requesting the peer to create a new outgoing SA, using
a new random SPI value, and waiting for data to appear on this new
SA.
For nodes that are mobile, an IP address from where it can be reached 5.3 Address data structure and status
is necessary if the node wants to be reachable by other nodes. The
Forwarding Agent provides one possible solution to this. The
reachability of the HIP node may require usage of both IPv6 and IPv4.
If the HIP node itself is behind a network that supports only one of
the IP protocol versions, the HIP node may use the FA for acting as a
gateway when the peer node wants to use a IP protocol version that
the HIP node behind the FA does not directly support.
The HIP node can "lease" IP address(es) from the FA if it needs an In a typical implementation, each remote address is represented as a
address from where it can be reached. This can be the case, for piece of state that contains the following data:
example, when a mobile node needs a contact address for peer nodes.
The HIP node contacts the FA, requests for an IP address (and SPI
range), and start announcing the IP address (and some SPI) to its
peers. The SPI is required if the IP address leased from the FA is
not unique, i.e. it does not map one-to-one to the HIT of the HIP
node. Further ESP protected data packets arriving to the FA can thus
be identified using the SPI value and verifying to which HIP node
that particular SPI has been reserved.
As long as the "lease" is valid, the FA will forward any packets sent the actual bit pattern representing the IPv4 or IPv6 address,
to the IP address (and an SPI within the range) to the HIP host. The
basic operational model is depicted in Figure 2. Without mobility
(REA), using a FA results in triangular routing, as shown.
+----------+ +--------------+ lifetime (seconds),
| HIP host |---------------------------->| Another host |
+----------+ +--------------+
^ real IP address |
| |
| |
+----------+ leased IP address |
| FA |<------------------------------------+
+----------+
Figure 2 status (UNVERIFIED, ACTIVE, DEPRECATED).
The actual method of discovering FAs is beyond the scope of this The status is used to track the reachability of the address:
document, and will be specified elsewhere.
4.4.1 Address leases from an Forwarding Agent UNVERIFIED indicates that the reachability of the address has not
been checked yet,
To acquire an address lease from a given FA, the HIP host sends a ACTIVE indicates that the reachability of the address has been
Forwarding Agent Query (FAQ) packet to it. In some cases, the FAQ checked and the address has not been deprecated,
may be sent as a broadcast or multicast packet; the details of such
practice will be specified elsewhere. The HIP host may use any
identity it wishes; however, the identity may be subject to local
access control by the FA. That is, some FAs may be willing to serve
only some HIP hosts.
If the FA is willing to serve an address to the HIP host, it replies DEPRECATED indicates that the address lifetime has expired
to the FAQ with a Forwarding Agent Advice (FAA) packet. A FAA
establishes an address lease to the HIP host. The HIP host can rely
on the FA to keep forwarding packets to the HIP host until the
address lease expires. If the FA is not willing to serve the HIP
host, it responds with a Forwarding Agent Denied (FAD) packet,
specifying the reason for denial.
Each address lease has a lifetime. The HIP host may renew the The following state changes are allowed:
address lease at any time before it the lease expires. Subject to
its policy, the FA should renew and extend the lease, but it MAY
refuse any extensions. In any case, it must not reduce the lease
lifetime making it to expire prior to the initial expiration time.
The HIP host may abandon the lease at any time, either by failing to UNVERIFIED to ACTIVE The reachability procedure completes
renew it or by sending an Forwarding Agent Query that specifies a succesfully.
zero lifetime. If an address lease expires without having been
renewed, the FA simply discards the forwarding state and any
resources associated with it.
4.4.2 Recovering from forwarding agent crashes UNVERIFIED to DEPRECATED The address lifetime expires while it is
UNVERIFIED.
If a FA crashes, it looses its state. Consequently, it cannot ACTIVE to DEPRECATED The address lifetime expires while it is ACTIVE.
forward packets sent to it, since it does not know the IP address
associated with the leased address (and the SPI). The only thing the
forwarding agent could do would be to simulate lost state by the
actual HIP host that is leasing the address. However, since the
crashed FA does not know the HIT of the host, it cannot do that.
Effectively, the forwarding agent becomes a black hole until the HIP
host recognizes the situation and ackquires a new lease.
It is currently an open problem whether a crashed FA should send some ACTIVE to UNVERIFIED There has been no traffic on the address for
kind of error message to the hosts sending ESP packets to it. some time, and the local policy mandates that the address
reachability must be verified again before starting to use it
again.
4.5 Security Associations DEPRECATED to UNVERIFIED The host receives a new lifetime for the
address.
The security associations between the nodes are not any longer A DEPRECATED address MUST NOT be changed to ACTIVE without first
directly connected to the IP address of the node. The SA is verifying its reachability.
associated with the HIT and there may be either one SA between the
nodes, or multiple SAs when the interface capabilities require such
an arrangement.
All addresses on a single interface share an SA. Multiple interfaces 6. Protocol overview
may share a single SA, but each interface may also have its own SA.
In practice, multiple interfaces may share an SA if the experienced
latency is fairly similar, in which case the packets are received
within the IPsec reordering window. However, the latencies between
two interfaces are considerably different, it becomes more likely
that some of the packets would be discarded due to appearing to have
been received outside of the ESP reordering window. Thus, in that
case it is necessary to use different SAs for different interfaces.
5. Protocol overview The readdressing protocol is designed to be piggybacked on a number
of existing HIP exchanges. The main packets on which the REA
parameters are expected to be carried on are New SPI (NES) packets.
However, some implementations may want to experiment with sending REA
parameters also on other packets, such as R1 and I2.
The HIP mobility and multi-homing functionality consist of the The protocol is an asymmetric protcool where one host, called the
following subprotocols: Mobile Host, informs another host, called the Peer host, about
changes of IP addresses on one of its interfaces. The protocol
consists of three steps, illustrated in Figure 2.
Acquiring an address lease from a Forwarding Agent 1. The Mobile Host sends a REA parameter to the Peer host.
Renewing an address lease 2. The Peer Host initiates an address check procedure by sending a
new SPI value to a new address. Any packet that contains a new
SPI may be used, including NES, I2 and R2. The new SPI value
MUST be random, i.e., the Mobile Host MUST NOT be able to guess
it. When the Mobile Host receives the new SPI value, it creates
a new outgoing SA and starts sending data on it.
Informing peers about multiple addresses or address changes, and 3. The Peer Host waits for new data to arrive on the new SA,
verifying the reachability of addresses indicated by the SPI. Once it has succesfully received data on
the SA, it marks the new address as reachable.
5.1 Acquiring an address lease from a Forwarding Agent Mobile host Peer host
HIP host Forwarding Agent REA parameter
Forwarding Agent Query
-----------------------------------> ----------------------------------->
R1 new SPI
<----------------------------------- <-----------------------------------
Forwarding Agent Query data on new SA
-----------------------------------> ----------------------------------->
Forwarding Agent Advice Figure 2
<-----------------------------------
To acquire an address lease, the HIP host sends an FAQ, requesting The idea of the address check procedure is that if the Mobile Host is
for an address lease. The host may specify the type of address it able to succesfully construct the new outgoing SA, using the new SPI
wants to have (IPv4, IPv6, either), the number of SPIs requested, and value, and send data on that SA, then it must have received the
the desired lifetime. Any of these fields may be left empty, as second message in the protocol, and therefore it must be reachable at
well. The FAQ is always signed. the said address.
If the Forwarding agent does not trust the HIP host, it may answer XXX: Residual threat: The Mobile Host able to anticipate the KEY
with an R1, basically asking the HIP host to solve a puzzle before index and guess the SPI value by trying out all? Not really, I
the Forwarding Agent is even willing to consider the request. Once think, since it would require about 2^31 packets on the average...
the HIP host has solved the puzzle, it may send the FAQ again, this
time including an answer to the puzzle.
XXX: Is it OK that the FA answers with a normal R1, or should we use 6.1 Initiating the protocol in NES
some other packet type, e.g., Forwarding Agent R1 (FAR1)?
If the FA is willing to serve the HIP host, it answers with an FAA, The most common case is to carry the readdress protocol on NES
specifying the leased IP address, its lifetime, and if the address is packets. In this case, the Mobile Host initiates rekey (usually
an IPv4 address, a range of SPIs that has been reserved for the HIP using the current Diffie-Hellman keys) and includes a REA parameter
host. on the initial NES packet. The Peer host replies to this with a
reply NES packet, sent to the new preferred address. As the Mobile
Host receives the reply NES, it starts using the new outgoing SA.
Finally, as the Peer Host receives traffic on the new incoming SA, it
marks the new address as valid and switches over to use the new
outgoing SA, associated with the new address.
5.2 Renewing an address lease Mobile host Peer host
Once an address lease is about to expire, the HIP host may want to NES with REA
renew it. ----------------------------------->
record additional addresses
(prepare new incoming SA)
NES with new SPI in NES_INFO
<-----------------------------------
(prepare new incoming SA)
(switch to new outgoing SA)
HIP host Forwarding Agent data on new SA
----------------------------------->
(switch to new outgoing SA)
change preferred address
Forwarding Agent Query The text in (parantheses) indicate functions that are
-----------------------------------> performed anyway, as a part of NES processing, and not
new to the REA processing.
Forwarding Agent Advice Figure 3
<-----------------------------------
To renew a lease, the HIP host simply sends a FAQ specifying an Basically, the processing structure is equal to the current NES
existing lease, together with the desired extended lease time, and processing other than that the Peer host records the additional
the FA replies with an FAA. addresses form the REA parameter, sends the NES reply to the new
preferred address instead of the current preferred address, and
updates the preferred address as soon as it receives data on the new
SA.
5.3 Readdressing and address status 6.2 Initiating the protocol in R1 or I2
HIP host Another host A Responder host MAY include one or more REA parameters in the R1
packet that it sends to the Initiator. These parameters MUST be
protected by the R1 signature. If the R1 packet contains REA
parameters, the Initiator SHOULD send the I2 packet to the new
preferred address. The Responder MUST make sure that the puzzle
solution is valid BOTH for the initial IP destination address used
for I1 and for the new preferred address. The I1 destination address
and the new preferred address may be identical.
REA Initiator Responder
----------------------------------->
AC R1 with REA
<----------------------------------- <-----------------------------------
record additional addresses
change responder address
ACR I2 with new SPI in SPI_LSI
-----------------------------------> ----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally)
When the host changes its IP address, gets more addresses or loses an Figure 4
address, it may want to tell this change to peer nodes. The address
changing host sends the readdress packet (REA) to the peer where it
tells all available addresses. The address update packet is signed
providing proof about the sending party.
As the node receiving a REA packet cannot be sure if all the received XXX: What about R1 source address? Most probably we want to allow it
addresses are valid even the signature is correct, it sends the to be any address to allow an optimized rendezvous server to send an
Address Check (AC) packet to each of the new addresses received. If R1 instead of the actual host?
the host receiving an AC message has sent the REA message that
matches the received AC message, it MUST send an Address Check Reply
(ACR) packet back to the peer for confirmation. New addresses
received in the REA packet are ready to be used after the ACR packet
has been received.
If a node receives an AC packet that does not match to any REA packet An Initiator MAY include one or more REA parameters in the I2 packet,
that is has sent out, it MUST drop the packet. Such a packet may be independent on whether there was REA parameter(s) in the R1 or not.
an indication that someone else is on purpose or on mistake sending a These parameters MUST be protected by the I2 signature. Even if the
false address to its peer. I2 packet contains REA parameters, the Responder MUST still send the
R2 packet to the source address of the I2. The new preferred address
SHOULD be identical to the I2 source address.
6. Protocol definition Initiator Responder
The location information update procedure in the HIP consists of the I2 with REA
readdress packet telling the current set of addresses that the node ----------------------------------->
is using, address check and address check replies. With this set of (process normally)
messages the IP addresses can be updated to the peer and the peer is record additional addresses
able to verify that the addresses are valid. R2 with new SPI in LSI_SPI
<-----------------------------------
(process normally)
In addition to the actual address update, the HIP node is provided a data on new SA
possibility to get leased addresses from the FA. The FA can provide ------------------------------------>
address(es) (and a range of SPIs) for the HIP node and the HIP node (process normally)
can use this towards other nodes. The FA thus forwards packets to the
HIP node when it receives packets sent to the leased address.
6.1 Packet formats Figure 5
6.1.1 REA - the HIP readdress packet 6.3 Explicit address check
A HIP readressing packet consists of one or more of REA_INFO When the Peer Host wants to use a new address that has not yet been
payloads, followed by a signature (HIP_SIGNATURE) and a HMAC. The checked, it must first run check the reachability of the address
purpose of the signature is to allow middleboxes to verify the before sending any large amounts of data to the address. See Section
integrity of the packet. The HMAC allows the peer node to verify the 8.3.
packet very fast.
Intermediate systems that use the SPI will have to inspect ALL HIP 7. Parameter and packet formats
packets for a REA packet. This is a potential DoS attack against the
Intermediate system, as the signature processing may be relatively
expensive. A further step against attack for the Intermediate
systems is to implement ESP's replay protection of windowing the
sequence number. This requires the intermediate system to track ALL
ESP packets to follow the Sequence Number.
Optionally, the message may contain an ESP protected datagram. This 7.1 REA parameter
datagram is processed as if it had arrived separately. The purpose
of allowing datagrams to be embedded inside the REA packet is to
increase the efficiency of transmitting the first data packet, as
only one IPv6 header is required.
XXX Note (by Jari Arkko): I don't believe that this is a significant 0 1 2 3
function. In fact, header compression on links is probably more 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
efficient than this (the effect could be negative), and there might +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
be some problems that this causes. I don't think it causes the same | Type | Length |
type of problems that piggybacking caused in Mobile IPv6, however, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
because the packet is always encrypted, hence it could not receive |P| Reserved | Interface ID |
different treatment at the firewalls etc. But I'm not 100% sure that +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
there are no other problems. | Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.1.1 REA_INFO payload Type 1 (first non-critical)
Note that the REA_INFO payload is a kind of "expanded" NES. Length Length in octets, excluding Type and Length fields.
XXX (Pekka): Note that I have, for the time being, removed the old P Preferred address. The first address in this REA is the new
ESP sequence number. Firstly, it may be hard to acquire reliably in preferred address.
some implemtations (ours included). Secondly, we now have a REA ID
field, which is basically a REA sequence number.
0 1 2 3 Reserved Zero when sent, ignored when received.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface ID Interface ID, as defined by the sending host. The
| Type | Length | interface IDs may have any values, and need not be consequtively
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ allocated.
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Lifetime Address lifetime, in seconds.
| Current SPI in reverse direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Zero when sent, ignored when received.
| Current SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address [2].
| New SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keymaterial index | REA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 128
Length Length in octets, excluding Type and Length
fields
Interface ID Interface ID, as defined by the sending host
Current SPI rev. The current SPI used in the reverse direction
Current SPI The current SPI used for receiving ESP on this
interface
New SPI The new SPI used for receiving ESP on this
interface
Keymaterial index A bit index to the KEYMAT, where to pick up
the keying material for the new SA.
REA ID A 16-bit sequence number of nonce, used to
match the REA packet to the corresponding AC
packet.
Address Lifetime Address lifetime
Reserved Zero when sent, ignored when received
Address An IPv6 address or an IPv4-in-IPv6 format
IPv4 address
[2]
The Interface ID field identifies the (logical) interface that this The Interface ID field identifies the (logical) interface that this
packet applies to. It is implicitly qualified by the Host Identity parameter applies to. It is implicitly qualified by the Host
of the sending host. The Interface ID groups a set of addresses to Identity of the sending host. The Interface ID groups a set of
an interface. The purpose of the Interface ID is to allow a addresses to an interface. The sending host is free to introduce new
knowledgeable peer to interact with the sender. For example, the interface IDs at will. That is, if a received REA has a new
sender could be informing its peer that that an interface has both an interface ID, it means that all the old addresses, assigned to the
IPv4 address and one or more IPv6 addresses. other interface IDs, are also supposed to still work, while the new
addresses in the newly received REA are supposed to be associated
with a new interface. On the other hand, if a received REA has an
interface ID that the receiver already knows about, it would replace
(all) the address(es) currently associated with the interface with
the new one(s).
The sending host is free to introduce interface IDs at will. That is, The Address Lifetime indicates how long the following address is
if a received REA has a new interface ID, it means that all the old expected to be valid. The lifetime is expressed in seconds. Each
addresses, assigned to other interface IDs, are also supposed to address MUST have a non-zero lifetime. The address is expected to
still work, while the new addresses in the REA are supposed to be become deprecated when the specified number of seconds has passed
associated with a new interface. On the other hand, if a received since the reception of the message. A deprecated address SHOULD NOT
REA has an interface ID that the receiver already knows about, it be used as an destination address if an alternate (non-deprecated) is
would replace (all) the address(es) currently associated with the available and has sufficient scope. Since IP addresses are ignored
interface with the new one(s). upon reception, deprecation status does not have any affect on the
receiver.
If the SA is changed, and if the SA is not used at any other The Address field contains an IPv6 address, or an IPv4 address in the
interface any more, it MUST NOT be deleted until all ESP packets with IPv4-in-IPv6 format [2]. The latter format denotes a plain IPv4
a lower Sequence Number have been received and processed, or a address that can be used to reach the Mobile Host.
reasonable time has elapsed (to account for lost packets).
6.1.1.2 HMAC 7.2 Modified NES_INFO parameter
The HMAC SHA-1 is used to verify a received packet. The NES_INFO parameter is defined in the base specification [3]. The
R-bit is defined to indicate wheter a NES is a reply to another NES
or not. If a NES is not a reply, the receiver must reply. If a NES
is an unexpected reply, the packet is simply dropped.
0 1 2 3 This specification changes the semantics of the R-bit slightly. (It
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 is expected that this change may be later incorporated to the base
specification.) The new semantics of the R-bit are defined as
follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R Zero if the sender is requesting an explicit
| Type | Length | NES_INFO as a reply, one if no reply is needed.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ HMAC data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65532 Processing NES packets currently defines the following behaviour.
Length Length in octets, excluding Type and Length fields
HMAC data 20 bytes of HMAC SHA-1 data
6.1.2 AC and ACR - the HIP Address Check and Address Check Reply If the system is in state E3 and the NES has the R-bit set, the
packet is silently dropped.
The HIP Address Check (AC) and Address Check Reply (ACR) packets The new behaviour is defined as follows.
contain an AC_INFO payload, followed by a HMAC.
In addition to acting as an address probe, the Address Check packet If the system is in state E3 and the NES_INFO has the R-bit set,
may also acts as an implicit acknowledgement to a REA packet. the system initiates unidirectional rekeying, as defined in
Section 8.3.
6.1.2.1 AC_INFO payload 7.3 NES packet with included REA
0 1 2 3 A single REA is included in a NES packet between the NES_INFO and
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 HMAC parameters:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID | REA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 129 IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
Length Length in octets, excluding Type and Length
fields
AC ID A 16-bit sequence number of nonce, used to match
the AC packet to the corresponding ACR packet.
REA ID A 16-bit sequence number of nonce, used to match
the REA packet to the corresponding AC packet.
RTT timestamp A timestamp field which may be used for RTT
estimation
Reserved Zero when sent, ignored when received
6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets If there are multiple REA parameters to be sent in a single NES, each
of them must be matched with a NES_INFO parameter:
The HIP FAQ, FAA and FAD packets contain an FA_INFO payload, and IP ( HIP ( REA1, REA2, NES_INFO1, NES_INFO2, [ DH, ] ... ) )
possibly other payloads. If a forwarding agent sends an R1 in
response to FAQ, the second FAQ must also contain an BIRTHDAY_COOKIE
payload, containing the cookie response. The FAA, and FAD packets
MUST contain a HOST_ID or HOST_ID_FQDN payload. The FAA packet MAY
contain a HOST_ID or HOST_ID_FQDN payload.
6.1.3.1 FA_INFO payload 7.4 R1 and I2 packets with included REA
0 1 2 3 The REA parameter is included early in the R1 and I2 packets, since
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 middle boxes may be interested in inspecting them. If a REA is not
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ present, a typical middle box is only interested in the SPI_LSI
| Type | Length | parameter and the signature.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Lease ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Addr type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 address: IP ( HIP ( REA,
BIRTHDAY_COOKIE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
( HOST_ID | HOST_ID_FQDN ),
HIP_SIGNATURE_2 ) )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP ( HIP ( SPI_LSI,
| Min SPI | REA,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BIRTHDAY_COOKIE,
| Max SPI | DIFFIE_HELLMAN,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIP_TRANSFORM,
| IPv4 address | ESP_TRANSFORM,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ENCRYPTED { HOST_ID | HOST_ID_FQDN },
| Reserved | HIP_SIGNATURE ) )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 address: 8. Processing rules
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ XXX: This section needs more work.
| |
| IPv6 address (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 130 8.1 Sending REAs
Length Length in octets, excluding Type and Length
fields
Request ID A 16-bit sequence number of nonce, used to The decision of when to send REAs is basically a local policy issue.
match the FAQ packet to the corresponding However, it is RECOMMENDED that a host sends a REA whenever it
FAA/FAD packet. recognizes a change of its IP addresses, and assumes that the change
Lease ID A 16-bit number XXX is going to last at least for a few seconds. Rapidly sending
Lease duration Duration of the lease conflicting REAs SHOULD be avoided.
Reserved Zero when sent, ignored when received
Addr type Address type: 4 for IPv4 and 6 for IPv6 (TBD)
6.2 Requesting Address Leases When a host decided to inform its Peers about changes in its IP
addresses, it has to decide how to group the various addresses into
interfaces, and whether to include any addresses on multiple
interfaces. Since each interface is associated with a different
Security Association, the grouping policy may be based on IPsec
replay protection considerations. In the typical case, simply basing
the grouping on actual kernel level physical and logical interfaces
is often the best policy. Virtual interfaces, such as IPsec tunnel
interfaces or Mobile IP home addresses SHOULD NOT be announced.
To request address leases from the FA, the HIP node sends an FAQ Once the host has decided on the interfaces and assingment of
packet to the FA. The FAQ packet consists of the HIP header, FA_INFO addresses to the interfaces, it creates a REA parameter for each
payload and a HIP_SIGNATURE. If the FAQ packet is the second one sent interface. If there are multiple interfaces and therefore multiple
from the HIP node to the FA, i.e. the FA responded to the first FAQ parameters, the parameters MUST be ordered so that the new preferred
with an R1 packet, a BIRTHDAY_COOKIE payload containing the cookie address is in the first REA parameter.
response must be included in the packet.
6.3 Providing address Leases The REA parameters MAY be sent in R1, I2 and NES packets. If the
host does not have any other reason to send R1, I2 or NES, it should
generate a new initial NES, SHOULD NOT include any Diffie-Hellman
parameter to it, and send the REA parameters in the newly generated
NES packet.
When the FA receives an FAQ packet from a HIP node, it may verify the If there are multiple REA parameters leading to a packet size that
signature in the packet. If the FA does not trust on the requesting exceeds the MTU, the host SHOULD send multiple packets, each smaller
node, it may generate an R1 packet containing a puzzle for the than the MTU. In the case of R1 and I2, the additional packets
requesting HIP node. should be NES packets that are send after the base exchange has been
completed.
If the FA trusts to the requesting HIP node, or the HIP node 8.2 Handling received REAs
responded to the R1 packet with a new FAQ with a solved puzzle, the
FA can allocate address(es) and possibly SPIs for the requesting
node. The FA_INFO payload may contain information about the requested
addresses or the requested SPI ranges. If these requests can be met,
the FA may allocate address(es) and possible SPIs for the requesting
node.
If the allocation request was accepted and a successfull reservation A host SHOULD be prepared to receive REA parameters in any HIP
of data was performed, the FA responds to the requesting node with a packets, excluding I1.
FAA packet. The FAA consists of an FA_INFO payload describing the
address(es) and possible SPIs that are reserved for the requesting
node.
However, if the FA was not able to allocate address(es), SPIs or the When a host receives a REA parameter, it first performs the following
request was malformed, the FA responds with a FAD packet. operations:
6.4 Sending REAs 1. The host checks if the Interface ID listed is a new one. If it is
a new one, it creates a new logical interface that contains no
addresses.
The HIP node may want to send address information to the peer node 2. For each address listed in the REA parameter, check that the
whenever there are updates in the addresses that are assigned to it. address is a legal unicast or anycast address. That is, the
The leased addresses can be considered also to be possible addresses addres MUST NOT be a broadcast or multicast address. Note that
and they must be assigned to a logical interface. some implementations MAY accept addresses that indicate the local
host, since it may be allowed that the host runs HIP with itself.
The REA packet contains the HIP header, one or more REA_INFO, 3. For each address listed in the REA parameter, check if the
HIP_SIGNATURE and HMAC TLVs. The REA_INFO describes all the addresses address is already listed at the interface. If the address is
that are associated with that particular interface identifier. If a listed, its lifetime is updated. If the address is status is
previously associated address is not included in the list, the peer DEPRECATED, the status is changed to UNVERIFIED. if the address
considers it as a lost address and removes it from the address is not listed, the address is added, and its status is set to
associations. UNVERIFIED.
6.5 Handling received REAs at end hosts 4. Mark all addresses at the interface that were NOT listed in the
REA parameter as DEPRECATED.
When a HIP node receives a REA packet, it verifies the signature in As a result, the interface now contains any addresses listed in the
it. If the packet was valid, it may initiate an address check REA parameter either as UNVERIFIED or ACTIVE, and any old addresses
procedure. The address check (AC) packet is sent to all addresses not listed in the REA parameter as DEPRECATED.
that were listed in the REA_INFO payload. The HIP node receiving the
REA packet from a node that it trusts, may accept all addresses
without making any address check for them. If ACs are sent, the
addresses in the REA_INFO must not be used until corresponding ACR
packet is received from the peer node.
7. Policy considerations Once the host has updated the interface, if the REA parameter
contains a new preferred address, the host SHOULD initiate a change
of the preferred address. This usually requires that the host first
verifies reachability of the address, and only then changes the
address. See Section 8.4.
TBD 8.3 Verifying address reachability
8. Security Considerations A host MAY what to verify the reachability of any UNVERIFIED address
at any time. However, the exact method of verification depends on
whether the host will next send a packet that contains a new SPI
value or not. That is, if the host is replying to a R1 with an I2,
to an I2 with an R2, or to a initial NES with a reply NES, then the
verification is piggybacked on the I2, R2, or reply NES packet.
Otherwise the verification is initiated by sending an unidirectional
NES packet containing REA and NES_INFO parameters.
Any of the I2, R2, NES-reply or unidirectional-NES packets cause
either the creation or change of the outgoing SA in the Mobile Host.
Furthermore, as part of the process to send R2, NES-reply or
unidirectional-NES, the Peer Host MUST prepare a new incoming SA,
using the SPI value included in R2 or NES, so that it is prepared to
receive traffic on the new SA.
Note that in the case of receiving a REA on an R1 and replying with
an I2, receiving the corresponding R2 is sufficient for marking the
Responder's primary address active, and there is no need to wait for
data to appear on the SA. On the other hand, marking the address
active as a part of receiving data on the SA is an idempotent
operation, and does not cause any harm.
Mobile host Peer host
prepare incoming SA
new SPI in R2, or NES
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
8.4 Changing the preferred address
A host MAY want to change the preferred outgoing address for many
reasons, e.g., because traffic information or ICMP error messages
indicate that the currently used preferred address may have become
unreachable. Another reason is receiving a REA parameter that has
the P-bit set.
To change the preferred address, the host initiates the following
procedure:
1. If the new preferred address is not listed on any interface, the
procedure fails.
2. If the new preferred address has DEPRECATED status and there is
at least one non-depraceted address, the host selects one of the
non-deprecated addresses as a new preferred address and
continues.
3. If the new preferred address has ACTIVE status, the preferred
address is changed and the procedure succeeds.
4. If the new preferred address has UNVERIFIED status, the host
starts to verify its reachability. Once the verification has
succeeded, the preferred address change is completed, unless a
new change has been initiated in the mean while.
9. Policy considerations
XXX: This section needs to be written.
The host may change the status of unused ACTIVE addresses into
UNVERIFIED after a locally configured period if inactivity.
10. Security Considerations
XXX: This section requires lots of more work.
(Initial text by Jari Arkko): If not controlled in some manner, (Initial text by Jari Arkko): If not controlled in some manner,
messaging related to address changes would create the following types messaging related to address changes would create the following types
of vulnerabilities: of vulnerabilities:
Revealing the contents of the (cleartext) communications Revealing the contents of the (cleartext) communications
Hijacking communications and man-in-the-middle attacks Hijacking communications and man-in-the-middle attacks
Denial of service for the involved nodes, by disabling their Denial of service for the involved nodes, by disabling their
ability to receive the desired communications ability to receive the desired communications
Denial of service for third parties, by redirecting a large amount Denial of service for third parties, by redirecting a large amount
of traffic to them of traffic to them
Revealing the location of the nodes to other parties Revealing the location of the nodes to other parties
In HIP, communications are bound to the public keys of the end-points In HIP, communications are bound to the public keys of the end-points
and not to IP addresses. The REA message is signed with the sender's and not to IP addresses. The REA message is signed with the sender's
private key, and hence it becomes impossible to hijack the public key, and hence it becomes impossible to hijack the
communications of another node through the use of the REA message. communications of another host through the use of the REA message.
Similarly, since only the node itself can sign messages to move its Similarly, since only the host itself can sign messages to move its
traffic flows to a new IP address, denial of service attacks through traffic flows to a new IP address, denial of service attacks through
REA can not cause the traffic flows to be sent to an IP address that REA can not cause the traffic flows to be sent to an IP address that
the node did not wish to use. Finally, In HIP all communications are the host did not wish to use. Finally, In HIP all communications are
encrypted with ESP, so a hijack attempt would also be unable to encrypted with ESP, so a hijack attempt would also be unable to
reveal the contents of the communications. reveal the contents of the communications.
Malicous nodes that use HIP can, however, try to cause a denial of Malicious nodes that use HIP can, however, try to cause a denial of
service attack by establishing a high-volume traffic flow, such as a service attack by establishing a high-volume traffic flow, such as a
video stream, and then redirecting it to a victim. However, the video stream, and then redirecting it to a victim. However, the
return routability check provides some assurance that the given return routability check provides some assurance that the given
address is willing to accept the new traffic. Only attackers who are address is willing to accept the new traffic. Only attackers who are
on the path between the peer and the new address could respond to the on the path between the peer and the new address could respond to the
test. test.
8.1 Why does the foreign agent may require a puzzle solution? 11. IANA Considerations
12. Acknowledgments
In Section 5.1 it is stated that a foreign agent may pass a puzzle,
in an R1, to the HIP host if it does not trust the HIP host. This
protects the foreing agent from CPU consuming DoS attacks. If this
protection were not used, an attacker could send a stream of bogus
FAQ packets to the foreign agent, making it to spend all of its CPU
to verify signatures that might be full garbage.
8.2 Attacker masquerading as a FA
The ability for an attacker to masquerade as a forwarding agent
depends on how the HIP host locates forwarding agents. That, in
turn, falls beyond the scope of this document. However, if the HIP
host accepts services from unknown or untrusted forwarding agents, it
is taking a risk of getting a black hole or eavesdropped address.
The resulting attack is usually not very serious, though, since all
actual data traffic is protected with ESP, and the HIP packets are
signed. Thus, the worst an untrustworthy forwarding agent can do is
to blackhole the packets.
8.3 Location privacy
TBD
9. IANA Considerations
10. Acknowledgments
Thanks to Kimmo Nieminen.
Normative references Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[3] Nikander, P. and R. Moskowitz, "Host Identity Protocol", [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
draft-moskowitz-hip-06 (work in progress), May 2003. Protocol", draft-moskowitz-hip-07 (work in progress), June 2003.
[4] Moskowitz, R., "Host Identity Protocol Architecture", [4] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-03 (work in progress), May 2003. draft-moskowitz-hip-arch-03 (work in progress), May 2003.
Informative references Informative references
[5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998. [5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998.
[6] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security, [6] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Mobility, and Multi-Homing in a HIP Way", Network and
Distributed Systems Security Symposium (NDSS'03), February 6-7,
2003, San Diego, CA, pages 87-99, Internet Society, February
2003.
[7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", draft-iab-sec-cons-03 (work in Security Considerations", draft-iab-sec-cons-03 (work in
progress), February 2003. progress), February 2003.
[8] Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E. [7] Nikander, P., "Mobile IP version 6 Route Optimization Security
Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work
Design Background", draft-nikander-mobileip-v6-ro-sec-00 (work in progress), July 2003.
in progress), April 2003.
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
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
Jari Arkko Jari Arkko
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
JORVAS FIN-02420 JORVAS FIN-02420
FINLAND FINLAND
Phone: +358 9 299 1 Phone: +358 9 299 1
EMail: jari.arkko@nomadiclab.com EMail: jari.arkko@nomadiclab.com
Petri Jokela
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Appendix A. Site multi-homing
A site, connected to multiple transit providers, is considered to be
multi-homed. There is a possibility to send traffic using any of the
transit provider networks. A node, connected to a multi-homed site,
can experience this multi-homing from the received IP addresses.
A.1 A host connected to a multi-homed site
When a node connects to a multi-homed network, it may receive
multiple IP addresses on this connected interface. These addresses
can be either local IP addresses (behind a NAT) or public addresses.
A traditional node setting up a connection, selects one of the
available local addresses for this particular connection. This
address cannot be changed for the existing connection.
A HIP node experiencing similar site multi-homing is not limited to Appendix A. Changes from previous versions
the one source address selected during the connection set up. The
node has multiple IP addresses on one interface and the mapping
between the Host Identity - Interface - IP addresses is a mapping
from one to one to many. The used IP address can be changed while the
connection exists.
When configured multiple addresses to one interface, the node can
update this list of addresses to peer nodes. Thus, the different
transit providers can be used according to policies defined in the
node. The policies can be defined locally or they can be received by
other methods. (see policies, TBD)
A.2 Transit providers with NATs A.1 From -00 to -01
A transit provider may have NAT boxes in the network. The HIP node The actual protocol has been largely revised, based on the new
connected to a site that is further connected to a transit provider symmetric New SPI (NES) design adopted in the base protocol draft
using NATs, must get the knowledge about the NAT box between itself version -08. There are no more separate REA, AC or ACR packets, but
and the peer node. The address that the HIP node sends to the peer their functionality has been folded into the NES packet. At the same
node must be a public one, thus NATted address is not valid. time, it has become possible to send REA parameters in R1 and I2.
The NAT box on the path must support address (and SPI) leasing for The Forwarding Agent functionality was removed, since it looks like
the HIP node. When the HIP node finds out that there is a NAT box, that it will be moved to the proposed HIP Research Group. Hence,
the host must get a leased address (or a set of addresses) from the there will be two other documents related to that, a simple
NAT. These addresses are routable at the other side of the NAT. They Rendezvous server document (WG item) and a Forwarding Agent document
still need not to be globally routable as there may be another NAT (RG item).
box on the path.
Appendix B. Implementation experiences Appendix B. Implementation experiences
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
 End of changes. 155 change blocks. 
715 lines changed or deleted 629 lines changed or added

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