Dynamic Multipath Onion Routing in Anonymous Peer-To ... - Chalmers

Download PDF
3 downloads 0 Views 232KB Size Report
Comment
Tarzan [10], AP3 [11], Cashmere [12], and information slicing. [13] . The large number of available nodes, their geographic distribution and local jurisdiction and ...
Dynamic Multipath Onion Routing in Anonymous Peer-To-Peer Overlay Networks Olaf Landsiedel, Alexis Pimenidis, Klaus Wehrle

Heiko Niedermayer, Georg Carle

Department of Computer Science RWTH Aachen University, Germany [email protected]

Department of Computer Science University of Tuebingen, Germany [email protected]

Abstract— Although recent years provided many protocols for anonymous routing in overlay networks, they commonly rely on the same communication paradigm: Onion Routing. In Onion Routing a static tunnel through an overlay network is build via layered encryption. All traffic exchanged by its end points is relayed through this tunnel. In contrast, this paper introduces dynamic multipath Onion Routing to extend the static Onion Routing paradigm. This approach allows each packet exchanged between two end points to travel along a different path. To provide anonymity the first half of this path is selected by the sender and the second half by the receiver of the packet. The results are manifold: First, dynamic multipath Onion Routing increases the resilience against threats, especially pattern and timing based analysis attacks. Second, the dynamic paths reduce the impact of misbehaving and overloaded relays. Finally, inspired by Internet routing, the forwarding nodes do not need to maintain any state about ongoing flows and so reduce the complexity of the router. In this paper, we describe the design of our dynamic Multipath Onion RoutEr (MORE) for peer-to-peer overlay networks, and evaluate its performance. Furthermore, we integrate address virtualization to abstract from Internet addresses and provide transparent support for IP applications. Thus, no applicationlevel gateways, proxies or modifications of applications are required to sanitize protocols from network level information. Acting as an IP-datagram service, our scheme provides a substrate for anonymous communication to a wide range of applications using TCP and UDP.

I. I NTRODUCTION Anonymous routing and forwarding enables private communication in today’s Internet. Its applications include private webbrowsing, online voting and anonymous email, chats and content distribution. Syverson et al. proposed Onion Routing [1] as a substrate to enable anonymous communication. Using Onion Routing, a host can connect to a server through a set of relays and thereby hide its identity. Layered encryption ensures that each hop in the relay network can only decrypt the address of its successor in the relay chain. To communicate, two nodes set up a route through the relay network. As this route remains the same until the communication between the two nodes has ended, the connection-based design of today’s Onion Routers enables practical attacks against the user’s anonymity such as [2]–[4]. For example, to attack a connection, the adversary applies a traffic pattern to one of the relays of the connection. This pattern then interferes with the communication between the server and the node and can be measured at both of them [2].

Instead of using a static route between two nodes, MORE routes each packet along a different path to its destination – making timing and pattern attacks, as the one described above, useless. Furthermore, the stateless forwarding is inspired by IP-routing. Thus, a relay does not maintain state and flow information for connections as in today’s Onion Routers. This reduces the complexity of the design and the architecture, allowing for the ease of implementation of relay nodes. Additionally, dynamic multipath Onion Routing results in an improved load balancing compared to traditional static Onion Routing. As result the impact of misbehaving or overloaded nodes on the throughput is reduced. Additionally, peer-to-peer networks have a number of properties desired in Onion Routers: The large number of available nodes, their geographic distribution and local jurisdiction and political backgrounds make such a widely distributed network an ideal candidate for anonymous communication and as result our work bases on a peer-to-peer overlay. The remainder of this paper is structured as follows. First, section II addresses related work and discusses the differences to our approach. Section III presents dynamic multipath Onion Routing and transparent support of IP applications. Section IV introduces anonymous services and section V evaluates the performance of the proposed approach. Section VI discusses future work and concludes the paper. II. R ELATED W ORK In this section, we address the differences of today’s near real-time anonymous communication schemes to our approach. Their design principle dates back to the Chaumian Mix [5], in which e-mail traffic is forwarded through a set of cascading mixes to hide the sender’s identity. The traffic enters one of the mixes and leaves the mix network at some random point. To reduce the impact of malicious mixes, the route through the mixes is set up via layered encryption (Onion Routing [1]). Thus, each mix only can decrypt the information about its successor in the cascade. Based on the Onion Routing principle, various systems have been proposed enabling near real-time communication for services like web browsing: Tor [6], Freedom [7] and Web Mixes [8]. These systems either use a centralized proxy for relay or a set of known relays. With the success of peer-topeer systems the peer-to-peer paradigm got adapted by various

anonymous communication schemes such as as MorphMix [9], Tarzan [10], AP3 [11], Cashmere [12], and information slicing [13] . The large number of available nodes, their geographic distribution and local jurisdiction and political backgrounds make such a widely distributed peer-to-peer network an ideal candidate for anonymous communication. However, peer-topeer networks suffer from the dynamics of nodes leaving and joining constantly and the heterogeneous bandwidth and computing capacities of their nodes. Nonetheless, all systems mentioned above rely on static routes and are thereby susceptible to pattern- and timing-based attacks [2]–[4]. To our best knowledge, our work is the first to propose dynamic multipath Onion Routing, i.e. to route each packet along a different path, for low latency anonymous networks. Focusing on traffic analysis of Mobile IP systems and not anonymity and Onion Routing, Fasbender et al. [14, 15] show that changing Mobile IP agents on a regular basis makes traffic analysis unfeasible. The closest work to MORE is a theoretical paper by Serjantov and Murdoch [16] about splitting large messages in remailer systems [17, 18]. It analyzes the usage of independent routes for each packet of a message to prevent an eavesdropper at the first mix from determining the message size and therefore being able to correlate this with an eavesdropper located near other mix nodes. As nodes are repeatedly used as first relay in a path, the packet flow is exponentially distributed to prevent the first relay from estimating the message size. This theoretical analysis primarily refers to remailer systems. However, in private communication its authors confirmed that most arguments in terms of security and threat analysis also apply to Onion Routing. III. I NTRODUCING THE MORE APPROACH This section introduces dynamic multipath Onion Routing. In particular, we discuss the architecture of MORE. Today’s Onion Routers operate flow oriented. Thus, when a flow between two end points is set up, each relay stores session information, e.g. symmetric keys, state information, successor, and predecessor. In contrast, MORE allows each packet to travel along a different path. To provide anonymity the first half of this path is selected by the sender and the second half by the receiver of the packet. As MORE operates connectionless, a session setup as in today’s Onion Routers cannot be done1 and is unnecessary2 . Therefore, in MORE, each packet needs to maintain the information about the relays in path and corresponding cryptographic keys. MORE uses Diffie-Hellman key exchange based on elliptic curve cryptography to generate symmetric keys for decrypting the information about the successor on each relay. Assume that the sender has generated a public / private key pair and that it knows the public key of the relay. From its own private key and the relay’s public key, it can retrieve a shared secret, i.e. a symmetric key. With this key, it encrypts the information about the next hop(s) and the destination. By 1 This 2 This

is good for security reasons. is good to achieve a small memory footprint.

Hop 1

Hop 2

Hop 3

Hop 4

Receiver

Data… Enc. with public key of rec.

Encrypted with public key of hop 4 Encrypted with public key of hop 3 Encrypted with public key of hop 2 Encrypted with public key of hop 1 Hops selected by the sender

Hops selected by the receiver

Fig. 1. Path information: the layered public key encryption ensures that each hop can only determine its successor.

adding its own public key to the header, it ensures that the relay itself can retrieve the symmetric key and determine its successor on the path (see figure 1). Applying this scheme to each hop, MORE ensures that each relay knows only about its successor. Additionally, padding packets to constant length prevents relays from identifying the length of the path and their position in it. To reduce the computational and the bandwidth overhead we use elliptic curve cryptography (ECC). Compared to RSA, ECC keys are significantly shorter. We use a key length of 192 bit, which has a security level similar to 2048 bit RSA keys. Additionally, encryption, decryption, key generation, and elliptic curve based Diffie-Hellmann key exchange (ECDH) are significantly faster than in RSA-based schemes [19]. Additionally, the sender adds a return route – leading back to itself – to the packet. Using this return route, the receiver can send an answer back to the sender. When forwarding a packet, a relay stores the previous and next relays and the corresponding key for some minutes to prevent the reuse of routes. This is important as the repeated use of a route would enable pattern and timing based attacks and so threaten the anonymity of the path destination. A. Path Concatenation So far, we discussed how a sender can communicate anonymously with a known receiver. However, we did not discuss how the receiver itself can stay anonymous and so offer for example a hidden service. We propose a path concatenation scheme to enable receiver anonymity. An anonymous service (hidden service) publishes routes to itself in some out-of-band media (see section III-B). The sender retrieves this information and adds its own hops to the route by adding further layers of encryption to the path section. For example, assume that Bob offers an anonymous service, that Alice wants to communicate to this service, and that she retrieved a route to the anonymous service. First, Alice selects a number of random nodes to relay her traffic in order to stay anonymous herself (see figure 2). Next, Alice concatenates the nodes she selected and the communication path she retrieved. Thus, she selected the head and Bob the tail of the path (see figure 1) and both stay anonymous. Interestingly, Alice needs to retrieve the anonymous path to Bob’s service only to set up communication. Once Alice reached the hidden

Alice (Sender)

Bob (Receiver) 2

3

1 4 Anonymous path

Hop selection

Fig. 2. Sender and receiver independently select a number of hops of the anonymous communication path.

service, anonymous path sections are piggybacked on the data traffic. Furthermore, the MORE design has to ensure that nobody can impersonate an anonymous service and offer – potentially malicious – own services instead. We use public / private key-based signatures to protect against impersonation. Thus, Bob computes a key pair and the public key becomes his anonymous identity (e.g. pseudonym). When Bob publishes a path section, he signs it with his private key. Knowing the anonymous identity, a MORE node can verify the issuer of path sections. B. Service Directory As discussed in the previous section, MORE needs a lookup service to provide paths to initiate communication to anonymous services. In MORE, the service directory provides this information. To hide its identity, a MORE node communicates with the service directory anonymously. In more detail, it provides the following services: • Relay discovery: each MORE node can retrieve other MORE nodes from the directory and use these to relay traffic. Furthermore, it registers itself as relay. Retrieving MORE nodes can be done anonymously or directly to enable bootstrapping. • Virtual IP addresses: to address anonymous services, each MORE node can retrieve a virtual IP address (e.g. 10.2.3.79) from the service directory. This IP address is unique in the MORE system and other nodes can use it to address and to connect to a service. • Name Service: next to virtual IP-addresses, we allow MORE nodes to register a domain name. • Path sections: to connect to a service, the sender needs to retrieve a path section pointing to the desired service. Thus, a service can store such path sections in the service directory. The service is designed to be deployed on be a scalable and redundant Distributed Hashtable (DHT) as all operations rely on simple put and get operations. However, in our current protype implemention, we use a dedicated machine. When communicating with the service directory, a MORE node signs its messages to prove its anonymous identity. C. Key Caching MORE benefits from elliptic curve cryptography as its keys are shorter and cryptographic operations are significantly faster than traditional RSA. These two factors make the design of a

multipath Onion Router feasible. However, ECC is still slower by an order of magnitude than symmetric key operations [19]. Thus, MORE allows clients to reuse keys. Combined with caching done by the relays the number of ECC operations can be reduced drastically. Packet forwarding consists of two operations. First, a relay computes the symmetric key via Diffie-Hellmann key exchange and then decrypts the packet with this symmetric key. Of these two operations, the Diffie-Hellmann key exchange is the more computationally expensive one, as it bases on asymmetric cryptography. Thus, MORE tries to reduce the overhead of this operation. When a MORE node uses a relay again, at any point in the relay path, it can reuse the same key set with a certain probability. Thus, the sender and the relay cache the asymmetric and symmetric keys for a while. When a key is reused, the sender and the relay do not need to recompute the corresponding symmetric key. Our evaluation (see section V) shows that key caching can drastically increase the throughput of the MORE system. Note that this technique allows relays, sender and receiver each two distinctive choices: sender and receiver have the choice to decide themselves between performance and confidentiality, while relays have the possibility to choose a tradeoff between processing power or memory. As the key reusage rate can be chosen by each MORE client individually, we expect this feature to have a positive impact on the deployment. D. Legacy Support For a fast adoption of MORE by a wide user range, it is necessary that users can reuse their unmodified networking applications in the MORE environment. Commonly, networking applications use TCP and UDP protocols, which themselves use the IP protocol. To provide support for such so called legacy applications MORE resides on the network level and is transparent to applications, i.e. MORE provides an IP overlay to the application. It is necessary that outgoing packets of a MORE node do not contain any information about its real identity, e.g. its IP address. Commonly today’s anonymous communication schemes use application-level gateways or proxies, but this requires the gateway or proxy to know the protocol formats of all applications used. Due to the large number of existing application level protocols we do not consider this engineering effort reasonable. Furthermore, some protocols are proprietary and their formats are not published. MORE addresses this problem by using an “anonymous communication stack” which is assigned a virtual IP address, e.g. 10.2.3.79 (see Fig. 3). The essence of this address virtualization technique is to abstract away any information about the identity of a node while remaining compatible with the IP addressing scheme and applications that depend on it. We use the service directory (see section III-B) to anonymously assign unique virtual IP addresses to each node.

U User S Space Multipath Onion Router (MORE)

Anonymous Application e.g. web browser, chat, ssh

IP NIC Driver

Virtual NIC (10.x.y.z)

System Space

TCP / UDP

Network Interface (NIC) Hardware “Traditional” Communication Stack Anonymous Communication Stack

Fig. 3. The virtual network interface enables transparent application support.

E. Naming Service For a seamless integration of existing applications, a name service is required. Users need a way to address anonymous services and to distinguish them from Internet-based ones. Thus, we provide a name service, which is transparent to the existing Domain Name Service (DNS), in order to map between DNS requests and anonymous services. Users can enter http://www.freespeech.anon into their webbrowsers and connect to an anonymous service. When a .anon domain is queried, the system sends a DNS request in order to resolve this domain. Our scheme reroutes this request to the MORE service directory and determines the virtual IP address and corresponding communication paths from the service directory. To distinguish between traditional domain names and the anonymous ones, we introduce new domain names, like .anon, as used in the previous example. F. Security Considerations Due to space limitations, this paper focuses on the design of the dynamic multipath Onion Router. For an extensive security analysis we need to refer the reader to an extended version of this paper [20]. Nonetheless, we want to shortly introduce the threat model and design extensions besides the basic multipath Onion Routing paradigm. Commonly, a global passive adversary is the assumed threat when analyzing theoretical anonymity designs. However, like all practical anonymous communication schemes that are scalable and enable low-latency communication, MORE can not protect against such a strong adversary. Furthermore, similar to its predecessors, MORE does not prevent (usually long-term) intersection attacks by local adversaries. We assume a practical adversary which can: • observe a limited part of the network • participate in the MORE network with a limited number of relays. • participate actively by offering a service, e.g. running a web server. • influence communications by generating, delaying, dropping, and modifying traffic content and patterns.

MORE is designed to prevent pattern analysis and packet counting attacks inside the network. This improves the anonymity in comparison to existing systems for interactive near-real-time traffic in a crucial point. Important measures to achieve this anonymity in addition to the basic approach of dynamic multipath Onion Routing are: (1) unlimited and random path length, (2) uneven distribution of flows among first or last hop to address packet counting attacks such as [3]3 , (3) selection of location/IP-diverse paths and (4) avoidance of long-lived identities. IV. MORE AND I NTERNET S ERVICES In this section, we discuss how services can be deployed in the MORE network. We distinguish two classes of services: (1) anonymous services and (2) exit points. As MORE is an IP overlay, a MORE node can provide the same services as a server in the Internet. Thus, it can run a web server, ftp server, ssh, content distribution, or streaming services. Introducing the virtual .anon domain makes it very intuitive for the user to connect to an anonymous service. Furthermore, a node can act as exit point. Exit points bridge between the anonymous MORE network and the Internet itself. Therefore, a MORE node can communicate anonymously to any Internet based service, for example a web-site, via an exit point. An exit point can provide access at two different protocol layers: (1) it can operate at the transport level and act as NAT device or (2) it can operate at application level, for example as an HTTP-proxy. As MORE operates on the network level and is accessed by the applications via the virtual network interface, standard off-the-shelf http-proxies and NAT software can be used. Additionally, we allow the operator of an exit point to introduce their own exit policies by restricting protocol types, destinations, and consumed bandwidth. Compared to many other existing anonymous communication schemes [6, 9]–[11], MORE provides a seamless integration of anonymous services and exit points within the overall architecture. A. Communication Example Connecting to a service in the MORE architecture consists of two steps: (1) retrieving a path to the service and (2) communicating to the service itself (see figure 4). In this section, we discuss these two steps in more detail. Let Alice connect to the service www.freespeech.anon and assume that Alice knows some MORE nodes that can relay traffic for her. Alice enters www.freespeech.anon into her web browser. As a result, the web browser sends a DNS query to resolve the domain name. In the network stack, the MORE application intercepts all queries for the .anon domain and thereby ensures that the query does not leave the host and leaks information about Alice’s intentions. Instead of communicating to a standard DNS server, the MORE application 3 This attack adds a number of malicious nodes to the network and eventually a user or hidden service will use these to relay traffic and thereby reveal its identity

queries – via a number of relay hosts – anonymously the service directory. From the directory, it retrieves the virtual IP address of www.freespeech.anon and some paths to it. After retrieving this information, the MORE application sends a fake DNS reply back to Alice’s web-browser. Next, the web-browser initiates a number of TCP connections to the web-site. As the destination address is a virtual IP address, packets are routed via the anonymous communication stack into the virtual network interface. Thus, the MORE application relays them anonymously into the MORE network. V. E VALUATING THE MORE A RCHITECTURE In this section, we evaluate the proposed architecture. First, we introduce implementation details, and then present throughput measurements. Finally, we discuss our ongoing work of deploying MORE in the “wild”. MORE, in contrast to existing anonymous near real-time communication schemes, relays each packet via a different path (dynamic multipath Onion Routing), which results in interesting implementation challenges: • Bandwidth and performance overhead: when each packet is routed along a different path, no relay tunnel can be set up and no connection establishment is done. Therefore, no shared secrets can be bound to a tunnel. Instead, MORE has to rely on asymmetric cryptography, which is computationally expensive. Furthermore, as each hop through the mix cascade requires a key to be embedded in a packet’s header, MORE needs to deal with additional bandwidth overhead. • Round-trip time variance: routing each packet along a different path results in a highly dynamic communication scheme. Some packets will be on routes with low round trip times due to proximity or low load while other packets will have high round trip times. This results in packets being delivered out of order at the final receiver. In case of an overlay TCP connection, TCP misinterprets this outof-order delivery as packet loss, its fast retransmission mechanism leads to additional packets and a decreased overall throughput. However, in the recent years various TCP extensions and algorithms [21]–[24] were proposed to enable efficient TCP flows and congestion control in multipath overlays. Our ongoing work focuses on the integration of such algorithms in the MORE architecture. A. Implementation We implemented MORE on Linux. A MORE node consists of two parts: (1) the relay service and (2) the virtual network interface. For elliptic curve cryptography, we use the Sizzle code [25] which is part of the OpenSSL library. To relay a packet in the MORE network, it needs to contain information about the next relay on the path, e.g. its IP address and the port number. Furthermore, the packet needs to contain the key the decrypt all this information, i.e. to remove one layer of encryption. IP address and port account for six bytes. With the 192 bit ECC key and one reserved byte, this information fits into a

32 byte header. Thus, MORE’s overhead is 32 bytes per relay, which we consider reasonable. Additionally, MORE uses a cell size of 1000 bytes to further reduce the header overhead. B. Performance We deployed MORE on our test network which consists of eight Linux hosts (5x Pentium IV 2.2 GHz, 3x Xeon 2.8 GHz) running Fedora Core 4, interconnected by a 100 MBit/s network. Each host acts as relay and one of the hosts offers an anonymous service. Another one communicates to this service via TCP. For the evaluation, sender and receiver use three relays each, resulting in a total of eight hops. Our evaluation has shown, that the overlay throughput, i.e. the net throughput that an application running on top of the MORE overlay can use, can drastically be speed up by key caching as it reduces the need for asymmetric cryptography. When making full use of key caching, the throughput reaches 2.5 MBit/s. This throughput is similar to the throughput the Tor anonymity network reaches in a testbed. For example, for a four hop connection (compared to the eight hops in MORE) the meanwhile highly optimized Tor implementation achieves a throughput of 3.6 MBit/s (Dual PIII, 1 Ghz). Our measurements identify two limiting factors for the throughput in MORE: (1) overlay TCP retransmissions caused by high round trip variance and (2) CPU processing performance, where the cryptographic operations mainly cause the processing load. When making full use of key caching, the overhead of asymmetric cryptography is removed from the system. As result it this case MORE only uses symmetric cryptography – just as Tor – and therefore reaching a similar performance and security level. Nonetheless, it can be said that TCP was not designed to cope efficiently with dynamic overlays as MORE and its high variance of round trip times. However, we evaluated that (1) packet play-out smoothing to limit out-of-order delivery and (2) per-hop acknowledgments reduce packet loss and thereby increase TCP performance. Currently, we are implementing these features in combination with recently proposed congestion control algorithms [21]–[24] for TCP overlay connections in MORE to achieve further performance improvements. The goal is the design and implemention of a flow and congestion control algorithm that can cope efficiently with such highly dynamic systems and provide high throughputs. C. MORE in the Wild Although our measurements indicate, that MORE can achieve a performance similar to the Tor anonymous router, only a deployment can evaluate the proposed design fully. Thus, we are currently deploying MORE on hosts at universities in various European countries. VI. F UTURE W ORK AND C ONCLUSION In this paper, we present a novel approach to anonymous Internet communication: dynamic multipath Onion Routing. MORE routes each packet along a different path in an IP

Relays

TCP data reply from 10.2.3.79

Path through relayy cascade

Path through relay cascade

Alice Virtual IP: 10.20.4.77

MO ORE

TCP data request to 10.2.3.79

MO ORE

Virtual IP and anonymous path sections TCP data request from 10.20.4.77 10 20 4 77

TCP data reply to 10.20.4.77

Bob’s anonymo ous web server

DNS reply 10.2.3.79

Alice’s we A eb browse er

GET http://w G www.freesp peech.anon n HTTP/1.1

Relays

Servicce Directo ory

Get path to freespeech.anon

DNS resolve freespeech.anon

Bob Virtual IP: 10.2.3.79

www.freespeech.anon

Fig. 4. Seamless integration of existing applications into the anonymous communication scheme: in this example, Alice uses a web browser to request the site http://www.freespeech.anon from an anonymous web server.

overlay. Compared to existing Onion Routers, MORE is not susceptible to pattern and timing based attacks and reduces the impact of overloaded relays. Its transparent architecture and name service allows a seamless integration of existing applications without changes to the applications or communication protocols. MORE is implemented transparently in the network stack via virtual IP addresses. Elliptic curve cryptography and key caching reduce the header and performance overhead and make the MORE implementation feasible. Our evaluation shows that MORE can reach a throughput similar to the Tor anonymous router while providing a more flexible routing paradigm. R EFERENCES [1] P. F. Syverson, D. M. Goldschlag, and M. G. Reed, “Anonymous Connections and Onion Routing,” in IEEE Symposium on Security and Privacy, Feb. 1997. [2] S. J. Murdoch and G. Danezis, “Low-Cost Traffic Analysis of TOR,” in Proc. of the IEEE Symposium on Security and Privacy, May 2005. [3] L. Overlier and P. Syverson, “Locating Hidden Servers,” in Proc. of IEEE Symposium on Security and Privacy (SP), May 2006. [4] S. J. Murdoch, “Hot or not: revealing hidden services by their clock skew,” in Proc. of 13th ACM conference on Computer and communications security(CCS), October 2006. [5] D. L. Chaum, “Untraceable electronic mail, return addresses, and digital pseudonyms,” Communications of ACM, Feb. 1981. [6] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The SecondGeneration Onion Router,” in Proc. of 13th USENIX Security Symposium, August 2004. [7] P. Boucher, A. Shostack, and I. Goldberg, “Freedom Systems 2.0 Architecture,” Zero Knowledge Systems, Inc., White Paper, Dec. 2000. [8] O. Berthold, H. Federrath, and S. K¨opsell, “Web MIXes: A system for anonymous and unobservable Internet access,” in Proc. of Designing Privacy Enhancing Technologies: Workshop on Design Issues in Anonymity and Unobservability, July 2000. [9] M. Rennhard and B. Plattner, “Introducing MorphMix: Peer-to-Peer based Anonymous Internet Usage with Collusion Detection,” in Proc. of Workshop on Privacy in the Electronic Society (WPES), Nov. 2002. [10] M. J. Freedman and R. Morris, “Tarzan: A Peer-to-Peer Anonymizing Network Layer,” in Proc. of 9th ACM Conference on Computer and Communications Security (CCS), Nov. 2002.

[11] A. Mislove, G. Oberoi, A. Post, C. Reis, P. Druschel, and D. Wallach, “AP3: A cooperative, decentralized service providing anonymous communication,” in Proc. of ACM SIGOPS European Workshop, September 2004. [12] L. Zhuang, F. Zhou, B. Y. Zhao, and A. Rowstron, “Cashmere: Resilient Anonymous Routing,” in Proc. of Symposium on Networked Systems Design and Implementation (NSDI), May 2005. [13] S. Katti, J. Cohen, and D. Katabi, “Information slicing: Anonymity using unreliable overlays,” in Proc. of the 4th USENIX Symposium on Network Systems Design and Implementation (NSDI), April 2007. [14] A. Fasbender, D. Kesdogan, and O. Kubitz, “Analysis of security and privacy in mobile ip,” in Proc. of 4 the International Conference on Telecommunication Systems Modeling and Analysis, March 1996. [15] ——, “Variable and scalable security: Protection of location information in mobile ip,” in Proc. of 46th IEEE Vehicular Technology Society Conference (VTC), April 1996. [16] A. Serjantov and S. J. Murdoch, “Message Splitting Against the Partial Adversary,” in Proc. of Privacy Enhancing Technologies workshop (PET), May 2005. [17] G. Danezis, R. Dingledine, and N. Mathewson, “Mixminion: Design of a Type III Anonymous Remailer Protocol,” in Proc. of the IEEE Symposium on Security and Privacy, May 2003. [18] U. M¨oller, L. Cottrell, P. Palfrader, and L. Sassaman, “Mixmaster Protocol — Version 2,” Draft, July 2003. [19] V. Gupta, D. Stebila, S. Fung, S. C. Shantz, N. Gura, and H. Eberle, “Speeding up Secure Web Transactions Using Elliptic Curve Cryptography,” in Proc. of the Network and Distributed System Security Symposium (NDSS), February 2004. [20] O. Landsiedel, A. Pimenidis, K. Wehrle, H. Niedermayer, and G. Carle, “Security Considerations for Dynamic Multipath Onion Routing,” Draft, March 2007. [Online]. Available: http://ds.cs.rwth-aachen.de/research/ projects/more/more security/download [21] H. Han, S. Shakkottai, C. V. Hollot, R. Srikant, and D. Towsley, “Multipath tcp: a joint congestion control and routing scheme to exploit path diversity in the internet,” IEEE/ACM Trans. Netw., 2006. [22] F. Kelly and T. Voice, “Stability of end-to-end algorithms for joint routing and rate control,” SIGCOMM Comput. Commun. Rev., 2005. [23] H. Han, S. Shakkottai, C. Hollot, R. Srikant, and D. Towsley, “Overlay tcp for multi-path routing and congestion control,” in Proc. of ENSINRIA ARC-TCP Workshop, 2003. [24] P. Key and L. Massouli, “Combining multipath routing and congestion control for robustnes,” in Proc. of 40th IEEE Conference on Information Sciences and Systems (CISS), March 2006. [25] V. Gupta, M. Millard, S. Fung, Y. Zhu, N. Gura, H. Eberle, and S. C. Shantz, “Sizzle: A Standards-Based End-to-End Security Architecture for the Embedded Internet,” in Proc. of IEEE International Conference on Pervasive Computing and Communications (PerCom), March 2004.