Russ

Author Archives: Russ

DR versus DIS: What’s the Diff?

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.

Broadcast network operation in link state protocols

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

Securing BGP: A Case Study (10)

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.

RPKI-Operation

(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):

  • AS65002 obtains, from the Regional Internet Registry (labeled the RIR in the diagram), a certificate showing AS65002 has been issued 2001:db8:0:1::/64.
  • AS65002 places this certificate into a local database that is synchronized with all the other operators participating in Continue reading

Basic Skills: Half Split Troubleshooting

Maybe my excuse should be that it was somewhere around two in the morning. Or maybe it was just unclear thinking, and that was that. Sgt P. and I were called out to fix the AN/FPS-77 RADAR system just at the end of our day so we’d been fighting this problem for some seven or eight hours already. For some reason, a particular fuse down in the high voltage power supply kept blowing. Given this is the circuit that fed the magnetron with 250,000 volts at around 10 amps, it made for some interesting discussion with the folks in base weather, who were thus dependent on surrounding weather RADAR systems to continue flight operations.

If this sounds familiar, I’ve told this story before in a different context, but bear with me…
basic-skills
So how did we miss the problem that actually caused the blown fuse, and hence the loss of our site’s weather RADAR system for more than a day? The reason is that it was, in fact, two in the morning, and we’d run out of ideas. If you want a sense of the complexity of the system we were working on, here is the troubleshooting guide, and here is Continue reading

Security ‘net: Privacy and Cybercrime Edition

DDoS blackmail is an increasingly common form of cybercrime, it appears. The general pattern is something like this: the administrator of a large corporate site receives an email, threatening a large scale DDoS attack unless the company deposits some amount of bitcoin in an untraceable account. Sometimes, if the company doesn’t comply, the blackmail is followed up with a small “sample attack,” and a second contact or email asking for more bitcoin than the first time.

The best reaction to these types of things is either to work with your service provider to hunker down and block the attack, or to simply ignore the threat. For instance, there has been a spate of threats from someone called Armada Collective over the last several weeks that appear to be completely empty; while threats have been reported, no action appears to have been taken.

We heard from more than 100 existing and prospective CloudFlare customers who had received the Armada Collective’s emailed threats. We’ve also compared notes with other DDoS mitigation vendors with customers that had received similar threats. -via Cloudflare

The bottom line is this: you should never pay against these threats. It’s always better to contact your provider and work Continue reading