
Author Archives: Russ
Author Archives: Russ
The post Worth Reading: Lego Robots versus Gesture Security appeared first on 'net work.
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.
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
The post Worth Reading: Docker Launches Vulnerability Scanner appeared first on 'net work.
The post Worth Reading: Six Tips for Securing BGP appeared first on 'net work.
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
The post Worth Reading: Social Media and Monetization appeared first on 'net work.
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
I will continue updating this post as I work through the remaining segments of this series.
The post Securing BGP: A Case Study appeared first on 'net work.
The post Worth Reading: Breaches at eMail Providers appeared first on 'net work.
The post Worth Reading: SD-WAN Consolidation? appeared first on 'net work.
These are the slides from my Interop presentation this last week.
The post Slideshare: Engineer versus Complexity appeared first on 'net work.
The post Worth Reading: It’s worth learning to troubleshoot appeared first on 'net work.
OSPF and IS-IS, both link state protocols, use mechanisms that manage flooding on a broadcast link, as well as simplify the shortest path tree passing through the broadcast link. OSPF elects a Designated Router (or DR) to simplify broadcast links, and IS-IS elects a Designated Intermediate System (or DIS—a topic covered in depth in the IS-IS Livelesson I recently recorded). Beyond their being used in two different protocols, there are actually subtle differences in the operation of the two mechanisms. So what is the difference?
Before we dive into differences, let’s discuss the similarities. We’ll use the illustration below as a basis for discussion.
Q1 and Q2 illustrate the operation of a link state protocol without any optimization on a broadcast network, with Q1 showing the network, and Q2 showing the resulting shortest path tree. Q3 and Q4 illustrate link state operation with optimization over a broadcast link. It’s important to differentiate between building a shortest path tree (SPT) across the broadcast link and flooding across the broadcast link—flooding is where the primary differences lie in the handling of broadcast links in the two protocols.
Let’s consider building the SPT first. Both protocols operate roughly the same in this Continue reading
The post Worth Reading: On the Quants and the Creatives appeared first on 'net work.
The next proposed (and actually already partially operational) system on our list is the Router Public Key Infrastructure (RPKI) system, which is described in RFC7115 (and a host of additional drafts and RFCs). The RPKI systems is focused on solving a single solution: validating that the originating AS is authorized to originate a particular prefix. An example will be helpful; we’ll use the network below.
(this is a graphic pulled from a presentation, rather than one of my usual line drawings)
Assume, for a moment, that AS65002 and AS65003 both advertise the same route, 2001:db8:0:1::/64, towards AS65000. How can the receiver determine if both of these two advertisers can actually reach the destination, or only one can? And, if only one can, how can AS65000 determine which one is the “real thing?” This is where the RPKI system comes into play. A very simplified version of the process looks something like this (assuming AS650002 is the true owner of 2001:db8:0:1::/64):