An Internet Architecture Based on the Principle of Least Privilege #

This paper presents a novel Internet architecture meant to replace IP. The architecture is based on the principle of least privilege, meaning that every actor in the network is only exposed to the bare minimum of information that is necessary to do its job. That is in contrast to the Internet’s current architecture: Routers can learn an IP packet’s origin, destination, and content, which facilitates censorship and surveillance. This paper proposes to change that so routers can only see the respective previous and next hop. Packet payload is end-to-end encrypted, thus opaque to routers. Overall, the authors’ design includes basic security guarantees, a payment scheme, a name resolution scheme, and route propagation.

Before this technical report, the authors were investigating how to replace IP with Tor. Apparently, this idea turned out to have several shortcomings that caused them to broaden their scope. One issue was the lack of memorable names in Tor. Tor’s hidden service names are global and self-authenticating, at the cost of being hard to remember.

I like that the paper does not limit itself to security properties, but considers a broad range of issues, including route propagation and a payment scheme. The payment scheme is necessary because their design is based on source routing, which is not compatible to the Internet’s peering-based paradigm. The authors also reason about usability aspects such as latency and flexibility; since the architecture is based on source routing, users can configure their own anonymity/performance trade-off.

Overall, this was an interesting read to me. Needless to say, completely replacing IP comes with a plethora of major engineering issues, most of which are simply handwaving in the paper. While that is to be expected from a 15-page document, I wish the authors would have discussed limitations and acknowledged the transition difficulty. After all, entire business models are based on the shortcomings of IP, and overcoming these shortcomings will cause major resistance from industry.

The paper also lacks a deployment strategy. If something like this should ever transcend simplified simulator environments and see the light of the day, it is necessary to have a sound, incremental deployment strategy. IP will have to co-exist with its successor; probably for a very long time. “Thanks” to the Internet’s address and transport layer ossification, we still haven’t managed to retire IPv4 in favour of IPv6, despite both protocols being quite similar. Also, their design does not seem to be able to evolve. Once deployed, how can we adapt to as-yet-unknown requirements? How are we to change crucial components such as cryptographic primitives? Other clean-slate designs claim to have answers to these questions.