I happen to have an architect’s mind. Looking at the network of today, I strongly feel the pain of the current architecture’s cracking and squeaking. Consequently, I believe that we – the wider IETF community responsible for Internet technology – need to re-think the architecture. We need to find a way to re-create the core of the Internet in a way that leads to a new era of innovation and intellectual prosperity. The highlight of my IETF64 meeting in Vancouver was that I started to see signs of interest and activity in the broader community to pursue such a goal.
Thinking about the architecture is not easy. The existing, real, out-there Internet architecture is no more the simple one that the founders designed it to be and that many of us wish it still was. We all know that. What we perhaps don’t consider very often is the fact that there are huge asset values embedded in various parts of the network. As the slower-than-expected migration to IPv6 has amply demonstrated, some parts of the current Internet are painfully hard to change. This makes any long-term architectural thinking and planning difficult.
Any change requires a reason to overcome the associated hurdle. Consequently, I have found it very instructive to try to think about the network and protocols in terms of assets, incentives, costs, and benefits. Whether we like it or not, every design decision we make embeds value propositions into the system. Basic understanding of micro-economics helps us to understand which assets are harder to change, what kind of incentives and disincentives we need to design into our protocols, and what likely benefits there are that may justify the cost of any change. For example, stateless protocol design [1] and client puzzles [2] have been known in various forms for a number of years. They help in resisting certain kinds of bad traffic by increasing the sender’s cost compared to the recipient’s cost, thereby providing a direct incentive for their adoption. However, they are still rarely used, presumably because many protocol designers fail to see their benefit, perhaps because they do not really understand the underlying micro-economic mechanisms. More recently, a wider community of computer science researchers and economists have started to pay more attention to these issues, resulting in publications and books, such as “Economics and Information Security” [3].
The Internet is a complex system, and changing complex systems is difficult, often with unanticipated consequences. However, it helps if we are able to understand that there are different types and sources of complexity. Some complexity is inevitable in any large system. This type of complexity is sometimes called emergent or systemic complexity, as it is the result of the large amount of interaction between networked components. It is a hot research area and likely to remain so for some time.
Another form of complexity is what might be called engineering or architectural complexity [4]. It is an (unintended) result of human design decisions, made during the design and evolution of a complex system. The resulting complexity is not so much a result of a very large number of networked components and their interactions but stems more from designed or accidental nonlinear and cyclic interactions between protocols and other architectural elements within a single network element. Kolmogorov complexity [5] appears to be a good theoretical framework for understanding this kind of complexity.
While we can at most work towards understanding emergent complexity in the first place, there is a great deal we can do about architectural complexity. We can try to design simpler protocols, attempt to resist featuritis, and even simplify the architecture when it becomes apparent that a common piece of functionality is being repeatedly implemented by several protocols. A key for working towards a simpler architecture is attitude. We need to look at our protocols as a whole, attempting to recognise repeated functionality. Once we see that a certain function is being implemented repeatedly in several different protocols, we can try to accomplish the protocol architecture equivalent of software refactoring, where during development of new code some time is also spent on re-writing old code to make it simpler and more general [6].
Given the current state of the Internet architecture, simplification may appear hopeless. Indeed, any attempt at simplification would probably be pointless without some understanding of the goal and the likely end result. We need some kind of an architectural vision and a related transition path; an idea of where we are heading and perhaps how we could get there.
My vision includes peaceful co-existence of both IPv4 and IPv6 for a fairly long time to come. While I would like to see a day when the last IPv4 node is shut down, it is more likely that only future generations will see that happening. In my vision it is possible to use any application I want wherever I am and whatever kind of connection I may have. Indeed, I imagine being able to use multiple wireless networks most of the time, and at least one almost always. I dream of once more being able to communicate with anyone, anywhere on the Internet, independent of the application we want to use, not artificially hindered by NATs or other non-premeditated middle boxes. Finally, in my vision we have baseline security as a built-in feature of the architecture, providing cryptographically strong end-to-end security and sufficient hooks for attaching different kinds of security infrastructures, some based on organisational management and some based on grassroots attempts to model interpersonal human trust relationships with decentralised authorisation systems.
It looks very likely that fulfilling my vision requires adding a new layer, a new “waist”, to the architecture [7]. We have to implement mobility, multi-homing, and the envisioned baseline security somewhere in the stack. If we want connectivity to span the partition between IPv4 and IPv6 networks, it looks necessary to build the functionality on the top of the existing hop-by-hop functionality of the IP layer. If we want connectivity to nodes behind IP addressing boundaries, we apparently need a name space that is located on top of the current IP address spaces. If we want decentralised baseline security without administrative overhead, the names in the new name space should be strongly integrated with cryptographic keys, enabling end-to-end security. We certainly could implement this all at any layer above the current IP layer. However, implementing it at transport protocols or anywhere higher seems to imply repeated realisation, leading to increased architectural complexity; something I greatly dislike. Hence, as much as I wish I could see multiple choices, I currently see no real options except the shim approaches that propose to inject the new functionality between the end-to-end and hop-by-hop functions of the IP layer, interfacing it with the functions below (such as routing) and above (including security).
Once we start to consider how to introduce the changes needed to progress towards any vision, it becomes apparent that the two hardest-to-change assets are the existing routing infrastructure and the set of all existing applications. Consequently, if we can introduce incremental changes that do not require changes to the routing infrastructure nor to the legacy applications, they have better a chance to survive than other changes. A new application is always easy – the main hurdle today is lack of network transparency. But network transparency is exactly what we should re-establish, as a ubiquitous utility instead of requiring each new application to do it themselves, each slightly differently. Changing the protocol stack is hard, but changes that are backwards compatible and allow consenting hosts to gain immediate benefits seem feasible. If a change is self-supporting, requiring no new services or pieces of infrastructure, it is more likely to succeed than one that depends on anything that may create new scaling problems.
Using a term that Brian Carpenter recently coined, I propose that we aim at providing new Architected Network Transparency (ANT). There seem to be three or four potential migration paths towards ANT. One possibility is to utilise a Cryptographically Generated Addresses (CGA) [8] based security model in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to provide end-to-end security and mobility even when IPv6 traffic is shimmed. Another possibility might be to build on top of Mobile IP by providing a new security model and capability of using multiple interfaces at the same time. A third way could build on existing IPsec, IKEv2, and NAT-T, combining them with IKEv2 Mobility and Multi-homing (MOBIKE) [10] for mobility and multi-homing and with Better-Than-Nothing Security (BTNS) [11] for easier and more scalable deployment. However, independent of which of the available paths happens to become the winning one, my suspicion is that the end result will be cunningly similar to the Host Identity Protocol (HIP) [12]. Hence, I follow with keen eyes the ongoing HIP experiment [13], hoping that we as a community can learn from any snags it encounters.
A pivotal impediment in any path towards the outlined ANT heaven seems to be the ability to include the envisioned baseline security in existing legacy applications without requiring any changes in them. One possible means might be Keyed Hash Identifiers (KHI, pronounced as the Greek letter ?) [14], currently subject to heated debate in the int-area and ipv6 mailing lists. Whether KHIs should be considered as an important but transitory stepping stone or as despicable opening of the flood gates to occupy the IPv6 address space with varmints remains to be seen.
The IAB has recently created a new mailing list, architecture-discuss [15], for wider discussion of architectural issues, which I hope will develop into a valuable forum over time. I hope to see you there.
[1] Aura and Nikander, Stateless connections, in International Conference on Information and Communications Security, ICICS’97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, Springer, 1997.
[2] Aura, Nikander, and Leiwo, DOS-resistant Authentication with Client Puzzles, in Security Protocols, 8th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26, Springer, 2002.
[3] Lewis, Economics of Information Security, Kluwer Academic Publishers, 2004.
[4] Nikander, Why architectural complexity is like body fat – food for thought,http://www.tml.tkk.fi/~pnr/FAT/, 2005.
[5] Li, and Vitányi, An Introduction to Kolmogorov Complexity and Its Applications, Springer, 1997.
[6] Fowler, Beck, Brant, Opdyke, and Roberts, Refactoring: Improving the Design of Existing code, Addison-Wesley Professional, 1999.
[7] Deering, Watching the Waist of the Protocol Hourglass, in Proceedings of 51st IETF meeting,http://www.iab.org/documents/docs/hourglass-london-ietf.pdf, IETF, 2001.
[8] Aura, Cryptographically Generated Addresses (CGA), RFC 3972, IETF, 2005.
[9] Site Multihoming by IPv6 Intermediation, IETF Working Group,http://www.ietf.org/html.charters/shim6-charter.html
[10] IKEv2 Mobility and Multihoming, IETF Working Group, http://www.ietf.org/html.charters/mobike-charter.html
[11] Better-Than-Nothing Security, IETF Working Group, http://www.ietf.org/html.charters/btns-charter.html
[12] Host Identity Protocol, IETF Working Group, http://www.ietf.org/html.charters/hip-charter.html
[13] Host Identity Protocol, IRTF Research Group, http://www.irtf.org/charter?gtype=rg&group=hip
[14] Nikander, Laganier, and Dupont, A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI), Internet Draft (work in progress), 2005.
[15] Architecture Discuss mailing list, https://www1.ietf.org/mailman/listinfo/architecture-discuss