Greenfield Vision of Autonomous Internet

Please add your ideas about autonomous internet here. "Greenfield" means that you are "wiping the slate clean" and trying to imagine a whole new system from the ground up. This is meant mostly as an exercise in imagining and visioning new alternatives. The practical reality is that most efforts will build on existing concepts and technologies. However, the goal of this page is to offer a space to think beyond those existing technologies.

A Whole-earth system

The internet is a global network. It does not need country borders and political divisions, and actually, it is hindered by them. It is simply infrastructure for the whole planet.

Thus, the domain system as a top-level navigation entity should disappear. Apart from the fact that it is not mandatory to be used (I can buy most domains in country top-level domains I am not living in), it is simply obsolete in a globalized environment.

Furthermore, the internet then could work as a single big system, instead of replicating functions and data silos across sites. Therefore, a service oriented architecture could be set up addressing the system as a whole; for example:

• Directory services for finding information, people, organizations, groups, etc.
• Accounting services for virtual/online currencies, etc.
• Profiling services, authentication services, security services (certificates, etc.)
• Rating services
• Tagging services
• many more

The internet would run humanity as a single organization (like a 'multinational ' for all people), thus bringing the collaborative / cooperative meme of our times to full fruition.

A Plural Architecture

Plural hardware routes

A minimum of 3 satellites are required for global communications. More is better to prevent bottlenecks. Physical connections, wires, cables, are another layer in the system.

Plural addressing schemes

Nodes on the networks have multiple addresses.

Plural communication protocols

Nodes on the networks implement multiple communication protocols.

Plural software APIs

Software on the network will implement APIs for interoperability. Good APIs will provide mechanisms for automated discovery and communication.

Spam

In the current internet, at the IP level, every packet is unsolicited; a router can't tell the difference between a packet that is part of an email from your boss and a smurf reply intended to flood a victim off the internet. Consequently, distributed denial service of attacks are impossible to stop, and disrupt existing relationships.

Similarly, your mail server can't tell the difference between a Nigerian spam email and an email from your boss, so spam is a constant problem, and leads to the loss of legitimate email.

We can divide communications into three categories:

• Continuing communications that are part of an existing relationship;
• Introductions, where an entity establishes a new relationship between two entities with which it already has relationships (for example, a SIP server setting up a call, or forwarding an email from one of your contacts to another);
• Unsolicited communications, where two previously unrelated entities establish a new relationship; for example, leaving a comment on a stranger's blog.

Unsolicited communications are a legitimate and important function of the internet. But any network that supports unsolicited communications will suffer from spam, and so there is no way to make unsolicited communications reliable in the presence of malicious actors who deliberately overload its capacity. However, it is possible for a network to prioritize continuing communications and introductions over unsolicited communications, reducing the damage done by spam. The POTS telephone network, for example, does not allow call setup messages to interfere with calls that have already been set up, and so AT&T's 1992 SS7 outage merely made it more difficult to set up new calls — it did not terminate calls in progress — and the same thing is true of telephone protests in which large numbers of callers "jam the switchboard" at a company.

To the extent that this is done in an overlay network on top of the current TCP/IP infrastructure, it remains vulnerable to denial-of-service attacks at the lower layers. In many cases, attackers can use IP-level denial-of-service attacks to map the physical topology of the network they are attacking, by anonymously observing the failures they induce. This has been a problem for IRC networks for many years, for example — even when hub servers have locally-routable and secret IP addresses, attackers can determine their IP neighborhood well enough to bring them down with a flood of traffic.

Current countermeasures to email spam and TCP- or IP-layer denial-of-service attacks largely work by empowering unaccountable intermediaries, who use error-prone heuristic algorithms to cut off "suspicious" communications. This also creates pressure against transparency, since many effective heuristics are only effective until the adversary knows them.

Content-centric networking

TCP/IP was designed in the 1970s and 1980s to set up one-to-one terminal connections by which mainframe users could access remote, centralized computing services. That's still the service it provides today, although HTTP and HTTPS is somewhat different from TELNET.

But much of the current usage of HTTP (as well as BitTorrent, RTSP, and other popular protocols) is not actually to access remote computing services, but rather to retrieve named pieces of information that have previously been stored in an online storage service. The actual computing is increasingly being done on the computer the user sits at, with AJAX, Comet, video codecs, and 3-D engines, while the cloud is used as much as possible simply for storage and transferring messages between users. Developments such as HTTP caches, the Google Libraries API, and CDNs in general exploit this fact to improve end-user performance and diminish bandwidth costs.

Van Jacobson, one of the key architects of TCP/IP, is now exploring how to design a replacement for IP oriented toward retrieving named chunks of data rather than sending messages to named communication endpoints. He calls it "content-centric networking". Projects like Freenet and GitTorrent provide a similar service as an overlay network over TCP/IP. If some variation of this idea is developed sufficiently and becomes mainstream, it should have the following benefits:

• Dramatically improved UI latency for things like AJAX applications.
• Dramatically simplified system administration, since many of the services currently provided by many different pieces of software running on web servers would be provided by self-managing software in the cloud.
• Improvements to privacy, since someone outside your ISP would only be able to determine that someone at your ISP wanted to download that Arabic comic about Martin Luther King and the bus boycott, not who or even how many; and similarly for your neighborhood or your house.
• Dramatically improved bandwidth usage on long-distance links, since each named chunk of information would only need to be transmitted over the low-bandwidth link a single time, instead of once for each requester. (IRC network topology and Usenet servers used to provide this benefit for particular kinds of information.)
• Reduced reliance on the reliability and trustworthiness of centralized servers, since you'd retrieve your friend's blog post directly by its name (hopefully a self-authenticating name) rather than through an intermediary who has the ability to edit it.
• Increased functionality for local non-internet networks. In many countries, and with many internet service providers, it is legal to set up private computer networks (wireless or otherwise) without permission from anyone, but not to provide internet access without a license from your ISP, the national government, or both; and for this reason, many hobbyist networks do not provide internet access. If they could nevertheless provide access to named chunks of information, possibly retrieved by a proxy server over the internet, they could be far more useful.

Ubiquitous encryption

When the current internet was designed, there were two major obstacles to encrypting all information transmitted over the network: US export controls on cryptographic software and the slowness of CPUs. Both of these problems have been essentially solved, but we still struggle under the burden of an internetwork design that makes encryption cumbersome, because it's incompatible with the installed base. A greenfield design could eliminate this problem.

MIXes

A significant class of risks in the current infrastructure stem from the unwarranted revelation of identity information. This can be used to retaliate against deviant behavior (e.g. homosexuality, journalism, copyright infringement, organizing protests to call for democracy, gambling, masturbation, or marital infidelity); to commit fraud using that identity information; to discriminate against classes of people, such as those who live outside the USA; to impede the use of the network, for example by denial-of-service attacks. (Impeding the use of the network may be a form of retaliation, but it is sometimes carried out for other reasons as well; consider Gaddafi's recent denial of telecommunications services to all Libyans, which was intended to prevent them from organizing protests, not to retaliate against them for having activist compatriots.)

MIX networks, such as the cypherpunks anonymous remailers and the TOR network, provide a way for people to communicate with each other without revealing identity information, and in particular without revealing their network locations. But MIX networks are currently subject to both technical and social limitations that stem from their non-ubiquity. Due to low and highly variable traffic, traffic analysis of current MIX networks could potentially reveal the identity information they are intended to conceal, and MIX node operators are sometimes subject to sanctions, such as being banned from editing Wikipedia or chatting on Freenode, or being raided by police in a few exceptional cases.

If MIXes were the standard infrastructure of a large network, they would be much less vulnerable to these problems.