Radia J. Perlman

Rbridges: transparent routing

This work describes a method of interconnecting links that combines the advantages of bridging and routing. The basic design is a replacement for a transparent bridge and makes no assumption about higher layer protocols. It involves creating an infrastructure of switches (which we call Rbridges, for routing bridges) in which packets are routed, although, as with bridges, layer 2 end code location is learned through receipt of data packets. It avoids the disadvantages of bridges, since packets within the infrastructure need not be confined to a spanning tree, and packets are protected with a hop count and not proliferated while in transit, so there is no need for any artificial startup delay on ports to avoid temporary loops. This allows IP nodes to travel within a multi-link campus without changing IP addresses. The paper introduces further optimizations for IP, such as avoiding hooding ARP messages through the infrastructure, and (for IP nodes), allowing Rbridges to avoid learning on data packets.

DoS protection for UDP-based protocols

Since IP packet reassembly requires resources, a denial of service attack can be mounted by swamping a receiver with IP fragments. In this paper we argue how this attack need not affect protocols that do not rely on IP fragmentation, and argue how most protocols, e.g., those that run on top of TCP, can avoid the need for fragmentation. However, protocols such as IPsecs IKE protocol, which both runs on top of UDP and requires sending large packets, depend on IP packet reassembly. Photuris, an early proposal for IKE, introduced the concept of a stateless cookie, intended for DoS protection. However, the stateless cookie mechanism cannot protect against a DoS attack unless the receiver can successfully receive the cookie, which it will not be able to do if reassembly resources are exhausted. Thus, without additional design and/or implementation defenses, an attacker can successfully, through a fragmentation attack, prevent legitimate IKE handshakes from completing. Defense against this attack requires both protocol design and implementation defenses. The IKEv2 protocol was designed to make it easy to design a defensive implementation. This paper explains the defense strategy designed into the IKEv2 protocol, along with the additional needed implementation mechanisms. It also describes and contrasts several other potential strategies that could work for similar UDP-based protocols.

User-centric PKI

The goal of supporting Single Sign-On to the Web has proven elusive. A number of solutions have been proposed -- and some have even been deployed -- but the capability remains unavailable to most users and the solutions deployed raise concerns for both convenience and security. In this paper, we enumerate desirable attributes in a scheme for authenticating from an Internet browser to a web site and the authorization that follows. We categorize the currently deployed or advocated approaches, describing their benefits and issues, and we suggest incremental improvements to such schemes. We then outline a design for public-key based authentication particularly suited to what we believe to be the common case: users, acting on their own behalf (as opposed to as an employee of an organization), performing actions on the web such as making a purchase or maintaining an account at a service provider. We contrast the usability/privacy/security properties of our design with other identity management/authentication schemes deployed or being proposed today. Our design is truly user-centric, in the sense that the user acts as his own CA, and as a decision point for authorizing release of user information to web sites, rather than having an Identity Provider be the center of trust.

Folklore of robust network routing

This paper describes various types of fragility that can occur in networks, along with various types of defenses that can mitigate these issues. Although some of the techniques suggested in this paper are novel, most of them are “known”, but only as folklore, instead of being written down. Because these issues are not well-documented, many protocols do not implement these well-known techniques. We include technologies that are considered “layer 2” as well as “layer 3”, because we use the term “routing” to include any technology in which paths are dynamically computed and packets are forwarded. This paper focuses on wired networks. Wireless networks face additional challenges.

Mythology and folklore of network protocols

Its natural to assume that network protocol design is by now a well-known science, where the designers of todays standards take care to understand the tricks and pitfalls learned from previous protocols. This talk dispells this and other myths. It is intended to be provocative, making people question the things people assume are true; instructive, giving hints as to how to avoid some of the problems in future protocols; and inspirational, convincing students that there are ample opportunities to make contributions. This talk discusses wrong turns that have been made, such as what necessitated the invention of bridges, and what caused IP multicast to be unimplementable. It also talks about how a protocol, even one “proven correct”, can go horribly wrong, such as the unstable ARPANET protocol for distributing routing information. It talks about “obvious” tricks such as version numbers, that even today protocol designers insist on misusing. And it covers some of the areas in which research is most needed.