Network Working Group P. Nikander
Internet-Draft J. Arkko
Expires: June 28, 2004 Ericsson Research Nomadic Lab
December 29, 2003
End-Host Mobility and Multi-Homing with Host Identity Protocol
draft-nikander-hip-mm-01
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 June 28, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies basic end-host mobility and multi-homing
mechanisms for the Host Identity Protocol.
Nikander & Arkko Expires June 28, 2004 [Page 1]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . . 7
4.2 End-host multi-homing . . . . . . . . . . . . . . . . . . . . 7
4.3 Site multi-homing . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Combined mobility and multi-homing . . . . . . . . . . . . . . 8
4.5 Network renumbering . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of HIP basic mobility and multi-homing
functionality . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Informing the peer about multiple or changed address(es) . . . 9
5.2 Address verification . . . . . . . . . . . . . . . . . . . . . 10
5.3 Address data structure and status . . . . . . . . . . . . . . 11
6. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12
6.1 Initiating the protocol in NES . . . . . . . . . . . . . . . . 13
6.2 Initiating the protocol in R1 or I2 . . . . . . . . . . . . . 13
6.3 Explicit address check . . . . . . . . . . . . . . . . . . . . 15
7. Parameter and packet formats . . . . . . . . . . . . . . . . . 16
7.1 REA parameter . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Modified NES_INFO parameter . . . . . . . . . . . . . . . . . 17
7.3 NES packet with included REA . . . . . . . . . . . . . . . . . 18
7.4 R1 and I2 packets with included REA . . . . . . . . . . . . . 18
8. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 Handling received REAs . . . . . . . . . . . . . . . . . . . . 20
8.3 Verifying address reachability . . . . . . . . . . . . . . . . 21
8.4 Changing the preferred address . . . . . . . . . . . . . . . . 22
9. Policy considerations . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
Normative references . . . . . . . . . . . . . . . . . . . . . 27
Informative references . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
A. Changes from previous versions . . . . . . . . . . . . . . . . 29
A.1 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 29
B. Implementation experiences . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 31
Nikander & Arkko Expires June 28, 2004 [Page 2]
Internet-Draft HIP Mobility and Multi-Homing December 2003
1. Introduction
This document specifies an extension to the Host Identity Protocol
[3] (HIP). The extension provides a simple and efficient means for
hosts to keep their communications on-going while having multiple IP
addresses, either at the same time or one after another. That is,
the extension provides basic support for multi-homing, mobility, and
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.
This document does not specify any rendezvous or proxy services.
Those are subject to other specifications . Hence, this document
alone does not necessarily allow two mobile hosts to communicate,
unless they have other means for initial rendezvous and solving the
simultaneous movement problem.
The Host Identity Protocol [3] (HIP) defines a mechanism that
decouples the transport layer (TCP, UDP, etc) from the
internetworking layer (IPv4 and IPv6), 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, thereby enabling end-host
mobility and multi-homing.
In practice, the HIP base exchange [3]creates a pair of IPsec
Security Associations (SA) between a pair of HIP enabled hosts.
These SAs are not bound to IP addresses, but to the Host Identifiers
(public keys) used to create them. However, the hosts must also know
at least one IP address where their peers are reachable. Initially
these IP addresses are the ones used during the HIP base exchange.
Since the SAs are not bound to IP addresses, the host are able to
receive packets that protected using a HIP created ESP SA from any
address. Thus, a host can change its IP address and continue to send
packets to its peers. However, the peers are not able to replys
before they can reliably and securely update the set of addresses
that they associate with the sending host.
This document specifies a mechanism that allows a HIP host to update
the set of addresses that its peers associate with it. The address
update is implemented with new HIP parameter types. Due to the danger
Nikander & Arkko Expires June 28, 2004 [Page 3]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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
readdressing functionality is not sufficient. These include the
initial reachability of a mobile host, location privacy, end-host and
site multi-homing with legacy hosts, and NAT traversal. In these
situations there is a need for some helper functionality in the
network. This document does not address those needs.
Nikander & Arkko Expires June 28, 2004 [Page 4]
Internet-Draft HIP Mobility and Multi-Homing December 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 & Arkko Expires June 28, 2004 [Page 5]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
Nikander & Arkko Expires June 28, 2004 [Page 6]
Internet-Draft HIP Mobility and Multi-Homing December 2003
4. 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.
4.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 host learn the new IP address. The upper
layer protocols need to know about the address and connectivity
change only for QoS and other similar purposes. In most cases, they
do not need to know.
4.2 End-host multi-homing
A host may have multiple interfaces, and it is desirable that it can
stay reachable through all or any subset 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 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 not be always available.
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 interfaces while revealing the real IP address of some others.
4.3 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
Nikander & Arkko Expires June 28, 2004 [Page 7]
Internet-Draft HIP Mobility and Multi-Homing December 2003
multiple upper Internet Service Providers, or just because the site
provides all host with both IPv4 and IPv6 addresses. It is desirable
that the host can stay reachable with all or any subset of the
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.
4.4 Combined mobility and multi-homing
It looks likely that in the future many mobile hosts will be
simultaneously mobile and multi-homed, i.e., have multiple mobile
interfaces. Furthermore, if the interfaces use different access
technologies, 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).
4.5 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.
Nikander & Arkko Expires June 28, 2004 [Page 8]
Internet-Draft HIP Mobility and Multi-Homing December 2003
5. Overview of HIP basic 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 protocol layer.
In the HIP architecture, 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 HIP base 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 packets into transport mode ESP payloads. The IP
header, carrying the ESP header, uses the actual IP addresses in the
network.
The base specification does not contain any mechanisms for changing
the IP addresses that were used during the base HIP exchange. Hence,
in order to remain connected any systems that implement only the
space specification and nothing else must retain the ability to
receive packets at their primary IP address; that is, those systems
cannot change the IP address they are using without causing loss of
connectivity.
5.1 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.
address11
/
interface1 - address12
/
/ address21
host -- interface2 <
\ address22
\
interface3 - address31
\
address32
Figure 1
Nikander & Arkko Expires June 28, 2004 [Page 9]
Internet-Draft HIP Mobility and Multi-Homing December 2003
In this document, the interfaces are considered to be logical
objects. A host may claim to have any number of interfaces. 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. Note,
however, that especially in the case of site multi-homing one of the
addresses may become unreachablewhile the other one still works. In
the typical case, however, this does not require the host to inform
its peers about the situation, since even the non-working address
still logically exists.
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.
While it would be possible to share an SA between multiple
interfaces, there would be no benefit from it. As the interfaces are
logical objects, and as the hosts are free to create new interface as
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.
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.
A single REA parameter contains data only about one interface. To
signal simultaneously changes on several interfaces, it is necessary
to send several REA parameters. The packet structure supports this.
If the REA parameter is send in a NES packet and the sender wants to
receive an acknowledgement, it must explicitly indicate so.
Otherwise the recipient of the REA parameter may consider the REA as
informational, and act only when it needs to activate a new address.
5.2 Address verification
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
Nikander & Arkko Expires June 28, 2004 [Page 10]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
5.3 Address data structure and status
In a typical implementation, each remote address is represented as a
piece of state that contains the following data:
the actual bit pattern representing the IPv4 or IPv6 address,
lifetime (seconds),
status (UNVERIFIED, ACTIVE, DEPRECATED).
The status is used to track the reachability of the address:
UNVERIFIED indicates that the reachability of the address has not
been checked yet,
ACTIVE indicates that the reachability of the address has been
checked and the address has not been deprecated,
DEPRECATED indicates that the address lifetime has expired
The following state changes are allowed:
UNVERIFIED to ACTIVE The reachability procedure completes
succesfully.
UNVERIFIED to DEPRECATED The address lifetime expires while it is
UNVERIFIED.
ACTIVE to DEPRECATED The address lifetime expires while it is ACTIVE.
ACTIVE to UNVERIFIED There has been no traffic on the address for
some time, and the local policy mandates that the address
reachability must be verified again before starting to use it
again.
DEPRECATED to UNVERIFIED The host receives a new lifetime for the
address.
A DEPRECATED address MUST NOT be changed to ACTIVE without first
verifying its reachability.
Nikander & Arkko Expires June 28, 2004 [Page 11]
Internet-Draft HIP Mobility and Multi-Homing December 2003
6. 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 protocol is an asymmetric protcool where one host, called the
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.
1. The Mobile Host sends a REA parameter to the Peer host.
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.
3. The Peer Host waits for new data to arrive on the new SA,
indicated by the SPI. Once it has succesfully received data on
the SA, it marks the new address as reachable.
Mobile host Peer host
REA parameter
----------------------------------->
new SPI
<-----------------------------------
data on new SA
----------------------------------->
Figure 2
The idea of the address check procedure is that if the Mobile Host is
able to succesfully construct the new outgoing SA, using the new SPI
value, and send data on that SA, then it must have received the
second message in the protocol, and therefore it must be reachable at
the said address.
XXX: Residual threat: The Mobile Host able to anticipate the KEY
index and guess the SPI value by trying out all? Not really, I
Nikander & Arkko Expires June 28, 2004 [Page 12]
Internet-Draft HIP Mobility and Multi-Homing December 2003
think, since it would require about 2^31 packets on the average...
6.1 Initiating the protocol in NES
The most common case is to carry the readdress protocol on NES
packets. In this case, the Mobile Host initiates rekey (usually
using the current Diffie-Hellman keys) and includes a REA parameter
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.
Mobile host Peer host
NES with REA
----------------------------------->
record additional addresses
(prepare new incoming SA)
NES with new SPI in NES_INFO
<-----------------------------------
(prepare new incoming SA)
(switch to new outgoing SA)
data on new SA
----------------------------------->
(switch to new outgoing SA)
change preferred address
The text in (parantheses) indicate functions that are
performed anyway, as a part of NES processing, and not
new to the REA processing.
Figure 3
Basically, the processing structure is equal to the current NES
processing other than that the Peer host records the additional
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.
6.2 Initiating the protocol in R1 or I2
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
Nikander & Arkko Expires June 28, 2004 [Page 13]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
Initiator Responder
R1 with REA
<-----------------------------------
record additional addresses
change responder address
I2 with new SPI in SPI_LSI
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally)
Figure 4
XXX: What about R1 source address? Most probably we want to allow it
to be any address to allow an optimized rendezvous server to send an
R1 instead of the actual host?
An Initiator MAY include one or more REA parameters in the I2 packet,
independent on whether there was REA parameter(s) in the R1 or not.
These parameters MUST be protected by the I2 signature. Even if the
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.
Initiator Responder
I2 with REA
----------------------------------->
(process normally)
record additional addresses
R2 with new SPI in LSI_SPI
<-----------------------------------
(process normally)
data on new SA
------------------------------------>
(process normally)
Figure 5
Nikander & Arkko Expires June 28, 2004 [Page 14]
Internet-Draft HIP Mobility and Multi-Homing December 2003
6.3 Explicit address check
When the Peer Host wants to use a new address that has not yet been
checked, it must first run check the reachability of the address
before sending any large amounts of data to the address. See Section
8.3.
Nikander & Arkko Expires June 28, 2004 [Page 15]
Internet-Draft HIP Mobility and Multi-Homing December 2003
7. Parameter and packet formats
7.1 REA parameter
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 (first non-critical)
Length Length in octets, excluding Type and Length fields.
P Preferred address. The first address in this REA is the new
preferred address.
Reserved Zero when sent, ignored when received.
Interface ID Interface ID, as defined by the sending host. The
interface IDs may have any values, and need not be consequtively
allocated.
Nikander & Arkko Expires June 28, 2004 [Page 16]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Address Lifetime Address lifetime, in seconds.
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
parameter 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 sending host is free to introduce new
interface IDs at will. That is, if a received REA has a new
interface ID, it means that all the old addresses, assigned to the
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 Address Lifetime indicates how long the following address is
expected to be valid. The lifetime is expressed in seconds. Each
address MUST have a non-zero lifetime. The address is expected to
become deprecated when the specified number of seconds has passed
since the reception of the message. A deprecated address SHOULD NOT
be used as an destination address if an alternate (non-deprecated) is
available and has sufficient scope. Since IP addresses are ignored
upon reception, deprecation status does not have any affect on the
receiver.
The Address field contains an IPv6 address, or an IPv4 address in the
IPv4-in-IPv6 format [2]. The latter format denotes a plain IPv4
address that can be used to reach the Mobile Host.
7.2 Modified NES_INFO parameter
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.
This specification changes the semantics of the R-bit slightly. (It
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
NES_INFO as a reply, one if no reply is needed.
Nikander & Arkko Expires June 28, 2004 [Page 17]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Processing NES packets currently defines the following behaviour.
If the system is in state E3 and the NES has the R-bit set, the
packet is silently dropped.
The new behaviour is defined as follows.
If the system is in state E3 and the NES_INFO has the R-bit set,
the system initiates unidirectional rekeying, as defined in
Section 8.3.
7.3 NES packet with included REA
A single REA is included in a NES packet between the NES_INFO and
HMAC parameters:
IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
If there are multiple REA parameters to be sent in a single NES, each
of them must be matched with a NES_INFO parameter:
IP ( HIP ( REA1, REA2, NES_INFO1, NES_INFO2, [ DH, ] ... ) )
7.4 R1 and I2 packets with included REA
The REA parameter is included early in the R1 and I2 packets, since
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
parameter and the signature.
IP ( HIP ( REA,
BIRTHDAY_COOKIE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
( HOST_ID | HOST_ID_FQDN ),
HIP_SIGNATURE_2 ) )
IP ( HIP ( SPI_LSI,
REA,
BIRTHDAY_COOKIE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID | HOST_ID_FQDN },
Nikander & Arkko Expires June 28, 2004 [Page 18]
Internet-Draft HIP Mobility and Multi-Homing December 2003
HIP_SIGNATURE ) )
Nikander & Arkko Expires June 28, 2004 [Page 19]
Internet-Draft HIP Mobility and Multi-Homing December 2003
8. Processing rules
XXX: This section needs more work.
8.1 Sending REAs
The decision of when to send REAs is basically a local policy issue.
However, it is RECOMMENDED that a host sends a REA whenever it
recognizes a change of its IP addresses, and assumes that the change
is going to last at least for a few seconds. Rapidly sending
conflicting REAs SHOULD be avoided.
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.
Once the host has decided on the interfaces and assingment of
addresses to the interfaces, it creates a REA parameter for each
interface. If there are multiple interfaces and therefore multiple
parameters, the parameters MUST be ordered so that the new preferred
address is in the first REA parameter.
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.
If there are multiple REA parameters leading to a packet size that
exceeds the MTU, the host SHOULD send multiple packets, each smaller
than the MTU. In the case of R1 and I2, the additional packets
should be NES packets that are send after the base exchange has been
completed.
8.2 Handling received REAs
A host SHOULD be prepared to receive REA parameters in any HIP
packets, excluding I1.
When a host receives a REA parameter, it first performs the following
operations:
Nikander & Arkko Expires June 28, 2004 [Page 20]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
2. For each address listed in the REA parameter, check that the
address is a legal unicast or anycast address. That is, the
addres MUST NOT be a broadcast or multicast address. Note that
some implementations MAY accept addresses that indicate the local
host, since it may be allowed that the host runs HIP with itself.
3. For each address listed in the REA parameter, check if the
address is already listed at the interface. If the address is
listed, its lifetime is updated. If the address is status is
DEPRECATED, the status is changed to UNVERIFIED. if the address
is not listed, the address is added, and its status is set to
UNVERIFIED.
4. Mark all addresses at the interface that were NOT listed in the
REA parameter as DEPRECATED.
As a result, the interface now contains any addresses listed in the
REA parameter either as UNVERIFIED or ACTIVE, and any old addresses
not listed in the REA parameter as DEPRECATED.
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.
8.3 Verifying address reachability
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.
Nikander & Arkko Expires June 28, 2004 [Page 21]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
Nikander & Arkko Expires June 28, 2004 [Page 22]
Internet-Draft HIP Mobility and Multi-Homing December 2003
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.
Nikander & Arkko Expires June 28, 2004 [Page 23]
Internet-Draft HIP Mobility and Multi-Homing December 2003
10. Security Considerations
XXX: This section requires lots of more work.
(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
public key, and hence it becomes impossible to hijack the
communications of another host through the use of the REA message.
Similarly, since only the host 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 host 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.
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
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.
Nikander & Arkko Expires June 28, 2004 [Page 24]
Internet-Draft HIP Mobility and Multi-Homing December 2003
11. IANA Considerations
Nikander & Arkko Expires June 28, 2004 [Page 25]
Internet-Draft HIP Mobility and Multi-Homing December 2003
12. Acknowledgments
Nikander & Arkko Expires June 28, 2004 [Page 26]
Internet-Draft HIP Mobility and Multi-Homing December 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] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
Protocol", draft-moskowitz-hip-07 (work in progress), June 2003.
[4] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-03 (work in progress), May 2003.
Nikander & Arkko Expires June 28, 2004 [Page 27]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Informative references
[5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998.
[6] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", draft-iab-sec-cons-03 (work in
progress), February 2003.
[7] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work
in progress), July 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 & Arkko Expires June 28, 2004 [Page 28]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Appendix A. Changes from previous versions
A.1 From -00 to -01
The actual protocol has been largely revised, based on the new
symmetric New SPI (NES) design adopted in the base protocol draft
version -08. There are no more separate REA, AC or ACR packets, but
their functionality has been folded into the NES packet. At the same
time, it has become possible to send REA parameters in R1 and I2.
The Forwarding Agent functionality was removed, since it looks like
that it will be moved to the proposed HIP Research Group. Hence,
there will be two other documents related to that, a simple
Rendezvous server document (WG item) and a Forwarding Agent document
(RG item).
Nikander & Arkko Expires June 28, 2004 [Page 29]
Internet-Draft HIP Mobility and Multi-Homing December 2003
Appendix B. Implementation experiences
Nikander & Arkko Expires June 28, 2004 [Page 30]
Internet-Draft HIP Mobility and Multi-Homing December 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 & Arkko Expires June 28, 2004 [Page 31]
Internet-Draft HIP Mobility and Multi-Homing December 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 & Arkko Expires June 28, 2004 [Page 32]