Russ

Author Archives: Russ

Securing BGP: A Case Study (5)

BGP provides reachability for the global ‘net, as well as being used in many private networks. As a system, BGP (ultimately) isn’t very secure. But how do we go about securing BGP? This series investigates the questions, constraints, and solutions any proposal to secure BGP must deal with as a case study of asking the right questions, and working at the intersection of business and technology.

As a short review, we started off with three questions, described in the first post, each of which we’ve been considering in some detail:

  • Should we focus on a centralized solution to this problem, or a distributed one?
    • Assuming we’re using some sort of encryption to secure the information used in path validation, where do the keys come from? The fourth post considers this question.
    • Should the information used to validate paths be distributed or stored in a somewhat centralized database?
  • Should we consider solutions that are carried within the control plane, within BGP itself, or outside?
  • What is it we can actually prove in a packet switched network? This is considered in post 2 and post 3.

Here I’m going to discuss the problem of a centralized versus distributed database to carry the Continue reading

Giveaway: Navigating Network Complexity

netcomplexI have one remaining copy of my latest book from the initial ten Addison-Wesley sent me on publication… What I’ve decided to do is sign it and give it away to one of my readers. What’s the catch? There are actually two.

First, you have to go to the contact form and leave me feedback with three design concepts (or other interesting things) you’d like to see me write about on this blog. I won’t do “how to configure” type articles, as I think there’s enough of that around on the ‘web. It’s useful stuff, but it’s not my “thing.”

Second, I can’t ship this thing out of the US.

I’ll ship the book, after I’ve signed it, to the person with the three best questions.

LinkedInTwitterGoogle+FacebookPinterest

The post Giveaway: Navigating Network Complexity appeared first on 'net work.

Reaction: More Encryption is Bad?

This week I was peacefully reading the March 9th issue of ACM Queue when I received a bit of a surprise. It seems someone actually buys the “blame the victim” game, arguing that governments are going to break all encryption if we don’t give them what they want.

These ideas are all based on the same principle: If we cannot break the crypto for a specific criminal on demand, we will preemptively break it for everybody. And whatever you may feel about politicians, they do have the legitimacy and power to do so. They have the constitutions, legislative powers, courts of law, and police forces to make this happen. The IT and networking communities overlooked a wise saying from soldiers and police officers: “Make sure the other side has an easier way out than destroying you.” But we didn’t, and they are.

reaction-3If you don’t get the point, it’s simple: the only way to really have secure communications is to give the government the keys. Once again, my inner philosopher threw up (as I recently said on a Network Break podcast). The reason I find the line of argument above so horrifying is simple: it’s just true enough to Continue reading

The Design Mindset (1)

How does a network designer, well, actually design something? What process do you use as a designer to get from initial contact with a problem to building a new design to deploying a solution? What is the design mindset? I’ve been asking myself just this question these last few months, going through old documentation to see if I can find a pattern in my own thinking that I could outline in a way that’s more definite than just “follow my example.” What I discovered is my old friends the OODA loop and the complexity model are often in operation.

So, forthwith, a way to grab hold of a designer mindset, played out in an unknown number of posts.

Begin with observe. Observation is the step we often skip, because we’ve either worked on the network for so long “we don’t need to,” or we’re “so experienced we know what to look for.” This is dangerous. Let me give you an example.

ooda-complexityA long time ago, in a small shire on the borders of reality (it seems now), I worked on a piece of equipment we called the funnyman. Specifically, this was the FNM-1, which was used to detect runway Continue reading

Research ‘net: The TEMPEST edition

When I was in the US Air Force, as part of the 438th Communications Group, we had a Group Readiness Center that contained a large board with the airfield equipment status, a safe with various drawers with different classification levels, a couple of encrypted communication systems, and… a couple of strange looking Z200 computers. The screen on these computers were covered with a fine mesh, and the power cables ran through a special cleaning box. What was the point of all this fanciness?research-net

TEMPEST. The ability to gather information about what’s on a computer’s screen by examining the signals transmitted (unintentionally) from the monitor screen, power cable, and other electronics. This might seem odd, but essentially any wire is an antenna that can (and will) carry information from a computer; at some range, these signals can be detected and deciphered in a way that allows you to determine what the computer is processing. Screens are more fruitful, as the older style Cathode Ray Tube (CRT) displays essentially shoot a stream of electrons onto a piece of glass, some of which must leak, and hence can be picked up and decoded to see what’s on the screen from quite a distance Continue reading

Slicing and Dicing Flooding Domains (2)

The first post in this series is here.

Finally, let’s consider the first issue, the SPF run time. First, if you’ve been keeping track of the SPF run time in several locations throughout your network (you have been, right? Right?!? This should be a regular part of your documentation!), then you’ll know when there’s a big jump. But a big jump without a big change in some corresponding network design parameter (size of the network, etc.), isn’t a good reason to break up a flooding domain. Rather, it’s a good reason to go find out why the SPF run time changed, which means a good session of troubleshooting what’s probably an esoteric problem someplace.

Assume, however, that we’re not talking about a big jump. Rather, the SPF run time has been increasing over time, or you’re just looking at a particular network without any past history. My rule of thumb is to start really asking questions when the SPF run time gets to around 100ms. I don’t know where that number came from—it’s a “seat of the pants thing,” I suppose. Most networks today seem to run SPF in less than 10ms, though I’ve seen a few that Continue reading

Reaction: BGP convergence, divergence & the ‘net

Let’s have a little talk about BGP convergence.

We tend to make a number of assumptions about the Internet, and sometimes these assumptions don’t always stand up to critical analysis. . . . On the Internet anyone can communicate with anyone else – right? -via APNIC

Geoff Huston’s recent article on the reality of Internet connectivity—no, everyone cannot connect to everyone—prompted a range of reactions from various folks I know.

For instance, BGP is broken! After all, any routing protocol that can’t provide basic reachability to every attached destination must be broken, right? The problem with this statement is it assumes BGP is, at core, a routing protocol. To set the record straight, BGP is not, at heart, a routing protocol in the traditional sense of the term. BGP is a system used to describe bilateral peering arrangements between independent parties in a way that provides loop free reachability information. The primary focus of BGP is not loop free reachability, but policy.

After all, BGP convergence is a big deal, right? Part of the problem here is that we use BGP as a routing protocol in some situations (for instance, on data center fabrics), so we have a hard time adjusting our thinking Continue reading