Author Archives: Russ
Author Archives: Russ
Fear sells. Fear of missing out, fear of being an imposter, fear of crime, fear of injury, fear of sickness … we can all think of times when people we know (or worse, a people in the throes of madness of crowds) have made really bad decisions because they were afraid of something. Bruce Schneier has documented this a number of times. For instance: “it’s smart politics to exaggerate terrorist threats” and “fear makes people deferential, docile, and distrustful, and both politicians and marketers have learned to take advantage of this.” Here is a paper comparing the risk of death in a bathtub to death because of a terrorist attack—bathtubs win.
But while fear sells, the desire to appear unafraid also sells—and it conditions people’s behavior much more than we might think. For instance, we often say of surveillance “if you have done nothing wrong, you have nothing to hide”—a bit of meaningless bravado. What does this latter attitude—“I don’t have anything to worry about”—cause in terms of security?
Several attempts at researching this phenomenon have come to the same conclusion: average users will often intentionally not use things they see someone they perceive as paranoid using. Continue reading
The NSFNET followed the CSNET, connecting the campuses of several colleges and supercomputing systems with a 56K core in 1986. The NSFNET was the first large-scale implementation of Internet technologies in a complex environment of many independently operated networks, and forced the Internet community to iron out technical issues arising from the rapidly increasing number of computers and address many practical details of operations, management and conformance. The NSF eventually became the “seed” of the commercialized core of the Internet, playing an outsized role in the current design of routing, transport, and other Internet technologies.
In this episode of the History of Networking, Dennis Jennings joins Donald Sharp and Russ White to discuss the origins and operation of the NSFNET.
You can find out more about Dennis and the NSFNET in the following links.
https://internethalloffame.org/inductees/dennis-jennings
https://en.wikipedia.org/wiki/National_Science_Foundation_Network
https://www.nsf.gov/news/news_summ.jsp?cntn_id=103050
http://arvidc.weebly.com/nsfnet.html
It’s easy to assume automation can solve anything and that it’s cheap to deploy—that there are a lot of upsides to automation, and no downsides. In this episode of the Hedge, Terry Slattery joins Tom Ammon and Russ White to discuss something we don’t often talk about, the Return on Investment (ROI) of automation.
I cannot count the number of times I’ve heard someone ask these two questions—
While these questions have always bothered me, I could never really put my finger on why. I ran across a journal article recently that helped me understand a bit better. The root of the problem is this—what does best common mean, and how can following the best common produce a set of actions you can be confident will solve your problem?
Bellman and Oorschot say best common practice can mean this is widely implemented. The thinking seems to run something like this: the crowd’s collective wisdom will probably be better than my thinking… more sets of eyes will make for wiser or better decisions. Anyone who has studied the madness of crowds will immediately recognize the folly of this kind of state. Just because a lot of people agree it’s a good idea to jump off a cliff does not mean it is, in fact, a good idea to jump off a cliff.
Perhaps it means something closer to this is no worse than our competitors. If that’s the meaning, though, it’s a pretty cynical Continue reading
Many engineers just assume that secure hardware boot is, in fact, secure. How does this security work, and just how secure is it, though? David Brown joins Tom Ammon, Eyvonne Sharp, and Russ White on this episode of the Hedge to discuss the secure boot loader in some detail. For more information on the secure boot loader and IoT, see David’s presentation at the Open Source Summit.
Last week I began discussing why AS Path Prepend doesn’t always affect traffic the way we think it will. Two other observations from the research paper I’m working off of are:
A slightly more complex network will help explain these two observations.
Assume AS65000 would like to control the inbound path for 100::/64. I’ve added a link between AS65001 and 65002 here, but we will still find prepending a single AS to the path won’t make much difference in the path used to reach 100::/64. Why?
Because most providers will have a local policy configured—using local preference—that causes them to choose any available customer connection over other paths. AS65001, on receiving the route to 100::/64 from AS65000, will set the local preference so it will prefer this route over any other route, including the one learned from AS65002. So while the cause is a little different in this case than the situation covered in the first post, the result is the Continue reading
Apple’s long-awaited privacy update for iOS is out, and it’s a solid step in the right direction.
One skill he focuses on is abduction, which was Sherlock Holmes’s favorite method.
Yesterday, The Epoch Times reported on leaked internal Chinese government documents revealing Continue reading
All good parties come to an end, and the one that Intel has enjoyed for an unbelievable dozen years, starting with the rollout of the “Nehalem” Xeon E5500 processors back in March 2009, is over. Find the Advil, grab a glass of water, and try not to drop all the pills Continue reading
Network engineers tend to look at the world through the lens of a single device—an individual appliance, sold by a vendor, with a well-developed CLI for configuration and maintenance. Networks, however, are the “odd person out” in the world of information technology. In the broader technology world, a stronger systems-oriented view is more common. In this episode of the Hedge, Bruce Davie joins Tom Ammon and Russ White to discuss a systems view of the world, as well as a new publishing model he’s working on, and some thoughts on the place of SDN.
You can find Bruce’s book, Computer Networks: A Systems Approach, here.
I’m a bit late posting this … but this Thursday (an odd day for me) I’m running How the Internet Really Works, Part 1, over at Safari Books Online. From the page:
You can register for the training at the link above. I’ll be giving part 2 of How the Internet Really Works next month.
Just about everyone prepends AS’ to shift inbound traffic from one provider to another—but does this really work? First, a short review on prepending, and then a look at some recent research in this area.
What is prepending meant to do?
Looking at this network diagram, the idea is for AS6500 (each router is in its own AS) to steer traffic through AS65001, rather than AS65002, for 100::/64. The most common method to trying to accomplish this is AS65000 can prepend its own AS number on the AS Path Multiple times. Increasing the length of the AS Path will, in theory, cause a route to be less preferred.
In this case, suppose AS65000 prepends its own AS number on the AS Path once before advertising the route towards AS65001, and not towards AS65002. Assuming there is no link between AS65001 and AS65002, what would we expect to happen? What we would expect is AS65001 will receive one route towards 100::/64 with an AS Path of 2 and use this route. AS65002 will, likewise, receive one route towards 100::/64 with an AS Path of 1 and use this route.
AS65003, however, will receive two routes towards 100::/64, one with an AS Continue reading
Intentionally poisoning BGP routes in the Default-Free Zone (DFZ) would always be a bad thing, right? Actually, this is a fairly common method to steer traffic flows away from and through specific autonomous systems. How does this work, how common is it, and who does this? Jared Smith joins us on this episode of the Hedge to discuss the technique, and his research into how frequently it is used.
Recent research into the text of RFCs versus the security of the protocols described came to this conclusion—
This should come as no surprise to network engineers—after all, complexity is the enemy of security. Beyond the novel ways the authors use to understand the shape of the world of RFCs (you should really read the paper; it’s really interesting), this desire to increase security by decreasing the ambiguity of specifications is fascinating. We often think that writing better specifications requires having better requirements, but down this path only lies despair.
Better requirements are the one thing a network engineer can never really hope for.
It’s not just that networks are often used as a sort of “complexity sink,” the place where every hard problem goes to be solved. It’s also the uncertainty of the environment in which the network must operate. What new application will be stuffed on top of the network this week? Will anyone tell the network folks about this new application, or just open a ticket when it doesn’t work right? What about all Continue reading
QUIC is a middle-aged protocol at this point—it’s several years old, and widely deployed although TCP still dominates the transport layer of the Internet. In this episode of the Hedge, Jana Iyengar joins Alvaro Retana and Russ White to discuss the motivation for developing QUIC, and its ongoing development and deployment.
One of the big movements in the networking world is disaggregation—splitting the control plane and other applications that make the network “go” from the hardware and the network operating system. This is, in fact, one of the movements I’ve been arguing in favor of for many years—and I’m not about to change my perspective on the topic. There are many different arguments in favor of breaking the software from the hardware. The arguments for splitting hardware from software and componentizing software are so strong that much of the 5G transition also involves the open RAN, which is a disaggregated stack for edge radio networks.
If you’ve been following my work for any amount of time, you know what comes next: If you haven’t found the tradeoffs, you haven’t looked hard enough.
This article on hardening Linux (you should go read it, I’ll wait ’til you get back) exposes some of the complexities and tradeoffs involved in disaggregation in the area of security. Some further thoughts on hardening Linux here, as well. Two points.
First, disaggregation has serious advantages, but disaggregation is also hard work. With a commercial implementation you wouldn’t necessarily think about these kinds of supply chain issues. Continue reading