Host Identity Protocol Working                                  A. Matos
Group                                                          J. Santos
Internet-Draft                                                 IT Aveiro
Expires: September 7, 2006                                      J. Girao
                                                              M. Liebsch
                                                          NEC Europe Ltd
                                                               R. Aguiar
                                                               IT Aveiro
                                                           March 6, 2006


           Host Identity Protocol Location Privacy Extensions
                 draft-matos-hip-privacy-extensions-01

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

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo describes a framework for the Host Identity Protocol that
   provides location privacy and mobility to end hosts.  It discusses
   the introduction of a new functional entity that prevents HIP enabled



Matos, et al.           Expires September 7, 2006               [Page 1]

Internet-Draft           HIP Privacy Extensions               March 2006


   nodes from revealing their location.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119] .


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Problem Statement and Location Privacy Considerations  . . . .  8
   4.  Location Privacy Framework Overview  . . . . . . . . . . . . . 10
     4.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.1.  HIP Mobile Node  . . . . . . . . . . . . . . . . . . . 11
       4.1.2.  Access Router  . . . . . . . . . . . . . . . . . . . . 11
       4.1.3.  Rendezvous Agent . . . . . . . . . . . . . . . . . . . 12
         4.1.3.1.  Rendezvous Agent Location  . . . . . . . . . . . . 12
       4.1.4.  Rendezvous Server  . . . . . . . . . . . . . . . . . . 12
     4.2.  RVA Protected Areas  . . . . . . . . . . . . . . . . . . . 12
       4.2.1.  Mechanisms for Location Privacy  . . . . . . . . . . . 13
       4.2.2.  Communication Interfaces . . . . . . . . . . . . . . . 13
         4.2.2.1.  HMN to AR Communication  . . . . . . . . . . . . . 14
         4.2.2.2.  AR to RVA Communication  . . . . . . . . . . . . . 14
         4.2.2.3.  RVA to RVA Communication . . . . . . . . . . . . . 14
   5.  Message and Parameter Requirements . . . . . . . . . . . . . . 15
     5.1.  Advertisement Message  . . . . . . . . . . . . . . . . . . 15
     5.2.  RVA Parameter  . . . . . . . . . . . . . . . . . . . . . . 15
     5.3.  HOST_ID Parameter  . . . . . . . . . . . . . . . . . . . . 15
     5.4.  RENDEZVOUS_AGENT Registration Type . . . . . . . . . . . . 15
     5.5.  FROM_ID Parameter  . . . . . . . . . . . . . . . . . . . . 15
   6.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Base Exchange with RVA . . . . . . . . . . . . . . . . . . 16
       6.1.1.  Certification  . . . . . . . . . . . . . . . . . . . . 17
     6.2.  Packet Translation at RVA  . . . . . . . . . . . . . . . . 17
     6.3.  Base Exchange with RVS . . . . . . . . . . . . . . . . . . 18
     6.4.  Base Exchange with HCN . . . . . . . . . . . . . . . . . . 19
     6.5.  Intra-RVA Handover . . . . . . . . . . . . . . . . . . . . 20
     6.6.  Inter-RVA Handover . . . . . . . . . . . . . . . . . . . . 21
     6.7.  RVA to RVA Update  . . . . . . . . . . . . . . . . . . . . 23
   7.  Conceptual Data Structures . . . . . . . . . . . . . . . . . . 25
     7.1.  HIP Mobile Node  . . . . . . . . . . . . . . . . . . . . . 25
     7.2.  Access Router  . . . . . . . . . . . . . . . . . . . . . . 25
     7.3.  Rendezvous Agent . . . . . . . . . . . . . . . . . . . . . 25
   8.  Compatibility Mode . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28



Matos, et al.           Expires September 7, 2006               [Page 2]

Internet-Draft           HIP Privacy Extensions               March 2006


   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. RVA Certification  . . . . . . . . . . . . . . . . . . . . 29
     10.2. Levels of Responsibility Assignment  . . . . . . . . . . . 29
     10.3. Credit Based Authorization . . . . . . . . . . . . . . . . 29
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     13.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 36








































Matos, et al.           Expires September 7, 2006               [Page 3]

Internet-Draft           HIP Privacy Extensions               March 2006


1.  Introduction

   The current Internet architecture has two important global
   namespaces: Internet Protocol (IP) addresses and fully qualified
   domain names (FQDN).  The Domain Name System (DNS) provides services
   for domain name to IP resolution.

   IP addresses have two different roles.  They are used simultaneously
   as locators and identifiers for a host.  At the network layer an IP
   address is used for routing and network-layer mechanisms thus acting
   as a locator.  Transport layer mechanisms bind IP addresses as names
   that identify communication endpoints.

   Using IP addresses for location and identification limits the current
   Internet architecture.  Mobility scenarios rely on constant re-
   addressing, which breaks the existing transport layer communications.

   The Host Identity Protocol (HIP) architecture [I-D.ietf-hip-arch]
   proposes a new namespace (Host Identity) to eliminate the dual role
   of IP addresses.  Instead of translating directly FQDNs to IP
   addresses a HIP enabled DNS [I-D.ietf-hip-dns] translates FQDNs to
   Host Identities (HI), and Host Identities to IP addresses.  HIs are
   now used by the transport layer as endpoint names.  The network layer
   continues to use IP addresses as pure locators.

   The HIP base protocol [I-D.ietf-hip-base] further defines a simple
   mechanism for rapid authentication between two hosts and allows the
   creation of cryptographic material for subsequent IPsec Encapsulated
   Security payload (ESP) communication [I-D.ietf-hip-esp].

   The HIP mobility and multihoming extensions [I-D.ietf-hip-mm] defines
   a generic Locator Parameter that allows a HIP node to dynamically
   change its set of underlying IP addresses without breaking transport
   layer sessions.

   Mobility management relying on dynamic DNS has been widely discussed.
   This approach has two drawbacks.  Dynamic DNS updates have a big
   performance impact when security is considered, and propagating
   updated DNS entries requires excessive time for many mobility
   scenarios.  The HIP architecture tries to reduce the DNS updates by
   introducing Rendezvous Server (RVS) [I-D.ietf-hip-rvs].  A HIP node
   registers his RVS's IP address in the DNS and then registers its IP
   addresses with the RVS, maintaining global reachability without
   relying on dynamic DNS updates.

   As defined in [I-D.haddad-momipriv-problem-statement], location
   privacy is the capability of preventing other parties from learning
   one's past or current location.  Here location pertains to the



Matos, et al.           Expires September 7, 2006               [Page 4]

Internet-Draft           HIP Privacy Extensions               March 2006


   topological and not geographical position of a node, although
   frequently the topological location can give a very accurate
   geographical position.  For a node to obtain location privacy, there
   must be no relation between its Host Identifier and its location.

   The location privacy problem is not limited to a single layer.  In
   fact it is related to the identifiers associated with a node, i.e.,
   the MAC and IP addresses.  Another related problem is their
   interdependency.

   The MAC Layer uses a MAC address which is unique for each device.
   When a mobile device attaches to a link, it is always identified by
   that address.  Also, the frame header of the MAC Layer contains a
   sequence number, which can be used to uniquely identify a node, even
   if the node changes MAC Address or uses pseudo-identifiers.  The
   location privacy problems concerning the MAC Layer are out of scope
   for this document.

   At the IP Layer, several issues result in loss of location privacy.
   In the IPv6 context, a Mobile Node (MN) performing address auto-
   configuration is implicitly disclosing its MAC address, allowing a
   direct mapping between MAC address and IPv6 address, therefore making
   itself easy to track.

   Another problem in the IP layer relates to mobility.  Moving across
   networks using different local addresses reveals the actual location
   of MN.

   Currently, the base HIP architecture does not support location
   privacy.  In the current HIP architecture, the resolution of a remote
   Host Identifier to its current locator is done by the host.  With
   HIP, the Locator Parameter usage on the base exchange and mobility
   update procedures discloses the current set of IP addresses
   (locators) used by the communicating HIP nodes.

   The proposed extensions to the HIP architecture attempts to resolve
   the problems at the network level.














Matos, et al.           Expires September 7, 2006               [Page 5]

Internet-Draft           HIP Privacy Extensions               March 2006


2.  Terminology

   o  Host Identity Protocol (HIP) - protocol that proposes a new
      namespace between the IP and DNS namespaces.  Decouples the dual
      locator/identifier role of an IP address.

   o  Host Identifier (HI) - public key used as name for a Host.

   o  Host Identity Tag (HIT) - 128 bit hash over the HI.

   o  HIP Mobile Node (HMN) - HIP enabled node capable of changing its
      point of attachment to the network.

   o  HIP Correspondent Node (HCN) - HIP enabled node on the other end
      point of a HIP communication with a HMN.

   o  HIP Base Exchange (BE) - HIP packets that manage the establishment
      of state between an Initiator (I) and a Responder (R) using a
      4-way handshake with a standard authenticated Diffie-Hellman key
      exchange for session key generation.  It allows the establishment
      of a Security Association between the hosts.

   o  Rendezvous Service - consists of relaying the first packet of the
      BE sent by the I to the R. It may also serve as a location
      registration point for HMNs.  This service is provided by
      RendezVous Servers (RVS)s and, in the case the HMN is registered
      with the RVS, it is also denominated as a RendezVous Client (RVC).

   o  Rendezvous Agent (RVA) - entity responsible for providing location
      privacy to its attendants in HIP.  The RVA is responsible for
      HIP-IP resolution and, at the same time, conceal the locators of
      HMN for outgoing packets and of its communication peer in
      incomming packets.

   o  Access Router (AR) - entity responsible for managing the last hop
      packet communication in the Access Network (rout).

   o  Locator - a name by which a packet can be routed through the
      network.  Normally an IP address.

   o  RVA protected area - area under a delegated RVA that provides
      location privacy.  No locators are used inside this area.

   o  Intra-RVA Mobility - mobility between access routers (AR), within
      the same RVA protected area.

   o  Inter-RVA Mobility - mobility between different RVA protected
      areas.



Matos, et al.           Expires September 7, 2006               [Page 6]

Internet-Draft           HIP Privacy Extensions               March 2006


   o  IPg - a globally routable IP address used in the core network
      attributed to a HMN under an RVA protected area.

   o  AN - Access Network















































Matos, et al.           Expires September 7, 2006               [Page 7]

Internet-Draft           HIP Privacy Extensions               March 2006


3.  Problem Statement and Location Privacy Considerations

   The current HIP architecture does not take into account location
   privacy issues.  HIP is an end-to-end protocol.  This means that when
   an Initiator and a Responder perform a base exchange, they learn the
   location of the each other immediately from the I1 and R1 packets as
   described in Section 6.4.

   If we consider the presence of an RVS, the Initiator does not
   immediately learn the current locator of the Responder.  However,
   that information is disclosed in the R1 packet.

   In both approaches an end-to-end addressing mechanism is used.  This
   means that both I and R will always learn each other's current IP
   address once the BE is completed.

   Furthermore, capturing the HIP base exchange enables an eavesdropper
   to learn the HITs and IPv6 addresses of both participants,
   consequently forfeiting the location privacy of the peers.

   In the current HIP mobility draft , [I-D.ietf-hip-mm] a HMN is
   required to update its locator for every HCN by sending explicit
   update messages in case a handover occurs.  These update messages
   contain the new locator of the node.  This is comparable to the
   Binding Update messages exchanged between MIPv6 [RFC3775] enabled
   Mobile Nodes (MN) and Correspondent Nodes (CN) when performing route
   optimization.  HIP ultimately suffers from the same location privacy
   issues as MIPv6, described in [I-D.haddad-momipriv-threat-model].

   If the target HIP node of a DNS query is not registered in an RVS
   then the DNS resolves to the current IPv6 address of the node.  In an
   architecture that supports location privacy, the HIP nodes should
   never be able to map the identifier to the real locator of the node.
   In older versions of [I-D.ietf-hip-rvs] some considerations and
   network elements were introduced that shield a HIP node's location,
   although there was no followup on this matters.

   The framework presented in this document addresses key issues before
   mentioned.  The solution limits as much as possible any disclosure,
   voluntary or involuntary, of location information from the nodes.
   Relying on the concept of a protected area, which can be though of as
   a network under an anchor point as in Hierarchical Mobile IP
   [RFC4140], privacy is assured by the suppression of locators on these
   networks, making the nodes unaware of their locations.  We can
   summarize some key aspects gained with this solution:

      The HCN never learns the IP address of a HMN, nor vice-versa, if
      both are under RVA protected areas.  The communication in the AN



Matos, et al.           Expires September 7, 2006               [Page 8]

Internet-Draft           HIP Privacy Extensions               March 2006


      is based on HITs and therefore no locators are necessary.  In case
      the transport in the AN requires locators for routing, the scope
      of these names are deemed as local and are never leaked outside
      the AN.

      The attacker is only able to learn a HMN's location if it is in
      the same AN.  In this case, the attacker can track HITs, MACs and
      possibly other AN transport information by simply eavesdropping on
      the physical medium.  We believe that this architecture can be
      extended or combined with other mechanisms to also cover this
      case.

      The globally assigned IPv6 addresses limits the amount of location
      information an eavesdropper in the core network obtains from
      mapping HITs to global addresses used in the routing process.
      This factor can even be reduced if an encrypted tunnel is used
      between the different RVAs.  If the eavesdropper is on the path
      and able to intercept all messages received by the HCN outside the
      HCN's protected area, it does not learn of local mobility and can
      only track movement between different RVA protected areas.  The
      size of RVA protected areas determines how much geographical
      location information an attacker can obtain by using this method.

      An attacker tracking the base exchange can learn the SPIs of IPsec
      SAs and afterwards map the SPIs to the assigned IPv6 addresses.
      Once again, the attacker is limited to the location of the RVAs
      information and the SPIs used.
























Matos, et al.           Expires September 7, 2006               [Page 9]

Internet-Draft           HIP Privacy Extensions               March 2006


4.  Location Privacy Framework Overview

   Location privacy is provided by delegating the HIT to IP resolution
   into a network entity called the RVA.

   Moving the resolution upwards in the network topology (from the HMNs
   to the RVA) has the benefit that locators are not used within the RVA
   protected area.

   The core feature of the proposed solution is the concept of an RVA
   protected area.  It is a section of the network where locators are
   either concealed or not used at all.  Instead, HITs are used to
   identify the traffic path.  Moreover, RVAs are responsible locating
   HMNs within the protected area, thus handling local mobility.

   We do not assume any type of transport at the network layer.  As long
   as it can support some type of identity based routing, any protocol
   can be used.  Currently, HIP is defined only for IPv4 and IPv6.  In
   this document, for the sake of simplicity, we provide examples
   assuming the presence of IPv6.

4.1.  Topology

   An example of the proposed topology has been illustrated in Figure 1.
   The scenario consists of two RVA protected areas connected to the
   Internet.  An RVA protected area is composed by multiple ARs which
   are directly connected to an RVA.  There are no assumptions on the
   number of RVA protected areas, although it is reasonable to think
   that an RVA covers a large number of ARs.  A wider coverage of area,
   geographical or topological, limits the amount of location
   information revealed to an external eavesdropper.  The RVSs and DNSs
   are located in the Internet, natively or, possibly, under different
   RVA protected areas.  Note that several RVSs may exist in this
   architecture.

   The AR and the RVA are functional entities, thus they can be
   collocated in the same machine.  As stated in location privacy
   considerations, due to the area coverage of such an RVA, this option
   has consequences in the quality of the location privacy provided to
   the HMNs in that RVA protected area.











Matos, et al.           Expires September 7, 2006              [Page 10]

Internet-Draft           HIP Privacy Extensions               March 2006


               +---+                  +---+
               |RVS|                   |DNS|
               +-+-+                   +-+-+
                 |        +--------+     |
                 +--------|INTERNET+-----+
                          +---+--+-+
                              |  |
                     +--------+  +---------+
                     |                     |
                   +-+--+                +-+--+
                   |RVA1|                |RVA2|
                   ++--++                ++--++
                    |  |                  |  |
                 +--+  +--+            +--+  +--+
                 |        |            |        |
               +-+-+    +-+-+        +-+-+    +-+-+
               |AR1|    |AR2|        |AR3|    |AR4|
               +---+    +---+        +---+    +-+-+
                 |                              |
              +--+-+                          +-+--+
              |HMN1|                          |HMN2|
              +----+                          +----+

   Figure 1: Basic architecture topology example

4.1.1.  HIP Mobile Node

   The HMN is meant to deal with intra and inter RVA mobility,
   signalling the RVA and RVS respectively.  The HMN has to perform
   movement detection, based on the advertisements it receives from the
   ARs.  The HMN does not need to implement auto-configuration
   mechanisms, unless required by the AN, but it is required to maintain
   a communication path to the AR.

4.1.2.  Access Router

   The AR is responsible for forwarding packets to and from the RVA or
   the AN edge router.  It keeps a HIT based neighbor list of all the
   HMNs under it.  Note that each entry of the HIT neighbor list
   contains an HIT based route for packet forwarding.

   The AR sustains the advertisement protocol by broadcasting RVA
   advertisement messages (defined in Section 5.1).  This enables the
   HMN to learn the HIT of the local RVA and to perform movement intra
   and inter RVA area handover.






Matos, et al.           Expires September 7, 2006              [Page 11]

Internet-Draft           HIP Privacy Extensions               March 2006


4.1.3.  Rendezvous Agent

   The RVA is an enhanced RVS that performs the IP-HI address resolution
   function.  This functionality splitting provides location privacy to
   the MNs behind it.  This is done by readdressing the packets flowing
   between an RVA area and the outside network.  To forward packets to a
   destination HIT outside a RVA protected area, the RVA addresses a
   globally routable IPv6 address previously assigned by another RVA to
   the destination host.  When an RVA receives packets from the outside
   network to a host belonging to its RVA protected area, it re-
   addresses them to HITs and forwards the packet to the destination.
   Note that the RVA is the entity which assigns globally routable IP
   addresses to the hosts under it, and the only one to map between HITs
   and global IP addresses.

   The RVA is capable of forwarding packets based on HITs because it
   maintains a table mapping for every HMN in the protected area to its
   point of attachment, which is the AR.

   The RVA is responsible for handling mobility for the HMNs in the
   protected area.  This means that the RVA might have to signal other
   RVAs or HCNs on behalf of the HMNs for location updates.

4.1.3.1.  Rendezvous Agent Location

   The RVA does not need to be the AR of a protected area.  The
   acumulation of functionality could lead to scalability problems.
   Therefore the RVA needs only to be within the protected area.  The
   area router then queries the RVA for routing decisions.

4.1.4.  Rendezvous Server

   The RVS is a network entity which serves as the initial contact point
   for HIP nodes registered in it, the RVCs.  The RVS provides a
   relaying service of incoming I1 packets to an RVC IP address.  An RVC
   should use the registration mechanisms defined in [I-D.ietf-hip-rvs].
   After this procedure is finished, all communication typically occur
   directly without the assistance of the RVS.

   The proposed architecture implies that instead of registering
   locators, the HIP nodes register the HIT of their designated RVA.
   When an incoming I1 packet arrives at an RVS intended to one of its
   RVCs, the RVS resolves HIT HMN to HIT of the HMN's RVA, then HIT RVA
   to IP address of the RVA where the packet is sent to.

4.2.  RVA Protected Areas





Matos, et al.           Expires September 7, 2006              [Page 12]

Internet-Draft           HIP Privacy Extensions               March 2006


4.2.1.  Mechanisms for Location Privacy

   Once the architecture described in this document is deployed, issues
   such as mobility have to be addressed.  To this purpose we believe
   that the use of an advertisement system based on identifiers, rather
   than locators, is sufficient.  The mechanism should be sufficient so
   that the node detects movement but shall not give out any additional
   information, especially in what concerns location.

   Inline with the aforementioned, the transport mechanism in the AN is
   also required to keep location information concealed.  Packets that
   are exchanged between RVAs, ARs and HMNs should not reveal global
   location information.

   One simple way of instantiating such a transport is to consider point
   to point connections between ARs and RVAs, not disclose any locator
   information, even if local, and use a switching method based on the
   peers of the different point to point connections.

   IPv6 can also be used within the protected area, given that the RVA
   performs the necessary address translations for the exchanged
   packets.  This allows better scalability with current tecnologies
   without limiting the size of the protected area.  Since the the
   routers in the protected area do not need to be HIP aware, nor
   maintain separte routes for each hip node, normal IP routing can be
   performed.  But, this has implications on the amount of information
   revealed within the protected area:

      The Initiator is aware of his local address, and possibly of the
      global IP of the Responder.

      An eavesdropper on path between RVA and HMN is able to map the hip
      node's position.

   There is a clear tradeoff between location privacy and scalabity
   within the protected area.

4.2.2.  Communication Interfaces

   Rather than defining a specific transport layer for this approach, we
   base ourselves in some basic assumptions that allow the mechanisms to
   work.  The architecture itself should be independent of the HIP
   transport layer.  We propose some instantiations based on direct IPv6
   address translations, tunnels and semantical adaptations (replacing
   IPv6 addresses with HITs).

   In principle all approaches are valid and one should just keep in
   mind that, when a specific approach is chosen, optimizations might be



Matos, et al.           Expires September 7, 2006              [Page 13]

Internet-Draft           HIP Privacy Extensions               March 2006


   possible.  For example, if a tunnel mechanism is used between RVAs,
   there is no need for a global locator attribution per HMN.

4.2.2.1.  HMN to AR Communication

   The basic assumption on the communication medium between HMN and AR
   is that packets can be transmitted based on HITs.  This can either be
   a bidirectional point-to-point connection or a broadcast shared
   medium.

4.2.2.2.  AR to RVA Communication

   The communication between a AR and RVA is done through a
   bidirectional point-to-point connection.

4.2.2.3.  RVA to RVA Communication

   The communication between RVAs is also done through a bidirectional
   point-to-point medium.  Typically this is over the Internet or a core
   network.































Matos, et al.           Expires September 7, 2006              [Page 14]

Internet-Draft           HIP Privacy Extensions               March 2006


5.  Message and Parameter Requirements

5.1.  Advertisement Message

   The advertisement message is sent by the ARs and contains the RVA HIT
   responsible for the RVA protected area of the AR sending the message.
   The HMN learns the RVA HIT from this message.

5.2.  RVA Parameter

   The RVA parameter announces the RVA responsible for the HMN sending
   the packet.  This parameter is sent from the HMN to the RVS.

5.3.  HOST_ID Parameter

   The HOST_ID Parameter to inform RVAs of which host (or HMN) the
   sending RVA is acting on behalf of.  This parameter announces the
   HMN's HIT and is always used together with a LOCATOR parameter.

5.4.  RENDEZVOUS_AGENT Registration Type

   This specification defines an additional registration for the HIP
   registration protocol [I-D.ietf-hip-registration] that allows
   registering with a rendezvous server for rendezvous service.

      Number   Registration Type
      ------   -----------------
      TBD      RENDEZVOUS_AGENT_SERVICE

5.5.  FROM_ID Parameter

   The FROM_ID parameter carries a HIT.  It is used when RVA to RVA
   packet forwarding occurs, so that the receiving node can validate the
   sending RVA and that it should perform update to the source of the
   packet.
















Matos, et al.           Expires September 7, 2006              [Page 15]

Internet-Draft           HIP Privacy Extensions               March 2006


6.  Protocol Operation

   For the privacy location scenario to work it is necessary to slightly
   alter the basic HIP mechanisms.  This includes minor changes in the
   following mechanisms:

      Base Exchange with RVA: The MN performs a base exchange with the
      RVA, allowing a RVA to deal with HMN intra mobility, packet
      forwarding and RVA to RVA signaling.

      Base Exchange with RVS: The BE with the RVS is performed through
      the RVA.  The RVA must monitor the exchange in order to create
      entries for the HMN's current point of attachment and assign a
      globally routable IPv6 address.

      Normal Base exchange (between I and R): The RVAs must perform
      network layer readdressing.  HIP session tracking must be
      performed in order to perform mobility signalling on behalf of the
      HMN.

      Handover: The normal update to the RVS requires RVA monitoring for
      entry creation and IPv6 assignment as in the base exchange to the
      RVS.  Local handover is also defined for intra-RVA mobility
      because there is no need to update the RVS, only the RVA.

      RVA to RVA update: After a HMN handover, a HCN's RVA still sends
      data packets to the old RVA until it is updated with the HMN's new
      location.  When an old RVA receives packets to a HMN no longer
      registered, it redirects them to the new RVA.  The new RVA then
      performs signalling on behalf of the HMN to update the location in
      the HCN's RVA.

      Normal Packet forwarding: this operation requires readdressing on
      the involved RVAs.

6.1.  Base Exchange with RVA

               +-----+                            +-----+
               |     |           1.I1             |     |
               |     |--------------------------->|     |1a. RVA learns
               |     |       2.R1(REG_INFO)       |     |    HIT-AR map
               | HMN |<---------------------------| RVA |
               |     |       3.I2(REG_REQ)        |     |
               |     |--------------------------->|     |
               |     |       4.R2(REG_RES)        |     |
               |     |<---------------------------|     |4a. RVA assigns
               +-----+                            +-----+    IPg for HMN




Matos, et al.           Expires September 7, 2006              [Page 16]

Internet-Draft           HIP Privacy Extensions               March 2006


   Figure 2: Base Exchange with RVA

   When a HMN first arrives on a protected area is has to register with
   the responsible RVA.  The RVA HIT is learnt from the Advertisement
   messages sent by the AR.  Upon receiving an advertisement message,
   the HMN register with the announced RVA by means of a base exchange
   using the registration extensions defined in [I-D.ietf-hip-
   registration].

   The RVA learns HIT-AR mapping from I1, for identity based routing.
   Note that no packet forwarding on the behalf of the HMN is done until
   the BE is completed, avoiding DoS attacks.  After the BE is
   completed, the RVA assings an IPg for the registering HMN.

   The HMN can use the BE described above to cross-certify his assigned
   RVA.  This procedure can later be explored for mobility delegation
   and other explicit signaling from the RVA to the RVS on behalf of the
   HMN.  Further details are discussed in Section 10.

6.1.1.  Certification

   In I2 the HMN should give out a CER Parameter, in order to certify
   the RVA.  This certificate can later be used for secure mobility
   updates, between RVAs

6.2.  Packet Translation at RVA

   After the BE, when communicating with nodes that are after the RVA,
   it is required that the RVA performs readressing.  On packets going
   outwars to the core network, the RVA hides the endpoints HIT's, and
   inserts the corresponding IP's (steps and 2 in figure Figure 3).  For
   packets arriving from the core network the RVA performs the required
   readdressing, concealing the globally routable IP addresses assigned
   to the HIP nodes, and inserts the corresponding HIT's, that are
   delivered according to the defined HIT based transport mechanism that
   conveys packets to the correct destination (steps 3 and 4 in figure
   Figure 3.














Matos, et al.           Expires September 7, 2006              [Page 17]

Internet-Draft           HIP Privacy Extensions               March 2006


    +-----+                       +-----+                   +-----+
    |     | 1.Data(HMN_HIT,R_HIT) |     |                   |     |
    |     |---------------------->|     |                   |     |
    |     |                       |     | 2.Data(IPg,R_IP)  |     |
    |  I  |                       | RVA |------------------>|  R  |
    |     |                       |     | 3.Data(IPg,R_IP)  |     |
    |     |                       |     |<------------------|     |
    |     | 4.Data(HMN_HIT,R_HIT) |     |                   |     |
    |     |<----------------------|     |                   |     |
    +-----+                       +-----+                   +-----+

   Figure 3: Packet Header Translation

6.3.  Base Exchange with RVS

   After arriving on a new RVA protected area and performing the BE with
   the RVA described above, the HMN has to register with his RVS or
   update it.  If the HMN is not yet registered in an RVS, it begins the
   registration process.  This registration procedure consists in an
   enhanced base exchange, depicted in Figure 4, which contains the
   identifier of the designated RVA for the node.

   The I1, R1 and R2 packets are the same as described for a standard
   base exchange with an RVS in [I-D.ietf-hip-rvs].  The I2 packet
   contains an extra HIP parameter which carries the newly discovered
   RVA identifier.  This parameter - RVA Parameter (see Section 5.2) -
   is used to inform the RVS of the RVA identifier this HMN is currently
   using.  This enables the HMN to register with the RVS not with a
   locator but with an identity.

   In a RVA protected area, packets are routed using a transport
   mechanism (eg. point-to-point IPsec) that does not use the locators
   in the core network.  For this reason, packets coming from a RVA
   protected area are processed and given the correct locators for
   routing in the core network.  Packets arriving from the outside
   network need to be forwarded correctly to the current assigned AR for
   destination HIT.  Until the base exchange is completed, no globally
   routable address is assigned to the HMN.  Therefore, in the outside
   network, packets concerning signalling to a RVS use the locator of
   the HMN's assigned RVA.











Matos, et al.           Expires September 7, 2006              [Page 18]

Internet-Draft           HIP Privacy Extensions               March 2006


               +-----+                            +-----+
               |     |           1.I1             |     |
               |     |--------------------------->|     |
               |     |       2.R1(REG_INFO)       |     |
               | HMN |<---------------------------| RVS |
               |     |   3.I2(REG_REQ,RVA_HIT)    |     |
               |     |--------------------------->|     |
               |     |       4.R2(REG_RES)        |     |
               |     |<---------------------------|     |
               +-----+                            +-----+

   Figure 4: Base Exchange with RVS

6.4.  Base Exchange with HCN

   The HIP base exchange between an Initiator and a Responder, depicted
   in Figure 5, remains unchanged from HIP base protocol at the HIP
   layer.  Key differences are at the network layer.  The Initiator's
   RVA performs readdressing of outgoing packets to globally routable IP
   addresses.  If the RVA does not know the Responder's HIT, it queries
   the DNS for its IP address as shown in step 2.  The DNS server then
   returns the IP address of the Responder's RVS in step 3.

   In step 4 and 5, the RVS relays I1 packet to the IP address of the
   Responder's RVA.  This is done based on the two step mapping
   previously discussed where the Responder's HIT is translated to the
   RVA HIT, and then RVA HIT is finally translated to the RVA IP
   address.  Also, the FROM and VIA Parameters are included as described
   in [I-D.ietf-hip-rvs].

   Upon receiving the I1 in step 5, the Responder's RVA forwards the
   packet to the destination HIT's currently.  The RVA also needs to
   store the newly learnt HIT I - IPg I mapping for further packet
   forwarding as shown in step 5a.

   In step 6, the HMN receives the packet and replies in step 7 with a
   R1 packet.  The R1 packet is then relayed in RVA, which performs its
   normal operation, readdressing the packet based on the on the learnt
   mapping.  In the base exchanges remaining packets (I2 and R2) the
   globally assigned IP addresses of both I and R are used between RVAs.











Matos, et al.           Expires September 7, 2006              [Page 19]

Internet-Draft           HIP Privacy Extensions               March 2006


     +---+       +----+      +---+       +---+     +----+   +---+
     | R |       |RVA1|      |RVS|       |DNS|     |RVA2|   | I |
     +---+       +-+--+      +---+       +-+-+     +-+--+   +-+-+
       |           |     |     |           |    |    |1.I1()  |
       |           |           |           |         |<-------|
       |           |     |     |           |2.query()|        |
       |           |           |           |<--------|        |
       |           |     |     |           |    |    |        |
       |           |           |           |3.reply()|        |
       |           |     |     |           |-------->|        |
       |           |           |           |4.I1()   |        |
       |           |     |     |<----------+---------|        |
       |           | 5.I1()    |           |    |    |        |
       |           |<----------|           |         |        |
       | 6.I1()    | 5a. HIT I <-> IPg I   |         |        |
       |<----------|     mapping learnt    |    |    |        |
       |           |           |           |         |        |
       | 7.R1()    |     |     |           |    |    |        |
       |---------->| 8.R1()    |           |         |        |
       |           |-----------+-----------+-------->| 9.R1() |
       |           |     |     |           |    |    |------->|
       |           |           |           |         |10.I2() |
       |           |     |     |             11.I2() |<-------|
       |           |<----------+-----------+---------|        |
       | 12.I2()   |           |           |         |        |
       |<----------|     |     |           |    |    |        |
       |           |           |           |         |        |
       | 13.I2()   |     |     |           |    |    |        |
       |---------->| 14.R2()   |           |         |        |
       |           |-----------+-----------+-------->|15.R2() |
       |           |     |     |           |    |    |------->|
       |           |           |           |         |        |

   Figure 5: Base Exchange

6.5.  Intra-RVA Handover

   When a HMN detects that it has changed AR, though, without changing
   RVA protected area, it performs an intra RVA handover (steps 1 and
   2).  Since the AR is in the same RVA protected area there is no need
   to update the RVS.  The HMN updates its binding to the RVA directly,
   performing a normal HIP update procedure without a locator as
   depicted in steps 3 to 5.  This update message is used by the RVA to
   learn the new HMN - AR mapping.  Note that the globally assigned IP
   for the node performing the handover remains the same.  This location
   change is transparent to the RVS since the HMN remains in the same
   area.  It is also transparent to other RVAs because the global
   assigned IP address for that node does not change.



Matos, et al.           Expires September 7, 2006              [Page 20]

Internet-Draft           HIP Privacy Extensions               March 2006


   +---+        +---+        +---+       +---+
   |HMN|        |AR1|        |AR2|       |RVA|
   +-+-+        +-+-+        +-+-+       +-+-+
     | 1.RVA_ADV()|            |           |
     |<-----x-----|            |           |
     |            |            |           |
     | 2.RVA_ADV()|            |           |3a.HMN<->AR
     |<-----------+------------|           |   mapping
     |            |            |           |   updated
     | 3.UPDATE() |            |           |
     |------------+------------+---------->|
     |            |            |           |
     |            |           4.UPDATE(AC) |
     |<-----------+------------+-----------|
     |            |            |           |
     |      5.UPDATE(ACR)      |           |
     |------------+------------+---------->|
     |            |            |           |

   Figure 6: Intra-RVA Handover

6.6.  Inter-RVA Handover

   The inter-RVA handover occurs when a HMN detects it has changed RVA
   protected area after receiving a RVA Advertisement message.  This is
   described in Figure 7 where the ARs in step 1 and 2 announce
   different RVA HITs.  At this point the HMN registers with the RVA by
   means of a base exchange as defined in Section 6.1.  Then the HMN
   performs a normal Update to the RVS and to the old RVA.

   To the RVS, the HMN sends a HIP Update packet including the RVA HIT
   on a RVA parameter (step 3), in the same way it is done for the I2
   packet mentioned in Section 6.3.  The RVS updates the HMN entry
   according to this parameter, changing the responsible entity for the
   HMN to the new announced RVA.
















Matos, et al.           Expires September 7, 2006              [Page 21]

Internet-Draft           HIP Privacy Extensions               March 2006


    +---+   +--------+      +----+    +--------+    +----+   +---+
    |HMN|   |AR(RVA1)|      |RVA1|    |AR(RVA2)|    |RVA2|   |RVS|
    +-+-+   +----+---+      +-+--+    +----+---+    +-+--+   +-+-+
      |          |            |            |          |        |
      |     1.RVA_ADV()       |            |          |        |
      |<----x----|            |            |          |        |
      |          |            |            |          |        |
      |          |        2.RVA_ADV()      |          |        |
      |<---------+------------+------------|          |        |
      |          |            |            |          |        |
      | -- BASE EXCHANGE (HMN <-> RVA) --- |          |        |
      |          |            |            |          |        |
      |  3.UPDATE(HIT_RVA2)   |            |          |        |
      |----------+------------+------------+--------->|        |
      |          |            |            |       UPDATE(HIT_RVA2)
      |          |            |            |          |------->|
      |          |            |            |          | 5.UPDATE(AC)
      |          |            |            |          |<-------|
      |          |            |           6.UPDATE(AC)|        |
      |<---------+------------+------------+----------|        |
      |          |            |            |          |        |
      |  7.UPDATE(ACR)        |            |          |        |
      |----------+------------+------------+--------->+        |
      |          |            |            |          | 8.UPDATE(ACR)
      |          |            |            |          |------->|

   Figure 7: Inter-RVA Handover - RVS Update

   To the old RVA, the HMN sends an update packet with an RVA parameter.
   This packet is used to inform the old RVA that HMN as changed RVA
   protected area.  After the update procedure is completed as depicted
   in Figure 8, the old RVA needs to forward the data packets destined
   to the HMN to the new RVA (step 8a).  When the new RVA receives the
   forwarded packets, it updates the location to the HCNs RVA's.

















Matos, et al.           Expires September 7, 2006              [Page 22]

Internet-Draft           HIP Privacy Extensions               March 2006


   +---+   +--------+      +----+    +--------+    +----+
   |HMN|   |AR(RVA1)|      |RVA1|    |AR(RVA2)|    |RVA2|
   +-+-+   +----+---+      +-+--+    +----+---+    +-+--+
     |          |            |            |          |
     |  1.RVA_ADV()          |            |          |
     |<----x----|            |            |          |
     |          |            |            |          |
     |          |       2.RVA_ADV()       |          |
     |<---------+------------+------------|          |
     |          |            |            |          |
     |  3.UPDATE(HIT_RVA2)   |            |          |
     |----------+------------+------------+--------->|
     |          |            |   4.UPDATE(HIT_RVA2)  |
     |          |            |<-----------+----------|
     |          |            |            |          |
     |          |            |      5.UPDATE(AC)     |
     |          |            |------------+--------->|
     |          |            |        6.UPDATE(AC)   |
     |<---------+------------+------------+----------|
     |          |            |            |          |
     |  7.UPDATE(ACR)        |            |          |
     |----------+------------+------------+--------->|
     |          |            |            |          |
     |          |            |        8.UPDATE(ACR)  | 8a. old RVA
     |          |            |<----------------------| forwards packets
                                                       to new RVA

   Figure 8: Inter-RVA Handover - old RVA Update

   It is possible to perform an inter-RVA handover without signalling
   the RVS.  The advantage of this approach is the reduced overhead of
   the handover, but it requires the RVAs to act as RVSs (forwarding de
   I1 packet) for every registered HMN.  This forms a cascading chain of
   RVSs that could be desirable if the geographical area covered by one
   RVA is considerably big.  This matter requires further study.

   For fast mobility a preparation phase is required.  The HMN needs to
   inform the current RVA that it is changing and to perform a BE with
   the new RVA.  The current RVA starts forwarding packets to the new
   RVA.  After the move, the HMN explicitly signals the new RVA which
   performs performs location updates to other RVA's or HCN's.  Further
   investigation is required on this matter.

6.7.  RVA to RVA Update

   When the new RVA receives the forwarded packets from another RVA, it
   updates the location to the HCNs RVA's.  The forwarded packets need
   to be differentiated from the normal traffic, allowing a RVA to



Matos, et al.           Expires September 7, 2006              [Page 23]

Internet-Draft           HIP Privacy Extensions               March 2006


   decide when mobility updates are needed or not.  This is acomplished
   by using the HIP FROM_ID PARAMETER in a new HIP Header inserted at
   the old RVA.  This allows increased security, authentication and
   triggers updates from the new RVA.  The procedure is depicted in
   Figure 9.

   +----+       +-------+       +-------+     +-----+     +----+
   |HMN1|       |new_RVA|       |old_RVA|     | RVA |     |HMN2|
   +-+--+       +---+---+       +---+---+     +--+--+     +-+--+
     |              |               |            | 1.DATA() |
     |              |               |            |<---------|
     |              |               |   2.DATA() |          |
     |              |               |<-----------+          |
     |              | 3.HIP(DATA()) |            |          |
     |              |<--------------|            |          |
     |  4.DATA()    |               |            |          |
     |<-------------|               |            |          |
     |              |  5.UPDATE()   |            |          |
     |              |---------------+----------->|          |
     |              |               |            |          |
     |              |               | 6.UPDATE() |          |
     |              |<--------------+------------|          |
     |              |               |            |          |
     |              |  7.UPDATE()   |            |          |
     |              |---------------+----------->|          |
     |              |               |            |          |

   Figure 9: HCN's RVA update after handover























Matos, et al.           Expires September 7, 2006              [Page 24]

Internet-Draft           HIP Privacy Extensions               March 2006


7.  Conceptual Data Structures

7.1.  HIP Mobile Node

   The HMN MUST have a path to the AR currently being used.  The table
   of all reachable ARs MAY be maintained.  This table should contain
   the RVA HIT, AR's MAC address and association lifetime.  Note that a
   AR may belong to two or more different RVA protected areas.

      +---------------------------------------------------+
      | RVA Host Identity Tag | AR MAC Address | Lifetime |
      +-----------------------+----------------+----------+
      |         ...           |        ...     |    ...   |
      +-----------------------+----------------+----------+

   Figure 10: HMN data structure

7.2.  Access Router

   The AR must maintain a HIT based neighbor table so that packet
   forwarding is possible, since there are no locators in RVA protected
   areas.

      +--------------------------------------------+
      | Host Identity Tag | MAC Address | Lifetime |
      +-------------------+-------------+----------+
      |       ...         |     ...     |    ...   |
      +-------------------+-------------+----------+

   Figure 11: AR data structure

7.3.  Rendezvous Agent

   The RVA MUST maintain a HMN HIT based table for downlink packet
   handling.  This entry keeps track of which AR the HMN is currently
   attached.

   The table MUST also contain location information (i.e. the globally
   assigned IPv6 address) for each registered HMN for packet routing in
   the core network.

      +-------------------------------------------------------------+
      | Host Identity Tag |AR MAC Address | Lifetime | IPg Assigned |
      +-------------------+---------------+----------+--------------+
      |       ...         |     ...       |    ...   |     ...      |
      +-------------------+---------------+----------+--------------+

   Figure 12: RVA data structure



Matos, et al.           Expires September 7, 2006              [Page 25]

Internet-Draft           HIP Privacy Extensions               March 2006


   The RVA maintains also a table containing information for each
   established session between nodes in the RVA protected area and CNs
   for proper data packet processing.

      +----------------------------------------------------+
      |  HMN registered   |        HCN        |  HCN/RVA   |
      | Host Identity Tag | Host Identity Tag |     IP     |
      +-------------------+-------------------+------------+
      |       ...         |       ...         |     ...    |
      +-------------------+-------------------+------------+

   Figure 13: Registered HMNs session data structure







































Matos, et al.           Expires September 7, 2006              [Page 26]

Internet-Draft           HIP Privacy Extensions               March 2006


8.  Compatibility Mode

   In a scenario where an HMN in a RVA domain is able to initiate a HIP
   session with a HCN not in RVA domain (directly connected to core
   network), the HMN's RVA location is revealed to the HCN.

                          +---+
               +---+      |HCN|        +---+
               |RVS|      +-+-+        |DNS|
               +-+-+        |          +-+-+
                 |        +-+------+     |
                 +--------|INTERNET+-----+
                          +---+--+-+
                              |  |
                     +--------+  +---------+
                     |                     |
                   +-+--+                +-+--+
                   |RVA1|                |RVA2|
                   ++--++                ++--++
                    |  |                  |  |
                 +--+  +--+            +--+  +--+
                 |        |            |        |
               +-+-+    +-+-+        +-+-+    +-+-+
               |AR1|    |AR2|        |AR3|    |AR4|
               +---+    +---+        +---+    +-+-+
                 |
              +--+-+
              |HMN |
              +----+

   Figure 14: Compatibility topology

   This scenario has obvious implications in location privacy.  A HCN is
   able to track the RVAs a HMN is using by inspecting the Update
   messages.  The HCN's location is still protected from the HCN.

   This issue can be solved by a full RVA deployment.














Matos, et al.           Expires September 7, 2006              [Page 27]

Internet-Draft           HIP Privacy Extensions               March 2006


9.  Security Considerations

   It is suggested that the nodes use IPsec in tunnel node.  If IPsec
   transport mode is used, a simple traceroute from one end to another
   might disclose the corresponding node's RVA, even if both exist
   behind an RVA protected area.  Using IPsec tunnel, only one hop
   exists between communicating nodes, providing more location privacy
   against this kind of attacks.  The drawback of using tunnel mode is
   the encapsulation overhead.

   Further security considerations are currently being investigated and
   will be added in future revisions of this memo.







































Matos, et al.           Expires September 7, 2006              [Page 28]

Internet-Draft           HIP Privacy Extensions               March 2006


10.  Open Issues

10.1.  RVA Certification

   When the HMN performs the BE with the RVA it should send its
   certificate, so that afterwards the RVA can perform mobility updates
   to other RVAs in a secure manner.  The [I-D.ietf-hip-base] a CER
   parameter is defined and can be used to deliver mobility handling
   delegation to a RVA.  For now it is assumed that trust between the
   RVAs is implicit and that the communication between two RVAs is done
   via a HIP association.

10.2.  Levels of Responsibility Assignment

   The proposed architecture can be hierarchical and provide several
   levels of responsibility assignment.  Basically, a RVA attaching down
   in other RVA may delegate to the top most RVA responsibility for it.
   This scenario may provide an environment for network mobility
   support.  This matter requires further study.

10.3.  Credit Based Authorization

   Credit Based Authorization [I-D.vogt-hip-credit-based-authorization]
   is a potentical item for itegration, due to the fact that prior to an
   update, the node is required to perform a Base Exchange with the RVA
   of the new network.  The framework would gain in terms of overall
   performance, reducing the time between association and updates and
   data packets flowing through the network.























Matos, et al.           Expires September 7, 2006              [Page 29]

Internet-Draft           HIP Privacy Extensions               March 2006


11.  IANA Considerations

   This document makes no request of IANA.
















































Matos, et al.           Expires September 7, 2006              [Page 30]

Internet-Draft           HIP Privacy Extensions               March 2006


12.  Acknowledgements

   We would like to thank Bernd Lamparter, Andreas Festag and Lars
   Eggert for their comments and suggestions on this document.















































Matos, et al.           Expires September 7, 2006              [Page 31]

Internet-Draft           HIP Privacy Extensions               March 2006


13.  References

13.1.  Normative References

   [I-D.ietf-hip-arch]
              Moskowitz, R. and P. Nikander, "Host Identity Protocol
              Architecture", draft-ietf-hip-arch-03 (work in progress),
              August 2005.

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokella, P., and T.
              Henderson, "Host Identity Protocol",
              draft-ietf-hip-base-05 (work in progress), March 2006.

   [I-D.ietf-hip-dns]
              Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions",
              draft-ietf-hip-dns-06 (work in progress), February 2006.

   [I-D.ietf-hip-esp]
              Jokela, P. and R. Moskowitz, "Using ESP transport format
              with HIP", draft-ietf-hip-esp-02 (work in progress),
              March 2006.

   [I-D.ietf-hip-mm]
              Henderson, T., "End-Host Mobility and Multihoming with the
              Host Identity Protocol", draft-ietf-hip-mm-03 (work in
              progress), March 2006.

   [I-D.ietf-hip-registration]
              Laganier, J., "Host Identity Protocol (HIP) Registration
              Extension", draft-ietf-hip-registration-01 (work in
              progress), December 2005.

   [I-D.ietf-hip-rvs]
              Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
              progress), October 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [I-D.haddad-momipriv-problem-statement]
              Haddad, W., "Privacy for Mobile and Multi-homed Nodes:
              MoMiPriv Problem Statement",
              draft-haddad-momipriv-problem-statement-02 (work in



Matos, et al.           Expires September 7, 2006              [Page 32]

Internet-Draft           HIP Privacy Extensions               March 2006


              progress), October 2005.

   [I-D.haddad-momipriv-threat-model]
              Haddad, W., "Privacy for Mobile and Multi-homed Nodes
              (MoMiPriv): Formalizing the Threat  Model",
              draft-haddad-momipriv-threat-model-01 (work in progress),
              October 2005.

   [I-D.vogt-hip-credit-based-authorization]
              Vogt, C., "Credit-Based Authorization for HIP Mobility
              with Concurrent IP-Address  Tests",
              draft-vogt-hip-credit-based-authorization-00 (work in
              progress), February 2005.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4140]  Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 Mobility Management
              (HMIPv6)", RFC 4140, August 2005.































Matos, et al.           Expires September 7, 2006              [Page 33]

Internet-Draft           HIP Privacy Extensions               March 2006


Authors' Addresses

   Alfredo Matos
   IT Aveiro
   Campus Universitario de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   Email: alfredo.matos@av.it.pt


   Justino Santos
   IT Aveiro
   Campus Universitario de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   Email: jsantos@av.it.pt


   Joao Girao
   NEC Europe Ltd
   Kurfuersten Anlage 36
   Heidelberg  D-69115
   Germany

   Phone: +49 (0)6221 905 11 17
   Fax:   +49 (0)6221 905 11 55
   Email: joao.girao@netlab.nec.de


   Marco Liebsch
   NEC Europe Ltd
   Kurfuersten Anlage 36
   Heidelberg  D-69115
   Germany

   Phone: +49 (0)6221 905 11 46
   Fax:   +49 (0)6221 905 11 55
   Email: marco.liebsch@netlab.nec.de







Matos, et al.           Expires September 7, 2006              [Page 34]

Internet-Draft           HIP Privacy Extensions               March 2006


   Rui Aguiar
   IT Aveiro
   Campus Universitario de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   Email: ruilaa@det.ua.pt










































Matos, et al.           Expires September 7, 2006              [Page 35]

Internet-Draft           HIP Privacy Extensions               March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Matos, et al.           Expires September 7, 2006              [Page 36]