The Discrete Internet and What to do About It

The original model of the Internet is simple and homogeneous: every interface is reachable via a long-lived address, routers do nothing but move packets as fast as possible over hopefully-stable routes, hosts are responsible for securing themselves, and any complicated function is implemented end-to-end by applications running on hosts. In recent years both network providers and end-site customers have deployed various forms of network intermediaries with accelerating frequency. Examples of intermediaries include NATs, transparent web caches, firewalls, and load balancers. The result of these deployments is a more complicated “Discrete Internet:” an Internet composed of discrete subnetworks, attached at a small number of choke points, lacking universal addressability, and including stateful in-network intermediaries as vital components of (what were once endto-end) services. This development has anguished many who design networks and applications. These critics make sound technical arguments for why the emerging design of the Internet is undesirable, and some argue for a return to the earlier, simpler model. This paper explains why the original homogeneous Internet model is gone forever, replaced by the Discrete Internet. A novel technical mechanism – a new “session” layer in the Internet protocol suite, inserted between the application and transport layers – is proposed as a way to manage the new complexity, retrieve some of the lost benefits of the original homogeneous model, and open a variety of new possibilities. I. THE DISCRETE INTERNET The Internet is increasingly being populated by intermediaries. For example, located between a browser and a web server there might be a NAT-ing firewall on the client side, one or more web caches at points in the network, and a workload balancer on the server side. Many lament the rise of intermediaries – especially NATs, but any stateful component – and argue that the Internet can or will return to its original model wherein the network center simply moves IP packets end-to-end between universally addressable hosts. This nostalgic hope usually takes the form of arguing that (1) NATs exist mostly to cope with the IPv4 address shortage, (2) deployment of IPv6 will solve the address shortage, and (3) a return to universal (IPv6) addressability will allow end-to-end use of IPSec. Roughly, IPv6 plus IPSec equals a secure Internet that obeys the original “end-to-end” model. As desirable as such a future may be, intermediaries are a fact of life, and are likely to become more, not less, popular for a variety of reasons that are technical, political, and operational: 1) End-system deployment of IPv6 will probably never happen for reasons similar to “ the tragedy of the commons:” although switching to IPv6 might be the best thing for the world at large, few if any individual parties will benefit tremendously or quickly from the upgrade. Therefore, each party connected to the Internet will separately calculate that its own best interest is to avoid the upgrade and stick with IPv4 – at least until disaster looms. NATs are supposedly an important part of handling the IPv4 address shortage. Since IPv4 is likely to be our long-term IP technology, NATs are likely to become more numerous. 2) A network administrator is wise to be conservative, and he/she may perceive security benefits to maintaining a private address space behind a NAT: attackers do not even know which addresses to attack, or which addresses to mention in their attacks against other parties. This is another argument for NATs.1 Many say that increased security through NAT-ing is a specious argument, for two reasons. First, address hiding can be accomplished as well with a “filtering router.” Second, a sense of security engendered by a NAT-ing firewall may lead administrators to leave hosts behind the NAT/firewall vulnerable. Similarly, general increased distrust and more bad actors attached to the Internet make firewalls seem attractive (even if other approaches to security might be more sound). 3) Port-translating NATs (NAPTs, the most widely deployed version of NAT) vastly ease renumbering: an organization needs to renumber only its external NAT interface if it switches ISPs or must return addresses to IANA. Even for NATs that are not NAPT, an organization need renumber only the set of IP addresses used on the public side. For similar reasons, NATs simplify the simultaneous use of multiple ISPs. 4) At least for the next several years, there is likely to be more link/network heterogeneity, as wireless service providers and cable companies experiment with different technologies, standards, and services. Heterogeneity leads to more differing protocols (e.g., WAP) and thence to more protocolconversion gateways. 5) Network providers want to protect links, not just hosts. In order to provide for billing, they want to prevent even the transmission of packets over their networks until after an attached host has authenticated. 6) Corporations are likely to want substantial control over the use of their intranets to limit employee actions (the Web sites they can visit, the data they can access) to prevent goofing off and avoid liability concerns. Such control is more easily implemented at a central network choke point such as a firewall. 7) ISPs and/or companies that control content (e.g., AOL) will naturally prefer the “walled garden” model wherein they receive enhanced revenue in return for enhanced services available only within their own network. A walled garden is more easily implemented by locking out users at a few network choke points than at each service site. 8) Governments are likely to want to “tap” networks in order to enforce laws governing taxation, wiretapping, import/export of certain types of data, etc. One example is that US Federal law requires telephone networks to be tap-able for criminal investigation; this will affect the design of IP telephony. 9) Finally, the equation for end-to-end latency of a packet is: