Russ
Author Archives: Russ
- Home → Author's archive:
Russ
Reducing Complexity through Interaction Surfaces
A recent paper on network control and management (which includes Jennifer Rexford on the author list—anything with Jennifer on the author list is worth reading) proposes a clean slate 4d approach to solving much of the complexity we encounter in modern networks. While the paper is interesting, it’s very unlikely we will ever see a clean slate design like the one described, not least because there will always be differences between what the proper splits are—what should go where.
There is one section of the paper that eloquently speaks to current architecture, however. The authors describe a situation where routing and packet filters are used together to prevent one set of hosts from reaching another set of hosts. Changes in the network, however, cause the packet filters to be bypassed, opening up communications between these two sets of hosts.
This is exactly the problem we so often face in network engineering today—overlapping systems used to solve a single problem do not pay attention to the same signals or information to do their jobs. So here’s a thought about an obvious way to reduce the complexity of your network—try to use one tool to do one job. Before the days of automation, this was much harder to do. There was no way to distribute QoS configurations, for instance, or access lists, much less what might be considered an “easy way.” Because of this, it made some kind of sense to use routing protocols as a sort of distributed database and policy engine to move filters and the like around.
Today, however, we have automation. Because of this, it makes more sense to use automation to manage as much data plane policy as you can, leaving the routing protocol to do its job—provide reachability across an ever-changing network. There are still things, like traffic steering and prefix distribution rules, which should stay inside routing. But when you put routing filters in place to solve a data plane problem, it might be worth thinking about whether that is the right thing to do any longer.
Automation, in this case, can change everything.
The Hedge Podcast 54: Bob Friday and AI in Networks
AI in networks is a hotly contested subject—so we asked Bob Friday, CTO of Mist Systems, to explain the value and future of AI in networks. Bob joins Tom Ammon and Russ White for this episode.
History of Networking: Heather Flanagan on Identity
While identity is adjacent to networking, it is an important part of the network engineering world—and is not well understood. Heather Flanagan joins Donald Sharp and Russ White to talk about SAML, unified identity, and some of the practical aspects of verifying a person’s identity.
Random Thoughts
This week is very busy for me, so rather than writing a single long, post, I’m throwing together some things that have been sitting in my pile to write about for a long while.
From Dalton Sweeny:
This is precisely the way network engineering is. There is value in the kinds of knowledge that expire, such as individual product lines, etc.—but the closer you are to the configuration, the more ephemeral the knowledge is. This is one of the entire points of rule 11 is your friend. Learn the foundational things that make learning the ephemeral things Continue reading
Weekend Reads 092520
In short: The Trolley Problem is not the kind of a problem that is open to a solution. The Trolley Problem is not for solving, it’s for teaching—for stimulating, for illustrating, for provoking, for exposing predilections and contradictions. It’s a thought experiment. (Philosophy also performs thought experiments with zombies.) The point is not to work out the answer to a riddle; the point is to think about the implications of the circumstances. We open Pandora’s Box, but we don’t intend to catch the demons and stuff them back in; we let them fly around wreaking Continue reading
The Hedge Podcast #53: Deprecating Interdomain ASM
Interdomain Any-source Multicast has proven to be an unscalable solution, and is actually blocking the deployment of other solutions. To move interdomain multicast forward, Lenny Giuliano, Tim Chown, and Toerless Eckhert wrote RFC 8815, BCP 229, recommending providers “deprecate the use of Any-Source Multicast (ASM) for interdomain multicast, leaving Source-Specific Multicast (SSM) as the recommended interdomain mode of multicast.”
Technologies that Didn’t: CLNS
Note: RFC1925, rule 11, reminds us that: “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.” Understanding the past not only helps us to understand the future, it also helps us to take a more balanced and realistic view of the technologies being created and promoted for current and future use.
The Open Systems Interconnect (OSI) model is the most often taught model of data transmission—although it is not all that useful in terms of describing how modern networks work. What many engineers who have come into network engineering more recently do not know is there was an entire protocol suite that went with the OSI model. Each of the layers within the OSI model, in fact, had multiple protocols specified to fill the functions of that layer. For instance, X.25, while older than the OSI model, was adopted into the OSI suite to provide point-to-point connectivity over some specific kinds of physical circuits. Moving up the stack a little, there were several protocols that provided much the same service as the widely used Internet Protocol (IP).
The Connection Oriented Network Service, or CONS, ran on top Continue reading
Reducing RPKI Single Point of Takedown Risk
The RPKI, for those who do not know, ties the origin AS to a prefix using a certificate (the Route Origin Authorization, or ROA) signed by a third party. The third party, in this case, is validating that the AS in the ROA is authorized to advertise the destination prefix in the ROA—if ROA’s were self-signed, the security would be no better than simply advertising the prefix in BGP. Who should be able to sign these ROAs? The assigning authority makes the most sense—the Regional Internet Registries (RIRs), since they (should) know which company owns which set of AS numbers and prefixes.
The general idea makes sense—you should not accept routes from “just anyone,” as they might be advertising the route for any number of reasons. An operator could advertise routes to source spam or phishing emails, or some government agency might advertise a route to redirect traffic, or block access to some web site. But … if you haven’t found the tradeoffs, you haven’t looked hard enough. Security, in particular, is replete with tradeoffs.
Every time you deploy some new security mechanism, you create some new attack surface—sometimes more than one. Deploy a stateful packet filter to protect a Continue reading
Weekend Reads 091820
In Europe and beyond we struggle with effective policing of online communications. As generations before, we want to be both: free and safe when we interact with others, go shopping or get our news. While this balance is difficult, it is possible to achieve: the rapid development of online communications, often proclaimed the wild west of modern society, Continue reading
The Hedge 52: Tobi Metz and the Technologist Question
Tobi Metz asked What is a Technologists? in a recent blog post. Tobi joins Tom and Russ on this episode of the Hedge to expand on his answer, and get our thoughts on the question.
The History of Comm Servers with Kevin Herbert
Communication Servers designed to support hundreds or thousands of users reached their peak capabilities just as dial-up service access began to recede in importance. In fact, many network engineers today have probably never managed a dial-up communications server, which were once used to connect everything from individual users to services like AOL and remote workers to entire sites (hence OSPF’s demand circuit capability). Kevin Herbert joins us to discuss the early work on communication servers, including some of the challenges of working with early networking hardware.
Everyone Must Learn to Code
The word on the street is that everyone—especially network engineers—must learn to code. A conversation with a friend and an article passing through my RSS reader brought this to mind once again—so once more into the breach. Part of the problem here is that we seem to have a knack for asking the wrong question. When we look at network engineer skill sets, we often think about the ability to configure a protocol or set of features, and then the ability to quickly troubleshoot those protocols or features using a set of commands or techniques.
This is, in some sense, what various certifications have taught us—we have reached the expert level when we can configure a network quickly, or when we can prove we understand a product line. There is, by the way, a point of truth in this. If you claim your expertise is with a particular vendor’s gear, then it is true that you must be able to configure and troubleshoot on that vendor’s gear to be an expert. There is also a problem of how to test for networking skills without actually implementing something, and how to implement things without actually configuring them. This is a Continue reading
The Hedge Podcast 51: Tim Fiola and pyNTM
Have you ever looked at your wide area network and wondered … what would the traffic flows look like if this link or that router failed? Traffic modeling of this kind is widely available in commercial tools, which means it’s been hard to play with these kinds of tools, learn how they work, and understand how they can be effective. There is, however, an open source alternative—pyNTM. While this tool won’t replace a commercial tool, it can give you “enough to go on” for many network operators, and give you the experience and understanding needed to justify springing for a commercial product.
It Has to Work
From time immemorial, humor has served to capture truth. This is no different in the world of computer networks. A notable example of using humor to capture truth is the April 1 RFC series published by the IETF. RFC1925, The Twelve Networking Truths, will serve as our guide.
According to RFC1925, the first fundamental truth of networking is: it has to work. While this might seem to be overly simplistic, it has proven—over the years—to be much more difficult to implement in real life than it looks like in a slide deck. Those with extensive experience with failures, however, can often make a better guess at what is possible to make work than those without such experience. The good news, however, is the experience of failure can be shared, especially through self-deprecating humor.
Consider RFC748, which is the first April First RFC published by the IETF, the TELNET RANDOMLY-LOSE Option. This RFC describes a set of additional signals in the TELNET protocol (for those too young to remember, TELNET is what people used to communicate with hosts before SSH and web browsers!) that instruct the server not to provide random losses through such things as “system crashes, lost data, Continue reading
Understandability
According to Maor Rudick, in a recent post over at Cloud Native, programming is 10% writing code and 90% understanding why it doesn’t work. This expresses the art of deploying network protocols, security, or anything that needs thought about where and how. I’m not just talking about the configuration, either—why was this filter deployed here rather than there? Why was this BGP community used rather than that one? Why was this aggregation range used rather than some other? Even in a fully automated world, the saying holds true.
So how can you improve the understandability of your network design? Maor defines understandability as “the dev who creates the software is to effortlessly … comprehend what is happening in it.” Continuing—“the more understandable a system is, the easier it becomes for the developers who created it to change it in a way that is safe and predictable.” What are the elements of understandability?
Documentation must be complete, clear, concise, and organized. The two primary failings I encounter in documentation are completeness and organization. Why something is done, when it was last changed, and why it was changed are often missing. The person making the change just assumes “I’ll remember Continue reading
Weekend Reads 090420
Running a bit late this week … 
That said, Intel over the past couple of years has expanded its Continue reading
The Hedge Podcast #49: Karen O’Donoghue and Network Time Security
Time is critical for many of the systems that make the Internet and other operational networks “go,” but we often just assume the time is there and it’s right. In this episode of the Hedge, Karen O’Donoghue joins Alvaro and Russ to talk about some of the many attacks and failures that can be caused by an incorrect time, and current and ongoing work in securing network time in the IETF.
The Hedge Podcast #50: The Challenge of Growing People
Many network engineers complain about their companies not giving them opportunities—but how many think about helping the company grow in a way that allows them to have the opportunities they desire? Scott Morris, aka “evil ccie,” joins Tom and Russ on this episode of the Hedge to talk about the challenges of certifications, growing people, and people learning how to grow in a way what improves the business. Sometimes growing means creating opportunities rather than just waiting for them to knock.