Author Archives: Russ
Author Archives: Russ
The post Worth Reading: Dyn’s DDoS Reveals IoT Weak Points appeared first on 'net work.
Just in time for Hallo’ween, the lucky thirteenth post in the BGP code dive series. In this series, we’re working through the Snaproute Go implementation of BGP just to see how a production, open source BGP implementation really works. Along the way, we’re learning something about how larger, more complex projects are structured, and also something about the Go programming language. The entire series can be found on the series page.
In the last post in this series, we left off with our newly established peer just sitting there sending and receiving keepalives. But BGP peers are not designed just to exchange random traffic, they’re actually designed to exchange reachability and topology information about the network. BGP carries routing information in updated, which are actually complicated containers for a lot of different kinds of reachability information. In BGP, a reachable destination is called an NLRI, or Network Layer Reachability Information. Starting with this code dive, we’re going to look at how the snaproute BGP implementation processes updates, sorting out NLRIs, etc.
When you’re reading through code, whether looking for a better understanding of an implementation, a better understanding of a protocol, or even to figure out “what went wrong” on Continue reading
The post Worth Reading: The Internet Needs a Security Upgrade appeared first on 'net work.
The post Worth Reading: The Facebook Wedge 100 appeared first on 'net work.
Ethan pointed me to this post about complexity and incremental improvement in a slack message. There are some interesting things here, leading me in a number of different directions, that might be worth your reading time. The post begins with an explanation of what the author calls “Keith’s law”—
The author attributes this to the property of emergence; given I don’t believe in blind emergence, I would attribute this effect to the combined intertwining of many intelligent actors producing an effect that at least many of them probably wanted (the improvement of the complex system), and each of them working in their own spheres to achieve that result without realizing the overall multiplier effect of their individual actions. If that was too long and complicated, perhaps this is shorter and better—
The law of Continue reading
The post Worth Reading: IoT devices and DDoS attacks appeared first on 'net work.
The post Worth Reading: The need for loud cyber weapons appeared first on 'net work.
The post Worth Reading: The hidden world of news cameras appeared first on 'net work.
The post Worth Reading: IPv6 and the DNS appeared first on 'net work.
Over at TechBeacon, my friend Chris Romeo has an article up about DevOps and security. It’s interesting to me because this is actually an area I’d never thought about before, even though it makes sense. Given DevOps is essentially writing software to control infrastructure (like routers, compute, and storage), and software needs to be written in a way that is secure, then it should be obvious that DevOps software should be developed with good security principles gleaned from software development as part of the foundation.
And here we face a challenge, as Chris says—
The key point in here is that every organization is doing things their own way. This isn’t wrong, of course, because every organization must have some “snowflakiness” to justify its existence, and that “snowflakiness” is often likely to show up, in a large way, in something like handling resources within Continue reading
The post Worth Reading: Microsoft and FPGAs appeared first on 'net work.
The post Worth Reading: Some notes on today’s DDoS appeared first on 'net work.
In our last post, we looked at how I2RS is useful for managing elephant flows on a data center fabric. In this post, I want to cover a use case for I2RS that is outside the data center, along the network edge—remote triggered black holes (RTBH). Rather than looking directly at the I2RS use case, however, it’s better to begin by looking at the process for creating, and triggering, RTBH using “plain” BGP. Assume we have the small network illustrated below—
In this network, we’d like to be able to trigger B and C to drop traffic sourced from 2001:db8:3e8:101::/64 inbound into our network (the cloudy part). To do this, we need a triggering router—we’ll use A—and some configuration on the two edge routers—B and C. We’ll assume B and C have up and running eBGP sessions to D and E, which are located in another AS. We’ll begin with the edge devices, as the configuration on these devices provides the setup for the trigger. On B and C, we must configure—
The post Worth Reading: Hack Cameras, DVRs, and DDoS appeared first on 'net work.
The post Worth Reading: Facebook’s video views appeared first on 'net work.