Internet DRAFT - draft-girao-generic-privacy-framework

draft-girao-generic-privacy-framework






Mobility and Multi-homing Privacy                           B. Lamparter
Internet-Draft                                                  J. Girao
Expires: January 9, 2006                                      M. Liebsch
                                                                T. Melia
                                                         NEC Europe Ltd.
                                                            July 8, 2005


                  A Generic Location Privacy Framework
                draft-girao-generic-privacy-framework-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes a generic framework that aims at protecting the
   privacy of its users.  It considers both the use of generic
   identifiers as well as concrete examples of applications.
   Furthermore, it provides a mobility framework with location privacy
   in mind.




Lamparter, et al.        Expires January 9, 2006                [Page 1]

Internet-Draft         Location Privacy Framework              July 2005


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.  Framework Overview . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   Concepts . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1   Identifiers and Locators . . . . . . . . . . . . . . .  7
         3.1.1.1   Global Identifier (GID)  . . . . . . . . . . . . .  8
         3.1.1.2   Pseudonym (PSID) . . . . . . . . . . . . . . . . .  8
         3.1.1.3   Regional Locator (RLoc)  . . . . . . . . . . . . .  9
       3.1.2   Mapping of Identifiers . . . . . . . . . . . . . . . .  9
       3.1.3   Visibility . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.4   Transport  . . . . . . . . . . . . . . . . . . . . . . 10
         3.1.4.1   Access Network . . . . . . . . . . . . . . . . . . 10
         3.1.4.2   Core Network/Backbone  . . . . . . . . . . . . . . 11
     3.2   Conceptual Data Structures (CDS) . . . . . . . . . . . . . 11
       3.2.1   Mobility Gateway CDS . . . . . . . . . . . . . . . . . 11
       3.2.2   Location Register CDS  . . . . . . . . . . . . . . . . 11
       3.2.3   Identity Server CDS  . . . . . . . . . . . . . . . . . 12
     3.3   Description of the Functional Elements . . . . . . . . . . 12
       3.3.1   Mobility Gateway (MGW) Function  . . . . . . . . . . . 12
       3.3.2   Location Registry (LR) Function  . . . . . . . . . . . 12
       3.3.3   Identity Server (IDsrv) Function . . . . . . . . . . . 13
       3.3.4   Mobility Attendant (MA) Function . . . . . . . . . . . 13
       3.3.5   Mobile Client (MC) Function  . . . . . . . . . . . . . 13
   4.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . . 14
     4.1   Registration . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2   CN to MN communication . . . . . . . . . . . . . . . . . . 15
     4.3   Creating a Pseudonym . . . . . . . . . . . . . . . . . . . 16
     4.4   GID to Pseudonym mapping . . . . . . . . . . . . . . . . . 16
     4.5   Pseudonym to Regional Locator  . . . . . . . . . . . . . . 17
     4.6   Accessing a Service Pseudonym  . . . . . . . . . . . . . . 17
   5.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1   Micro Mobility (between ARs) . . . . . . . . . . . . . . . 18
     5.2   Macro Mobility (between MGWs)  . . . . . . . . . . . . . . 18
     5.3   Other Mobility Issues  . . . . . . . . . . . . . . . . . . 20
   6.  Communication with legacy nodes  . . . . . . . . . . . . . . . 21
     6.1   MN initiates a connection to CN  . . . . . . . . . . . . . 21
     6.2   CN initiates a connection to MN  . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     7.1   Trust  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       7.1.1   Between MNs and others . . . . . . . . . . . . . . . . 23



Lamparter, et al.        Expires January 9, 2006                [Page 2]

Internet-Draft         Location Privacy Framework              July 2005


       7.1.2   Between MGWs and others  . . . . . . . . . . . . . . . 23
       7.1.3   Between CNs and LRs  . . . . . . . . . . . . . . . . . 23
       7.1.4   Between different Operators  . . . . . . . . . . . . . 23
       7.1.5   Security Gateways (SGWs) . . . . . . . . . . . . . . . 23
     7.2   Cross Certification  . . . . . . . . . . . . . . . . . . . 23
       7.2.1   As a means to Authorization  . . . . . . . . . . . . . 23
       7.2.2   As a means to Authentication . . . . . . . . . . . . . 23
     7.3   Encryption between MNs and IDsrv . . . . . . . . . . . . . 23
   8.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 24
     8.1   With IPv4/v6 . . . . . . . . . . . . . . . . . . . . . . . 24
     8.2   With HIP . . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 26
     10.2  Informative References . . . . . . . . . . . . . . . . . . 26
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
       Intellectual Property and Copyright Statements . . . . . . . . 28


































Lamparter, et al.        Expires January 9, 2006                [Page 3]

Internet-Draft         Location Privacy Framework              July 2005


1.  Introduction

   As network architectures evolve, the requirements of an aware user
   will also be adjusted to his new environment.  The concepts of
   mobility and global reachability start to enter the homes of the
   users, as services such as VoIP gain popularity.  Today, the
   requirements for the everyday use of the Internet are already quite
   different from the ones a few years ago, in terms of security and
   privacy.

   In order to keep up with user requirements, the authors of
   [I-D.haddad-momipriv-problem-statement], have enumerated a list of
   issues that affect the user's privacy.  Together with [I-D.haddad-
   momipriv-threat-model], they establish a working base for what is
   described in this draft as a generic location privacy framework with
   mobility support.  This framework is a proposal to address the issues
   on these drafts, as well as identifying other issues that appear once
   an architecture based on this framework is in place.

   As defined in [I-D.haddad-momipriv-threat-model], location privacy is
   the capability of preventing other parties from learning one's past
   or current location.  Here location pertains to the 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 Identifier and its location.

   Furthermore, as a next step towards location privacy, it may even be
   desirable that the Access Network (AN) cannot identify the user
   associated to a locator.  For this reason, we introduce the concept
   of pseudonym, in the framework, which maps the identifier of the node
   with another identifier, the pseudonym, which cannot be tracked back
   to the user.  This way, we can disassociate global reachability with
   addressing and routing issues, which presents new opportunities for
   business models and incorporation of identity management schemes in
   the future architectures of the Internet.

   This framework considers issues on mobility and security from the
   beginning.  While a user's identity and location are more related
   with privacy, for such an architecture there are also heavy
   requirements on trust.  The user must know, without any doubt, that
   his location is indeed safe from an eavesdropper.  At the same time,
   this framework impacts mobility since the mappings from identifiers
   to pseudonyms and from pseudonyms to locators can be quite volatile.
   This fact alone impacts the reachability of the node.

   As a last step, we must also consider that an architecture based on
   this framework may not be available to every communicating node.



Lamparter, et al.        Expires January 9, 2006                [Page 4]

Internet-Draft         Location Privacy Framework              July 2005


   Therefore, we must consider nodes which run with other mobility
   schemes or simply don't have one at all.  These issues are addressed
   in the section on communication with legacy nodes.

   This memo focuses on the distribution of functional elements over the
   network and the connections between them.  These elements can then be
   instantiated, or partly instantiated, using well known standardized
   approaches such as Mobile IP [RFC2002], Hierarchical MIP [I-D.ietf-
   mobileip-hmipv6] or even HIP [I-D.ietf-hip-base].  One example is
   given with a partial application of the framework using HIP in
   [I-D.matos-hip-privacy-extensions].  The objective is to obtain an
   infrastructure which is possible to build over already well known
   network architectures and network layers.  Although we do not target
   layer 2 location privacy problems, we do provide comments on how to
   integrate solutions for L2 issues into the architecture.




































Lamparter, et al.        Expires January 9, 2006                [Page 5]

Internet-Draft         Location Privacy Framework              July 2005


2.  Terminology

   o  Regional Locator (RLoc) - This identifier is the address used to
      actually route data between MGWs.  The RLoc of a node is only
      revealed to trusted nodes, especially the MGWs.  An end user
      device shall never get knowledge of any RLoc including his own
      one.

   o  Global Identifier (GID) - This is the identifier under which a
      server or device is reachable.

   o  Pseudonym (PSID) - This ID is used temporarily to identify a
      device or server.  Its scope is global.

   o  Identity Server (IDsrv) - This server maps global identifiers to
      pseudonyms.

   o  Location Registry (LR) - This server maps pseudonyms to RLoc.
      I.e. trusted MGWs may ask the LR for the RLoc of a given
      pseudonym.  Note: The IDsrv and the LR should not be able to
      cooperate.  I.e. the IDsrv is not allowed to ask the LR for the
      RLoc of a given pseudonym.

   o  Mobility Gateway (MGW) - This router asks the LR for the mappings
      between pseudonym to RLoc and hence is able to forward this
      identifiers when forwarding packets between nodes.

   o  Mobile Node (MN) - This nodes can change their point of attachment
      to the Internet anytime.  They communicate with each other using
      pseudonyms only.

   o  Access Router (AR) - This is the first router for a MN.  Usually
      the AR has a wireless interface to let MNs connect and a wired
      interface to connect to the Internet.

















Lamparter, et al.        Expires January 9, 2006                [Page 6]

Internet-Draft         Location Privacy Framework              July 2005


3.  Framework Overview

   In this section we present an overview of the framework and of it's
   components.  To simplify, we map functional elements to nodes in a
   generic architecture which we represent as an example in Figure 1.
   We provide Figure 1 as a road-map to this section.

              +--+                   +-----+
              |LR|                   |IDsrv|
              +-++                   +--+--+
                |        +--------+     |
                +--------+INTERNET+-----+
                         +---+--+-+
                             |  |
                    +--------+  +---------+
                    |                     |
                  +-+--+                +-+--+
                  |MGW1|                |MGW2|
                  ++--++                ++--++
                   |  |                  |  |
                +--+  +--+            +--+  +--+
                |        |            |        |
              +-+-+    +-+-+        +-+-+    +-+-+
              |AR |    |AR |        |AR |    |AR |
              +-+-+    +---+        +---+    +-+-+
                |                              |
              +-+-+                          +-+-+
              |MNa|                          |MNb|
              +---+                          +---+

                   Figure 1: Basic architecture example

   This example portraits the distribution of the functional elements
   over a typical instantiation of the framework.

3.1  Concepts

   This section explains the location privacy concept.  First we explain
   the used identifiers and locators, how they are mapped to each other,
   and for which entity they are visible.  Then we explain briefly how
   packets are transported over the network.

3.1.1  Identifiers and Locators

   Figure 2 gives an overview of the different identifiers and the
   entities which may know the mapping between the identifiers.  No
   entity should ever get knowledge of both mappings because the mapping
   from GID to RLoc should never be revealed to anybody.  In the



Lamparter, et al.        Expires January 9, 2006                [Page 7]

Internet-Draft         Location Privacy Framework              July 2005


   following sections the identifiers are explained.

             +------+
             | GID  |\
             +--+---+ |
                |     | - Identity Server (IDsrv)
             +--+---+ |
             | PSID |X
             +--+---+ |
                |     | - Location Register (LR), Mobility Gateway (MGW)
             +--+---+ |
             | RLoc |/
             +------+

       Figure 2: Mapping of Global Identifiers and Regional Locators


3.1.1.1  Global Identifier (GID)

   This is the anchor under which a node can be reached.  The identifier
   can be an NAI [RFC2486], a full qualified domain name (FQDN), or any
   other identifier with a structure allowing a scalable name
   resolution.  This identifier is never used in the actual
   communication between two nodes.

3.1.1.2  Pseudonym (PSID)

   The pseudonym is only used temporarily for the communication between
   two nodes.  A node might use a new pseudonym for new sessions.  This
   is useful if e.g. a bank wants to hide the identity.  Because
   pseudonyms cannot can be mapped back to GIDs by ordinary nodes, an
   eavesdropper cannot find out with whom a node is communicating.  Even
   if the eavesdropper communicates with the same node as a honest MN he
   would not know, because different pseudonyms are used.

   Depending on the scenario the pseudonym can be flat or hierarchical.
   In the hierarchical case any node can find out which is the
   responsible LR.  This reveals the administrative domain of an MN's
   LR.  If this is the same as the domain of the GID and the
   communication partner anyhow knows the GId, there is no reason of
   hiding.

   If this domain should be hidden, a flat pseudonym must be chosen.
   But still mapping of the pseudonym to a RLoc is necessary to setup a
   connection.  Hence either the RLoc is directly known by the IDsrv or
   the Idsrv knows the LR and reveals it to trusted nodes.





Lamparter, et al.        Expires January 9, 2006                [Page 8]

Internet-Draft         Location Privacy Framework              July 2005


3.1.1.3  Regional Locator (RLoc)

   The RLoc is used to transport user data between MGWs.  This can be an
   IP-in-IP tunnel, a NAT or some other mechanism.  There are two
   constraints.  The first is, that the mechanism allows to reconstruct
   the original packet sent by the MN.  I.e. that MN and CN see the
   connection between the MGWs as one hop.  The second constraint is,
   that CN cannot find out the location of MN.

   Note 1: If NA(P)T is used, i.e. the MGWs translate the pseudonyms to
   RLocs and back, the MN might be able to use traceroute or other tools
   in order to find out the location of CN.  Additionally the TTL header
   field reveals the distance between MGWs and changes in this distance.
   Hence MN can guess to some extend the location of CN.  An IP-in-IP
   tunnel avoids this vulnerabilities but has slightly higher overhead.
   Additionally fewer RLocs are needed.

   Note 2: It is close to impossible to really hide the distance,
   because a measurement of the end-to-end delay is always possible.

3.1.2  Mapping of Identifiers

   o  GID - PSID: IDsrv - During registration an MN contacts his IDsrv
      to register a pseudonym.  The pseudonym is calculated by the IDsrv
      according to a profile and parameters MN sent with the request.
      From now on trusted nodes (especially trusted MGWs) can ask IDsrv
      for the current PSID of a node by sending the GID.  A node may
      register multiple pseudonyms and tell IDsrv that they may be used
      only once. in this case a mechanism is needed to let the node know
      when new pseudonyms are needed.  Remark [BL]: perhaps a node can
      learn implicitly of a new pseudonym whenever he is contacted.
      This feature could be useful for big banking servers.  Whenever an
      MN wants to contact a CN, he asks the MGW for a pseudonym.  The
      GID is encrypted, so that the MGW cannot learn it.  This means
      that a SA between MN and IDsrv is needed.  The MGW in turn asks
      the corresponding IDsrv for the pseudonym including the address of
      the corresponding LR.  The address might be implicitly given as
      part of the pseudonym.  In this case the involvement of the MGW
      would not be necessary, but this is not known before the response
      is received.

   o  PSID - Loc: LR/MGW - When a packet from MN arrives at MGW via the
      access network, MGW has to transmit the packets to the MGW of CN.
      I.e. a mapping of the two pseudonyms to RLocs is necessary.  The
      RLoc of MN is already known from the time when MN attached to MGW.
      Because MGW stored the LR of each pseudonym MN asked for, MGW can
      ask LR for the RLoc of CN (Rem.: MGW might perform this query
      before and cache the result).  If the LR trusts the MGW, it



Lamparter, et al.        Expires January 9, 2006                [Page 9]

Internet-Draft         Location Privacy Framework              July 2005


      reveals the RLoc of CN.  From now on the MGW can forward traffic
      of MN to CN and back.  Note: If LR does not fully trust MGW, it
      might point to an intermediate MGW which he trusts.  This MGW then
      acts transparently as forwarder to the MGW to which CN is attached
      to.  Principally even a chain of MGWs is possible.  It has to be
      analyzed what protection this network exactly gives (e.g. against
      traceroute).


3.1.3  Visibility

   The identifiers are visible by some entities.  The following table
   gives an overview:

               +-----------+-------+-------+------+------+
               |           | MN/CN | IDsrv |  LR  | MGW  |
               +-----------+-------+-------+------+------+
               | GID       |   Y   |   Y   |   N  |  N   |
               +-----------+-------+-------+------+------+
               | Pseudonym |   Y   |   Y   |   Y  |  Y   |
               +-----------+-------+-------+------+------+
               | RLoc      |   N   |   N   |   Y  |  Y   |
               +-----------+-------+-------+------+------+

   Usually, the RLoc should not even be revealed to the MN.  The main
   reason is that some software could accidentally or maliciously read
   and reveal it to non-authorized entities.

3.1.4  Transport

   The transport of packets is split into two areas: The Access Network
   and the Core Network.  Packets from MN usually travel first through
   an access network, then through the core, and then again through an
   access network to the CN.

3.1.4.1  Access Network

   The access network is responsible for transporting packets from the
   mobile node to the MGW.  This draft does not mandate any technology
   for this transport mechanism.  The only requirements are that it has
   to support the flat address scheme of the pseudonyms and that never
   RLocs are revealed to MNs or other unauthorized nodes.  Possible
   technologies are:

   o  Any layer-2 technology

   o  Techniques like cellular IP where the routers maintain a routing
      table.



Lamparter, et al.        Expires January 9, 2006               [Page 10]

Internet-Draft         Location Privacy Framework              July 2005


   o  Tunneling the packets from the MGW to the access router MN is
      attached to.


3.1.4.2  Core Network/Backbone

   The core network is responsible for transporting packets of the MNs
   between the MGWs.  Addressing between the MGWs is done by the RLocs.
   Packets from the MN destined to CN get newly addressed with RLocs and
   send towards the next MGW.

3.2  Conceptual Data Structures (CDS)


3.2.1  Mobility Gateway CDS

   The Mobility Gateway must maintain a Local Mobility table to map
   registered MNs' RLoc to the information required for routing packets
   within a Mobility Gateway's domain.  Dependent on the protocol
   solution for local mobility, the RLoc can be mapped either to the
   MN's detailed location information, or to a corresponding next hop.
   Further mapping policies are possible in case of relying on
   hierarchical approaches for local mobility management.  Details about
   locators or identifiers, to which a particular RLoc is mapped, are
   out of the scope of this document and must be maintained in the Local
   Mobility table appropriately.

   Since the Mobility Gateway represents the relay for data packets
   being sent and received by MNs and at the same time serves as
   responsible entity to hide location information of communication
   peers, the Local Mobility table must dynamically support the Mobility
   Gateway's resolution function of CN information and add information
   about the CN's RLoc.  This entry comprises binding information
   between the addressed CN's PSID and its associated RLoc.  As soon as
   a CN's binding is available in a Mobility Gateway's Local Mobility
   table, this information can serve the Mobility Gateway to quickly
   relay other MNs' packets to quickly relay packets to the CN without
   the need to initiate a further resolution process.

3.2.2  Location Register CDS

   The Location Register must maintain a Location table to allow mapping
   of registered MNs' pseudonym to the associated RLoc.  A particular
   MN's entry is generated during the registration procedure and
   comprises the binding between the PSID and the RLoc.  Since the
   generation of both, the registered MN's PSID and the associated RLoc
   is under control of a function different from the Location Register,
   the binding will be explicitly registered from external functional



Lamparter, et al.        Expires January 9, 2006               [Page 11]

Internet-Draft         Location Privacy Framework              July 2005


   entities and must be made available to the Location Register or
   external functional entities on request.

3.2.3  Identity Server CDS

   The Identity Server must maintain an ID table that is used to map
   registered nodes' Global Identifier to an associated pseudonym.  To
   do so, the Identity Server populates the table during MNs'
   registration.  Pseudonyms can either be generated locally on the
   Identity Server or with the help of an external function.
   Furthermore, information about the Location Register, which has been
   assigned to the MN during the registration procedure, must be stored
   with the MN's entry in the ID table.

3.3  Description of the Functional Elements

   This chapter describes the functional elements (FE), which are
   required to support the operation of the proposed framework for
   location privacy.  Mapping of the described FEs to physical
   components can be done arbitrarily and is out of the scope of this
   document, but in some cases it is obvious where FEs should be
   implemented.  Different schemes in mapping FEs to physical components
   provides flexibility in realizing the proposed framework by means of
   using and incorporating available protocols, as for name resolution
   or mobility management.

3.3.1  Mobility Gateway (MGW) Function

   The MGW represents a proxy to MNs for mobility-related signaling and
   data packet forwarding, which hides MNs' detailed location
   information and local movements to the outside of a MGWs domain.  The
   MGW learns about a MN's PSID during the registration phase.  The PSID
   and the MN's location information is used to maintain a Local
   Mobility table in the MGW, which is used to add and remove routing
   and identifier information to/from packets being forwarded.  As the
   locator of CNs should not be revealed to MNs, the MGW adds CNs'
   address information to packets, which are originated by MNs.  This is
   done by means of adding the RLoc information of CNs to these packets.
   Return packets arriving at the MGW for being forwarded to the MN will
   be removed the RLoc information of CNs and only the PSID will remain
   in the packet to identify the CN.  The MGW has to find out the RLoc
   of a particular CN as soon as the MN wants the MGW to relay a packet.

3.3.2  Location Registry (LR) Function

   The LR function performs mapping between an MN's PSID and the
   associated RLoc.  During an MN's registration procedure, the MGW
   informs the LR function about the binding between the MN's PSID and



Lamparter, et al.        Expires January 9, 2006               [Page 12]

Internet-Draft         Location Privacy Framework              July 2005


   its RLoc.  Based on this information, the LR creates an entry for the
   MN in its Location table.  The LR function might serve as a pure
   resolution database without any functionality to generate identifiers
   or locators.  Dependent on the mapping of the LR function to physical
   components , the node implementing the LR function might also perform
   proxy functionality.

3.3.3  Identity Server (IDsrv) Function

   The IDsrv function performs mapping between a registered MN's GID and
   its PSID.  During an MN's registration procedure, the MGW informs the
   IDsrv function about the binding between the MN's GID.  If the IDsrv
   has no entry for the registering MN in its ID table, it creates a new
   entry and generates a PSID for the MN.  The PSID can be generated
   either locally on the IDsrv function or with the help of another
   function, which might be collocated on the same or a remote physical
   component.  The generated PSID is sent back to the MGW to allow
   maintaining its Local Mobility table.  The LR function serves as a
   pure resolution database without providing proxy functionality.

3.3.4  Mobility Attendant (MA) Function

   The MA function is optional and might help to hide physical
   components of the visited domain to a MN.  Having for instance the MA
   co-located with an Access Router, the MA might serve as a link-local
   signaling proxy for the MN in a system that disallows MNs to learn
   about and address physical network components, which implement one or
   multiple of the functional entities described in this section,
   directly.  Details about whether an MA is stateful or stateless
   depends on the desired functionality and allowed level of complexity
   and is out of the scope of this version of the draft.  So far, the
   base functionality of the MA is mentioned in this section, but not
   used in the remaining sections of this document for simplicity
   reasons.  Some security-related reasons to include an MA in the
   signaling path are summarized in section 8.

3.3.5  Mobile Client (MC) Function

   The MC function is implemented with mobile devices and represents the
   client function to support location privacy-enabled mobility.  This
   function controls the registration and handover procedure of an MN
   and the associated protocol operation with the MGW and the IDsrv.
   The MC either communicates directly with the MGW or via an attendant
   function, which might be collocated with the mobile' Access Routers.







Lamparter, et al.        Expires January 9, 2006               [Page 13]

Internet-Draft         Location Privacy Framework              July 2005


4.  Protocol Operations

   When an MN wants to communicate with a CN, several steps are
   necessary (We assume that MN is already attached to the access
   point).  First MN has to register with the network it is currently
   visiting.  Then it has to find out the pseudonym with which he has to
   address CN.  Now it can send a packet towards the MGW.  The MGW has
   now to find out the current location of the pseudonym.  The next
   sections explain this steps in more detail.

   There are many security issues, especially every entity has carefully
   to consider which information may be revealed to which entity.  This
   is not detailed in this version of the document but only sometimes
   mentioned.

4.1  Registration

     +----+            +----+     +-----+        +--------+     +----+
     | MN |            | AR |     | MGW |        |IDsrv_MN|     | LR |
     +-+--+            +-+--+     +--+--+        +---+----+     +-+--+
       |                 |           |               |            |
       |                 |           |               |            |
       | 1.ADV(MGW,AR)   |           |               |            |
       |<----------------|           |               |            |
       |                 |           |               |            |
       |     2.Reg(IDsrv, E(MN), LR) |               |            |
       | ----------------+---------->|3.Reg(IDsrv, E(MN), LR)     |
       |                 |           |-------------->|            |
       |                 |           |               |            |
       |                 |           | 4.Conf(PSID)  |            |
       |                 |           |<--------------|            |
       |                 |           |               |            |
       |        5.Conf(PSID)         |       6.Inst(PSID, RLoc)   |
       |<----------------+-----------|---------------+----------->|
       |                 |           |             7.Ack          |
       |                 |           |<--------------+------------|
       |                 |           |               |            |
       |                 |           |               |            |

                        Figure 3: Registration MSC

   1.  Within the usual advertisement the Access Router additionally
       reveals the MGW.

   2.  MN registers with the IDsrv via the MGW.  MN has to address MGW
       because to this time MN is not globally reachable.





Lamparter, et al.        Expires January 9, 2006               [Page 14]

Internet-Draft         Location Privacy Framework              July 2005


   3.  MGW forwards the request to IDsrv which determines a random
       pseudonym (PSID) or requests one from a third party.

   4.  The pseudonym is sent back to MGW which stores the pseudonym and
       LR.

   5.  MGW sends MN the pseudonym.

   6.  MGW sends LR the RLoc of the pseudonym.

   7.  LR acknowledges the end of the registration.


4.2  CN to MN communication

   +----+     +----+    +-----+   +----------+     +----+         +----+
   | CN |     | AR |    | MGW |   | IDsrv_MN |     | LR |   ...   | MN |
   +-+--+     +-+--+    +--+--+   +----+-----+     +-+--+         +-+--+
     |          |          |           |             |              |
     |          |          |           |             |              |
     |   1.Query(E(MN))    |           |             |              |
     |----------+--------->| 2.Query(E(MN))          |              |
     |          |          |---------->|             |              |
     |          |          |           |             |              |
     |          |          | 3.QResp(PSMN, E(MN), LR)|              |
     | 4.QResp(PSMN, E(MN))|<----------|             |              |
     |<---------+----------|           |             |              |
     |          |          |           |             |              |
     | 5.SRC:PSCN DST:PSMN |           |             |              |
     |----------+--------->|      6.RLocQ(PSMN)      |              |
     |          |          |------------------------>|              |
     |          |          |           |             |              |
     |          |          |    7.RLocR(RLocMN, PSMN)|              |
     |          |          |<------------------------|              |
     |          |          |           |             |              |
     |          |          |    8.SRC:RLocCN  DST:RLocMN            |
     |          |          |----------------------------->          |
     |          |          |           |            9.SRC:PSCN DST:PSMN
     |          |          |           |             |    --------->|
     |          |          |           |             |              |
     |          |          |           |             |              |
     |          |          |           |             |              |

                          Figure 4: CN to MN MSC

   1.  CN queries MGW for the pseudonym of a given GID.  MGW cannot read
       the complete GID because it is encrypted.  But it can find out
       the domain and thus can find out the responsible IDsrv.



Lamparter, et al.        Expires January 9, 2006               [Page 15]

Internet-Draft         Location Privacy Framework              July 2005


   2.  MGW forwards the request to IDsrv.

   3.  IDsrv responds with the pseudonym (PSMN) and the responsible LR.
       MGW stores this information.

   4.  MGW forward the response to CN.

   5.  CN sends the first packet towards MN.  MGW has now to find out
       the location of MN.

   6.  MGW requests the RLoc for PSMN

   7.  If MGW is trusted the location of MN is revealed by answering
       with RLoc.

   8.  Now MGW_CN can tunnel the packets to MGW_MN.

   9.  MGW_MN strips off the RLocs and forwards the packet to MN.  MN
       only sees the packet as send out by CN.

   Remark: Steps 6 and 7 might be performed in parallel to steps 4 and 5
   for performance reasons.

   In the following sections some of the steps are described in more
   detail.

4.3  Creating a Pseudonym

   During registration of MN a pseudonym is created by the IDsrv upon
   request of MN.  The MN sends a request to the MGW.  The request
   contains the GID of MN (encrypted, so MGW cannot read it) and the
   identifier of the IDsrv.  The MGW forwards the GID to the IDsrv.  The
   response contains the address of the LR where the RLoc of MN has to
   be registered.  MGW can immediately register the RLoc of MN with LR
   in parallel to forwarding the response to MN.  The LR might be chosen
   by the MN, MGW, or IDsrv.  MGW has to know it in order to register
   MN, the IDsrv has to know it in order to be able to tell other MGWs
   the address.  This is discussed in the next section.

4.4  GID to Pseudonym mapping

   The first step for MN when starting a communication with CN is to ask
   the corresponding IDsrv for a pseudonym.  Like in the registration
   step, this request is proxied by MGW.  Also the queried GID is
   encrypted so that only IDsrv can read it.  The MGW thus only gets in
   knowledge of IDsrv and the LR.  The response is read by MGW and the
   pseudonym and LR is stored.  Because MN will soon start a
   communication with this pseudonym, MGW can already request the RLoc



Lamparter, et al.        Expires January 9, 2006               [Page 16]

Internet-Draft         Location Privacy Framework              July 2005


   of the pseudonym of CN from the given LR and cache it.

4.5  Pseudonym to Regional Locator

   After resolving the GID to a pseudonym, MN can send packets towards
   CN.  The packets are intercepted at MGW and MGW has to find out the
   proper RLoc.  Because usually MN has just send the request to find
   the pseudonym, MGW should know the corresponding LR.  Thus MGW can
   ask LR for the RLoc of the pseudonym.

4.6  Accessing a Service Pseudonym

   Usually the GID will be resolved to the pseudonym which the MN
   registered with the IDsrv and each request will resolve the same
   pseudonym.  But in some situations additional privacy services are
   needed.  If an application (=CN) wants to use a new pseudonym each
   time a client opens a sessions, the IDsrv responses with a new one
   each time a client asks for it.  Because the GID is encrypted, an
   attacker cannot find out to whom the pseudonym belongs, even if he
   has opened a session to the same service at the same time using the
   same GID.  Both, the IDsrv and CN, could generate the pseudonyms.  In
   both cases it is necessary to exchange the information between IDsrv
   and CN.  Additionally LR has to be informed.  In order to avoid the
   real-time exchange of this information, multiple pseudonyms may be
   created at once and exchanged between IDsrv, CN, and LR.  Before they
   are all used, new ones are generated.  To enable this feature, the
   registration contains a parameter which tells IDsrv how often a
   pseudonym might be used.  It could be also envisioned, that at each
   request one of a set of pseudonyms is randomly chosen by IDsrv.






















Lamparter, et al.        Expires January 9, 2006               [Page 17]

Internet-Draft         Location Privacy Framework              July 2005


5.  Mobility

   This section provides a general overview on mobility related issues.
   We mainly identify two types of mobility: micro mobility on intra-
   regional mobility and macro mobility or inter-regional mobility.

   The advantage of an architecture based on this framework is the fact
   that mobility is handled between MGWs.  Routing issues are not of the
   responsibility of the MN, which reduces the complexity of the
   terminal.

5.1  Micro Mobility (between ARs)

   Micro mobility is identified as the action of performing handovers
   within a region controlled by a single MGW.  Out of the scope of this
   document is to describe how solutions could be implemented.  As a
   basic requirement, the MGW needs to map an RLoc to a local
   identifier, either Layer two or Layer three, to perform packet
   routing/forwarding.

5.2  Macro Mobility (between MGWs)

   Macro mobility is namely the process by which the MN changes its
   current point of attachment to the network within a new region
   controlled by a new MGW.  For better understanding, we introduce the
   old MGW (oMGW) as the current MGW and the new MGW (nMGW) as the
   target MGW.  According to how the MN implements logic to discover
   neighboring networks, the handover process could be either proactive
   or reactive.

   Figure 5 describe a typical case of proactive handover.  Upon the
   discovery of a new available network under control of a nMGW the MN
   sends an HO_REQ to the oMGW indicating the willingness to change its
   point of connection.  The message contains the target MGW (nMGW).  By
   means of the PSID_UP the LR is informed a RLoc update for a specific
   PSID (and specific MGW) is imminent.  The oMGW, after receiving a
   PSID_UP_ACK, forwards the request to the nMGW in order to announce a
   new MN.  The nMGW, upon reception of the HO_DEC message, generates a
   non conflicting RLoc and updates the LR tables.  Finally the nMGW
   notifies the MN of the successful handover sending an HO_ACK message.
   This last message SHOULD piggyback the acknowledge from the oMGW.
   The advantage of the described approach is that does not require re-
   authentication procedures.  Instead, existing security associations
   between the oMGW and the LR are used to update the necessary tables.
   Moreover, it has to be noted that the proposed signalling handles
   mobility within MGWs only, allowing a context transfer alike
   communication.




Lamparter, et al.        Expires January 9, 2006               [Page 18]

Internet-Draft         Location Privacy Framework              July 2005


   Additional clarifications need to be mentioned with respect to the
   data (user) plane.  To enable seamless communications whilst a user
   is roaming between MGWs, data packets have to be duplicated, for a
   short period, to both the old link and the new link.  Techniques,
   such as bi-casting or tunneling from the oMGw to the nMGW, can be
   implemented to reduce packet loss during the handover process.
   Figure 6 depicts an example.

   In case the link connection is broken before the MN initiates any
   network discovery procedure, a reactive handover has to be issued.
   Although many possibilities to optimize this handover process are
   possible, we prefer in this case to re-run a complete registration
   procedure, avoiding time consuming handshakes between oMGW, nMGW and
   LR.

    +-----+   +------+  +------+   +-------+
    | MN  |   | oMGW |  |  LR  |   |  nMGW |
    +--+--+   +---+--+  +--+---+   +---+---+
       | HO_REQ   |        |           |
       |--------->|PSID_UP(nMGW)       |
       |          |------->|           |
       |          |PSID_UP_ACK         |
       |          |<-------|           |
       |          |HO_DEC  |           |
       |          |------------------->|
       |          |        |   RLoc_UP |
       |          |        |<----------|
       |          |        |RLoc_UP_ACK|
       |          |        |---------->|
       |          |        |           |
       |          | HO_ACK(ACK_oMGW)   |
       |<------------------------------|
       |          |        |           |

                  Figure 5: Proactive Handover Signalling
















Lamparter, et al.        Expires January 9, 2006               [Page 19]

Internet-Draft         Location Privacy Framework              July 2005


5.3  Other Mobility Issues

                  +-----+
                  | CN  |
                  +-----+
                    /
                +----------+
                |  MGW_CN  |
                +----------+
                  /      \
                 /        \
                /          \
               /            \
      +----------+        +----------+
      |   oMGW   |--------|    nMGW  |
      +----------+        +----------+
          \                    /
           \                  /
           +----+
           | MN |--------->
           +----+

                  Figure 6: Proactive Handover Signalling

   Since mobility is handled at the MGWs, one mechanism which can be
   exploited for traffic with low requirements on responsiveness and
   jitter is to shift the functionality of data forwarding to the oMGW
   and perform route optimization only as a second step, implicitly.
   Rather than having one to many packets triggered by a handover, which
   is the normal case in today's architectures, we can exploit the
   forwarding mechanisms of the oMGW, based on the PSID of the MN, to
   maintain connectivity and avoid explicit signalling to the MGW of the
   CN.  Furthermore, one can always define certain scenarios where the
   explicit signalling may be required (such as for VOIP).

















Lamparter, et al.        Expires January 9, 2006               [Page 20]

Internet-Draft         Location Privacy Framework              July 2005


6.  Communication with legacy nodes

   When an MN wants to communicate with a legacy node a compatibility
   mode must be used.  Basically the legacy CN uses the standard IPv6
   protocol, whereas MN uses the privacy enhanced protocol.  Still the
   location of MN shall not be revealed and MN should not need to
   distinguish between enhanced CNs and legacy CNs.  The idea of the
   solution is to enhance LR with a functionality similar a home agent
   (HA) in mobile IPv6.  This node behaves like a privacy enhanced CN,
   i.e. it has a layer-2 connection to a MGW.  The architecture is
   depicted in figure xxx.  The IDsrv works in this case as DNS, i.e. it
   has in addition to the pseudonyms also the home IP-address of MN.
   The MN can choose under which home address(es) it want to be
   reachable.  Registration of the home IP-address with DNS is not
   necessary.

             +---------+  +---+  +-----+
             |IDsrv/DNS|  |MGW+--+LR/HA|
             +----+----+  +-+-+  +-+---+
                  |         |     /
                  |      +-------++     +--+
                  +------|INTERNET+-----+CN|
                         +---+----+     +--+
                             |
                           +-+-+
                           |MGW|
                           +-+-+
                             |
                           +-+-+
                           |MN |
                           +-+-+

                    Figure 7: Interworking architecture


6.1  MN initiates a connection to CN

   The address of CN is given as DNS name.  As in the privacy mode MN
   can ask his IDsrv for a pseudonym, but instead the IP-address of CN
   will be in the response.  Because MGW is the proxy in this query, it
   learns learns that CN is a legacy node.  The response also contains
   the RLoc of HA.  If MN directly addresses CN, i.e. without querying
   DNS, MGW has to query MN's IDsrv for this information.  Instead of
   the usual pseudonym the IPv6 address of CN is send to MN (MGW could
   also build a pseudonym, but then the answer cannot be authenticated).
   Then MN starts sending packets towards CN.  The destination address
   is the IP-address of CN and the source the usual pseudonym.  MGW
   intercepts the packet and detects that the destination address is an



Lamparter, et al.        Expires January 9, 2006               [Page 21]

Internet-Draft         Location Privacy Framework              July 2005


   IPv6-address.  Thus the RLoc of MN's HA is used as the destination
   address and MN's RLoc as source address.  Thus the packet travels to
   the MGW of HA where the locators are removed and the packet send to
   HA.  The HA exchanges the pseudonym of MN by the home IP address and
   sends the packet to CN.  For a packet on the way back the same
   changes are performed.

6.2  CN initiates a connection to MN

   If MN wants to be reachable by legacy nodes, a DNS has to store its
   home address.  CN can query the DNS for MN's IP-address and will get
   the home IP-address.  With this CN can start a communication.  The
   packets will be intercepted at the HA of MN.  As in the last section
   the home address is exchanged by a pseudonym and the packet is
   further handled like in the case of MN initiated connections.  In
   both cases several details have to be worked out.  One example is the
   question on how and when the MGWs get knowledge of the information
   they need and how this data is transmitted to another MGW in case of
   handover.  The functionality of HA and MGW might be integrated into
   one function, i.e. the address translations and inserting/removal of
   locators are done in one step.






























Lamparter, et al.        Expires January 9, 2006               [Page 22]

Internet-Draft         Location Privacy Framework              July 2005


7.  Security Considerations

   In this section we list issues that are related to the security
   discussion on this particular draft.

7.1  Trust


7.1.1  Between MNs and others


7.1.2  Between MGWs and others


7.1.3  Between CNs and LRs

7.1.4  Between different Operators


7.1.5  Security Gateways (SGWs)

7.2  Cross Certification


7.2.1  As a means to Authorization


7.2.2  As a means to Authentication


7.3  Encryption between MNs and IDsrv




















Lamparter, et al.        Expires January 9, 2006               [Page 23]

Internet-Draft         Location Privacy Framework              July 2005


8.  Deployment Considerations

   This section will contain specific architecture issues when applying
   the framework to concrete Internet protocols.

8.1  With IPv4/v6


8.2  With HIP

   See draft-matos-hip-privacy-extensions-00.txt for a partial
   instantiation.







































Lamparter, et al.        Expires January 9, 2006               [Page 24]

Internet-Draft         Location Privacy Framework              July 2005


9.  IANA Considerations

   None.
















































Lamparter, et al.        Expires January 9, 2006               [Page 25]

Internet-Draft         Location Privacy Framework              July 2005


10.  References

10.1  Normative References

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

10.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-01 (work in
              progress), February 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-00 (work in progress),
              February 2005.

   [I-D.ietf-hip-base]
              Moskowitz, R., "Host Identity Protocol",
              draft-ietf-hip-base-02 (work in progress), February 2005.

   [I-D.ietf-mobileip-hmipv6]
              Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
              "Hierarchical MIPv6 mobility management (HMIPv6)",
              draft-ietf-mobileip-hmipv6-06 (work in progress),
              July 2002.

   [I-D.matos-hip-privacy-extensions]
              Matos, A., Santos, J., Girao, J., Liebsch, M., and R.
              Aguiar, "Host Identity Protocol Location Privacy
              Extensions", draft-matos-hip-privacy-extensions (work in
              progress), June 2005.

   [RFC2002]  Perkins, C., "IP Mobility Support", RFC 2002,
              October 1996.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.









Lamparter, et al.        Expires January 9, 2006               [Page 26]

Internet-Draft         Location Privacy Framework              July 2005


Authors' Addresses

   Bernd Lamparter
   NEC Europe Ltd.
   Kurfuersten Anlage 36
   Heidelberg, Heidelberg  D-69115
   Germany

   Phone: +49-6221-90511-50
   Fax:   +49-6221-90511-55
   Email: bernd.lamparter@netlab.nec.de


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

   Phone: +49-6221-90511-17
   Fax:   +49-6221-90511-55
   Email: joao.girao@netlab.nec.de


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

   Phone: +49-6221-90511-46
   Fax:   +49-6221-90511-55
   Email: marco.liebsch@netlab.nec.de


   Telemaco Melia
   NEC Europe Ltd.
   Kurfuersten Anlage 36
   Heidelberg, Heidelberg  D-69115
   Germany

   Phone: +49-6221-90511-42
   Fax:   +49-6221-90511-55
   Email: telemaco.melia@netlab.nec.de







Lamparter, et al.        Expires January 9, 2006               [Page 27]

Internet-Draft         Location Privacy Framework              July 2005


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




Lamparter, et al.        Expires January 9, 2006               [Page 28]