Return to Table of Contents

Chapter 10 - Future Musings

10.1   Policy Routing Triad
10.2   The Protocols: IPv4, IPv6, and IPSec
10.3   Security and Commerce
10.4   Summary

You have seen the theory and a practical implementation of the theory of Policy Routing. Many of the concepts have been part of the routing structures for IPv4 and other protocols for years. The explosion of interest in the Internet has led to a wide-scale need for and adoption of Policy Routing structures.

This chapter covers some of the thoughts and projections of direction for Policy Routing. Some of these concepts are extensions of logic, others are merely wishful thinking at this stage. I hope that you will have your own thoughts and inferences to add to this list.

10.1 Policy Routing Triad

Back in Chapter 3 you were introduced to the concept of the Triad of Policy Routing. This concept was developed through theory and implementation within the context of the IPv4 networking structure. The core provisions for this concept consist of the definition and scope of action for the three main elements of Policy Routing structures. In review, the three elements are

Address   defines the location of a service.
Route   defines the location of the address.
Rule   defines the location of the route.

As you have seen and explored, each of these elements contains a wealth of detail in use and construct. The interactions between these multiply-faceted elements defines the range of actions possible under Policy Routing.

What you saw in Chapter 9 was how the nascent format of IPv6 has made use of some of these constructs and yet seems not to have implemented the core. This will change. As discussed in that chapter, IPv6 is still a very young and sparsely used protocol. Even IPv4 did not need to use Policy Routing in the first few decades.

IPv6 will become the new Internet protocol suite. Many of the uses of the Internet are, as with everything Internet, changing at a rapid pace. Think back merely five years, to the release of the first IPv6 RFC in December of 1995, to see the difference. In 1995, not having a Web address was normal and having one was "cutting edge." Cutting edge is a polite way of saying "too risky" and "fit only for the severely bored." Microsoft was busy dismissing the Internet as a fad and trying to release Windows 95. Novell's NetWare still pretty much ruled the corporate network with IPX. Ethernet was just overtaking TokenRing as the corporate LAN topology.

Now think of today. Not having a Web site or at least an email address indicates you are a nobody. Even if that address is on AOL or MSN or Hotmail, at least you "get it" (whatever "it" is). And that's what makes this entire sequence so downright funny to those of us who remember ARPAnet, BITnet, Vaxen, that newfangled Usenet (remember the old uselessnet jokes...), and specifying email addresses in terms of gateways and uucp paths. Back then many of us looked down on those poor local users (lusers in the trade...) who did not grok the wonders of communicating the computer way.

What will you think when the next generation, or even the one beyond that, walk up to you and tell you about how wonderful this Policy networking stuff is, and how you old fogeys don't get "it"? It will happen. You stand today on the shoulders of shoulders of giants. Much of what is so gee-whiz today has been around for eons as translated into Internet time and you see that nothing really has changed incomputing terms. However, in human terms the change is fundamental.

So it will be when IPv6 finally becomes the only reality in the Internet. The fundamental definitions of the Triad will probably be reworded, but they will exist. And the decisions that drove Policy Routing to what it is today will re-emerge. Networking defines a continuous, multiconnected structure.

Consider the evolution of networks themselves. Think of the early point-to-point structures, such as a mainframe with terminals. Note the evolution into multiconnected structures such as LANs. A LAN defines a group of points that each connect at one location, with the allowance that any particular point may talk to any other point. Now consider that a LAN can be thought of as a single point on a network. Initially, you may have connected your LAN points with a WAN. Traditionally you had a point-to-point WAN, then you evolved into a multipoint FrameRelay, where any point in your corporate network can talk to any other point. Step back once more and look at your entire corporate network as a point, and the Internet as the WAN to all the other points. And for the final consideration, think of your point as having more than one connection into this WAN.

At this stage you see how Policy Routing has entered the game. But that could have happened at any of the transitions between single to multiple connections. Today, IPv6 usage on the current Internet is at the point-to-point LAN stage. When we grow into the full multiconnected WAN, Policy Routing will be implemented yet again to suit the new structures.

In this manner, the basics of the Triad have not and will not change. The implementation and the actual uses will probably differ, in some cases substantially. And new uses not yet dreamed of will burst into life much as the Web transformed the use of the Internet in 1993. The ride will be fun, so long as you want the thrill.

10.2 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 normal or are you curious? Normal, you decide to ensure that your routing code will never perform that action. Curious, 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[md]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.

10.3 Security and Commerce

Security, stability, and ease are a holy grail to current e-commerce vendors. The usual disclaimers and arguments prevail about the scope of the supposed problems. These are all very technically interesting, but from the point of view of the end user, all very irrelevant. The original demographics that drove the interest in e-commerce are simple.

Remember back to some of the original surveys of Internet denizens in 1993/94, especially some of the "average Web user" results. Most of these surveys showed that the average Web surfer was highly educated, upper middle class income, with rather large discretionary spending habits. And at that time that was mostly true because outside of the University settings, only the somewhat technocratic elite even had an inkling of the Web thingie.

Show those demographics to a marketing manager and he or she practically starts panting and drooling. Thus the Internet Gold Rush was born. As with the real gold rushes of the past few centuries, most of the real, hard cash was made by providing the miners with supplies. ISPs, Web site creators, network and computing hardware vendors, and related infrastructure providers grew and prospered.

The last thing on the suppliers minds in most cases was security. Next to last was long-term planning. While the early Internet had security problems, the stresses were moderate and fairly convoluted in use. Breaches tended to be few in number but complex and convoluted in execution due to the preponderance of large time-shared systems with accounting structures.

Security was a subject that was researched and catalogued, a la CERT, CERIAS, and similar organizations. There were alerts and processes for patching and mitigating the breaches. The process was almost leisurely in contrast even to the long-term development of the protocols. The actual connection density of the Internet was only beginning to expand. And as with the superhighway system, the greater connection density and mobility of the Internet would fracture the security model and force a whole new structure.

As with the automobile and the telephone, the emergence of the Internet started over a period of time with fractional parties fighting to promote their service and vision. With standardization and eventually serious commercial reasons, a la the Web, the use of the product surged. The masses had arrived. What goes around comes around, especially when considering a redefining technological invention.

Consider that before the advent of direct dial you would have a difficult time making a crank call. Noting that direct dial was the direct result of a perceived commercial problem, you can easily see the parallels to the Internet of the early 1990s. Once the masses were ensconced, the rules of the game changed.

Consider today the reference to the "Slashdot Effect," usually e-coded as "/. effect". This effect refers to what happens when you are mentioned on a widely read Internet news source and suddenly millions of people are trying to reach your Web site. Many sites have crashed or at least slowed to a crawl due to the massive surge in volume. Indeed, there is at least one instance where a suspicion exists that the site was purposely promoted to an Internet news site in order to slam the referenced site into the ground.

Such actions are only the tip of the iceberg. Just as crank calling evolved into phreaking and other attacks using the telephone systems, so too with the security structures of the Internet. As with most phenomena it was predictable yet unknown. The supposed power brokers tried to pan it off as rogue adolescence that would fade as new, more powerful and well-designed computers and operating systems were released onto the market. So here we are with all of these more powerful operating systems and computers fighting a battle for control against the dark side.

What exactly is being fought? Is it a ruthless, intellectual elite bent on wreaking world havoc? A global conspiracy to silence the oh so wonderfully innovative companies whose dazzling products are the salvation of computing kind? Or just a bunch of inquisitive people? Sadly, the answer lies more toward the last group.

As with the commercial interest that produced the automatic dialing systems, most computing products, especially operating systems, are designed for the benefit of the manufacturer. Security is a cost center, just as Information Technology is a cost center. To paraphrase the IBM commercial, realizing that your business is based on your Web site - that is an epiphany. And that epiphany has not yet taken hold.

Rather than promote security to a profit center by blending it into the design and development of a product, it is easier to blame the evil forces that surround each and every one of us. And as with the computer virus problem, why design to remove the problem when you can make a profit tending it instead? Just think of the financial losses that would be incurred if any of the secure computing structures designed several decades ago were to be enforced. Most of the anti-virus, firewall, and security consulting firms would crash and burn.

No, those structures are not hard to use. Just ask anyone who has a higher level security clearance who has been a user on a trusted computer system. The vast majority of the time you do not notice that the system prevents you from doing harm. It is only if you try to do something that is not permitted for your level that you see the results of the security structure. Now the old draconian lockstep argument arises. We would all be slaves to the machines is the battle cry.

The point is that if you consider the vast majority of supposedly horrific attacks, especially in terms of costs, on the Internet in the last half of the 1990s, over 85% of them would not have occurred with just a modicum of security structures within the computing platforms and networks in use. Some of the simple steps are being taken but often are both seen and advertised as amazing and difficult work.

In such an environment, can you imagine the carnage of the implementation of IPSec or IPv6? It's bad enough that in many cases IPv4 is still not implemented correctly. And consider too the current status of Policy Routing.

From this perspective the current statements about e-commerce and security are inherently ludicrous. For every single credit card number stolen on the Internet in 2000, dozens or hundreds of people were mislead by telesales, swindles, and other direct interface security breaches. That pendulum is starting to swing. The necessary technical systems and structures do exist to prevent that swing. But it remains to be seen whether the commercial incentive will be seen in time.

And that brings up the other problem of the Internet Gold Rush: long-term planning. The security problems faced on the Internet are much the same in concept as the security problems of the telephone and the automobile. You can break in to a site and make your getaway with the goods. You can impersonate or internally compromise a site. And you can coerce others into giving you the goods in good faith.

Today if you were to start a physically located business, say in a strip mall, you would leave the doors unlocked at all times. Especially when you were not there. And you would not bother using a cash register that locks or even closes the cash drawer. And most assuredly you would not know what you had in stock at any given point in time because you were only interested in this minute right now.

Ok, you can tone down the laughter. All of these steps are essentially what you would obtain today with the vast majority of Internet commerce proposals. And this includes just being a participant, let alone the proprietor. This is largely due to a lack of foresight, also called long-range planning.

If you go into a bank, or to the Venture Capitalists, or other sources of business funding today for your strip mall store, you will find that what they really want to see is whether you have planned out the long-term and short-range goals. This is often referred to as a business plan. If in the details of your business plan you have not allowed for some basic security structures, you will be denied immediately. Unfortunately, that is only now starting to be implemented for Internet commerce.

The long-term planning of most e-commerce sites even now consists of: Grow big by losing money, IPO and sell out. Usually the entire sequence is considered to be complete within two years. The long-term planning that is starting to be seen, especially in the details, is more along the lines of: Protect the assets, and nurture the position into recurring revenue. And you can bet that those details now contain the locks, keys, and provisions for counting the merchandise before and after the sale.

So the security, stability, and ease factors are starting to return. Ease was first and often at the complete detriment of stability and security. Now a balance is being found as the hollow tones of "you cannot have your cake and eat it too" are being shown as simple lack of foresight coupled with a sales incentive to care less about the actual consumer. The security and stability of systems are ever increasing with the same ease still present. And this is mainly due to the leap of the competing interests and proprietary systems into the acceptance and implementation of standards.

As with the early telephone systems standards and the issuance of rules of the road, the standards of the Internet are evolving to promote cooperation and foster a secure, stable, and easy path to interconnection. Progress can be seen in the mere acceptance of many of the system design security standards laid down in the seminal 1975 article of Jerome Saltzer and Michael Schroeder from Proceedings of the IEEE 63(9) pp 1278-1308. As time marches on in the Internet, the standards change. Perhaps the best point about the change structure of the Internet is that it is not driven by any one or any group of corporate interests. Thus the eventual apogee will provide security, stability, and ease of use for all.

10.4 Summary

I hope you have enjoyed your ride through the theory and practice of Policy Routing structures. As with most network concepts, the principles may be timeless but the implementations change and flow. The future of IPv6 and beyond slowly coalesces. In general, the direction is pretty much the same. In detail lies the excitement and wonder. I hope you have seen the wonder and excitement and are itching to go change the world.

Return to Table of Contents