Author Archives: Russ
Author Archives: Russ
Over the past several weeks, there’s been a lot of talk about something called “differential privacy.” What does this mean, how does it work, and… Is it really going to be effective? The basic concept is this: the reason people can identify you, personally, from data collected off your phone, searches, web browser configuration, computer configuration, etc., is you do things just different enough from other people to create a pattern through cyber space (or rather data exhaust). Someone looking hard enough can figure out who “you” are by figuring out patterns you don’t even think about—you always install the same sorts of software/plugins, you always take the same path to work, you always make the same typing mistake, etc.
The idea behind differential security, considered here by Bruce Schneier, here, and here, is that you can inject noise into the data collection process that doesn’t impact the quality of the data for the intended use, while it does prevent any particular individual from being identified. If this nut can be cracked, it would be a major boon for online privacy—and this is a nut that deserves some serious cracking.
But I doubt it can actually be cracked Continue reading
The post Worth Reading: 60 Limit and the CCDE appeared first on 'net work.
Over at IPSpace this last week, Ivan pointed to a paper by Dijkstra (and if you don’t know who that is, you need to learn a thing or two about the history of routing protocols—because history makes culture, and culture matters—or, as the tagline on this blog says, culture eats technology for breakfast). In this paper, Dijkstra points out some rather important things about computer science and programming that can be directly applied to the network engineering world. For instance, Ivan says—
I was fascinated with Ivan’s take on this paper—particularly in that complexity is an area I find interesting and very useful in my everyday life as a designer—that I went and read the original article. You should, too.
I think Ivan’s observations are spot on, but I think it’s worthwhile to actually broaden them. From where I sit, after 25 years building and breaking networks, I agree that complexity sells—but it sells for two particular reasons. The reason, as Dijkstra said all those years ago (in computer terms), is this:
Since the Continue reading
The post Worth Reading: One-fourth of malware comes from sharing appeared first on 'net work.
I wonder how many times I’ve seen this sort of diagram across the many years I’ve been doing network design?
It’s usually held up as an example of how clever the engineer running the network is about resilience. “You see,” the diagram asserts, “I’m smart enough to purchase connectivity from two providers, rather than one.”
Can I point something out? Admittedly it might not be all that obvious from the diagram, but… Reality is just about as likely to squish your network connectivity like a bug no a windshield as it is any other network. Particularly if both of these connections are in the same regional area. The tricky part is knowing, of course, what a “regional area” might happen to mean for any particular provider.
The problem with this design is very basic, and tied to the concept of shared link risk groups. But let me start someplace a little simpler than that—with the basic, and important, point that putting fiber in the ground, and maintaining fiber that’s in the ground, is expensive. Unless you live in Greenland, fiber can be physically buried pretty easily (fiber in Greenland is generally buried with dynamite by a blasting crew, or Continue reading
The post Worth Reading: Docker meets zombies appeared first on 'net work.
The first microprocessor sold by Intel was the four-bit 4004 in 1971. It was designed to work in conjunction with three other microchips, the 4001 ROM, 4002 RAM and the 4003 Shift Register. Whereas the 4004 itself performed calculations, those other components were critical to making the processor function. -Tom’s Hardware
(Note: this is a slide show, rather than an article)
The post Worth Reading: The history of the Intel CPU appeared first on 'net work.
The post Worth Reading: Public cloud versus private data center appeared first on 'net work.
DDoS attacks, particularly for ransom—essentially, “give me some bitcoin, or we’ll attack your server(s) and bring you down,” seem to be on the rise. While ransom attacks rarely actually materialize, the threat of DDoS overall is very large, and very large scale. Financial institutions, content providers, and others regularly consume tens of gigabits of attack traffic in the normal course of operation. What can be done about stopping, or at least slowing down, these attacks?
To answer, this question, we need to start with some better idea of some of the common mechanisms used to build a DDoS attack. It’s often not effective to simply take over a bunch of computers and send traffic from them at full speed; the users, and the user’s providers, will often notice machine sending large amounts of traffic in this way. Instead, what the attacker needs is some sort of public server that can (and will) act as an amplifier. Sending this intermediate server should cause the server to send an order of a magnitude more traffic towards the attack target. Ideally, the server, or set of servers, will have almost unlimited bandwidth, and bandwidth utilization characteristics that will make the attack appear Continue reading
The post Worth Reading: The danger of macros appeared first on 'net work.
The post Worth Reading: Leaky end users appeared first on 'net work.
The post Worth Reading: Leaving fixed function switches behind appeared first on 'net work.
The post Worth Reading: The end of the hypervisor appeared first on 'net work.
As a keen observer of the network engineering world for the last twenty… okay, maybe longer, but I don’t want to sound like an old man telling stories quite yet… years, there’s one thing I’ve always found kind-of strange. We have a strong tendency towards hero worship.
I don’t really know why this might be, but I’ve seen it in Cisco TAC—the almost hushed tones around a senior engineer who “is brilliant.” I’ve seen it while sitting in a meeting in the middle of an argument over some technical point in a particular RFC. Someone says, “we should just ask the author…” Which is almost always followed by something like: “Really? You know them?”
To some degree, this is understandable—network engineering is difficult, and we should truly honor those in our world who have made a huge impact. In many other ways, it’s unhelpful, and even unhealthy. Why?
First, it tends to create an “us versus them,” atmosphere in our world. There are engineers who work on “normal” networks, and then there are those who work on, well, you know, special ones. Not everyone needs those “special skills,” so we end up creating a vast pool of people Continue reading