The Protocols: IPv4, IPv6, and IPSec

Thinking about how the evolution of networking has driven the fundamental features of Policy Routing brings up the subject of the other foundations of networking: the protocols. As with many of the facets of modern life, you seldom stop to consider the fundamental building blocks. And yet these fundamentals funnel your actions in many ways.

Consider the way in which an actual information exchange takes place under IPv4. "Ah-hah," you shout, "Are you using TCP or UDP?" "Neither," I will reply, but thanks for asking. The point not so subtly made is that the mere definition of the protocol in question defines the mechanism of communications. As you well know, TCP shakes hands whereas UDP could care less.

But what about telnet? Oh ”that is TCP. Or is it? Can you do telnet over UDP? Sure you can, but that is not the definition according to the RFCs. So you need to have an RFC to communicate? No, it just ensures that the communication is standard. And that is the root reason for all the usefulness and all of the problems with any of the protocol suites. The standard definition of the protocol as ratified and encoded in a document defines the methodology for using said protocol across a network. Why would you care? Think of the following sequence.

You are reading through one of the IPv6 RFCs. It talks about how a router treats the packets. You come across the statement that the router must not perform a certain action. Are you on the level or are you curious ? On the level, you decide to ensure that your routing code will never perform that action. As a curiosity , you work up some routing code to perform that action and see how it affects the rest of the network.

This thought sequence plays out all over networking. But the black-and-white definition rarely is true. Shades of gray dominate the Internet. Many examples exist of incorrect implementations of standard protocols. Look through many of the core attack formats for networks. Many of these attacks make use of a particular implementation type. Arguments rage constantly on how to interpret statements within the RFCs and in some cases on how to even implement an agreed upon definition.

Indeed the mere concept of host fingerprinting exists due to variations in implementation. Host fingerprinting refers to the process of determining an OS type by looking at the sequence of responses to types of communication. And much of this difference in communication actually refers to responses to very defined and structured packet sequences. But if you have ever written code, especially for something as complicated as a network communication protocol, you know that more than one method is usually feasible .

From this viewpoint of the vagaries present, even in defined and well accepted actions, you see that the vague specification and tricky definitions of other actions leaves a wide open gap. Much as Policy Routing seems now a foregone conclusion, many of the structures in networking in general only solidify over time. The usual consideration provides that all matters will eventually either solidify through consensus or be discarded by friction.

While this viewpoint implies that the best course of action may be to ride out the storm , the best course of action bails the boat. Wisdom is the application of intelligence to experience. You must have both prerequisites. Thus while waiting around to gather experience, you should study the definitions. One overriding truism in networking, as in many other endeavors, notes that the larger-scale phenomena recur. By positioning yourself in the thick of the struggles that define and shape the Internet, you will understand and manipulate the result in ways you cannot even now imagine.

The fundamental concerns of this outlook define an inquisitive course of action. As you study the RFCs and the code that implements the action studied, try to think of the action from both sides ”what would happen if the action is correct and also what would happen if the action is incorrect. Just as with the asymmetric NAT routing, you need to see the entire scope of the problem along with noting the details. Policy Routing is extraordinarily powerful, but if you only have one IP address on one computer with one Internet connection, what does it matter? Conversely, why implement ten traditional routers when one policy router would suffice?

This spectrum will come to a particularly crucial point when IPSec becomes as widely implemented as the original specifications imagined. IPSec was and still is designed as an integral part of a comprehensive IPv6 Internet. The idea is that all parties within the Internet can be assured of each others' identity and may securely converse . This authenticated, non-repudiated, and encrypted structure will be provided transparently . Ignoring for the moment the practical problems with key exchange, DNSSec, and so on, consider the mere definition of a multiply-connected gear meshed system that this provides.

In a gear meshed system, all points of multiple connection are conceived of as three dimensionally connected points, kind of Escherian in scope. Think of a traditional star network. Now consider that all of the remote points of that star are stars themselves . Consider that some of those stars connect to stars that then eventually connect back to the original star. Visualizing that web of connections in two dimensions is hard enough. But now think of each star as drawn in two dimensions as a gear. And where those gears mesh together is the mutually shared point of contact. Now extend down from each gear a shaft on which other gears are located. That is a fully gear meshed network. And designing one of those buggers really illustrates Policy Routing.

Conceiving that a fully IPSec-enabled Internet defines a gear meshed network, you realize the full future and potential of Policy Routing structures. While ideally you would never worry about the integrity and security provided in such a system, in practicality you would be scared stiff. Consider that you are connected to a pure embodiment of network evil, which according to the media would equate to a normal 14-year-old online male. You have an authenticated, non-repudiated, encrypted connection to said person.

So when he wreaks havoc on your systems, you have no problem because you know who, what, and where. Of course your systems are destroyed , your business fails, and you are now homeless. But at least you had an authenticated, non-repudiated, encrypted connection to that person. Oh, but he was located physically in some small island within the Indonesian archipelago where you have no extradition rights and where what he did was not considered a crime. In hindsight you would have rather had a Policy Routing structure where you control access and availability to your systems.

And therein lies the long- term viewpoint. If you peruse history as it was actually recorded rather than as the predistilled pap you may have memorized in school, you see that the overall driving factor of any technology is human. The invention of the highway system meant serial killers now had larger scopes of action. Oh, and it also allowed you to live in the suburbs and move several hundred miles away from your parents and still be close to home. The point is that the technology itself did not change fundamental human behaviors so much as it provided new avenues to pursue the same interrelations as had always been pursued.

So it will be in the Internet. The real explosion of growth has not been fueled by the technocratic elite but by common humanity. To connect with each other and feel ourselves connected to by others drives the fundamental impetus of this technology. People do not consider or even care how the connections are made and what drives the actions, they merely want to connect. On the other hand, you will be ensuring that they do connect and that such a connection is made with the provisions of security, stability, and ease.

Top