LAP: Lightweight Anonymity and Privacy #

This paper from Security & Privacy 2012 proposes a new network-layer anonymity system called Lightweight Anonymity and Privacy (LAP). LAP is a new point in the design space for anonymity systems, which trades off a strong threat model for significantly better performance. In practice, its anonymity guarantees are weaker than Tor, but latency is much less of a problem. Being a network-layer anonymity system, LAP is not as easy to deploy as Tor. While it would work in the current-day Internet by leveraging IP options, it is meant to be part of next-generation Internet architecture such as SCION or MobilityFirst. The authors made an effort to use symmetric and stateless crypto, to account for computational shortcomings of routers, and also propose a way to make LAP incrementally deployable.

Since LAP is a network-layer anonymity system, it is replacing IP, but it needs a destination IP address for path establishment. At the core of LAP’s design is the notion of “packet-carried forwarding state.” As the name suggests, the idea is that forwarding decisions are made by routers based on encrypted packet headers. Each router can only read forwarding decisions that are encrypted to its own key. A set of these forwarding decisions form an e-path which clients need to communicate with a destination. An e-path is incrementally compiled by on-path routers as a client sends a REQUEST packet—a packet destined for the destination’s IP address. As an on-path router forwards the packet, it appends encrypted forwarding information to the packet. The same happens for a REPLY packet which is sent by the destination after it received a REQUEST packet. Again, on-path routers add encrypted forwarding information to the packet. After the REPLY and REQUEST packets, both the client and destination are in possession of an e-path, now allowing them to communicate without IP addresses. Once the client and destination start to exchange data using their respective e-path, each router on the path decrypts its own forwarding information embedded in the e-path. In a way, LAP can be understood as a mechanism to upgrade IP-based communication to e-path-based communication. However, the system only requires the destination’s IP address at the very beginning; the client does not need an IP address as the destination has an e-path to reply.

In LAP, the client’s ISP learns where she is connecting to, and must therefore be trusted. That’s different in Tor. For LAP, the primary adversary is the destination—the farther you are away from the client topologically, the higher the client’s anonymity set. As a result, the autonomous system right after the client knows the client’s ISP, but not its IP address. (It might know the client’s approximate physical location, though, if the ISP only operates in, say, a single city.) Like Tor, LAP cannot protect against an adversary that controls ingress and egress traffic. In fact, traffic can simply be correlated by looking at the payload. Since LAP does not use onion routing, the encrypted payload never changes as it travels from the client to the destination. E-paths, however, don’t need to be reused. The authors took special care to make e-path construction cheap, so clients are encouraged to rotate them frequently. Another benefit from the lightweight crypto is that computational DoS is less of a problem. LAP also allows clients to tune their desired level of privacy by allowing them to influence the number of hops on the path.

While the bulk of the paper is about sender anonymity, the authors also considered how to implement receiver anonymity. Similar to Tor’s onion services, receiver anonymity is based on a rendez-vous point and a lookup service that allows clients to learn the e-path between the rendez-vous point and the destination.

While LAP seems like a promising first step, it has no way to “evolve” if it were to be fully deployed. What if the crypto needs to be upgraded? What if we need to account for a design aspect that wasn’t considered when LAP was rolled out? If we really have a chance to redesign the ossified address and network layer, we better do it in a way that allows for architectural evolution.