wdiff draft-nikander-hip-mm-00.txt draft-nikander-hip-mm-01.txt

Network Working Group P. Nikander
Internet-Draft J. Arkko
Expires: December 16, 2003 P. Jokela June 28, 2004 Ericsson Research Nomadic Lab
June 17,
December 29, 2003

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

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. June 28, 2004.

Abstract

This document specifies basic end-host mobility and multi-homing
mechanisms for the Host Identity Protocol.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 . 3
2. Conventions used in this document . . . . . . . . . . . . . 6 . 5
3. Usage scenarios Terminology . . . . . . . . . . . . . . . . . . . . . . 7
3.1 End-host mobility . . . 6
4. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Location privacy
4.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . . 7
3.3
4.2 End-host multi-homing . . . . . . . . . . . . . . . . . . . . 7
3.4
4.3 Site multi-homing . . . . . . . . . . . . . . . . . . . . . 8
3.5 . 7
4.4 Combined mobility and multi-homing . . . . . . . . . . . . . . 8
3.6
4.5 Network renumbering . . . . . . . . . . . . . . . . . . . . 8
3.7 Combined all . . . . . . . . . . . . . . . . . . . . . . . . 8
4.
5. Overview of HIP basic mobility and multi-homing
functionality . . 9
4.1 IP addresses assigned to a node . . . . . . . . . . . . . . . . . . . . . . 9
4.2
5.1 Informing the peer about multiple or changed address(es) . . . 9
4.3
5.2 Address verification . . . . . . . . . . . . . . . . . . . . 10
4.4 Forwarding Agents . . . . . 10
5.3 Address data structure and status . . . . . . . . . . . . . . 11
6. Protocol overview . . 10
4.4.1 Address leases from an Forwarding Agent . . . . . . . . . . 11
4.4.2 Recovering from forwarding agent crashes . . . . . . . . . . 12
4.5 Security Associations .
6.1 Initiating the protocol in NES . . . . . . . . . . . . . . . . 13
6.2 Initiating the protocol in R1 or I2 . . 12
5. Protocol overview . . . . . . . . . . . 13
6.3 Explicit address check . . . . . . . . . . 13
5.1 Acquiring an address lease from a Forwarding Agent . . . . . 13
5.2 Renewing an address lease . . . . . 15
7. Parameter and packet formats . . . . . . . . . . . . 14
5.3 Readdressing and address status . . . . . 16
7.1 REA parameter . . . . . . . . . 14
6. Protocol definition . . . . . . . . . . . . . . . 16
7.2 Modified NES_INFO parameter . . . . . 16
6.1 Packet formats . . . . . . . . . . . . 17
7.3 NES packet with included REA . . . . . . . . . . . 16
6.1.1 REA - the HIP readdress packet . . . . . . 18
7.4 R1 and I2 packets with included REA . . . . . . . . . 16
6.1.2 AC and ACR - the HIP Address Check and Address Check
Reply . . . . 18
8. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets 20
8.1 Sending REAs . . . . . . 20
6.2 Requesting Address Leases . . . . . . . . . . . . . . . . . 21
6.3 Providing address Leases . . 20
8.2 Handling received REAs . . . . . . . . . . . . . . . . 21
6.4 Sending REAs . . . . 20
8.3 Verifying address reachability . . . . . . . . . . . . . . . . 21
8.4 Changing the preferred address . . . . 21
6.5 Handling received REAs at end hosts . . . . . . . . . . . . 22
7.
9. Policy considerations . . . . . . . . . . . . . . . . . . . . 23
8.
10. Security Considerations . . . . . . . . . . . . . . . . . . 24
8.1 Why does the foreign agent may require a puzzle solution? . 24
8.2 Attacker masquerading as a FA . . . . . . . . . . . . .
11. IANA Considerations . . 24
8.3 Location privacy . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments .
Normative references . . . . . . . . . . . . . . . . . . . . . 27
Normative
Informative references . . . . . . . . . . . . . . . . . . . . 28
Informative references . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
A. Site multi-homing . . . . . 28
A. Changes from previous versions . . . . . . . . . . . . . . . . 31 29
A.1 A host connected From -00 to a multi-homed site -01 . . . . . . . . . . . 31
A.2 Transit providers with NATs . . . . . . . . . . . . . . . . 31 29
B. Implementation experiences . . . . . . . . . . . . . . . . . 32 . 30
Intellectual Property and Copyright Statements . . . . . . . 33 . 31

1. Introduction

This document specifies how an extension to the Host Identity Protocol
[3] (HIP) (HIP). The extension provides a simple and efficient means for nodes
hosts to communicate keep their communications on-going while
being multi-homed, mobile, having multiple IP
addresses, either at the same time or simultanously mobile one after another. That is,
the extension provides basic support for multi-homing, mobility, and multi-homed.
simultaneous multi-homing and mobility. Additionally, HIP the extension
allows communications to continue even when the multi-homing or mobility
causes a change in of the IP version that is available in the
network.

More specifically, 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, 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. This enables mapping, thereby enabling 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 [3]creates a pair of IPsec
Security Associations (SA) between any communicating a pair of HIP enabled
nodes. hosts.
These SAs are not bound to IP addresses addresses, but to the Host Identifiers
(public keys). keys) used to create them. However, the hosts must also know
at least one IP address where their peers are reachable. Initially this
these IP address is addresses are the one ones used during the HIP base exchange.

Since the SAs are not bound to IP addresses, the nodes host are able to
receive IPsec packets that protected using a HIP packets created ESP SA from any
address. Thus, a node host can change its IP address and continue to send
packets to its peers. However, the peers are not able to send replies replys
before they can reliably and securely update the set of addresses
that they associate with the sending node's address(es). host.

This document specifies a mechanism that allow allows a HIP node host to update
the set of addresses that its address(es) to its peers. peers associate with it. The address
update is implemented with
a new HIP packet type, the HIP Readdress (REA) packet. parameter types. Due to the danger
of flooding attacks (see [4]), the peer peers must always check the
reachability of the node host at a new address before it can use the new
addresses. The reachability check is implemented with by the challenger
creating a pair of new HIP packet
types, HIP Address Check (AC) SPI, announcing the new SPI, and HIP Address Check Reply (ACR). waiting for traffic
on the new SPI. In addition to initiating and reachbility the reachability check, an AC packet may
announcing the new SPI also
act acts as an acknowledgement for a
preceding REA packet. 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 node, 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. In this 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]. does not address those needs.

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].

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
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

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 nodes 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 need
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

4.2 End-host multi-homing

A host may have multiple interfaces, and it is desired 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 available only some of the time. 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 interface interfaces while revealing the real IP address of some others.

3.4

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
multiple upper Internet Service Providers, or just because the site
provides all nodes 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.

3.5

4.4 Combined mobility and multi-homing

It looks likely that in the future many of the mobile nodes hosts will be
simultaneously mobile and multi-homing, multi-homed, i.e., have multiple mobile
interfaces. Furthermore, if the interfaces use different access
technology,
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).

3.6

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.

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).

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 architecure, 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 base 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 headers packets into transport mode ESP payloads. The IP
header, carrying the ESP header, uses the actual IP addresses in the
network.

In the

The base specification, hosts use specification does not contain any mechanisms for changing
the same IP addresses for nodes that were used during the base HIP exchange. This specification
defines Hence,
in order to remain connected any systems that implement only the way how IP addresses can be changed during
space specification and nothing else must retain the
communication.

4.1 IP addresses assigned ability to a node

A host can have multiple
receive packets at their primary IP addresses. It may have many interfaces address; that are assigned is, those systems
cannot change the IP addresses or it may have address they are using without causing loss of
connectivity.

5.1 Informing the peer about multiple addresses
assigned or changed address(es)

This document specifies a new HIP protocol parameter, the REA
parameter (see Section 7.1), that allows the hosts to one interface. There may also be multiple exchange
information about their IP addresses in
function of time: the node may address(es), and any changes its topological location in
the network, or its network may change addresses. 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

In this document, the interfaces are considered to be 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. 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.

4.2 Informing Note,
however, that especially in the peer 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 or changed address(es)

To
interfaces were to share an SA, it would become fairly likely that
some of the packets would be able discarded due to use effectively multiple addresses assigned 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 host interfaces are
logical objects, and update 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 change during two physical interfaces are in fact
one logical one, thereby allowing the communication with
another node, 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 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, different SPI, and addresses. This is
illustrated in Figure 1.

address11

/
interface1 - address12
/
/ address21
host -- interface2 <
\ address22
\
interface3 - address31
\
address32

Figure 1 since
the receiver will ignore the IP addresses anyway.

A single REA payload handles parameter contains data only about one interface. To
signal simultaneously changes on several interfaces, it is necessary
to send several consequtive REA payloads. parameters. The packet structure supports this.

4.3

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 for sure whether the other host is
actually reachable at the claimed addresses. In fact,
if the other HIP a
maliciouspeer host is not fully trusted, it may be intentionally giving a bogus
address with the intention of causing addresses in
order to cause a packet flood towards the given address [8]. [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 with the HIP Address Check (AC) and
Address Check Reply (ACR) packets.

To acknowledge that it has received by requesting the REA, and peer to initiate an
address check, the HIP host receiving create a REA immediately sends an AC new outgoing SA, using
a new random SPI value, and waiting for data to all addresses mentioned in the REA. appear on this new
SA.

5.3 Address data structure and status

In a typical implementation, an each remote address consists is represented as a
piece of state that contains the following data:

the actual
bitpattern used in bit pattern representing the IP source and destination fields, a lifetime,
and a status. IPv4 or IPv6 address,

lifetime (seconds),

status (UNVERIFIED, ACTIVE, DEPRECATED).

The status is used to track the reachability of the
address.

4.4 Forwarding Agents

For nodes address:

UNVERIFIED indicates 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 address has not
been checked yet,

ACTIVE indicates that supports only one of
the IP protocol versions, the HIP node may use reachability of the FA for acting as a
gateway when address has been
checked and the peer node wants to use a IP protocol version address has not been deprecated,

DEPRECATED indicates that the HIP node behind the FA does not directly support. address lifetime has expired

The HIP node can "lease" IP address(es) from the FA if following state changes are allowed:

UNVERIFIED to ACTIVE The reachability procedure completes
succesfully.

UNVERIFIED to DEPRECATED The address lifetime expires while it needs an is
UNVERIFIED.

ACTIVE to DEPRECATED The address from where lifetime expires while it can be reached. This can be is ACTIVE.

ACTIVE to UNVERIFIED There has been no traffic on 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),
some time, and start announcing the IP local policy mandates that the address (and some SPI)
reachability must be verified again before starting to its
peers. use it
again.

DEPRECATED to UNVERIFIED The SPI is required if host receives a new lifetime for the IP
address.

A DEPRECATED address leased from the FA MUST NOT be changed to ACTIVE without first
verifying its reachability.

6. Protocol overview

The readdressing protocol is
not unique, i.e. it does not map one-to-one designed to the HIT be piggybacked on a number
of the existing HIP
node. Further ESP protected data exchanges. The main packets arriving to on which the FA can thus REA
parameters are expected to be identified using the carried on are New SPI value and verifying (NES) packets.
However, some implementations may want to which HIP node
that particular SPI has been reserved.

As long experiment with sending REA
parameters also on other packets, such as the "lease" R1 and I2.

The protocol is valid, the FA will forward any packets sent
to the IP address (and an SPI within asymmetric protcool where one host, called the range) to
Mobile Host, informs another host, called the HIP host. Peer host, about
changes of IP addresses on one of its interfaces. The
basic operational model is depicted protocol
consists of three steps, illustrated 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

1. The actual method of discovering FAs is beyond Mobile Host sends a REA parameter to the scope of this
document, and will be specified elsewhere.

4.4.1 Address leases from an Forwarding Agent

To acquire Peer host.

2. The Peer Host initiates an address lease from check procedure by sending a given FA, the HIP host sends
new SPI value to a
Forwarding Agent Query (FAQ) new address. Any packet to it. In some cases, the FAQ
may be sent as that contains a broadcast or multicast packet; the details of such
practice will new
SPI may be specified elsewhere. used, including NES, I2 and R2. The HIP host may use any
identity it wishes; however, the identity may new SPI value
MUST be subject to local
access control by random, i.e., the FA. That is, some FAs may Mobile Host MUST NOT be willing able to serve
only some HIP hosts.

If guess
it. When the FA is willing to serve an address to Mobile Host receives the HIP host, new SPI value, it replies
to the FAQ with creates
a Forwarding Agent Advice (FAA) packet. A FAA
establishes an address lease to the HIP host. The HIP host can rely new outgoing SA and starts sending data on the FA to keep forwarding packets it.

3. The Peer Host waits for new data to arrive on the HIP host until the
address lease expires. If new SA,
indicated by the FA is not willing to serve SPI. Once it has succesfully received data on
the HIP
host, SA, it responds with a Forwarding Agent Denied (FAD) packet,
specifying marks the reason for denial.

Each new address lease has a lifetime. The HIP as reachable.

Mobile host may renew Peer host

REA parameter
----------------------------------->

new SPI
<-----------------------------------

data on new SA
----------------------------------->

Figure 2

The idea of the address lease at any time before it check procedure is that if the lease expires. Subject Mobile Host is
able to
its policy, succesfully construct the FA should renew and extend new outgoing SA, using the lease, but it MAY
refuse any extensions. In any case, new SPI
value, and send data on that SA, then 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, have received the FA simply discards
second message in the forwarding state protocol, and any
resources associated with it.

4.4.2 Recovering from forwarding agent crashes

If a FA crashes, therefore 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 must be to simulate lost state by the
actual HIP host that is leasing reachable at
the said 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

XXX: Residual threat: The security associations between the nodes are not any longer
directly connected Mobile Host able to anticipate the IP address of the node. The SA is
associated with the HIT KEY
index and there may be either one SA between the
nodes, or multiple SAs when guess the interface capabilities SPI value by trying out all? Not really, I
think, since it would 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 about 2^31 packets are received
within the IPsec reordering window. However, the latencies between
two interfaces are considerably different, it becomes more likely
that some of on the packets would be discarded due to appearing to have
been received outside of average...

6.1 Initiating the ESP reordering window. Thus, protocol in that NES

The most common case it is necessary to use different SAs for different interfaces.

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, carry the HIP host sends an FAQ, requesting
for an address lease. The host may specify readdress protocol on NES
packets. In this case, the type of address it
wants to have (IPv4, IPv6, either), Mobile Host initiates rekey (usually
using the number of SPIs requested, current Diffie-Hellman keys) and includes a REA parameter
on the desired lifetime. Any of these fields may be left empty, as
well. initial NES packet. 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 Peer host replies to solve this with a puzzle before
the Forwarding Agent is even willing
reply NES packet, sent to consider the request. Once
the HIP host has solved the puzzle, it may send new preferred address. As the FAQ again, this
time including an answer to Mobile
Host receives the puzzle.

XXX: Is reply NES, it OK that starts using the FA answers with a normal R1, or should we use
some other packet type, e.g., Forwarding Agent R1 (FAR1)?

If new outgoing SA.
Finally, as the FA is willing to serve Peer Host receives traffic on the HIP host, new incoming SA, 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
marks the HIP
host.

5.2 Renewing an address lease

Once an new address lease is about to expire, the HIP host may want as valid and switches over to
renew it.

HIP host Forwarding Agent

Forwarding Agent Query
----------------------------------->

Forwarding Agent Advice
<-----------------------------------

To renew a lease, use the HIP host simply sends a FAQ specifying an
existing lease, together new
outgoing SA, associated with the desired extended lease time, and
the FA replies with an FAA.

5.3 Readdressing and address status

HIP new address.

Mobile host Another Peer host

NES with REA
----------------------------------->

AC
record additional addresses
(prepare new incoming SA)
NES with new SPI in NES_INFO
<-----------------------------------

ACR
(prepare new incoming SA)
(switch to new outgoing SA)

data on new SA
----------------------------------->

When the host changes its IP address, gets more addresses or loses an
address, it may want
(switch to tell this new outgoing SA)
change to peer nodes. The preferred address
changing host sends the readdress packet (REA)

The text in (parantheses) indicate functions that are
performed anyway, as a part of NES processing, and not
new to the peer where it
tells all available addresses. The address update packet REA processing.

Figure 3

Basically, the processing structure is signed
providing proof about equal to the sending party.

As current NES
processing other than that the node receiving a REA packet cannot be sure if all Peer host records the received additional
addresses are valid even form the signature is correct, it REA parameter, sends the
Address Check (AC) packet NES reply to each of the new addresses received. If
the host receiving an AC message has sent
preferred address instead of the REA message that
matches current preferred address, and
updates the received AC message, preferred address as soon as it MUST send an Address Check Reply
(ACR) packet back to receives data on the peer for confirmation. New addresses
received in new
SA.

6.2 Initiating the protocol in R1 or I2

A Responder host MAY include one or more REA packet are ready to be used after parameters in the ACR packet
has been received.

If a node receives an AC packet that does not match to any REA R1
packet that is has sent out, it MUST drop sends to the packet. Such a packet may Initiator. These parameters MUST be
an indication that someone else is on purpose or on mistake sending a
false address to its peer.

6. Protocol definition

The location information update procedure in
protected by the HIP consists of R1 signature. If the
readdress R1 packet telling the current set of addresses that contains REA
parameters, the node
is using, address check and address check replies. With this set of
messages Initiator SHOULD send the IP addresses can be updated I2 packet to the peer and the peer is
able to verify new
preferred address. The Responder MUST make sure that the addresses are valid.

In addition to the actual address update, the HIP node puzzle
solution is provided a
possibility to get leased addresses from the FA. The FA can provide
address(es) (and a range of SPIs) valid BOTH for the HIP node initial IP destination address used
for I1 and for the HIP node
can use this towards other nodes. new preferred address. The FA thus forwards packets to I1 destination address
and the
HIP node when 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 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 be any address to allow middleboxes an optimized rendezvous server to verify the
integrity send an
R1 instead 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 actual host?

An Initiator MAY include one or more REA packet. This is a potential DoS attack against parameters in the
Intermediate system, as I2 packet,
independent on whether there was REA parameter(s) in the signature processing may R1 or not.
These parameters MUST be relatively
expensive. A further step against attack for protected by the Intermediate
systems is to implement ESP's replay protection of windowing I2 signature. Even if the
sequence number. This requires
I2 packet contains REA parameters, the intermediate system to track ALL
ESP packets Responder MUST still send the
R2 packet to follow the Sequence Number.

Optionally, source address of the message may contain an ESP protected datagram. This
datagram is processed as if it had arrived separately. I2. The purpose
of allowing datagrams to new preferred address
SHOULD be embedded inside the REA packet is identical to
increase the efficiency of transmitting the first I2 source address.

Initiator Responder

I2 with REA
----------------------------------->
(process normally)
record additional addresses
R2 with new SPI in LSI_SPI
<-----------------------------------
(process normally)

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 new SA
------------------------------------>
(process normally)

Figure 5

6.3 Explicit address check

When the same
type of problems Peer Host wants to use a new address 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 has not 100% sure that
there are no other problems.

6.1.1.1 REA_INFO payload

Note that yet been
checked, it must first run check the REA_INFO payload is a kind reachability of "expanded" NES.

XXX (Pekka): Note that I have, for the time being, removed the old
ESP sequence number. Firstly, it may be hard address
before sending any large amounts of data to acquire reliably in
some implemtations (ours included). Secondly, we now have a REA ID
field, which is basically a the address. See Section
8.3.

7. Parameter and packet formats

7.1 REA sequence number. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current SPI in reverse direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keymaterial index | REA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 128 1 (first non-critical)

Length Length in octets, excluding Type and Length
fields 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
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 host. 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. IDs may have any values, and need not be consequtively
allocated.

Address Lifetime Address lifetime lifetime, in seconds.

Reserved Zero when sent, ignored when received received.

Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address
[2] [2].

The Interface ID field identifies the (logical) interface that this
packet
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 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 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 SA following address is changed, and if the SA
expected to be valid. The lifetime is not used at any other
interface any more, it expressed in seconds. Each
address 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 non-zero lifetime. The HMAC SHA-1 address is used expected 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ HMAC data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 65532
Length Length in octets, excluding Type and Length fields
HMAC data 20 bytes
become deprecated when the specified number of HMAC SHA-1 data

6.1.2 AC and ACR - seconds has passed
since the HIP Address Check reception of the message. A deprecated address SHOULD NOT
be used as an destination address if an alternate (non-deprecated) is
available and Address Check Reply has sufficient scope. Since IP addresses are ignored
upon reception, deprecation status does not have any affect on the
receiver.

The HIP Address Check (AC) and Address Check Reply (ACR) packets
contain field contains an AC_INFO payload, followed by IPv6 address, or an IPv4 address in the
IPv4-in-IPv6 format [2]. The latter format denotes a HMAC.

In addition plain IPv4
address that can be used to acting as 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 address probe, unexpected reply, the Address Check packet is simply dropped.

This specification changes the semantics of the R-bit slightly. (It
is expected that this change may also acts 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 implicit acknowledgement to explicit
NES_INFO as a REA packet.

6.1.2.1 AC_INFO payload

Type 129
Length Length reply, one if no reply is needed.

Processing NES packets currently defines the following behaviour.

If the system is in octets, excluding Type state E3 and Length
fields
AC ID A 16-bit sequence number of nonce, used to match the AC NES has the R-bit set, the
packet to is silently dropped.

The new behaviour is defined as follows.

If the corresponding ACR packet. 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 ID

A 16-bit sequence number of nonce, used to match
the single REA is included in a NES 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 - between the NES_INFO and
HMAC parameters:

IP ( HIP Forwarding Agent packets

The ( 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 FAQ, FAA ( REA1, REA2, NES_INFO1, NES_INFO2, [ DH, ] ... ) )

7.4 R1 and FAD I2 packets contain an FA_INFO payload, with included REA

The REA parameter is included early in the R1 and
possibly other payloads. I2 packets, since
middle boxes may be interested in inspecting them. If a forwarding agent sends an R1 REA is not
present, a typical middle box is only interested in
response to FAQ, the second FAQ must also contain an BIRTHDAY_COOKIE
payload, containing the cookie response. The FAA, SPI_LSI
parameter and FAD packets
MUST contain a the signature.

IP ( HIP ( REA,
BIRTHDAY_COOKIE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
( HOST_ID or | HOST_ID_FQDN payload. The FAA packet MAY
contain a ),
HIP_SIGNATURE_2 ) )

IP ( HIP ( SPI_LSI,
REA,
BIRTHDAY_COOKIE,
DIFFIE_HELLMAN,
HIP_TRANSFORM,
ESP_TRANSFORM,
ENCRYPTED { HOST_ID or HOST_ID_FQDN payload.

6.1.3.1 FA_INFO payload

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

Request ID A 16-bit sequence number HOST_ID_FQDN },
HIP_SIGNATURE ) )

8. Processing rules

XXX: This section needs more work.

8.1 Sending REAs

The decision of nonce, used when to
match 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 FAQ packet 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 corresponding
FAA/FAD packet.
Lease ID A 16-bit number XXX
Lease duration Duration of various addresses into
interfaces, and whether to include any addresses on multiple
interfaces. Since each interface is associated with a different
Security Association, the lease
Reserved Zero when sent, ignored when received
Addr type Address type: 4 for IPv4 grouping policy may be based on IPsec
replay protection considerations. In the typical case, simply basing
the grouping on actual kernel level physical and 6 for IPv6 (TBD)

6.2 Requesting Address Leases

To request address leases from logical interfaces
is often the FA, best policy. Virtual interfaces, such as IPsec tunnel
interfaces or Mobile IP home addresses SHOULD NOT be announced.

Once the HIP node sends an FAQ
packet to host has decided on the FA. The FAQ packet consists interfaces and assingment of
addresses to the HIP header, FA_INFO
payload and interfaces, it creates a HIP_SIGNATURE. REA parameter for each
interface. If there are multiple interfaces and therefore multiple
parameters, the FAQ packet parameters MUST be ordered so that the new preferred
address is in the second one first REA parameter.

The REA parameters MAY be sent
from in R1, I2 and NES packets. If the HIP node
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 FA, i.e. REA parameters in the FA responded newly generated
NES packet.

If there are multiple REA parameters leading to a packet size that
exceeds the first FAQ
with an MTU, the host SHOULD send multiple packets, each smaller
than the MTU. In the case of R1 packet, a BIRTHDAY_COOKIE payload containing and I2, the cookie
response must additional packets
should be included in NES packets that are send after the packet.

6.3 Providing address Leases 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 the FA a host receives an FAQ packet from a HIP node, REA parameter, it may verify first performs the
signature in following
operations:

1. The host checks if the packet. 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 FA does not trust on REA parameter, check that the requesting
node,
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 generate an R1 packet containing a puzzle for be allowed that the
requesting host runs HIP node. with itself.

3. For each address listed in the REA parameter, check if the
address is already listed at the interface. If the FA trusts to address is
listed, its lifetime is updated. If the requesting HIP node, or address is status is
DEPRECATED, the HIP node
responded status is changed to UNVERIFIED. if the R1 packet with a new FAQ with a solved puzzle, address
is not listed, the
FA can allocate address(es) address is added, and possibly SPIs for its status is set to
UNVERIFIED.

4. Mark all addresses at the requesting
node. The FA_INFO payload may contain information about interface that were NOT listed in the requested
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 requested SPI ranges. If these requests can be met, REA parameter as DEPRECATED.

Once the FA may allocate address(es) and possible SPIs for host has updated the requesting
node.

If interface, if the allocation request was accepted and REA parameter
contains a new preferred address, the host SHOULD initiate a successfull reservation change
of data was performed, the FA responds to preferred address. This usually requires that the requesting node with a
FAA packet. The FAA consists host first
verifies reachability of an FA_INFO payload describing the
address(es) address, and possible SPIs that are reserved for only then changes the requesting
node.
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 FA was not able host is replying to allocate address(es), SPIs a R1 with an I2,
to an I2 with an R2, or the
request was malformed, the FA responds to a initial NES with a FAD reply NES, then the
verification is piggybacked on the I2, R2, or reply NES packet.

6.4 Sending REAs

The HIP node may want
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 address information to R2, NES-reply or
unidirectional-NES, the peer node
whenever there are updates in Peer Host MUST prepare a new incoming SA,
using the addresses SPI value included in R2 or NES, so that are assigned to it.
The leased addresses can be considered also to be possible addresses
and they must be assigned it is prepared to
receive traffic on the new SA.

Note that in the case of receiving a logical interface.

The REA packet contains on an R1 and replying with
an I2, receiving the HIP header, one or more REA_INFO,
HIP_SIGNATURE corresponding R2 is sufficient for marking the
Responder's primary address active, and HMAC TLVs. The REA_INFO describes all there is no need to wait for
data to appear on the SA. On the other hand, marking the addresses
that are associated with that particular interface identifier. If a
previously associated address
active as a part of receiving data on the SA is an idempotent
operation, and does not included 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 list, preferred address

A host MAY want to change the peer
considers it as a lost preferred outgoing address and removes it from for many
reasons, e.g., because traffic information or ICMP error messages
indicate that the currently used preferred address
associations.

6.5 Handling received REAs at end hosts

When a HIP node receives may have become
unreachable. Another reason is receiving a REA packet, it verifies parameter that has
the signature in
it. P-bit set.

To change the preferred address, the host initiates the following
procedure:

1. If the packet was valid, it may initiate an address check
procedure. The new preferred address check (AC) packet is sent to all addresses
that were not listed in on any interface, the REA_INFO payload. The HIP node receiving
procedure fails.

2. If the
REA packet from a node that it trusts, may accept all new preferred address has DEPRECATED status and there is
at least one non-depraceted address, the host selects one of the
non-deprecated addresses
without making any as a new preferred address check for them. and
continues.

3. If ACs are sent, the
addresses in new preferred address has ACTIVE status, the REA_INFO must not be used until corresponding ACR
packet preferred
address is received from changed and the peer node.

7. 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

TBD

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,
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
public key, and hence it becomes impossible to hijack the
communications of another node host through the use of the REA message.
Similarly, since only the node 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 node 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.

Malicous

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.

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
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

11. IANA Considerations
10.
12. Acknowledgments

Thanks to Kimmo Nieminen.
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 R. Moskowitz, P. Jokela, "Host Identity
Protocol",
draft-moskowitz-hip-06 draft-moskowitz-hip-07 (work in progress), May June 2003.

[4] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-03 (work in progress), May 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]

[7] 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 draft-nikander-mobileip-v6-ro-sec-01 (work
in progress), April 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
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 Changes from the received IP addresses. previous versions

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 From -00 to
the one source address selected during the connection set up. -01

The
node actual protocol has multiple IP addresses been largely revised, based 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 new
symmetric New SPI (NES) design adopted in the
node. The policies can be defined locally base protocol draft
version -08. There are no more separate REA, AC 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 ACR packets, but
their functionality has been folded into the knowledge about NES packet. At the NAT box between itself same
time, it has become possible to send REA parameters in R1 and the peer node. I2.

The address Forwarding Agent functionality was removed, since it looks like
that the HIP node sends to the peer
node must it will 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 moved to the proposed HIP node finds out that Research Group. Hence,
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 will be two other side of the NAT. They
still need not documents related to be globally routable as there may be another NAT
box on the path. that, a simple
Rendezvous server document (WG item) and a Forwarding Agent document
(RG item).

Appendix B. Implementation experiences
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

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
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.