A Practical Approach to provide Communication Privacy

A Practical Approach to provide Communication Privacy Joao Girao, Bernd Lamparter, Marco Liebsch and Telemaco Melia NEC Europe Ltd. 69115 Heidelberg, Germany E-mail: {joao.girao,bernd.lamparter,marco.liebsch,telemaco.melia}@netlab.nec.de

Abstract— Privacy and security are important features for the future mobile wireless Internet since users expect a privacy level comparable to that of today’s cellular networks. Separating identifiers from locators is a current practice in today’s new network protocols and is a small step on the right direction. However, the separation must be maintained in the presence of an intruder who eavesdrops or manipulates the traffic. In this paper we present a generic framework that targets these problems at the network layer. We further instantiate this framework with an example architecture using well-known protocols which support mobility.

I. I NTRODUCTION As network architectures evolve, the requirements of a user will also adjust 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’s requirements for security and privacy in the everyday use of the Internet are already quite different from the ones of a few years ago. Although the issues related to privacy, trust and security cover the whole spectrum of computer communications, this work focuses on a subset of these issues identified in the network layer. In general, privacy can be obtained as the combination or sub-set of anonymity, pseudonymity and unlinkability. In anonymity we are concerned with the fact that an individual can not be identified by entities belonging to a certain group or without some knowledge a priori. Pseudonymity is not as strong as anonymity in the sense that it provides protection on the users’ identity but not on tracing their actions to the same pseudonym, a characteristic known as linkability. Unlinkability is the feature which unbinds different actions to the same identity, or pseudonym. In this work we focus on how to achieve the principles of anonymity, pseudonymity and unlinkability when applying them to location privacy. In location privacy we address the relation between the identifier of a node and its current or past topological location [8]. Currently, IP addresses not only identify the node but also serve as routing addresses. As a consequence, when a packet is sent from one IP address to another, both sender and receiver reveal their topological location in the network, which can then be translated to a rough estimation of the geographical location. This issue is coupled with the mechanisms that allow a user to access a certain network. Currently, the user must reveal his identity to the visited network in order to obtain permission to

join the Access Network (AN) and services. In similar manner, when a user accesses a service, his visited AN is many times allowed to observe the exchange of identifiers and the service. While most of the previous work only focused on protecting the users’ identity from other users, we believe that privacy is an issue also in the visited domain. Nevertheless, the home domain has to guarantee that the visited domain will receive payment, regardless of the anonymity of the user. Hence there must be a pseudonym for which accounting information is collected. The home network is able to map the pseudonym to a real user and to finally bill the user. The framework presented in this paper considers mobility and security from the beginning. Since the users’ identity and location are directly related to privacy, these introduce heavy requirements on the trust model assumed in the framework. The user must entrust his location to an entity in the network and must be later on assured that his location is not compromised. While this could be seen as a simple matter of confidentiality, the impact on the framework design to support mobility is not as trivial; where the mappings from identifiers to pseudonyms and from pseudonyms to locators can be volatile and the node expects to be constantly global reachable. Finally, it is not likely that such a framework is globally deployed. Since the deployment of such technologies is seldom large scale and there might be many different flavors in the mappings to the underlying architecture we must consider a hybrid system where only part of the network is protected. The rest of this paper is organized as follows: In section II we provide a short survey of related work. Section III presents our proposed solution for a generic framework followed by IV, a real life deployment example based on existing technologies. A comparison is presented in section V. We conclude the paper with our final remarks in sections VI. II. R ELATED W ORK Current work in this area focuses on two different aspects of the framework presented in this paper. The first aspect, covered in [16] [9] [4], relates to the problem of identifiers and locators and how to separate the two. The second aspect is dealt with in papers on new network architectures or mechanisms, such as [11] [3] [12] [14] [15] [6], which cover the issue of location privacy. Apart from these, currently existing protocols, such as [7] [5] [10], must also be analyzed from privacy perspective.

Traditional mobility approaches, in particular Mobile IPv4 and MIPv6 [7] [5], provide non-optimal routing mechanisms which could be used for location privacy. However, the tunneled approach via the home network impacts the performance in such a way it renders it unusable for real-time traffic. Protocols such as HIP [10] provide the separation between locator and identifier but fail in providing location privacy since the communication is done directly between the peers, using the current locators. Blind [16] is an approach to hide the identities of two peers from the network. It focuses on the generation of identifiers in such a way they are untraceable. SNF [9] and FARA [4] are two other approaches which decouple the locator and identifier properties of the names and then provide a connected network underneath. Location privacy per se is not one of the goals in either paper. New architectures, such as IP2 [11], TRIAD [3], TurfNet [12] and I3 [14], while not focusing directly on location privacy, achieve some of the goals on that path. IP2 [11] is an approach which shifts the mobility logic to the network and obscures the real position of the node by compromising simply the scope where the node is located. This is achieved by introducing an anchor point in the network which handles mobility issues, much like HMIPv6 [13] and our approach. The main differences with the framework described in this paper have to do with the amount of information revealed to the communication partners and the lack of anonymity of the user. In TRIAD [3], and I3 [14], an overlay network is set up which defines a different realm for routing, based on names. While TRIAD is meant for protecting the application level content and therefore has a different scope, it is still an interesting approach which makes use of realms and relay points to determine the scope of names and locators. I3 [14] also provides location privacy by introducing a third party entity which serves as a rendezvous point for the communication partners. Once again, this has serious impacts on performance since routing is non-optimal. TurfNet [12] is another innovative architecture which takes a different perspective on network composition and routing. Although it provides location privacy, it is very difficult to reach a set up which provides optimal routing under those conditions. The privacy aspect of this approach is also dependant on the trust between the several domains. Onion routing ([15] and further developed in [6]) is an interesting technology used to make web communication anonymous. It uses multiple onion routers to create an anonymous connection. The client first sets up a connection to the first onion routing proxy. Before a packet is sent, it is encrypted several times, so that there are several peels around the data. Each onion routers decrypts one peel before forwarding the inner part. The system protects against strong attackers because the identity of the user is hidden as long as one onion router does not reveal the last hop of a connection. However, the mechanism introduces a high amount of overhead and the identity of the user is not concealed against the access router and the first onion router.

As far as the knowledge of the authors of this paper is concerned, no approach covers both the problems of privacy at identifier level and suggests an architecture which supports them while providing location privacy. This framework aims at just that. III. F RAMEWORK In this section we present an overview of the framework for privacy support and of its relevant functional elements. To simplify the illustration and description, we map associated functional elements to nodes in a generic architecture. Such exemplary distribution of the functional elements over a typical instantiation of the framework is illustrated in Fig. 1 and comprises an Identity Server (IDsrv), a Location Register (LR), a Mobility Gateway (MGW) as well as two mobile devices representing a Mobile Node (MN) and a Correspondent Node (CN).

Fig. 1. Framework with Identity Server (IDsrv), Location Register (LR), Mobility Gateway (MGW), Mobile Node (MN) and Correspondent Node (CN)

A. Privacy Concept This section describes the privacy concept. We explain the different identifiers and locators used by the concept, the mapping between identifiers and locators, as well as visibility of individual identifiers to the different entities. 1) Identifiers and Locators: The concept relies on a Global Identifier, a Pseudonym and the actual Locator, as well as associated mapping between them with the help of the entities illustrated in Fig. 1. A key requirement of the concept is that no single network entity should ever get knowledge of both mappings since the resolution of the Global Identifier to the Locator should never be revealed to anybody. (i) The Global Identifier (GID) is the anchor under which a node can be reached. The identifier can be an NAI [1], 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. (ii) The Pseudonym (PSID) 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. Since pseudonyms cannot be mapped back to GIDs, 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 this information. If the domain should be hidden, a flat pseudonym must be chosen. But still mapping of the pseudonym to a Regional Locator (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 the LR to trusted nodes. (iii) The Regional Locator (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 exactly 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 the CN cannot find out the location of a given MN. 2) Visibility: The identifiers are visible by some entities, table I gives an overview. 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 nonauthorized entities. GID Pseudonym RLoc

MN/CN Y Y N

IDsrv Y Y N

LR N Y Y

MGW N Y Y

TABLE I V ISIBILITY OF THE DIFFERENT IDENTIFIERS TO THE INVOLVED ENTITIES

B. Protocol Operation When an MN wants to communicate with a CN, the MN must first register with the visited network. Then it has to find out the pseudonym to be used for addressing the CN. Now the MN can send packets addressed to the CN towards the MGW. The subsequent subsections describe the registration process as well as the operation between the different entities for setting up a connection. Furthermore, a mobility scenario and the communication with legacy nodes is discussed. 1) Registration: The registration procedure is illustrated in Fig. 2. An MN might learn about its responsible MGW by means of advertisements (1) or alternative discovery mechanisms. To register, the MN sends his global identifier (GID) and information about its LR to MGW1 . The GID of the MN is partly encrypted with the public key of MN’s IDsrv, so 1 Alternatively and dependent on the operators’ policy, the MGW or the IDsrv can determine the MN’s LR

the MGW can see the domain part, but not the user part of the identifier (2). The MGW forwards the request to the IDsrv of the domain referred to within the GID (3). In return, the IDsrv includes the pseudonym for the MN (4). Additional parameters for authentication (e.g. a challenge for EAP-AKA [2]) are included. The MGW determines the RLoc for the MN and sends it to the LR. In parallel the MGW finishes the authentication procedure with the MN depending on the authentication and key agreement protocol. AR

MN

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

Fig. 2.

Mobile Node registration with the network.

2) CN to MN communication: The session setup procedure is illustrated in Fig. 3. To set up a connection from the CN to an MN, the CN has to query its MGW for the PSID of the MN (identified by the MN’s GID). Again, the user part of the GID is encrypted with the public key of the responsible IDsrv so that only the domain of the MN is revealed to the MGW (1). The MGW forwards the request to the given IDsrv (2) and receives the MN’s PSID together with the corresponding LR address (3). The PSID might be constant, changed from time to time or even be a one time nonce. The MGW stores all the information and forwards only the PSID to the CN (4). The CN can now send the first packet towards the MN. The MN’s PSID is used as destination address, whereas the source address represents the CN’s PSID. The packet is routed towards the MGW with a local mechanism, e.g. hierarchical Mobile IP or any layer 2 technology (5). The MGW requests the RLoc for the destination PSID at the stored LR2 (6). Before responding (7), the LR checks whether or not the MGW is authorized to know the location of the MN. The MGWCN can now tunnel the packet to the MGWMN (8), which unpacks the packet, i.e. restores the PSIDs and forwards it with the local technique to the MN (9). Now both MGWs have learned the mappings from the PSIDs to the associated RLocs and back and can therefore forward packets without further queries. 3) Basic Mobility Support: MN and CN can now communicate with each other as long as both are in the transmission range of an AR of the same MGW. We assume that mobility between ARs of one MGW is handled in the same local way (micro mobility). Because MGWMN remains the same for the MN, there is no need to inform MGWCN or LR about the movement. In case the MN moves into the domain of a different MGW (macro mobility), some network entities must be notified. 2 This

can be queried in advance

CN

MGW

IDsrv MN

MN

LR

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[RLocMN] 7. RLocR[RLocMN,PSMN] 8. src:RLocCN dst:RLocMN 9. src:PSCN dst:PSMN

Fig. 3.

Session setup between CN and MN.

There are several schemes one could follow, e.g. Mobile IP. We describe a mobile initiated solution without going into details. The current MGW is denoted MGWold and the handover target MGW as MGWnew . To initiate the handover, the MN sends a handover request to MGWold that includes the address of MGWnew . Details about how the MGWnew is discovered are out of scope of this paper. MGWold transfers state information for the MN towards the MGWnew . Then the MGWold updates the MN’s LR as well as the MGWs of all CNs being associated with the MN’s connections. The MGWold keeps the state of the MN for some time and forwards traffic destined to the MN towards the MGWnew . The acknowledgement for handover from MGWold is already sent on the new link. If MGWold and MGWnew are in different administrative domains, it cannot be assumed that the MGWs have a mutual trust relationship. Hence operators might deploy Security Gateways (SGW) as signalling proxies between the two MGWs (section III-C). Still the actual data traffic between MN and CN is transferred directly. 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 MGWold , MGWnew , and LR. This means that the MGWCN might have to ask the LR for the new RLoc. 4) Communication with legacy nodes: When a privacy enhanced MN wants to communicate with a legacy node (CNl ) a compatibility mode must be used. Basically it is assumed that the legacy CNl uses the standard IPv6 protocol and has a FQDN, whereas the MN uses the privacy enhanced protocol. Still the location of the MN shall not be revealed to CNl and the MN should not need to distinguish between enhanced CNs and legacy CNs. The idea of the solution is to enhance the LR with a functionality similar to a Mobile IPv6 Home Agent (HA). This node behaves like a privacy enhanced CN towards the MN, i.e. it has a layer-2 connection towards a MGW (indeed the two functional entities HA and MGW might be co-located). The architecture is depicted in Fig.4. The IDsrv is also enhanced and works as DNS, i.e. it maintains in addition to the pseudonyms also the home IP-address of the MN. The MN can choose under which home address(es) it wants to be reachable. Registration of the home IP-address(es) with DNS is not a must because CNl could know them from somewhere

Fig. 4.

Interworking architecture

else (e.g. from a SIP server). When the MN now wants to initiate a connection to CNl , the MN can request its IDsrv for a pseudonym, but instead of a real pseudonym the IP-address of the CN will be in the response. Because the MGW serves as proxy in this query, it learns that CNl is a legacy node. The response also contains the RLoc of the HA. If the MN directly addresses CNl , i.e. without querying DNS, the MGW has to query the MN’s IDsrv for this information. In this way the MN’s IDsrv can choose the MGW for the session. Instead of the usual pseudonym the IPv6 address of the CN is in the response. Then the MN starts sending packets towards the CN. The destination address of packets is the IP-address of the CN and the source refers to the usual pseudonym. The MGW intercepts the packet and detects that the destination address is an IPv6-address. Thus the RLoc of the MN’s HA is used as the destination address and the MN’s RLoc as source address. The packet travels to the MGW of the HA where the locators are removed and the packet is send to HA. The HA exchanges the pseudonym of the MN by the home IP address and sends the packet to CNl . For a packet on the way back the same changes are performed. If MN wants to be reachable for legacy nodes, the home address has to be revealed somehow (e.g. DNS or SIP proxy). The CN can query this instance for the MN’s IP-address and will get the home IP-address. With this information, CNl can initiate a communication. The packets will be intercepted at the MN’s HA. 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. The functionality of the HA and the MGW might be integrated into one function, i.e. the address translations and inserting/removal of locators are done in one step. C. Security and Trust The signalling between the functional elements have to be secured (encrypted and authenticated) by standard technologies like IPsec. This includes inter operator signalling between MGWs and between MGWs and IDsrv/LR. As this is impractical we propose to include a Security Gateway (SGW)

into the framework, which is a proxy for the requests from and towards other domains. As the communication between a MN and an IDsrv is encrypted, the visited network never learns the identity of a node. If certain instances cooperate then the identity and/or the location of a node can be revealed to unauthorized entities. E.g. The cooperation of IDsrv and LR reveals the location of a node. Hence it is important that the location of a node is only given to trusted MGWs over secured links. If an MN wants to communicate with a CN located in an untrusted domain, the LR does not reveal the current RLoc of the MN, but an RLoc on a trusted MGW. This MGW then forwards the packets to the real MGW. Hence multiple MGWs might be on the path between an MN and a CN and only the first and the last remove the RLoc information, the others translate one or both of the RLocs (source, destination) to the RLoc information of the next hop in the path. This results in an overlay network build between the involved MGWs. There must be a security association between the MGWs for signalling (direct or via SGWs), but there is no security need for the transport layer. If the domains trust each other in not revealing relation between pseudonyms and RLocs, data can be send without further protection as it is sent nowadays. IV. E XAMPLE In this section we present a way of deploying existing technologies to implement the framework described in this paper. Specifically we refer to three well acknowleged technologies, namely Hierarchical Mobile IPv6 (HMIPv6) [13], Mobile IPv6 [5] and LDAP [17]. Figure 5 depicts the intended architecture. LDAP

HA

CN

INTERNET MAP MAP (MGW) MAP (MGW)

with the Home Agent and the CNs. In the presented framework the MGW can implement MAP functionalities. Thus, the RLoc (associated with a PSID) maps to the RLoc introduced in the HIMPv6 protocol. This RLoc is therefore registered in the LR, which in this case is implemented by a Home Agent. Additionally, to comply to the protocol operations specified for the session setup between a CN and a MN, the MAP has to query the LR for the resolution of a PSID-RLoc tuple. Micro mobility within a MGW domain can be considered as micromobility inside one MAP domain. B. HA implements LR Standard Mobile IPv6 can be used to implement LR functionalities. The LR can be seen as an HA retaining the binding between the PSID (to some extends a temporary home address) and the RLoc (current location of the MN). The LR will then be contacted during the registration phase by the MGW in order to update the binding cache. During the session setup the LR is contacted by the MGW (RLocQ[RLocMN] message) to resolve the RLoc of the requested node. C. The LDAP server implements IDsrv In order to realize the mapping between the GID and the generated PSID we suggest the use of an LDAP server providing information directory as well as security and advanced access control via Access Control Instances (ACIs). Here follows an example of how the system could be configured, taking into account that a user could use different/multiple PSIDs: dn: cn=GID, ou=PSID, dc=foobar, dc=com cn: GID Configuration GlobalID: AAAA Pseudonyms: BBBB Pseudonyms: CCCC Pseudonyms: DDDD The access to the information on the server would then be done over the normal operation of the LDAP protocol.

MAP

V. C OMPARISON AND D ISCUSSION MN

Fig. 5.

Deployment of existing technology

A. MAP implements MGW HMIPv6, compared to standard MIPv6, introduces a new functional entity, the Mobility Anchor Point (MAP), which controls a MAP domain composed by several access routers. The MAP is acting as a local HA, receiving all packets on behalf of the mobile node, encapsulating and forwarding them directly to the mobile node’s current address. The MN receives information about available MAPs via router advertisements messages. It configures two different IPv6 addresses: the LCoa, for IP connectivity to the AR, and the RLoc registered

A. Requirements on Privacy We see the main requirements on a privacy architecture as follows: Location Privacy The current physical location of the user should only be revealed to nodes which definitly need it for the purpose of reaching the terminal of the user. Anonymity towards the network The user needs to be authorized, but only the home network needs to know the real identity for charging reasons. The visited network only needs to know the home network of an user. Anonymity towards the communication partner Many applications in the internet don’t need any information of the user, they only need a link on which they can send packets towards the user terminal. For this an anonymous

Location Privacy Anonymity to the access network Anonymity towards CN Route optimization

Onion Routing yes

Privacy Architecture yes

Mobile IPv6 no1

no yes no

yes yes yes

no no yes1

TABLE II C OMPARISON OF DIFFERENT APPROACHES 1 I N MOBILE IP LOCATION PRIVACY AND ROUTE OPTIMIZATION EXCLUDE

unlinkability, while considering the scope of several identifiers and locators. We further investigated into this approach by performing a comparison with the state of the art and providing an example of how such a framework can be conceived using existing protocols. Since the existing protocols do not take full advantage of the framework, our next steps will consist of extending existing protocols or designing new ones to provide a full location privacy architecture.

EACH OTHER

VII. ACKNOWLEDGEMENTS identifier is sufficient. Additional information may be revealed on application level as needed. Additionally the following requirements should be considered as much as possible: Scalability Because a world-wide deployment is anticipated the solution has to be scalable, e.g. central servers have to be avoided. Optimal routing path In the current internet either the location is revealed, or the packets are routed in a triangle (MIPv6). But as triangulation increases delay and the amount of traffic it should be avoided while keeping the location secret. The privacy architecture does not provide resistance against traffic analysis. An attacker can easily find out if a certain node sends or receives traffic by listening to the wireless connection. He just needs to find out the current MAC address of the victim. If the wireless traffic is not encrypted at least the current pseudonym and the pseudonym of CN are revealed even if end-to-end encryption is used. B. Comparison with other approaches We compare our framework with two other approaches: Onion routing and Mobile IPv6. Table II shows an overview of the results, but further analysis is needed. As onion routing uses several onion routers on the path, the anonymity is higher. In our privacy architecture one compromised MGW is sufficient to trace users and to map any identity to the current location. In onion routing one trust worthy onion router is enough to provide full privacy. But this comes with the high price of non-optimal routing and several layers of encryption. If an attacker can eavesdrop the complete traffic to and from an MGW, he can match in- and outgoing packets and might be able to find the mapping between pseudonym and locator. This depends on the encryption schema between MN and MGW. At least the attacker can find the mapping from the MAC address of MN to the locator of this node. If the attacker suspects that a given identifier is in a given subnetwork he can try to contact the node and might then be able to see his own packets approaching. Some onion routing implementations send dummy traffic to prevent this attack. VI. C ONCLUSION In this paper we presented a framework which provides the elements required for privacy, anonymity, pseudonymity and

This work is supported in part by the EU Framework Programme 6 for Research and Development (IST-2002-506997). Results are part of the DAIDALOS project (http://www.istdaidalos.org). R EFERENCES [1] B. Aboba and M. Beadles. The Network Access Identifier. RFC 2486 (Proposed Standard), January 1999. [2] Bernard Aboba, Larry J. Blunk, John R. Vollbrecht, James Carlson, and Henrik Levkowetz. Extensible Authentication Protocol (EAP). RFC 3748, June 2004. [3] D. R. Cheriton and M. Gritter. Triad: A scalable deployable nat-based internet architecture, 2000. [4] David Clark, Robert Braden, Aaron Falk, and Venkata Pingali. Fara: reorganizing the addressing architecture. In FDNA ’03: Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 313–321, New York, NY, USA, 2003. ACM Press. [5] C. Perkins D. Johnson and J. Arkko. Mobility support in ipv6. RFC 3775, 2004. [6] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: The second-generation onion router. In Proceedings of the 13th USENIX Security Symposium, August 2004. [7] Charles E. Perkins (Ed.). IP Mobility Support for IPv4. RFC 3344, August 2002. [8] Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Soohong Daniel Park, and Basavaraj Pati. Privacy for Mobile and Multihomed Nodes: MoMiPriv Problem Statement. draft-haddad-momiprivproblem-statement-01, 2005. [9] Andreas Jonsson, Mats Folke, and Bengt Ahlgren. The split naming/forwarding network architecture. In First Swedish National Computer Networking Workshop, Arlandastad, 2003. [10] Robert Moskowitz, Pekka Nikander, Petri Jokela, and Thomas R. Henderson. Host Identity Protocol. draft-ietf-hip-base-03.txt, June 2005. [11] Takatoshi Okagawa, Manhee Jo, Katutoshi Nishida, and Akira Miura. Ip packet routing mechanism based on mobility management in ip-based imt network platform. In 8th International Conference on Intelligence in next generation Networks (ICIN 2003), Bordeaux, France, 2003. [12] Stefan Schmid, Lars Eggert, Marcus Brunner, and Juergen Quittek. Turfnet: An architecture for dynamically composable networks. In Proc. 1st IFIP TC6 WG6.6 Workshop on Autonomic Communication (WAC 2004), Berlin, Germany, 2004. [13] Hesham Soliman, Claude Castellucia, Karim El Malki, and Ludovic Ballier. Hierarchical Mobile IPv6 Mobility Management (HMIPv6). RFC 4140, August 2005. [14] Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, and Sonesh Surana. Internet indirection infrastructure. In Proceedings of ACM SIGCOMM, 2002. [15] Paul Syverson, Gene Tsudik, Michael Reed, and Carl Landwehr. Towards an Analysis of Onion Routing Security. In H. Federrath, editor, Proceedings of Designing Privacy Enhancing Technologies: Workshop on Design Issues in Anonymity and Unobservability, pages 96–114. Springer-Verlag, LNCS 2009, July 2000. [16] Jukka Ylitalo and Pekka Nikander. Blind: A complete identity protection framework for end-points. In to appear in Security Protocols, Twelfth International Workshop, Cambridge, 2004. [17] K. Zeilenga. Lightweight directory access protocol version 2. RFC 3494, 2003.