Summary of: “P5 A Protocol for Scalable Anonymous Communication” Overview: --------- This paper investigates a protocol that utilizes peer-to-peer technology to provide anonymous communication over the Internet. The aim is to provide sender-, receiver-, and sender/receive-anonymity. The protocol is customizable, allowing the admin to strike an acceptable balance between communication latency, network bandwidth, and anonymity. The P5 protocol is meant to withstand adversaries that are capable of monitoring all or a subset of the network links. The brute- force version of P5 assumes the existence of a broadcast channel over which all communication endpoints send fixed-length packets at a constant rate. These packets could just be noise packets meant to prevent traffic analysis, or they can be data packets intended for a particular recipient. In the latter case, the packets are encrypted using the target’s public key. Since this naďve solution leads to a significant loss in bandwidth, the paper introduces the idea of having a logical broadcast tree, where each node represents a broadcast group (or a broadcast channel). Two values, a bitstring and a mask, are used to represent the contents of a group, and define how messages are sent. Users join one or more groups. Communication efficiency increases as the mask size increases, whereas anonymity increases as the mask size decreases. The paper presents some analysis of P5’s anonymity, talks about potential attacks, and presents some simulation results. Discussion Points ----------------- - How much performance/bandwidth are we willing to give up for anonymity? - Is the assumption that adversaries are capable of monitoring all communication links too strong? Are there other ways we can counter, or reduce the effect of, traffic analysis? - Resistance to DoS attacks – do we buy the paper’s argument regarding DoS? Legitimate packets may also be dropped. DDoS can cause havoc. - Using multicast versus unicast to implement the broadcast groups. - The performance hit caused by the excessive use of asymmetric cryptography (hop-to-hop!).. In scalability’s analysis they require machine to handle two hundred 1000 byte public-key decryptions per second! While this can be done by end-machines, it is too much for routers. - It is not clear whether the “anonymity” they are trying to achieve is location or identity anonymity. It appears to be location identity, since the paper assumes an out-of-band method for ascertaining public keys of endpoints. In any case, many privacy papers do not distinguish between these two things. Privacy protocols have to take into account the possible different requirements for location anonymity and identity anonymity, this is important particularly in the world of pervasive and ubiquitous computing. - The need for a PKI infrastructure for this, and the practicality of an out-of-band mechanism for establishing public keys between the communicating entities. - Management of users in the broadcast groups. What if users are added/removed frequently (mobile users)? It appears like the system cannot handle frequent additions and removal of users. Paper Pros & Cons ----------------- Pros by Kevin Cernekee: - Has the unique ability to let users trade bandwidth efficiency for anonymity - Provides sender, receiver, and sender-receiver anonymity - Allows multiple concurrent conversations - More scalable than the "global broadcast channel" example Cons by Kevin Cernekee: - Strong anonymity discourages legit commerce and encourages illicit activity. Americans are highly unlikely to join a P5-based network unless there is a payoff (such as free music) - Cannot withstand active network attacks - Wastes a lot of bandwidth Pros by Adam Slagell - Section 3.5 was a good consideration of many attacks. Although I think they may be wrong in their evaluation of DoS attacks. Flooding with noise will be limited by the queue limits, but the queue will be forced to drop more good packets as it is filled up. - It was clever to break the encryption to chunks so that the hosts don’t have to do as many calculations to decide whether they are the destination. - While there was no actual implementation, they did a very extensive analysis in simulation. Their simulation model did not appear to be make too many simplifications or assumptions either. Cons by Adam Slagell - While a user can decrease anonymity, he/she can’t increase it back (1.2) - It seems like the only distinct advantage they provide over similar systems is the ability to simultaneously support multiple sender receiver pairs. They note that people in [5] did all but this (1.2) - Section 2 seems pointless without going into more depth. - They require broadcast groups to be implemented as unicast and not multicast trees in the underlying network. This appears to be a major cost to efficiency. - The model allows packets to be lost and quite easily if you require much anonymity. This seems inappropriate in an environment where ACKs are impossible. Processes use unreliable protocols like UDP, usually use it to request a service. If they never get what they want, like a DNS response, they send another request. Here you never have any reasonable guarantee that your messages are ever delivered. Where is this model acceptable other than maybe in an anonymous chat room? - The use of a topology means a loss of decentralization, which may be very important. Also, it puts the requirements of trust into the model. Though, they briefly address this in saying that you can use multiple topology servers. But the need for many topology servers can hurt scalability. - They require the assumption that users do not leave the group. If this happens, groups may become too small and the entire hierarchy may need to be rebuilt. - Public key encryption on every packet is needed between every hop. This limits scalability. Though at least the decryption of every packet need only be done on portion of the packet. - They seem to have a problem of scalability for d>=24 because it becomes an unmanageable amount of state per host. Their solution for this appears to be weak. (4.3)