Network Working Group J. Melen
Internet-Draft J. Ylitalo
Intended status: Experimental P. Salmela
Expires: November 27, 2009 Ericsson Research NomadicLab
T. Henderson
The Boeing Company
May 26, 2009
Host Identity Protocol-based Mobile Router (HIPMR)
draft-melen-hip-mr-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 November 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Melen, et al. Expires November 27, 2009 [Page 1]
Internet-Draft HIP Mobile Router May 2009
Abstract
This drafts defines a moving network support for HIP enabled hosts.
The protocol uses asymmetric authentication and symmetric
authorization. The solution presented in this draft is based on
delegation of signalling rights between mobile nodes and mobile
routers that results in route optimization between end-hosts.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background and Primary Use Case . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Pre-Movement Phase . . . . . . . . . . . . . . . . . . . . 8
3.2. Node Movement Phase . . . . . . . . . . . . . . . . . . . 8
3.3. Delegation Phase . . . . . . . . . . . . . . . . . . . . . 8
3.4. Network Movement Phase . . . . . . . . . . . . . . . . . . 9
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
4.1. Mobile Router Discovery . . . . . . . . . . . . . . . . . 10
4.2. HIP base/update exchange between the MN and its peers . . 10
4.3. Mobile Node Authorizes a Mobile Router . . . . . . . . . . 10
4.4. MR runs update exchange with the peer nodes . . . . . . . 12
4.5. Leaving a Moving Network; Revoking tickets . . . . . . . . 13
4.6. Kerberos vs. Ticket based Delegation of Signalling
Rights . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Using the keying material . . . . . . . . . . . . . . . . 15
5. Packet processing . . . . . . . . . . . . . . . . . . . . . . 16
5.1. End-to-end Base Exchange . . . . . . . . . . . . . . . . . 18
5.2. End-to-end update exchange . . . . . . . . . . . . . . . . 20
5.3. Payload Packet Processing . . . . . . . . . . . . . . . . 21
6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Future work . . . . . . . . . . . . . . . . . . . . . 28
A.1. Static Signalling Proxies in the Fixed Network . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Melen, et al. Expires November 27, 2009 [Page 2]
Internet-Draft HIP Mobile Router May 2009
1. Introduction
The Host Identity Protocol (HIP) [RFC5201] has been designed to allow
hosts to preserve existing security associations and higher-layer
protocol sessions by defining host mobility and multihoming
mechanisms [RFC5206]. Specifically, a mobile or multihomed host that
changes its IP address, or acquires new addresses, can securely
notify its corresponding peers of the new address(es). Similarly, a
mobile HIP-aware host can update information about its current IP
address(es) by updating records in HIP Rendezvous Servers [RFC5204]
or other name services.
However, in many situations, hosts do not move independently but as
part of an overall mobile network. Trains, buses, airplanes and
Personal Area Networks (PANs) are examples of where different mobile
network technologies can be applied. Herein, a mobile network is
defined as a cluster consisting of mobile nodes (MNs) and mobile
routers (MRs) [RFC3753], for which the IP addresses used to reach the
mobile network must change due to the local topology. A mobile
router connects the mobile network to the Internet or other larger
network, and at a minimum, the IP address of the link to which the
mobile router connects must be consistent with local addressing.
When the mobile nodes are moved along with the mobile network, they
change their topological location together with the mobile router.
On the other hand, when they move independently, they change their
topological location independent of the mobile router.
This draft describes HIP protocol extensions that allow a HIP-based
mobile network to use the services of a HIP-aware mobile router for
mobility management. Specifically, the HIP-aware hosts that are
clients of the HIP-aware mobile router delegate to the MR the
authority to signal mobility-related updates on their behalf. Two
approaches to perform the delegation are outlined herein. One
authorization system is architecturally similar to the well known
Kerberos [RFC4120] system, but differs in many details and in the
area of application. The second authorization system presented is a
public-key-based authorization.
Melen, et al. Expires November 27, 2009 [Page 3]
Internet-Draft HIP Mobile Router May 2009
2. Background and Primary Use Case
In general, there seems to be three fundamentally different
approaches to network mobility:
Approach-1: A simplistic approach is to forget that there is a
moving network and consider the moving nodes as separate mobile
nodes. Each of the mobile nodes takes care of mobility signalling
separately. The problem with this approach is that it leads to
high amounts of signalling and long hand-off reaction times. This
approach may require the mobile router to acquire a block of new
addresses (one for each mobile node) rather than just a single new
address.
Approach-2: A tunnelling approach is to create a tunnel from the
Mobile Router in the mobile network to some home router in the
fixed network side. All traffic is routed through this tunnel,
making the mobile network appear to be at a fixed location. The
problems with this approach are suboptimal routing (so called
triangular routing) and the larger packet size caused by
tunnelling overhead. A possible optimization is NEMO optimization
(cite the approaches).
Approach-3: A third approach is to make the mobile nodes delegate
the right to do mobility signalling to the mobile router, which
under certain conditions may delegate this right further to
another router in the fixed network side. However, the mobile
router presents itself to the visited network as a single node,
and performs network address translation on behalf of the mobile
nodes. This draft presents a variant of this approach.
One possible sequence of events is as follows. Mobile nodes on a
mobile platform register with the mobile router, using the HIP
registration extension [RFC5203]. The MN may discover the MR via a
router advertisement or preconfiguration. The mobile nodes next
perform a delegation to the mobile router; this delegation will
authorize the mobile node to generate and process some HIP-related
signaling messages upon mobility events. A possible first action for
the mobile router may be to notify the mobile host of its reachable
IP address if it differs from the one assigned to it on the local
network segment. Another possible first action is to allow the MR to
update the MN's record in DNS or the rendezvous server.
Some time later, the mobile host or a peer may initiate a HIP base
exchange with a peer located outside the mobile network. Since the
IP address used by the MN may not correspond to the publicly
reachable address, the MR inserts parameters into the HIP base
exchange that tell each party in the session about the presence of
Melen, et al. Expires November 27, 2009 [Page 4]
Internet-Draft HIP Mobile Router May 2009
the address mapping. These parameters may be authenticated by the
peer by virtue of the authorization tokens delegated to the MR by the
MN. Additionally, the MR establishes binding state and tracks that
there is an active session between a MN and a peer. In particular, a
SPINAT [I-D.melen-spinat] state for the association must be created
and maintained at the MR; the SPINAT maps the MN's IP address and SPI
value to public values. SPINAT can be thought of NAT-PT in which the
port translation is replaced by SPI translation.
Some time later, the mobile host or the peer may rekey their security
association or generate new keying material. The MR may translate
the IP address of such messages and optionally add NAT_ESP_INFO
parameter to the messages (see [I-D.melen-spinat]). Otherwise, the
MR does not participate in any keying-related exchanges; the end-to-
end encryption and authentication keys used by HIP are not known to
the MR or any other on-path observer.
Next, assume that the MR changes its attachment to the network and
obtains a new public-facing IP address. While packets sent from a MN
to a peer may still successfully reach the peer, packets from a peer
to the MN, or any new connection attempts to the MN, will fail. In
this scenario, the MR will generate an update message to the peer and
to any name services that the MN is connected to.
As a result of a mobile router hand-off, the mobile router sends an
update message to the peer nodes for which it holds binding state.
The mobile router uses its authorization token to digitally sign the
update messages that it sends to the peer nodes on behalf of the
mobile node. The peer node verifies received update messages using
the token. The MR should also notify the MN of the change of
address, although it is not strictly required.
A few variations of this scenario are possible. In the nested moving
network case, the mobile router may attach to and run registration
exchange with another mobile router. Once the two mobile routers
have a security association between them, the authorization token can
be sent over the protected channel to the new mobile router. The
approach described herein admits such a possibility, but we will not
describe it in any further detail for now.
Another variation is that the MN may not be HIP aware. In this case,
the MR may act as a "HIP proxy" for one or more MNs in the mobile
network. In such a case, the MR holds the HIP key for the MN and
participates in the full HIP signaling and encryption without the
participation of the MN. We do not consider this scenario further in
this draft.
Another variation is that a MN may initially create associations with
Melen, et al. Expires November 27, 2009 [Page 5]
Internet-Draft HIP Mobile Router May 2009
peers and subsequently move behind a HIP-aware mobile router. In
such a case, the MR can not participate in the base exchange but must
participate in the UPDATE exchange. Details of this case must be
worked out further; in particular, the MN must be able to discover
and register with the MR before initiating any UPDATEs to peers. HIP
may need to be extended to allow a HIP MR to ask a MN to register
with it, before allowing the UPDATE to proceed.
Two authorization and authentication frameworks for delegating rights
to a MR are proposed herein. The first is based on a Kerberos-like
ticket model. Here, the ticket is issued by the MN to the MR and
passed to the MR during the registration base exchange. This ticket
may be further passed onward to an upstream MR without participation
by the MN; i.e., any node that acquires the ticket is then
authorized. The ticket contains an HMAC key that is used by the MR
to sign its message parameters. The ticket has a lifetime, and may
be revoked. The security is based on that the new HMAC session key
is given only to trustworthy mobile routers. The lifetime of the
session key and the revoke mechanism also protects the mobile node
from the misuse of the given tickets. The second mode is based on
public-key delegation using certificates. Here, the MN gives each MR
a certificate (with lifetime) and the MR must sign its messages with
the key authorized in the certificate. This approach requires
asymmetric public-key verification by the peer node but has a benefit
over the Kerberos-like approach in that the MN can enforce that the
MR cannot further delegate its signalling rights upstream without the
participation of the mobile node.
Melen, et al. Expires November 27, 2009 [Page 6]
Internet-Draft HIP Mobile Router May 2009
3. Protocol Overview
The basic idea of the solution presented in this draft allow mobile
nodes (MN) to securely delegate to mobile routers (MR) the authority
to notify the peers of the MN whenever the MR moves with a resulting
addressing change. The security is based on the MN sharing with the
MR a portion of its symmetric key space (derived during the HIP base
exchange), with which the MR can compute HMACs on the mobility update
messages (MR). The overall approach of security delegation resembles
that of Kerberos [RFC4120]. The delegation of the signalling rights
is based on two trust relationships: 1) Trust relationship between a
mobile node and a peer node and 2) Trust relationship between a
mobile node and a mobile router. The peer node need not have any
pre-existing trust relationship with the MR.
In one typical use case, a MN may be semi-permanently located behind
a MR, such as a host connected to a mobile router on a mobile
platform. Typical operations for this use case, which we call the
"MN dedicated to a MR" case, can be considered to consist of these
phases:
o Pre-movement phase, where the MN creates HIP associations through
the MR with any number of its peers.
o Delegation phase, where the MN creates new keys and passes them
both to the MR and its peers.
o Network movement phase, where the MR changes its location and
informs all the peers of all of the MNs about the movement.
Another use case is when the MN is itself mobile and moves behind an
existing MR even though it has already established security
associations beforehand. We call this case the "roaming MN" case,
which can can consist of these phases:
o Pre-movement phase, where the MN creates HIP associations with any
number of its peers.
o Node movement phase, where the MN moves to a location that is
behind a MR and finds the MR.
o Delegation phase, where the MN creates new keys and passes them
both to the MR and its peers.
o Network movement phase, where the MR changes its location and
informs all the peers of all of the MNs about the movement.
Melen, et al. Expires November 27, 2009 [Page 7]
Internet-Draft HIP Mobile Router May 2009
3.1. Pre-Movement Phase
As in any typical use of HIP [RFC5201], this draft is based on an
assumption that the MN and its peer nodes create pieces common keying
material using the Diffie-Hellman method during the HIP base
exchange. This keying material is known only by the two hosts
participating to its creation. Keys drawn from the keying material
are used to protect the HIP signalling (e.g. location update
messages) [RFC5206] and data transmission between the nodes.
3.2. Node Movement Phase
When the MN moves behind a mobile router it will get information
about available mobile routers by monitoring incoming beacons that
the mobile routers use to advertise themselves. Once a suitable
router is found, the MN initiates a HIP base exchange with the mobile
router, and using the HIP registration extension [RFC5203], the MN
registers itself as a user of the mobile routing service, provided by
the mobile router.
The mobile sends runs update exchange with the peer nodes to updates
its HIP association. The mobile router transparently establishes a
SPINAT [I-D.melen-spinat] state per each end-to-end HIP session by
intercepting the end-the-end update exchange messages and forwarding
them between end-points.
3.3. Delegation Phase
The task of the mobile router is to act as a signalling proxy and
SPINAT node between the MN and its peer nodes. With this
arrangement, the amount of signalling is minimized when the mobile
router changes its location and location updates are sent to active
peer nodes. To be able to send HIP location update messages on
behalf of the mobile nodes inside the mobile network the mobile
router needs a so-called HMAC key from the MN. Knowing the mobile
node's HMAC key the mobile router can create HMAC protected messages
on the behalf of the MN, thereby being able to represent it by means
of symmetric cryptography.
To avoid aliasing and replay problems, the mobile node needs to
create a new HMAC key, for each of its peers, each time it wants to
use mobile routing service. The MN selects a new key for this
purpose from the keying material that it already has with its peer,
and prepares a ticket to be sent to the mobile router over the
negotiated ESP Security Association. The ticket contains the
following information:
Melen, et al. Expires November 27, 2009 [Page 8]
Internet-Draft HIP Mobile Router May 2009
o The new HMAC key to be used by the mobile router to calculate the
HMAC protected messages on the MN's behalf.
o Authentication information, which contains the same new HMAC key
(or key index information that the peer can use to get the same
key from its own keying material), integrity protected and
optionally encrypted with the HIP session key(s) that were
initially negotiated between the MN and its peer. The mobile
router cannot decrypt or modify this part of the message without
the peer noticing it.
3.4. Network Movement Phase
When the mobile router changes its location, it creates location
update packets for the mobile nodes behind the mobile router.
However, the update can be distinguished from an end-to-end update by
the use of a special "UPDATE-PROXY" message type. Each location
update contains the MN's HIT as the source HIT and includes location
update information as if it was sent by the MN itself. To
authenticate the packet, the Mobile Router inserts a new parameter
into the packet. The new parameter contains 1) the unmodified
authentication information from the ticket it received from the MN,
and 2) an HMAC calculated using the new HMAC key received from the
MN. This packet is delivered to the peer node. The peer can verify
the authentication information part of the packet and get the HMAC
key. Using this key, it can verify that the incoming update packet
was sent by a node authorized by the Mobile Node.
If the mobile router moves behind another mobile router (nested
mobile routers), it can deliver received tickets to the new mobile
router which in turn is capable of making location updates to peer
nodes based on the information received in these tickets. Because
there is no association between the peer and the mobile router, there
is no need to provide any additional information about the previous
mobile router and the same ticket can be used by the new mobile
router for location updates.
If the MN moves out of the mobile network, it needs to revoke the old
keys. It sends an update message to the peer containing information
about the keys that are no longer valid. After receiving this
information the peer node does not accept any new location updates
with that key.
Melen, et al. Expires November 27, 2009 [Page 9]
Internet-Draft HIP Mobile Router May 2009
4. Protocol Description
The mobile router consists of two integrated services: i) a
signalling proxy and ii) SPINAT services. The signalling proxy and
SPINAT services are presented in separate drafts. This draft defines
the signalling proxy service and defines some extensions to the HIP
base and update exchanges. The signalling proxy service is used to
establish, update and create SPINAT states for ESP packets. The
SPINAT service is presented in [I-D.melen-spinat].
4.1. Mobile Router Discovery
The mobile node must discover the mobile router. For this purpose,
the HIP base exchange, combined with the registration extension
[RFC5203], can be used for the service registration procedure as
presented in draft [I-D.jokela-hip-service-discovery]. The mobile
node requests a mobile routing service from the mobile router using
the registration extension.
4.2. HIP base/update exchange between the MN and its peers
Either before or after the valid registration exchange, the mobile
node runs a HIP base-exchange or an update exchange with its peer
node as described in [RFC5201]. Typically, the base exchange is used
with new peers and updates are used with existing peers. As a result
of the base exchange, the mobile node and its peers posses mutual,
secret keying material that is used to generate various keys,
including those used to protect the HIP mobility management messages.
The end-to-end HIP base/update exchange creates a SPINAT state at the
mobile router (see [I-D.melen-spinat]).
4.3. Mobile Node Authorizes a Mobile Router
With the mutual keying material available with its peers, the mobile
node creates tickets (Figure 1), one for each of its active peers, to
authorize the mobile router to signal on behalf of the MN. A ticket
contains the end-to-end session key, for HMAC integrity protection
calculation, generated by the mobile node and to be generated or
received by the peer node. This new HMAC session key is later used
to protect the mobility management messages that the mobile router
sends to the peer node on behalf of the mobile node.
In addition to the new HMAC key, the mobile node includes other
relevant information in the ticket, like lifetime and what type of
authorization this is. This information is protected using HMAC with
the HIP session key agreed between the mobile node and the peer, and
it may be encrypted. The mobile router doesn't have the HIP session
Melen, et al. Expires November 27, 2009 [Page 10]
Internet-Draft HIP Mobile Router May 2009
key between the MN and its peer, and therefore the mobile router
cannot modify (or decrypt) the part of the ticket that is protected
with end-to-end keying material. The ticket has to contain, at
least, either the same HMAC key that is given to the mobile router or
a pointer to the place in the shared keying material from where the
key was drawn so that the peer can draw the same key. In addition to
the key information, the integrity protected part of the ticket can
contain also other information if needed.
Encrypted {
HI-MN; HI-PEER;
HI-issuer; HI-subject;
HMAC-key;
HMAC {
HMAC-key-index;
Action;
Lifetime;
} Key-MN-PEER
} Key-issuer-subject
Figure 1: Signalling proxy Ticket information
Figure 1 shows the ticket that is sent either from the MN (issuer) to
the MR (subject), or in case of nested mobile routers, from MR1
(issuer) to MR2 (subject). The key Key-MN-PEER is only known by the
MN and the peer. It is used to protect the integrity of the
authentication information from modifications.
If, instead of the HMAC-key-index, the whole HMAC-key is included in
the authentication information, the HMAC-key must be encrypted with
the key known only by the MN and the peer.
Note that the mobile node cannot deny the mobile router the
permission to give the tickets further to other mobile routers, as it
cannot prevent the mobile router from distributing the new HMAC-key
to other nodes.
{
HI-MN; HI-PEER;
HMAC {
HMAC-key-index;
Action;
Lifetime;
} Key-MN-PEER
}
Figure 2: Authentication ticket (Extracted from signalling proxy
ticket)
Melen, et al. Expires November 27, 2009 [Page 11]
Internet-Draft HIP Mobile Router May 2009
Figure 2 shows the authentication information, as extracted from the
ticket, that is sent from the MR to the peer when the MR updates
location information at the peer.
4.4. MR runs update exchange with the peer nodes
Once the mobile router changes the location, it creates location
update packets to be sent to peers based on the information about the
location change and the information that it had earlier received from
the mobile hosts.
The update packet contains the following information:
o The new IP address of the mobile node as seen by the peer node.
(Note: the mobile router implements the SPINAT functionality.)
o The authentication information as extracted from the received
ticket.
o A HMAC integrity code, calculated using the new HMAC key.
To avoid attacks related to the location update exchange, the peer
nodes must send challenges to the mobile node's claimed location
(i.e., reachability test). In practice, these challenge messages are
destined to the mobile router. The mobile router on the forwarding
path uses the new HMAC key to protect the reply message and sent the
message back to the peer nodes on behalf of the mobile nodes.
To distinguish the UPDATE from an end-to-end UPDATE exchange, a new
message type ("PROXY-UPDATE") is used. The peer node knows from this
message type that the HIP message was not generated by (and cannot be
signed by) the MN HIP host. From a message processing perspective, a
PROXY-UPDATE is handled similarly to a regular UPDATE. Notably, the
MN may simultaneously be in the process of a separate UPDATE exchange
with the peer for other reasons (e.g. rekeying). Therefore, both an
UPDATE exchange and PROXY-UPDATE exchange may be occurring
concurrently.
When a mobile router (MR1) moves into another mobile network, it
becomes the client for the next level mobile router (MR2). The MR1
sends the tickets it has received from its own network to the next
level mobile router (MR2) so that MR2 can send the location updates
also on behalf of the mobile nodes behind the MR1. Because there is
no association between the MR1 and the peer nodes, it doesn't need to
add any own information to the ticket, but it can deliver them
directly to the MR2. The MR2 gets all needed information from the
tickets.
Melen, et al. Expires November 27, 2009 [Page 12]
Internet-Draft HIP Mobile Router May 2009
Long ticket lifetimes allow the mobile router to signal on behalf of
the mobile node after the node has moved away from the mobile
router's link. Therefore, the lifetime of ticket is the estimated
locator lifetime at the mobile node's current location. The mobile
node generates a new ticket if it stays longer in the same link than
it initially expected. The mobile node stores also a ticket
revocation list. The list consists of hashes of active tickets that
were sent to the previous mobile routers. After the mobile node
leaves a moving network, it informs its active peers about the
revoked tickets using an enhanced location update exchange.
4.5. Leaving a Moving Network; Revoking tickets
Once a mobile node leaves a moving network it should revoke the
ticket both at the peer and at the mobile routers. The revoke
mechanism for tickets will be added for the draft version -03.
The rough idea is following. The revoke message must be sent to the
peer nodes and should be sent to the rendezvous of the mobile router.
The mobile node receives the rendezvous locator of the mobile router
during the registration exchange.
4.6. Kerberos vs. Ticket based Delegation of Signalling Rights
The signalling trust between the HIP enabled nodes is purely based on
the secret session key material that is generated during the initial
authenticated Diffie-Hellman (DH) key exchanges, i.e., the HIP base
exchanges. The generated session keying material is used to derive
new keys, which in turn are used to authenticate the proxied update
messages.
There is a clear analogy between this approach and the existing, well
known Kerberos [RFC4120] system. The mobile node acts like a
Kerberos-KDC, the mobile router works as a Kerberos-client, and the
peer node represents the Kerberos-service. However, there are also
differences due to which the legacy Kerberos system cannot be used as
such in this draft.
In Figure 3, the based relation to the Kerberos model is illustrated.
In the case of nested mobile routers, the Mobile Router 1 would
become a KDC and the Mobile Router 2 would become the client, when
the MR1 moves behind the MR2.
Melen, et al. Expires November 27, 2009 [Page 13]
Internet-Draft HIP Mobile Router May 2009
"Kerberos: client"
+--------+ +--------+
| MR1 | | MR2 |
+--------+ +--------+
^
"Kerberos: KDC" | "Kerberos: peer"
+--------+<-(SA)-+ +--------+
| MN |<--Security Association (SA)----->| Peer |
+--------+ +--------+
Figure 3: Relationship to Kerberos model
The difference between Kerberos and the solution presented in this
draft is that this draft relies only on the session keys, not on the
identifiers. In Kerberos, the ticket contains an encrypted
identifier of the principal that is allowed to access the service.
That encryption key is known only by the KDC and the service. In the
nested moving network case this causes scalability problems. As
earlier described, each nested mobile router acts as a client for the
next mobile router higher in the group hierarchy. Once the nested
mobile router approves a ticket to the other mobile router it also
becomes a KDC itself. However, the mobile router (middle-box) does
not have a security association with the peer node. As a result, the
nested mobile router (i.e. KDC) cannot encrypt the identifier of the
other mobile router to the ticket.
To overcome the problem, this solution approves only anonymous
tickets. In other words, the host (principal) that knows ("owns")
the secret session key, is allowed to signal on behalf of the mobile
node. Each mobile node (/nested mobile router) authenticates mobile
router in the architecture with the HIP base-exchange. Thus, the
mobile node (/nested mobile router) does not approve a ticket to the
mobile router if the authentication fails.
The situation with the ticket based delegation scheme is partially
similar to the public key based delegation scheme. Once using SPKI
[RFC2693] authorization certificates the issuer of the certificate
can only limit the length of the authorization chain. The issuer
cannot know how the principals in the chain act. In other words, the
mobile node trusts the link local mobile router to delegate the
signalling rights to another trustworthy mobile router. The same
kind of trust chain applies also to the ticket based authorization
scheme. Instead of expressing the trust with certificates this
solution uses symmetric key based tickets to authorize nodes in the
architecture. This solutions uses asymmetric cryptography to
authenticate client to the KDC and symmetric cryptography to
authorize the client.
Melen, et al. Expires November 27, 2009 [Page 14]
Internet-Draft HIP Mobile Router May 2009
4.7. Using the keying material
When the mobile host performs a HIP base exchange with the peer node,
they generate keying material using Diffie-Hellman method. From this
keying material (same for both hosts) they can retrieve keys
sequentially for HIP (encryption and authentication) as well as ESP
(encryption and authentication). During a session, hosts can re-key
the ESP association during which new keys for the ESP Security
Association are drawn from the keying material. HIP association keys
remain the same during the whole session.
This solution uses the same keying material for drawing keys for the
HMAC protected update messages from the mobile router to the peer
node. In normal case, the MN uses the HIP authentication key for
calculating the HMAC in update message. Because of the requirement
that the MN must be able to revocate the key that is sent to the MR,
the originally drawn HIP authentication key cannot be used. Thus, a
new key is retrieved from the keying material and sent to the mobile
router.
To be able to keep the mobile node's and peer node's keying material
pointers synchronized, the index value has to be transmitted between
the nodes. This is done in the authentication information that the
mobile node sends to the mobile router, which in turn delivers it to
the peer unmodified in location update messages.
The peer node can decrypt the received authentication information, if
all delegation information is properly delivered earlier, and it can
trust that the mobile router is acting on behalf of the correct
mobile node.
Melen, et al. Expires November 27, 2009 [Page 15]
Internet-Draft HIP Mobile Router May 2009
5. Packet processing
The following flow chart (Figure 4) illustrates the delegation of
signalling rights using tickets, for the "MN delegates to fixed MR"
case:
+--------+ +-------+ +--------+
| MN | | MR1 | | Peer |
+--------+ +-------+ +--------+
| | |
| 1. serv. disc. | |
|<-----------------| |
| | |
| | |
|2. registration exchange |
|<---------------->| |
| 3. base exchange: generate session keys |
|<------------------------------------------------------>|
| |
|4. provide ticket | |
|<---------------->| |
|5. update exchange |
|<------------------------------------------------------>|
| (hand-off) |
|6. hand-off NOTIFY |
|<-----------------| |
| |7. update exchange + peer ticket |
| |<----------------------------------->|
| | +--------+ |
| | | MR2 | |
| (hand-off) +--------+ |
|8. hand-off NOTIFY | |
|<-----------------| | |
| |9. registration exchange + ticket |
| |<------------------>| |
| | (hand-off) |
|11. |10. hand-off NOTIFY |
|<-----------------|<-------------------| |
| | |12. update exchange
| | | + peer ticket|
| | |<-------------->|
| | | |
Figure 4: Flow chart
Melen, et al. Expires November 27, 2009 [Page 16]
Internet-Draft HIP Mobile Router May 2009
Step-1 The mobile node MN discovers the mobile router MR1 through a
service discovery announcement or other configuration. The MN
autoconfigures an address on its interface, based on whichever
(DHCP, stateless autoconfiguration, or manual) technique is in
place.
Step-2 The MN performs a base exchange and registration with MR1,
registering for mobile router services.
Step-3 The mobile node and a peer node run a base exchange and
generate keying material from which session keys are drawn.
Subsequent to the base exchange, additional keys are drawn from
the material to be given to the mobile router and to be used to
protect the update messages with HMAC. Note that this base
exchange includes a modified I2 for SPINAT SPI remapping, as
described in [I-D.melen-spinat]. and SPINAT state is created.
This means, from the perspective of the peer host, the outbound
SPI and destination address to the MN may be different than the
inbound SPI and source address used by the MN, due to the SPINAT
translation.
Step-4 The mobile node uses the established security association
between it and the mobile router to encrypt a ticket. The ticket
allows the mobile router to later send update messages to the peer
node. The ticket also contains authorization rights information
and a lifetime field that is HMAC protected using the keys drawn
from the security association between mobile node and the peer
node. This end-to-end authentication keying material is not sent
to the mobile router, and it is only known by the end-hosts.
(Note: once the mobile node leaves the moving network, it revokes
the ticket from the mobile router.)
Step-5 The mobile node runs an update exchange with the peer node in
parallel with the registration exchange and provides it with a
signaling proxy ticket that authorizes one or more MR to signal on
its behalf. This update is also needed to notify the peer to
advance its keying material index, when the ticket uses a key
drawn from the end-to-end KEYMAT.
Step-6 The mobile router (MR1) makes a hand-off and sends a NOTIFY
message to the MN or a generic hand-off notification message to
the link local multicast/broadcast address on the private link.
The mobile node does not send acknowledgement back to the mobile
router, because it causes extra load for the mobile router during
hand-off. The notification message may be used at the mobile node
to inform layers above IP layer about hand-off. In addition, the
notify message contains the public locator of the mobile router.
Melen, et al. Expires November 27, 2009 [Page 17]
Internet-Draft HIP Mobile Router May 2009
Step-7 The mobile router runs (in parallel with step-6) an update
exchange with the peer node on behalf of the mobile node. It
informs the peer node that the mobile node has changed its
location. The mobile router presents the authorization
information to the peer node using the ticket. The peer node uses
the key information in the ticket to get a correct HMAC key from
the keying material to verify the received update message. (NOTE:
it is possible that the MN sent the HMAC key to the MR also
encrypted with a key that is known only by the peer, in which case
the MR sends this to the peer which can decrypt it and get the
HMAC key from that). The mobile router also updates its SPINAT
state.
Step-8 See step-6.
Step-9 The mobile router (MR1) attaches to another mobile router
(MR2). The situation is also called a nested mobile network case.
MR1 registers to the MR2 and gives the ticket to the MR2. The
session key is encrypted using the security association between
MR1 and MR2. The ticket contains also the encrypted end-to-end
part that cannot be decrypted by the mobile routers or other
intermediate nodes.
Step-10 See step-5.
Step-11 Once a mobile router receives a hand-off notification
message from the upper link it signs the messsage with its own HI
and multicasts the same message in its own private link (see
step-6).
Step-12 The MR2 sends a location update on behalf of the mobile node
to the peer node. The update message contains also the ticket
given in step-9. The peer node trusts that the update message
comes from an authentic sender, because the message was protected
with the correct HMAC, and the lifetime of the ticket is valid.
Note that the MR2 will also include a NAT_ESP_INFO parameter that
again changes the inbound SPI towards the MN.
5.1. End-to-end Base Exchange
The mobile router establishes a state during the end-to-end base
exchange between mobile host and peer hosts. This is illustrated in
Figure 5.
Melen, et al. Expires November 27, 2009 [Page 18]
Internet-Draft HIP Mobile Router May 2009
+--------+ +--------+ +--------+
| MN | | MR | | Peer |
+--------+ +--------+ +--------+
| | |
| registration exchange |
|<---------------->| |
| base/update exc. + SIGNED(locator TLV + ESP-INFO TLV) |
|<------------------------------------------------------>|
| | ticket exchange +
| | HMAC(locator TLV + ESP-INFO TLV) |
| |<----------------------------------->|
| | |
Figure 5: End-to-end base exchange through mobile router
The mobile host receives the rendezvous locator of the peer host from
the DNS and sends the I1 message to that location. The mobile router
establishes a soft NAT state for the MN before forwarding the I1
message to the rendezvous node ([RFC5204]). It also translates the
private source locator to the public multiplexed locator of the
mobile router. In addition, the mobile router adds an encrypted
'echo request' parameter to the I1 message that is echoed back by the
peer host in R1 message.
The I1 message may be forwarded via the rendezvous node to the peer
host. After receiving the I1 message, the peer host replies with the
R1 message. The peer host adds its locator set to the R1 message
according to [RFC5206]. The peer host sends the packet back to the
destination address that was used as the source address of the I1;
i.e. to the MR's public, multiplexed address.
Once the mobile router receives the R1 message it marks the initial
destination locator (used in I1) as verified. The peer host was
reachable behind the initial locator. The mobile router also
verifies that the received 'echo reply' parameter contains the same
secret that was included in the I1 message. The mobile router stores
the received locator set of the peer host, if it was included. The
mobile router translates the destination locator to the private
locator of the mobile host.
After receiving the R1 message, the mobile host sends back I2 message
to the rendezvous locator of the peer host. The mobile router node
does not forward the packet to the rendezvous node but reselects a
locator-pair between its public locator set and the earlier stored
peer host's locator set. (Note: Only the I1 message may be routed
via the rendezvous node and the rest of the messages of the base
exchange are sent directly between the mobile router and the peer
host.) In addition, the mobile router adds its signed LOCATOR TLV
Melen, et al. Expires November 27, 2009 [Page 19]
Internet-Draft HIP Mobile Router May 2009
and NAT_ESP_INFO TLV to the I2 message. The NAT_ESP_INFO TLV
contains the translated SPI values.
After receiving the I2 message the peer host creates a state for the
mobile host. From the peer host's point of view, the mobile host is
reachable at the mobile router's locator. The peer host replies with
an R2 message. The mobile router marks the destination locator of
the earlier sent I2 message as verified. Before forwarding the R2
message to mobile host, the mobile router node do the same locators
translation that took place with the R1 message. The soft state is
also changed to hard state and IPsec SAs are created at the mobile
router (see [I-D.melen-spinat])
5.2. End-to-end update exchange
The mobile host runs the base exchange with the peer host only once.
After that the mobile host updates its location to the peer host by
running an update exchange. This is illustrated in Figure 5. From
the mobile router viewpoint, the state establishment using the update
exchange differs from the base exchange case. The update exchange is
only a three way handshake, while the base exchange consists of four
messages. (Note: The peer host must add it locator set to the
initial R1 message in the base exchange.) The end-to-end update
exchange is used both for updating a state at the peer host and for
creating state at the mobile routers.
The signed _peer_ host's locator set and the ticket are added to the
first update message. Once the mobile router receives the update
message, it creates a soft state. The mobile router selects a
locator pair between the peer's and mobile router's locator sets.
The mobile router also adds its own signed LOCATOR TLV and
NAT_ESP_INFO TLV to the update message before forwarding the message
to the peer host. The NAT_ESP_INFO TLV contains the translated SPI
values. In addition, the mobile router caches the first update
message to be able to retransmit the message later.
The peer host replies with the update (challenge) message and sends
it directly to the mobile router. The peer host should use one of
the locators of the LOCATOR TLV included in the first update message.
The mobile router verifies that the source locator in the update
(challenge) message sent by the peer host belongs to the locator set
that was carried in the first update message. In addition, the
mobile router compares locators in the earlier cached message and the
received challenge message. If the destination locator in the cached
packet and the source locator in the challenge packet differ from
each other the packet has been routed via a rendezvous node. In that
case, the mobile router cannot directly start using the received
source locator with the peer host. Instead, the mobile router node
Melen, et al. Expires November 27, 2009 [Page 20]
Internet-Draft HIP Mobile Router May 2009
silently drops the received challenge message and retransmits the
cached update message to the source locator of challenge message and
adds 'echo request' parameter to the message. In other words, the
mobile router uses the first round trip of the update exchange as a
reachability test.
If the peer host was reachable from its claimed location, the mobile
router receives the challenge message from the peer host containing
correct 'echo reply' parameter. The mobile router node marks the
peer host's location verified and forwards the packet to the mobile
host. The mobile host finalizes the update exchange by sending the
last update message to the peer host. The mobile router uses the
already verified destination locator towards the peer host.
5.3. Payload Packet Processing
The locator rewriting for payload packet headers is done in
alternative ways for IPv4 and IPv6 packets. In the IPv4 case, the
mobile router uses SPINAT mechanism for locator translation
[I-D.melen-spinat]. In the IPv6 case, the locator rewriting follows
the Six/One principles [I-D.vogt-rrg-six-one] as discussed in the
following. It is also good to notice that this draft does not rely
on the Six/One host context, but uses instead the HIP context at the
end hosts for locator-to-identifier bindings.
Basically, it is possible either to renumber the moving network
during mobile router hand-off or use rewriting mechanisms to rewrite
the prefixes in the packet headers at the mobile router. Without
prefix rewriting at mobile router, a mobile router hand-off would
result in renumbering in the moving network. Therefore, the hosts in
the moving network SHOULD use link-local subnet prefixes or unique
local subnetwork prefixes RFC4193 [RFC4193] that are replaced with
globally routable prefixes at the mobile router attached to the
Internet. Whenever a mobile router changes its attachment to the
network it gets a new prefix from the new access router. The mobile
router implements DAD for each address on behalf of the hosts
attached to the moving network. In other words, the host ID part of
the IPv6 address remains the same during prefix rewriting procedure
at the mobile router.
Melen, et al. Expires November 27, 2009 [Page 21]
Internet-Draft HIP Mobile Router May 2009
6. Payload Format
TBA for version -02.
Melen, et al. Expires November 27, 2009 [Page 22]
Internet-Draft HIP Mobile Router May 2009
7. Security Considerations
This draft defines an authorization and delegation mechanism that is
used for delegating update exchange rights between mobile nodes and
mobile routers. The security considerations are discussed in the
protocol context throughout the draft.
The authentication between nodes relies on the HIP base exchange.
The security considerations of the authentication procedure can be
found from the HIP based draft [RFC5201]. The single-hop delegation
between mobile hosts and mobile routers relies on the Kerberos
[RFC4120] security model. The multi-hop delegation between mobile
hosts and mobile routers relies on the SPKI [RFC2693] delegation
principles with certain restrictions. Using authorization
certificates it is possible to limit the length of the certificate
chain. However, the delegation mechanism in this draft does not
limit the length of the delegation chain. As earlier mentioned, the
mobile nodes(/mobile routers) should not delegate the signalling
rights to unauthenticated mobile routers.
When either the mobile node or the peer does not get incoming ESP
packets for a specific SA in KEEPALIVE seconds, it should revoke the
ticket bound to a corresponding SPI value, initiate a new
registration exchange and create a new ticket. A reason for the
communication break may be a re-direction attack that is made by a
malicious node. This requires that the malicious node has obtained
the session key in the ticket due to opportunistic HIP authentication
[RFC5201].
Melen, et al. Expires November 27, 2009 [Page 23]
Internet-Draft HIP Mobile Router May 2009
8. IANA Considerations
Melen, et al. Expires November 27, 2009 [Page 24]
Internet-Draft HIP Mobile Router May 2009
9. Acknowledgments
A number of people have contributed to the text and ideas. The list
of these people include Pekka Nikander, Petri Jokela, Raimo
Vuopionpera, Yuri Ismailov, Jan Holler, Goran Selander, Goran Schultz
and Jari Arkko. Our apologies to anyone whose name is missing.
Melen, et al. Expires November 27, 2009 [Page 25]
Internet-Draft HIP Mobile Router May 2009
10. References
10.1. Normative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203,
April 2008.
[I-D.vogt-rrg-six-one]
Vogt, C., "Six/One: A Solution for Routing and Addressing
in IPv6", draft-vogt-rrg-six-one-01 (work in progress),
November 2007.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
10.2. Informative References
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[I-D.jokela-hip-service-discovery]
Jokela, P., "HIP Service Discovery",
draft-jokela-hip-service-discovery-00 (work in progress),
June 2006.
[I-D.melen-spinat]
Melen, J., Ylitalo, J., and P. Salmela, "Security
Parameter Index multiplexed Network Address Translation
(SPINAT)", draft-melen-spinat-01 (work in progress),
Melen, et al. Expires November 27, 2009 [Page 26]
Internet-Draft HIP Mobile Router May 2009
July 2008.
Melen, et al. Expires November 27, 2009 [Page 27]
Internet-Draft HIP Mobile Router May 2009
Appendix A. Future work
A.1. Static Signalling Proxies in the Fixed Network
The mobile router may also optimize the over-the-air signalling
between it and the Internet. The mobile router may register its
clients and delegate the signalling rights to a static signalling
proxy located in the fixed network. When the mobile router makes a
hand-off, it runs a single location update exchange with the static
signalling proxy. The mobile router's multiplexed IP address may
represent the current location of all the clients belonging to the
moving network behind it.
The static signalling proxy in the fixed network can use the
available high bandwidth to send the burst of location updates to the
peer nodes on behalf of the mobile nodes. The peer nodes send the
challenge messages to the multiplexed locator of the mobile router if
the signalling proxy is not on the forwarding path. The peer nodes
must verify that the mobile nodes are at the location where the
static signalling proxy claims them to be.
Melen, et al. Expires November 27, 2009 [Page 28]
Internet-Draft HIP Mobile Router May 2009
Authors' Addresses
Jan Melen
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: jan.melen@nomadiclab.com
Jukka Ylitalo
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: jukka.ylitalo@nomadiclab.com
Patrik Salmela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: patrik.salmela@nomadiclab.com
Tom Hendersson
The Boeing Company
Seattle, WA P.O. Box 3707
USA
Phone:
Email: thomas.r.henderson@boeing.com
Melen, et al. Expires November 27, 2009 [Page 29]