« SECSAC: Richard M. Smith | Main | SECSAC: John Klensin; discussion. »

SECSAC: Steve Bellovin.

Steve Crocker introduces Bellovin, "incredibly smart guy." Topic: Architectural issues.

Offering help to people who enter bad domain names is a fine thing. Doing it at the center of the net inherently leads to problems.

Directories vs. lookups. DNS not built as directory, but as lookup service. Query leads to predictable answer. Human beings want directory services. Programs design on DNS' lookup service character. Surprising results -- programs no longer do what you expect. From architectural perspective, pre-emption more serious. Internet: Empower endpoints, not middle. Old networks: Intelligence in the network. Internet: Smart edge, dumb center. Want to make sure that center does as little as possible, so it does not prevent ends from doing the right thing in a particular context. Wildcards at this level disable edge from doing what's appropriate. TLD wildcards worked more-or-less adequately for (most) Web work and ordinary email. Wildcards not well-tested for non-email protocols.

What about other protocols? Hourglass model. "Everything over IP, IP over everything." IP over avian carriers, signal drums. Layer new protocols on top of IP and transport protocols. Fundamental reason for layering: Innovation. IETF doesn't invent most services. (Skipping some remarks about [not] layering things on top of HTTP.)

Did not need cooperation from ISPs, IETF to deploy web. More recently: Peer-to-peer. New service that did not come from the center. It came because college students had bright idea and were able to deploy it. Next killer app is going to ocome from the edge, and must be usable without cooperation.

Center of the net must stay out of the way of innovation.

Wildcards break things because DNS does not know what application the user wants. Does not know what service user will use. Semantics of what DNS returns matches expectations at IP level. This does not mean we don't want directory service. DNS is just not the right place to implement it. Wildcard optimized for one service will often work poorly or not at all for other services.

Even simple services may be complex.

Problems for e-mail -- even there implications aren't understood, and that's the service for which wildcards were designed. New protocols?

Don't quarrel with goal, quarrel with implementations.

Conclusions: Internet built on set of architectural assumptions. Architecture fostered innovation.

End of presentation. No question. Crocker: Lunch-time effect or everybody compelled?

TrackBack

TrackBack URL for this entry:
http://log.does-not-exist.org/mt/mt-tb.cgi/662

About

This page contains a single entry from the blog posted on October 7, 2003 7:22 PM.

The previous post in this blog was SECSAC: Richard M. Smith.

The next post in this blog is SECSAC: John Klensin; discussion..

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.35