The Rot Within

The Internet as it now exists is dying. The rot isn't very visible yet, because it is at the very heart of what makes the Internet function: the TCP/IP protocols underlying the whole network and the consolidation of backbone providers. Some of the symptoms are the rapidly-shrinking pool of available addresses, combined with slow adoption of IPv6 (which would expand the address pool dramatically); the prevalence of spam in virtually every medium; inability to easily find the resources you want the first time you need them; lawsuits over ownership of domain names; denial of service attacks and other types of remote hacking; and occasional outages across a large span of the network.

TCP/IP was designed for survivability. If a network node went down, the damage would be detected and routed around. In other words, the Internet as originally conceived was designed to survive a nuclear attack gracefully. Today, it cannot survive a backhoe accident gracefully.

The Internet works by INTERconnecting individual NETworks. Thus, my network at my house talks to Verizon's network via a permanent connection. I don't have any backup. If that connection (my DSL line) fails, I'm limited to my local network until the connection is restored. This is a risk I accept because the financial cost of redundant connections is higher than their worth to me. For a business, though, being disconnected is simply unacceptable; they connect at multiple points to multiple backbone providers (Verizon, Sprint, AT&T, etc), sometimes through geographically distinct locations (IBM, for example, connects in many many cities to many many different providers). If one of their connections fails, the other takes all of the traffic and routes it accordingly...theoretically.

In practice, this only works a little for most companies, for two reasons. First, most companies have consolidated their network connections down to a bare minimum. They have done this for cost, yes, but mostly they have done so because the more connections you have, the more difficult it is to seal off your network. Originally, all networks would route any traffic through them. But as attacks became more prevalent, and as free riders used up bandwidth they weren't paying for, companies increasingly sealed off their networks so that only their own traffic would go in and out. The connection points had to be protected, and monitored, and that was difficult if you had too many connection points. And, too, there was the problem of other companies also sealing off their networks, so you had to connect only to backbone providers or to intermediaries who specialize in connecting networks (ISPs).

The net effect of this was to make the backbone providers much more important, because there was no longer a web of interconnections between companies or organizations that were geographically near each other, or had shared business between them. (These days, it is not unusual for different units of the same company have no interconnection except through the backbone providers.) But the backbone providers have powerful incentives to consolidate. They have to share several locations to all come together and talk, in order to work (Google on MAE-East and MAE-West some time). This means that those interconnection points for backbone providers have a lot of high-capacity lines running in to them. And because the number of lines is finite, and the demand is large, most of those lines are in some way shared between different providers for some or all of their distance. As a result, it is very possible for a backhoe within a few hundred miles of one of these major interconnects to take down large parts of the network.

This problem cannot be fixed unless you fix the underlying issues with TCP/IP. TCP/IP was not designed with security or predictability in mind: all the packets are unencrypted; you don't know much about the packet other than it is coming from an adjacent node to which you are connected, and where it is going (the router then compares the destination with its table of where to send things, and sends the packet down the appropriate line); and it's not predictable - delivery of packets you send cannot be guaranteed.

There are ways to fix this, which would guarantee that you could establish dependable connections, still capable of routing around damage, where you know where the traffic is coming from in an unspoofable way. The only problem is that you have to replace all of the equipment on which the Internet runs (down to the the network cards in your home computer, potentially), and rewrite all or parts of the various applications and operating systems which understand the current ISO network model and the TCP/IP protocols.

I'm going off into gobbledygook land for a minute here, so if you're not a computer person, feel free to either Google the terms I've emphasized, or skip the next couple of paragraphs.

Here are some existing parts that could be brought together to make this work: the address scheme could be provided by OIDs. If every network device had an inalterable OID, and every user also had non-repudiatable (learn about PKI) identity, and every packet had the entire chain of OIDs from initiation to where the packet currently sits contained in it with the appropriate cryptographic signatures to allow the detection of forgery, any virus initiators or crackers could be tracked down and could not reasonably deny their culpability.

Ah, but what about routing these addresses, since OIDs are not tied to physical organizations? Well, neither are IP addresses. IP addresses are issued byIANA to one of APNIC, ARIN, LACTIC or RIPE, which then issue them further down. For example, my home network IP comes from IANA to ARIN to Verizon to me. Each issuer keeps track of those blocks that have been issued, and of how they route. IANA has an OID, and it could establish a branch for addresses (if it hasn't already) and thus the routing continuity is available.

How would you find a name under this scheme? DNS would need huge modifications. But it could be done using LDAP servers, with a modified DNS front ending them, using a cascading system of references not unlike what DNS does. This also would provide other benefits, like being able to instantly tie an address (not just for an end point, but for any device you talk to) to its owner. This has a further advantage, because you can tie down more than just addresses to names. You can also tie names to services and names to people, so that you could (for example) say something like, "send this email to Jeff Medcalf from the DFW area, wherever he is now" and the network could do it transparently. Or you could say something like "tell me where the nearest grocery store is", and if the grocery store registered its physical address and you registered your current location, the network could tell you.

OK, so at this point, you have a way of verifying where something came from when it hits your network, but the traffic is still going in the clear, so passwords and credit card numbers are still vulnerable unless you are using SSH or SSL or something similar. Well, heck, as long as we're replacing all of the underlying infrastructure, let's say than any two nodes can be configured to talk IPSec (or, more correctly, an appropriate analog). That is, all nodes will encrypt the traffic so that it can only be decrypted by the node it's sent to. Remember how I said above "every packet had the entire chain of OIDs from initiation to where the packet currently sits contained in it with the appropriate cryptographic signatures to allow the detection of forgery"? Well, it so happens that capability is tied up with the capability to encrypt traffic from node to node.

Now that you know where something is coming from, and can guarantee that it can't be forged without detection, you can establish webs of trust. For example, you could trust those networks you connect to to send you traffic, and also trust any traffic they pass on from outside. A company would want to cut off the web of trust at anonymizers (which would allow you to hide your ultimate identity even in this scheme), and everyone would cut off their web of trust at domains hosting spammers or virus writers.

With this security problem solved, you can now turn to traffic problems that prevent adjacent networks from connecting. Why would someone pay for the bandwidth they need, when they can connect to their neighbor's higher-bandwidth system cheaper and leech off of them? Well, as long as we're redesigning the core protocols, why not include traffic shaping as a core feature? If you know where packets are coming from, and you have a registry (remember the LDAP servers above?) tracking all of the networks you are connecting to, it would be pretty easy for routers to centrally update how much traffic is coming from where. You could then sign enforcable agreements with your neighboring network as to how much traffic each of you will allow to be routed through your network. At that point you've reestablished the ability to mesh networks and have thus addressed the fundamental routing weakness by deemphasizing the backbone providers.

One last thing, since we're redesigning the core protocol. There should be two connection types that you can request: shared or dedicated. A shared connection would be similar to IP now - it just routes each packet individually. But a dedicated connection would attempt to establish a persistent channel to the end point. If each device along the way was configured to allow this, and if you were in the web of trust of each of these devices, you could maintain a persistent connection that could guarantee deliverability (and even to some extent predicability of time of delivery) at the cost of overall network efficiency.

OK, so with a lot of fleshing out, this kind of scheme would allow you to solve the underlying weaknesses of the network. As a nice side effect, a lot of the services currently built on top of the network would become unnecessary, or would become easier. The only problem, as I said, is that you'd have to replace the Internet and all that runs on it. It turns out that DARPA is considering just that. (Link via SlashDot)

Posted by Jeff at March 13, 2004 09:28 AM | Link Cosmos