Network Working Group P. Nikander
Internet-Draft J. Arkko
Expires: December 16, 2003 P. Jokela
Ericsson Research Nomadic Lab
June 17, 2003
End-Host Mobility and Multi-Homing with Host Identity Protocol
draft-nikander-hip-mm-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies end-host mobility and multi-homing mechanisms
for the Host Identity Protocol.
Nikander, et al. Expires December 16, 2003 [Page 1]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . 6
3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . 7
3.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . 7
3.2 Location privacy . . . . . . . . . . . . . . . . . . . . . . 7
3.3 End-host multi-homing . . . . . . . . . . . . . . . . . . . 7
3.4 Site multi-homing . . . . . . . . . . . . . . . . . . . . . 8
3.5 Combined mobility and multi-homing . . . . . . . . . . . . . 8
3.6 Network renumbering . . . . . . . . . . . . . . . . . . . . 8
3.7 Combined all . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview of HIP mobility and multi-homing functionality . . 9
4.1 IP addresses assigned to a node . . . . . . . . . . . . . . 9
4.2 Informing the peer about multiple or changed address(es) . . 9
4.3 Address verification . . . . . . . . . . . . . . . . . . . . 10
4.4 Forwarding Agents . . . . . . . . . . . . . . . . . . . . . 10
4.4.1 Address leases from an Forwarding Agent . . . . . . . . . . 11
4.4.2 Recovering from forwarding agent crashes . . . . . . . . . . 12
4.5 Security Associations . . . . . . . . . . . . . . . . . . . 12
5. Protocol overview . . . . . . . . . . . . . . . . . . . . . 13
5.1 Acquiring an address lease from a Forwarding Agent . . . . . 13
5.2 Renewing an address lease . . . . . . . . . . . . . . . . . 14
5.3 Readdressing and address status . . . . . . . . . . . . . . 14
6. Protocol definition . . . . . . . . . . . . . . . . . . . . 16
6.1 Packet formats . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.1 REA - the HIP readdress packet . . . . . . . . . . . . . . . 16
6.1.2 AC and ACR - the HIP Address Check and Address Check
Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets . . . . . . 20
6.2 Requesting Address Leases . . . . . . . . . . . . . . . . . 21
6.3 Providing address Leases . . . . . . . . . . . . . . . . . . 21
6.4 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . 21
6.5 Handling received REAs at end hosts . . . . . . . . . . . . 22
7. Policy considerations . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . 24
8.1 Why does the foreign agent may require a puzzle solution? . 24
8.2 Attacker masquerading as a FA . . . . . . . . . . . . . . . 24
8.3 Location privacy . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
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
Nikander, et al. Expires December 16, 2003 [Page 2]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Intellectual Property and Copyright Statements . . . . . . . 33
Nikander, et al. Expires December 16, 2003 [Page 3]
Internet-Draft HIP Mobility and Multi-Homing June 2003
1. Introduction
This document specifies how the Host Identity Protocol [3] (HIP)
provides simple and efficient means for nodes to communicate while
being multi-homed, mobile, or simultanously mobile and multi-homed.
Additionally, HIP allows communications even when the multi-homing or
mobility causes a change in the IP version that is available in the
network.
More specifically, the Host Identity Protocol [3] (HIP) defines a
mechanism that decouples the transport layer from the internetworking
layer, and introduces a new Host Identity namespace. When a host
uses HIP, the transport layer sockets and IPsec Security Associations
are not bound to IP addresses but to 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. 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
Associations (SA) between any communicating pair of HIP enabled
nodes. These SAs are not bound to IP addresses but to Host
Identifiers (public keys). However, the hosts must also know at
least one IP address where their peers are reachable. Initially this
IP address is the one used during the HIP base exchange.
Since the SAs are not bound to IP addresses, the nodes are able to
receive IPsec protected HIP packets from any address. Thus, a node
can change its IP address and continue to send packets to its peers.
However, the peers are not able to send replies before they can
reliably and securely update the sending node's address(es).
This document specifies a mechanism that allow a HIP node to update
its address(es) to its peers. The address update is implemented with
a new HIP packet type, the HIP Readdress (REA) packet. Due to the
danger of flooding attacks (see [4]), the peer must always check the
reachability of the node before it can use the new addresses. The
reachability check is implemented with a pair of new HIP packet
types, HIP Address Check (AC) and HIP Address Check Reply (ACR). In
addition to initiating and reachbility check, an AC packet may also
act as an acknowledgement for a preceding REA packet.
There are a number of situations where the simple end-to-end
readdressing functionality is not sufficient. These include the
initial reachability of a mobile node, location privacy, end-host and
site multi-homing with legacy hosts, and NAT traversal. In these
Nikander, et al. Expires December 16, 2003 [Page 4]
Internet-Draft HIP Mobility and Multi-Homing June 2003
situations there is a need for some helper functionality in the
network. In this document we describe mechanisms for initial
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].
Nikander, et al. Expires December 16, 2003 [Page 5]
Internet-Draft HIP Mobility and Multi-Homing June 2003
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
Nikander, et al. Expires December 16, 2003 [Page 6]
Internet-Draft HIP Mobility and Multi-Homing June 2003
3. Usage scenarios
In this section we briefly introduce a number of usage scenarios
where the HIP mobility and multi-homing facility is useful. To
understand these usage scenarios, the reader should be at least
minimally familiar with the HIP protocol specification [3]. However,
for the (relatively) uninitiated reader it is most important to keep
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
context.
3.1 End-host mobility
A mobile IP host must change its IP address according to
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
link, a new DHCP lease, or an actual movement to another subnet. In
order to maintain its communication context, the host must inform its
peers about the new IP address.
Although HIP enables ESP and the upper layer to be independent 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
IP address. Thus, from the functional point of view, it is
sufficient that the peer nodes learn the new IP address. The upper
layer protocols need to know about the address and connectivity
change only for QoS and similar purposes. In most cases, they need
not 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
A host may have multiple interfaces, and it is desired that it can
stay reachable through all of the currently available interfaces. It
is expected that the set of available interfaces may change
dynamically, and that there may be policies associated with the usage
Nikander, et al. Expires December 16, 2003 [Page 7]
Internet-Draft HIP Mobility and Multi-Homing June 2003
of the different interfaces. For instance, the host may have a fast
but low range wireless interface and a slow high range interface.
The host may generally prefer to use the fast interface, but it may
be available only some of the time.
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
its interface while revealing the IP address of some others.
3.4 Site multi-homing
A host may have an interface that has multiple globally reachable IP
addresses. Such a situation may be a result of the site having
multiple upper Internet Service Providers, or just because the site
provides all nodes with both IPv4 and IPv6 addresses. It is
desirable that the host can stay reachable with all currently
available globally routable addresses, independent on how they are
provided.
Note that a single interface may experience site multi-homing while
the host itself may have multiple interfaces.
3.5 Combined mobility and multi-homing
It looks likely that in the future many of the mobile nodes will be
simultaneously mobile and multi-homing, i.e., have multiple mobile
interfaces. Furthermore, if the interfaces use different access
technology, it is fairly likely that one of the interfaces may appear
stable (retain its current IP address) while some other(s) may
experience mobility (undergo IP address change).
3.6 Network renumbering
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
renumber is similar to mobility.
3.7 Combined all
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).
Nikander, et al. Expires December 16, 2003 [Page 8]
Internet-Draft HIP Mobility and Multi-Homing June 2003
4. Overview of HIP mobility and multi-homing functionality
HIP mobility and multi-homing is fundamentally based on the HIP
architecture [4], where the transport and internetworking layers are
insulated from each other with the new host identity layer. In the
HIP architecure, the transport layer sockets are bound to the Host
Identifiers (through HIT or LSI in the case of legacy APIs), and the
Host Identifiers are translated to the actual IP address.
In the base HIP protocol specification [3], it is defined how two
hosts exchange their Host Identifiers and establish a pair of ESP
Security Associations (SA). The ESP SAs are then used to carry the
actual payload data between the two hosts, by wrapping TCP, UDP, and
other upper layer headers into transport mode ESP payloads. The IP
header, carrying the ESP header, uses actual IP addresses in the
network.
In the base specification, hosts use the same IP addresses for nodes
that were used during the base HIP exchange. This specification
defines the way how IP addresses can be changed during the
communication.
4.1 IP addresses assigned to a node
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
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)
To be able to use effectively multiple addresses assigned to the host
and update addresses that change during the communication with
another node, a HIP protocol packet, the REA packet (see Section
6.1.1), is specified. The logical structure created with REA packets
has three levels: hosts, interfaces, and addresses. This is
illustrated in Figure 1.
address11
Nikander, et al. Expires December 16, 2003 [Page 9]
Internet-Draft HIP Mobility and Multi-Homing June 2003
/
interface1 - address12
/
/ address21
host -- interface2 <
\ address22
\
interface3 - address31
\
address32
Figure 1
A single REA payload handles only one interface. To signal
simultaneously changes on several interfaces, it is necessary to send
several consequtive REA payloads. The packet structure supports
this.
4.3 Address verification
When a HIP host receives a group of IP addresses from another HIP
host in a REA, it does not necessarily know for sure whether the
other host is actually reachable at the claimed addresses. In fact,
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
address check, the HIP host receiving a REA immediately sends an AC
to all addresses mentioned in the REA.
In a typical implementation, an address consists of the actual
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
For nodes that are mobile, an IP address from where it can be reached
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
Nikander, et al. Expires December 16, 2003 [Page 10]
Internet-Draft HIP Mobility and Multi-Homing June 2003
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
address from where it can be reached. This can be the case, for
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
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.
+----------+ +--------------+
| HIP host |---------------------------->| Another host |
+----------+ +--------------+
^ real IP address |
| |
| |
+----------+ leased IP address |
| FA |<------------------------------------+
+----------+
Figure 2
The actual method of discovering FAs is beyond the scope of this
document, and will be specified elsewhere.
4.4.1 Address leases from an Forwarding Agent
To acquire an address lease from a given FA, the HIP host sends a
Forwarding Agent Query (FAQ) packet to it. In some cases, the FAQ
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
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
Nikander, et al. Expires December 16, 2003 [Page 11]
Internet-Draft HIP Mobility and Multi-Homing June 2003
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
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
renew it or by sending an Forwarding Agent Query that specifies a
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
If a FA crashes, it looses its state. Consequently, it cannot
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
kind of error message to the hosts sending ESP packets to it.
4.5 Security Associations
The security associations between the nodes are not any longer
directly connected to the IP address of the node. The SA is
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
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.
Nikander, et al. Expires December 16, 2003 [Page 12]
Internet-Draft HIP Mobility and Multi-Homing June 2003
5. Protocol overview
The HIP mobility and multi-homing functionality consist of the
following subprotocols:
Acquiring an address lease from a Forwarding Agent
Renewing an address lease
Informing peers about multiple addresses or address changes, and
verifying the reachability of addresses
5.1 Acquiring an address lease from a Forwarding Agent
HIP host Forwarding Agent
Forwarding Agent Query
----------------------------------->
R1
<-----------------------------------
Forwarding Agent Query
----------------------------------->
Forwarding Agent Advice
<-----------------------------------
To acquire an address lease, the HIP host sends an FAQ, requesting
for an address lease. The host may specify the type of address it
wants to have (IPv4, IPv6, either), the number of SPIs requested, and
the desired lifetime. Any of these fields may be left empty, as
well. The FAQ is always signed.
If the Forwarding agent does not trust the HIP host, it may answer
with an R1, basically asking the HIP host to solve a puzzle before
the Forwarding Agent is even willing to consider the request. Once
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
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,
specifying the leased IP address, its lifetime, and if the address is
an IPv4 address, a range of SPIs that has been reserved for the HIP
host.
Nikander, et al. Expires December 16, 2003 [Page 13]
Internet-Draft HIP Mobility and Multi-Homing June 2003
5.2 Renewing an address lease
Once an address lease is about to expire, the HIP host may want to
renew it.
HIP host Forwarding Agent
Forwarding Agent Query
----------------------------------->
Forwarding Agent Advice
<-----------------------------------
To renew a lease, the HIP host simply sends a FAQ specifying an
existing lease, together with the desired extended lease time, and
the FA replies with an FAA.
5.3 Readdressing and address status
HIP host Another host
REA
----------------------------------->
AC
<-----------------------------------
ACR
----------------------------------->
When the host changes its IP address, gets more addresses or loses an
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
addresses are valid even the signature is correct, it sends the
Address Check (AC) packet to each of the new addresses received. If
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
that is has sent out, it MUST drop the packet. Such a packet may be
an indication that someone else is on purpose or on mistake sending a
Nikander, et al. Expires December 16, 2003 [Page 14]
Internet-Draft HIP Mobility and Multi-Homing June 2003
false address to its peer.
Nikander, et al. Expires December 16, 2003 [Page 15]
Internet-Draft HIP Mobility and Multi-Homing June 2003
6. Protocol definition
The location information update procedure in the HIP consists of the
readdress packet telling the current set of addresses that the node
is using, address check and address check replies. With this set of
messages the IP addresses can be updated to the peer and the peer is
able to verify that the addresses are valid.
In addition to the actual address update, the HIP node is provided a
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
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
6.1.1 REA - the HIP readdress packet
A HIP readressing packet consists of one or more of REA_INFO
payloads, followed by a signature (HIP_SIGNATURE) and a HMAC. The
purpose of the signature is to allow middleboxes to verify the
integrity of the packet. The HMAC allows the peer node to verify the
packet very fast.
Intermediate systems that use the SPI will have to inspect ALL HIP
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
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
function. In fact, header compression on links is probably more
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 of problems that piggybacking caused in Mobile IPv6, however,
because the packet is always encrypted, hence it could not receive
different treatment at the firewalls etc. But I'm not 100% sure that
there are no other problems.
Nikander, et al. Expires December 16, 2003 [Page 16]
Internet-Draft HIP Mobility and Multi-Homing June 2003
6.1.1.1 REA_INFO payload
Note that the REA_INFO payload is a kind of "expanded" NES.
XXX (Pekka): Note that I have, for the time being, removed the old
ESP sequence number. Firstly, it may be hard to acquire reliably in
some implemtations (ours included). Secondly, we now have a REA ID
field, which is basically a REA sequence number.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current SPI in reverse direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keymaterial index | REA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nikander, et al. Expires December 16, 2003 [Page 17]
Internet-Draft HIP Mobility and Multi-Homing June 2003
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
packet applies to. It is implicitly qualified by the Host Identity
of the sending host. The Interface ID groups a set of addresses to
an interface. The purpose of the Interface ID is to allow a
knowledgeable peer to interact with the sender. For example, the
sender could be informing its peer that that an interface has both an
IPv4 address and one or more IPv6 addresses.
The sending host is free to introduce interface IDs at will. That is,
if a received REA has a new interface ID, it means that all the old
addresses, assigned to other interface IDs, are also supposed to
still work, while the new addresses in the 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).
If the SA is changed, and if the SA is not used at any other
interface any more, it MUST NOT be deleted until all ESP packets with
a lower Sequence Number have been received and processed, or a
reasonable time has elapsed (to account for lost packets).
6.1.1.2 HMAC
The HMAC SHA-1 is used to verify a received packet.
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
Nikander, et al. Expires December 16, 2003 [Page 18]
Internet-Draft HIP Mobility and Multi-Homing June 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ HMAC data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65532
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
The HIP Address Check (AC) and Address Check Reply (ACR) packets
contain an AC_INFO payload, followed by a HMAC.
In addition to acting as an address probe, the Address Check packet
may also acts as an implicit acknowledgement to a REA packet.
6.1.2.1 AC_INFO payload
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID | REA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 129
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
Nikander, et al. Expires December 16, 2003 [Page 19]
Internet-Draft HIP Mobility and Multi-Homing June 2003
6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets
The HIP FAQ, FAA and FAD packets contain an FA_INFO payload, and
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Lease ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Addr type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 address:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 address:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 130
Length Length in octets, excluding Type and Length
fields
Nikander, et al. Expires December 16, 2003 [Page 20]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Request ID A 16-bit sequence number of nonce, used to
match the FAQ packet to the corresponding
FAA/FAD packet.
Lease ID A 16-bit number XXX
Lease duration Duration of the lease
Reserved Zero when sent, ignored when received
Addr type Address type: 4 for IPv4 and 6 for IPv6 (TBD)
6.2 Requesting Address Leases
To request address leases from the FA, the HIP node sends an FAQ
packet to the FA. The FAQ packet consists of the HIP header, FA_INFO
payload and a HIP_SIGNATURE. If the FAQ packet is the second one sent
from the HIP node to the FA, i.e. the FA responded to the first FAQ
with an R1 packet, a BIRTHDAY_COOKIE payload containing the cookie
response must be included in the packet.
6.3 Providing address Leases
When the FA receives an FAQ packet from a HIP node, it may verify the
signature in the packet. If the FA does not trust on the requesting
node, it may generate an R1 packet containing a puzzle for the
requesting HIP node.
If the FA trusts to the requesting HIP node, or the HIP node
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
of data was performed, the FA responds to the requesting node with a
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
request was malformed, the FA responds with a FAD packet.
6.4 Sending REAs
The HIP node may want to send address information to the peer node
whenever there are updates in the addresses that are assigned to it.
The leased addresses can be considered also to be possible addresses
and they must be assigned to a logical interface.
Nikander, et al. Expires December 16, 2003 [Page 21]
Internet-Draft HIP Mobility and Multi-Homing June 2003
The REA packet contains the HIP header, one or more REA_INFO,
HIP_SIGNATURE and HMAC TLVs. The REA_INFO describes all the addresses
that are associated with that particular interface identifier. If a
previously associated address is not included in the list, the peer
considers it as a lost address and removes it from the address
associations.
6.5 Handling received REAs at end hosts
When a HIP node receives a REA packet, it verifies the signature in
it. If the packet was valid, it may initiate an address check
procedure. The address check (AC) packet is sent to all addresses
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.
Nikander, et al. Expires December 16, 2003 [Page 22]
Internet-Draft HIP Mobility and Multi-Homing June 2003
7. Policy considerations
TBD
Nikander, et al. Expires December 16, 2003 [Page 23]
Internet-Draft HIP Mobility and Multi-Homing June 2003
8. Security Considerations
(Initial text by Jari Arkko): If not controlled in some manner,
messaging related to address changes would create the following types
of vulnerabilities:
Revealing the contents of the (cleartext) communications
Hijacking communications and man-in-the-middle attacks
Denial of service for the involved nodes, by disabling their
ability to receive the desired communications
Denial of service for third parties, by redirecting a large amount
of traffic to them
Revealing the location of the nodes to other parties
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
private key, and hence it becomes impossible to hijack the
communications of another node through the use of the REA message.
Similarly, since only the node itself can sign messages to move its
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
the node did not wish to use. Finally, In HIP all communications are
encrypted with ESP, so a hijack attempt would also be unable to
reveal the contents of the communications.
Malicous nodes that use HIP can, however, try to cause a denial of
service attack by establishing a high-volume traffic flow, such as a
video stream, and then redirecting it to a victim. However, the
return routability check provides some assurance that the given
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
test.
8.1 Why does the foreign agent may require a puzzle solution?
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
Nikander, et al. Expires December 16, 2003 [Page 24]
Internet-Draft HIP Mobility and Multi-Homing June 2003
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
Nikander, et al. Expires December 16, 2003 [Page 25]
Internet-Draft HIP Mobility and Multi-Homing June 2003
9. IANA Considerations
Nikander, et al. Expires December 16, 2003 [Page 26]
Internet-Draft HIP Mobility and Multi-Homing June 2003
10. Acknowledgments
Thanks to Kimmo Nieminen.
Nikander, et al. Expires December 16, 2003 [Page 27]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[3] Nikander, P. and R. Moskowitz, "Host Identity Protocol",
draft-moskowitz-hip-06 (work in progress), May 2003.
[4] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-03 (work in progress), May 2003.
Nikander, et al. Expires December 16, 2003 [Page 28]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Informative references
[5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998.
[6] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security,
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
progress), February 2003.
[8] Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-nikander-mobileip-v6-ro-sec-00 (work
in progress), April 2003.
Authors' Addresses
Pekka Nikander
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Jari Arkko
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: jari.arkko@nomadiclab.com
Nikander, et al. Expires December 16, 2003 [Page 29]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Petri Jokela
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Nikander, et al. Expires December 16, 2003 [Page 30]
Internet-Draft HIP Mobility and Multi-Homing June 2003
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
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 transit provider may have NAT boxes in the network. The HIP node
connected to a site that is further connected to a transit provider
using NATs, must get the knowledge about the NAT box between itself
and the peer node. The address that the HIP node sends to the peer
node must be a public one, thus NATted address is not valid.
The NAT box on the path must support address (and SPI) leasing for
the HIP node. When the HIP node finds out that there is a NAT box,
the host must get a leased address (or a set of addresses) from the
NAT. These addresses are routable at the other side of the NAT. They
still need not to be globally routable as there may be another NAT
box on the path.
Nikander, et al. Expires December 16, 2003 [Page 31]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Appendix B. Implementation experiences
Nikander, et al. Expires December 16, 2003 [Page 32]
Internet-Draft HIP Mobility and Multi-Homing June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Nikander, et al. Expires December 16, 2003 [Page 33]
Internet-Draft HIP Mobility and Multi-Homing June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nikander, et al. Expires December 16, 2003 [Page 34]