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]