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]
