Protocol Problems and
Architectural Issues

Steven M. Bellovin

AT&T Labs – Research

smb@research.att.com

http://www.research.att.com/~smb

Different Kinds of Problems

Directory versus lookup

Surprising results

Chokepoints

Preemption

Directory Versus Lookup

A directory provides an imprecise, often interactive service

A lookup system provides reproducible, predictable answers, suitable for use by programs

The DNS was designed to be the latter

Surprising Results

Programs no longer do what you expect

Sometimes there is incorrect behavior; sometimes, an error presents itself differently

Preemption

The Internet empowers the endpoints, not the middle

Endpoints – applications, hosts, etc. – can best decide how to handle error cases such as non-existent host name

Wildcards pre-empt that ability and put control in the center

What is the Internet?

TLD wildcards worked more-or-less adequately for (most) Web work and ordinary email.

The IAB noted that wildcards in general are mostly used for email only.

TLD wildcards do not work well for other protocols.

What is the minimum common protocol set for the Internet?

The Hourglass Model

Historically, the Internet architecture has been modeled as a hourglass: “Everything over IP, and IP over everything.”

Is the new model “Everything over HTTP”?

IP

Ethernet

Wireless

...

TCP

UDP

...

Apps

Apps

Apps

Today's Hourglass

IP

Ethernet

Wireless

...

TCP

Apps

Apps

Apps

Tomorrow's Hourglass?

HTTP

Where Do Services Originate?

Most interesting new services come from the edges

Often, neither the ISPs nor the IETF are involved, most notably in the early days of the Web.

One part of the center's job is to stay out of the way of others' innovation – we don't want to lock in the Internet into the mostly-http model

Why Wildcards Can
Break Things

The DNS does not know what application the user wants

Is that an ancient mistake?

It mirrors the division of responsibility between IP and the upper layers

A service intended for one or two purposes will often fail for other purposes.

Even “normal” services can be complex

Conclusions

The Internet is built on a set of architectural assumptions

This architecture encouraged innovation

Breaking the architectural model will cause unforseeable failures, both in less-common existing software and for future ideas

Steven Bellovin

2003-10-03T09:57:52