Russ White Archives - Page 131 of 164

Beach Bench

The post Beach Bench appeared first on 'net work.

Universal Scaling and Complexity

The universal scaling law is a model designed to help engineers understand transaction based systems, particularly databases and applications. What could a transaction based system have to do with network design? After all, networks aren’t really transaction based, are they? Or maybe they are…

complexity-model Let’s ignore the data flowing through the network for a moment (though the universal scaling law might provide an interesting way to look at packets or flows per second as transactions), and focus just on the control plane. When we look at the control plane, we find a routing protocol or a centralized controller that accepts information about changes in the network topology (and other data points), and builds a model of the network topology which can be used to forward traffic. Questions we can ask about the state being handled by the control plane include things like: How many changes are there? What is the rate at which this information arrives? How many changes might be present in the system at any given time? How many devices participate in the control plane?

If these all sound like questions about state, one of the three “legs” of the complexity model (state, optimization, surface), that’s because they Continue reading

Thinking about side channel attacks

When Cyrus wanted to capture Babylon, he attacked the river that flows through the city, drying it out and then sending his army under the walls through the river entrance and exit points. In a similar way, the ventilator is a movie favorite, used in both Lord of the Rings and Star Wars, probably along with a thousand other movies and stories throughout time. What do rivers and ventilators have to do with network security?

Side channel attacks. Now I don’t know if the attacks described in these papers, or Cyrus’ attack through the Euphrates, are considered side channel, or just lateral, but either way: the most vulnerable point in your network is just where you assume you can’t be attacked, or that point where you haven’t thought through security. Two things I read this week reminded me of the importance of system level thinking when it comes to security.

security-net The first explores the Network Time Protocol (NTP), beginning with the general security of the protocol. Security in a time protocol is particularly difficult, as the entire point of encryption is to use algorithms that take a lot of time for an attacker to calculate—and there’s probably some relationship between Continue reading

Why you need to learn to code

We’ve all heard it by now: you’d better learn to code, or your network engineering career is going to die a quick (and potentially painful) death. Maybe you could still act as a briefcase carrier, and call yourself a consultant, but without coding skills, you’re open ended job is going to become a dead end, and you’ll be a has been. While just about everyone has weighed in on this topic recently, I don’t know if anyone has, IMHO, really dug down to the bottom of the question. Permit me to give it a try (and feel free to disagree in the comments).

To get to the point, allow me to summarize both sides of the argument (hopefully without building and straw men along the way). On one side are folks who say that the Command Line Interface (CLI) is dead, and that we must learn to automate everything. Part of the argument here seems to be that without automation, we won’t be able to keep the operational costs (OPEX) down; as networks are primarily a cost center (rather than a strategic asset), driving costs down is one of the most important tasks a network engineer can take on. That, Continue reading

Securing BGP: A Case Study

What would it take to secure BGP? Let’s begin where any engineering problem should begin: what problem are we trying to solve? This series of posts walks through a wide range of technical and business problems to create a solid set of requirements against which to measure proposed solutions for securing BGP in the global Internet, and then works through several proposed solutions to see how they stack up.

Post 1: An introduction to the problem space
Post 2: What can I prove in a routing system?
Post 3: What I can prove in a routing system?
Post 4: Centralized or decentralized?
Post 5: Centralized or decentralized?
Post 6: Business issues with centralization
Post 7: Technical issues with centralization
Post 8: A full requirements list
Post 9: BGPSEC (S-BGP) compared to the requirements
Post 10: RPKI compared to the requirements