[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/