Network Working Group J. Melen
Internet-Draft J. Ylitalo
Expires: September 29, 2008 P. Salmela
Ericsson Research NomadicLab
March 28, 2008
Host Identity Protocol based Mobile Router (HIPMR)
draft-melen-hip-mr-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 September 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Melen, et al. Expires September 29, 2008 [Page 1]
Internet-Draft HIPMR March 2008
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: Alternative Moving Network Approaches . . . . . . 4
3. Basic concept . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Pre-Movement Phase . . . . . . . . . . . . . . . . . . . . 5
3.2. Node Movement Phase . . . . . . . . . . . . . . . . . . . 5
3.3. Delegation Phase . . . . . . . . . . . . . . . . . . . . . 6
3.4. Network Movement Phase . . . . . . . . . . . . . . . . . . 6
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. Mobile Router Discovery . . . . . . . . . . . . . . . . . 8
4.2. HIP base/update exchange between the MN and its peers . . 8
4.3. Mobile Node Authorizes a Mobile Router . . . . . . . . . . 8
4.4. MR runs update exhchange with the peer nodes . . . . . . . 10
4.5. Leaving a Moving Network; Revoking tickets . . . . . . . . 11
4.6. Kerberos vs. Ticket based Delegation of Signalling
Rights . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Using the keying material . . . . . . . . . . . . . . . . 12
5. Packet processing . . . . . . . . . . . . . . . . . . . . . . 14
5.1. End-to-end Base Exchange . . . . . . . . . . . . . . . . . 16
5.2. End-to-end update exchange . . . . . . . . . . . . . . . . 18
6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Future work . . . . . . . . . . . . . . . . . . . . . 25
A.1. Static Signalling Proxies in the Fixed Network . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Melen, et al. Expires September 29, 2008 [Page 2]
Internet-Draft HIPMR March 2008
1. Introduction
Trains, busses, airplanes and Personal Area Networks (PANs) are
examples of where different moving network technologies can be
applied. In general, a moving network is a cluster consisting of
mobile nodes (MNs) and mobile routers (MRs). A mobile router
connects the moving network to the Internet or other larger network.
When the mobile nodes are moved along the moving 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 a HIP [I-D.ietf-hip-base] based moving network
solution that is based on public-key based authentication and
symmetric key based authorization. The presented authorization
system is architecturally similar to the well know Kerberos [RFC4120]
system, but differs in many details and in the area of application.
The network mobility operations can be considered to consists of
subsequent phases. Initially, a mobile node and a peer node create
security association and a session key during end-to-end HIP base
exchange. The session key is used to protect the location update
messages. Once the mobile node attaches to mobile router, it creates
a security association with the mobile router using the HIP base
exchange [I-D.ietf-hip-base] with registration extension
[I-D.ietf-hip-registration].
The mobile node generates a new HMAC session key and sends it to the
mobile router using the protected channel created during the mobile
router attachment phase. This key is generated with the specific
purpose of allowing the mobile router to use it to represent
movements on the behalf of the mobile node. 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 has
security association between them, the session key can be send over
the protected channel to the new mobile router.
As a result of a mobile router hand-off, the mobile router sends an
update message to the peer node. The mobile router uses the given
new HMAC session key to protect 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 new HMAC key and the initially
generated session key. The lifetime of the session key is send in
the ticket. 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.
Melen, et al. Expires September 29, 2008 [Page 3]
Internet-Draft HIPMR March 2008
2. Background: Alternative Moving Network Approaches
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.
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 to appear 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.
Approach-3: A third approach is to make the mobile nodes to delegate
the right to do mobility signalling to the mobility router, which
under certain conditions may delegate this right further into some
node in the fixed network side. This draft presents a variant of
this approach.
Melen, et al. Expires September 29, 2008 [Page 4]
Internet-Draft HIPMR March 2008
3. Basic concept
The basic idea of the solution presented in this draft is to
represent delegation of signalling rights using symmetric keys and
HMAC based computation. This is made possibly by utilizing existing
security associations between the MN and its peers, and by creating
new symmetric keys in a Kerberos [RFC4120]-like fashion. 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.
Typical operations can be considered to consist of four 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.
3.1. Pre-Movement Phase
As typically in any setting using HIP [I-D.ietf-hip-base], this draft
is based on an assumption that the MN and its peer nodes create
pieces common keying material using 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) [I-D.ietf-hip-mm] 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
[I-D.ietf-hip-registration], 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
Melen, et al. Expires September 29, 2008 [Page 5]
Internet-Draft HIPMR March 2008
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:
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 that look as if it were created by the mobile nodes
behind the mobile router. 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
Melen, et al. Expires September 29, 2008 [Page 6]
Internet-Draft HIPMR March 2008
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 doesn't accept any new location updates
with that key.
Melen, et al. Expires September 29, 2008 [Page 7]
Internet-Draft HIPMR March 2008
4. Protocol Description
The mobile router consists of two integrated services that are
signalling proxy and a 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
[I-D.ietf-hip-registration], can be used for the service registration
procedure like 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 desribed in [I-D.ietf-hip-base]. 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 protect the HIP mobility
management messages.
the end-to-end HIP base/update exchange creates a SPINAT state at the
mobile router (see draft xxx).
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,
for the mobile router to signal on behalf of it. 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
Melen, et al. Expires September 29, 2008 [Page 8]
Internet-Draft HIPMR March 2008
it may be encrypted. The mobile router doesn't have the HIP session
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 there must be encrypted
with the key known only by the MN and the peer.
It is good to notice 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
Melen, et al. Expires September 29, 2008 [Page 9]
Internet-Draft HIPMR March 2008
ticket)
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 exhchange 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 router. (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.
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.
Long ticket lifetimes let 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
Melen, et al. Expires September 29, 2008 [Page 10]
Internet-Draft HIPMR March 2008
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 -01.
The rough idea is following. The revoke messahe must be sent to the
peer nodes and should be sent to the rendezvous of the mobile router.
The mobile node reveices 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.
"Kerberos: client"
+--------+ +--------+
| MR1 | | MR2 |
+--------+ +--------+
^
"Kerberos: KDC" | "Kerberos: peer"
+--------+<-(SA)-+ +--------+
| MN |<--Security Association (SA)----->| Peer |
+--------+ +--------+
Figure 3: Relationship to Kerberos model
Melen, et al. Expires September 29, 2008 [Page 11]
Internet-Draft HIPMR March 2008
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.
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
Melen, et al. Expires September 29, 2008 [Page 12]
Internet-Draft HIPMR March 2008
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 September 29, 2008 [Page 13]
Internet-Draft HIPMR March 2008
5. Packet processing
The following flow chart (Figure 4) illustrates the delegation of
signalling rights using tickets:
+--------+ +--------+
| MN | | Peer |
+--------+ +--------+
| 1. base-exchange: generate session key |
|<------------------------------------------------------>|
| |
| +--------+ |
| | MR1 | |
(hand-off) +--------+ |
|2. registration exchange + ticket |
|<---------------->| |
|3. update exchange |
|<------------------------------------------------------>|
| |4. ticket exchange |
| |<----------------------------------->|
| (hand-off) |
|5. hand-off NOTIFY |
|<-----------------| |
| |6. update exchange + peer ticket |
| |<----------------------------------->|
| | +--------+ |
| | | MR2 | |
| (hand-off) +--------+ |
|7. hand-off NOTIFY | |
|<-----------------| | |
| |8. registration exchange + ticket |
| |<------------------>| |
| |9. update exchange + peer ticket |
| |<----------------------------------->|
| | |10. ticket exchange
| | |<-------------->|
| | (hand-off) |
|12. |11. hand-off NOTIFY |
|<-----------------|<-------------------| |
| | |13. update exchange
| | | + peer ticket|
| | |<-------------->|
| | | |
Figure 4: Flow chart
Melen, et al. Expires September 29, 2008 [Page 14]
Internet-Draft HIPMR March 2008
Step-1 The mobile node and the peer node run base-exchange and
generate keying material from where session keys are drawn. Later
on, new keys are drawn from the material to be given to the mobile
router and to be used to protect the update messages with HMAC.
Step-2 The mobile node makes hand-off and moves behind a mobile
router (MR1). It runs registration exchange with the mobile
router and request a mobile router service from the mobile router.
The mobile node uses the established security association between
it and the mobile router to encrypt a ticket. The mobile hosts
approves the ticket to the mobile router. The ticket allows the
mobile router to send update messages to the peer node. The
ticket also contains authorization right information and lifetime
that is HMAC protected using the security association between
mobile node and the peer node. This end-to-end encryption keying
material is not sent to the mobile router, and it is only known by
the end-hosts. During the registration exchange the mobile node
also receives the locators leased from the mobile router's
rendezvous node. (Note: once the mobile node leaves the moving
network, it revokes the ticket from the mobile router.)
Step-3 The mobile node runs update exchange with the peer node in
parallel with the registration exchange. The update exchange
creates a SPINAT state for the end-to-end ESP traffic at the
mobile router.
Step-4 The mobile router (MR1) runs 1-round-trip ticket exchange
with the peer node. The exchange contains ticket received in
step-2. In addition to the ticket, the MR1 sends HMAC protected
LOCATOR and ESP_INFO TLVs to the peer node. The HMAC is computed
using the key received in the ticket.
Step-5 The mobile router (MR1) makes a hand-off and sends a hand-off
notification message to the link local multi-cast/broadcast
address at the private link. The mobile node does not send
acknowledgement back to mobile router, because it causes extra
load for the mobile router during hand-off. If the notification
message doesn't reach the mobile node, it is better to let mobile
router run update exchnage in step-5, instead of slowing down the
hand-off procedure. 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.
Step-6 The mobile router runs (in parallel with step-5) 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
Melen, et al. Expires September 29, 2008 [Page 15]
Internet-Draft HIPMR March 2008
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-7 See step-5.
Step-8 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-9 The same as step-6.
Step-10 The same as step-4.
Step-11 See step-5.
Step-12 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-4).
Step-13 The MR2 sends location update on behalf of the mobile node
to the peer node. The update message contains also the ticket
given in step-7. 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.
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 September 29, 2008 [Page 16]
Internet-Draft HIPMR March 2008
+--------+ +--------+ +--------+
| MN | | MR | | Peer |
+--------+ +--------+ +--------+
| | |
| registration exchange |
|<---------------->| |
| base/update exc. + SIGNED(locator TLV + ESP-INFO TVL) |
|<------------------------------------------------------>|
| | ticket exchange +
| | HMAC(locator TLV + ESP-INFO TVL) |
| |<----------------------------------->|
| | |
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 state for the HIT-pair before forwarding the I1
message to the rendezvous node ([I-D.ietf-hip-rvs]). It also
translates the private source locator to the public multiplexed
locator of the mobile router. The mobile router adds its self-signed
locator set information to the end of the I1 message before
forwarding the I1 message. 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 [I-D.ietf-hip-mm]. the peer host uses one of the
received mobile router's locators. The packet is sent directly, i.e.
using optimized routing, to one of the mobile router's locators.
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. The mobile router
translates the locators according to [I-D.melen-spinat]. The mobile
router translates the source locator to point to the destinaton
locator of the earlier I1 message before forwarding the R1 message to
the mobile host. In other words, the source locator is translated to
the same locator as to where the I1 message was sent, and the
destination locator is translated to the private locator of the
mobile host.
After receiving the R1 message, the mobile host sends back I2 message
Melen, et al. Expires September 29, 2008 [Page 17]
Internet-Draft HIPMR March 2008
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
and ESP_INFO TLV to the I2 message. The 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 xxxdraftspinat)
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 moible router viewpoint, the state establishment using the update
exchange differs from the base exchange case. The update exchange is
only a three way hand shake, while the base exchange consists of four
messages. (Note: The peer host must add it locator set to the intial
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
states 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 ESP_INFO
TLV to the update message before forwarding the message to the peer
host. The 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
Melen, et al. Expires September 29, 2008 [Page 18]
Internet-Draft HIPMR March 2008
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
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.
Melen, et al. Expires September 29, 2008 [Page 19]
Internet-Draft HIPMR March 2008
6. Payload Format
TBA for version -01.
Melen, et al. Expires September 29, 2008 [Page 20]
Internet-Draft HIPMR March 2008
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 [I-D.ietf-hip-base]. 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
[I-D.ietf-hip-base].
Melen, et al. Expires September 29, 2008 [Page 21]
Internet-Draft HIPMR March 2008
8. IANA Considerations
Melen, et al. Expires September 29, 2008 [Page 22]
Internet-Draft HIPMR March 2008
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 September 29, 2008 [Page 23]
Internet-Draft HIPMR March 2008
10. References
10.1. Normative References
[I-D.ietf-hip-base]
Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007.
[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007.
[I-D.ietf-hip-registration]
Laganier, J., "Host Identity Protocol (HIP) Registration
Extension", draft-ietf-hip-registration-02 (work in
progress), June 2006.
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.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006.
[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-00 (work in progress),
March 2008.
Melen, et al. Expires September 29, 2008 [Page 24]
Internet-Draft HIPMR March 2008
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 September 29, 2008 [Page 25]
Internet-Draft HIPMR March 2008
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
Melen, et al. Expires September 29, 2008 [Page 26]
Internet-Draft HIPMR March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Melen, et al. Expires September 29, 2008 [Page 27]