This month we are looking at a humorous rule that also turns out to be one of the primary keys to understanding network engineering and life: RFC1925, rule11. The rule is every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. In other words, the present and future might not repeat the past, but it will certainly rhyme. The number of times this has happened in the world of networking technology is almost beyond counting—mostly because there are only a few real problems to solve in every area of networks, and there are only a few real solutions to those problems.
For instance, one of the first difficult problems solved in networking was allowing two hosts to connect to one another over mixed media—specifically, local wired networks connected through a wireless (van mounted) network. The solution for this problem was … essentially a form of tunneling, creating an end-to-end protocol that could run on top of any physical network medium. Today we call this protocol the Internet Protocol (IP), and we don’t consider it tunneling any longer.
Since then this same concept—tunneling—has been invented at least eighteen times since the invention of IP, including IP in IP, DLSw, DOVE, eVPN, GRE, IPsec, MPLS, OTV, GENEVE, L2TPv3, and VXLAN. Even before there IP became the default transport protocol, there were tunneling protocols associated with IPX, VIP, ATM, and many others. The smart engineer might ask—why do we keep inventing tunneling protocols? Why not just create one and be done with it? There aren’t many new standards you can write that way, are there? This rule doesn’t just apply to transport protocols, however; it also applies to control planes. For instance, the way broadcast and unknown traffic in ATM LANE, LISP, and eVPNs are all very similar.
How can you keep engineers on their toes if you aren’t constantly inventing something new—even if it is the same as something old with a different name and headers?
Sometimes even inventions designed to be funny turn out to be all too real. RFC1926 describes a system for transmitting data over an acoustical side channel between computers, such as between the speaker on one computer sending digital signals to another computer through its microphone. A full system is developed for transmitting IP, including multiple acoustical LANS using the same shared medium (air, of course). Recent research, such as this paper by Daniel Arp et al., describe just such a side-channel for transmitting information between a smartphone and a computer. A more interesting example is this recent paper by Ilia Shumailov et al. using sound wave distortions to determine where on a glass screen a user is pressing (thus being able to tell what letters they are typing).
Then there is RFC7169, which defines a new bit (called the No Security Afforded, or NSA, bit) in the IP header to make the packet appear to be encrypted although it really isn’t. This is very useful for those who want to believe the information they are sending over the open Internet is really, really secure, when it’s not. It would be the only kind of encryption IP users have left, in practice, if all the governments who like to see what kinds of things people are stuffing in those packets have their way.
Another rather humorous example are emojis and emoticons. When emoji’s were invented in the 1990s, no-one expected them to become one of the primary forms of communication between teenagers. In fact, I’ve seen multiple page research reports written entirely in emoji, which seems to be its own language at this point. In honor of the emoji, RFC5841 describes a new TCP option to describe the mood of the packet. This is like an emoji, but it’s for web, FTP, and other servers to describe their mood. You never see these, of course, because they are protected by these servers using the NSA bit—which means they are really really super-secret and cannot be detected or read by normal humans.
The next time you see some huge new product announcement, the first thing you should do is look for when this has been invented before, how it was used, and how it broke back then. This might give you some serious help in understanding how it is going to break this time.
Russ White has more than twenty years' experience in designing, deploying, breaking, and troubleshooting large scale networks. Russ is currently a member of the Architecture Team at LinkedIn, where he works on next generation data center designs, complexity, and security. His most recent books are The Art of Network Architecture and Navigating Network Complexity.