Author Archives: Russ
Author Archives: Russ
But when designing underlying cyber protections, too many architects are taking zero trust to be the primary objective. This is a misinterpretation. In the first instance, we should look to protect our resources from attack. What zero trust reminds us is that we are fallible, and that we should put in place backup plans in the form of monitoring and incident response for the (hopefully rare) cases where our protection Continue reading
Have you ever tried to make water flow in a specific direction? Maybe you have some particularly muddy spot in your yard, so you dig a small ditch and think, “the water will now flow from here to there, and the muddy spot won’t be so muddy the next time it rains.” Then it rains, and the water goes a completely different direction, or overflows the little channel you’ve dug, making things worse. The most effective way to channel water, of course, is to put it in pipes—but this doesn’t always seem to work, either.
The next time you think about shadow IT in your organization, think of these pipes, and how the entire system of IT must look to a user in your organization. For instance, I have had corporate laptops where you must enter two or three passwords to boot the laptop, provided by departments that require you to use your corporate laptop for everything, and with security rules forbidding the use of any personal software on the corporate laptop. I have even had company issued laptops on which you could not modify the position of icons on the desktop, change the menu items in any piece Continue reading
Mark Kosters joins Donald and I to talk about the history of the whois system.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
We often use metaphors to describe a particular part of a thing or the thing itself. For instance, we might say “I’m as hungry as a horse,” to describe how much we think we could eat (although a more appropriate saying might be “as hungry as a bird,” as it turns out!). Network operators and engineers are no exception to this making of metaphors, of course.
Metaphors have a reductionistic tendency. For instance, when saying I am as hungry as a horse, I am relating the amount of food a horse might eat to the amount of food I feel like eating. The metaphor reduces the entire person and the entire horse so the turn on a single point—a quantity of food. In using this kind of comparison, I am not claiming to have the same number of legs as a horse, or perhaps a swishing tail like a horse.
The danger in using a metaphor is that you can take the part to be the whole. When this happens, the metaphor says things it should not say, and can cause us to misunderstand the scope, complexity, or solution to a problem. For some reason, we tend to do Continue reading
Your job search can feel like a movie you’ve seen over and over. The same thing seems to happen every time. You get motivated to finally start looking for a new job. You hunt around the internet and make a list of intriguing jobs. You start imagining yourself getting out of your current job. You start applying, there’s progress, you get some call backs, maybe you even go on-site to interview a few times. There’s a Continue reading
As long-standing contributor to open standards, and someone trying to become more involved in the open source world (I really need to find an extra ten hours a day!), I am always thinking about these ecosystems, and how the relate to the network engineering world. This article on RedisDB, and in particular this quote, caught my attention—
The point of the article is a lot of companies that support open source projects, like RedisDB, are moving to a more closed source solutions to survive. The cloud providers are called out as a source of a lot of problems in this article, as they consume a lot of open source software, but do not really spend a lot of time or effort in supporting it. Open source, in this situation, becomes a sort of tragedy of the commons, where everyone things someone else is going to do the Continue reading
Several things of note for the near future.
As of today, I have moved into a role at Juniper networks. You will probably hear more about what I am working on over time, both here and there, and probably other places as well.
I hope to be changing platforms from WordPress to Craft in the spring; work is currently underway. This will likely mean some things about the design of this site will change; others will remain the same. Content wise, I am going to continue highlighting interesting research, soft skills, and networking technologies, but I will be trying to focus a bit more on disaggregation in all of these areas, rather than just floating around all over the place.
More as 2019 develops.
I’m teaching a three hour webinar on network complexity on the 8th of February through Safari Books Online. This will likely be the last time I run this course over on the Safari side of things; I’m considering redoing it as a udemy course at some point, or something similar.
Much like most other problems in technology, securing the reachability (routing) information in the internet core as much or more of a people problem than it is a technology problem. While BGP security can never be perfect (in an imperfect world, the quest for perfection is often the cause of a good solution’s failure), there are several solutions which could be used to provide the information network operators need to determine if they can trust a particular piece of routing information or not. For instance, graph overlays for path validation, or the RPKI system for origin validation. Solving the technical problem, however, only carries us a small way towards “solving the problem.”
One of the many ramifications of deploying a new system—one we do not often think about from a purely technology perspective—is the legal ramifications. Assume, for a moment, that some authority were to publicly validate that some address, such as 2001:db8:3e8:1210::/64, belongs to a particular entity, say bigbank, and that the AS number of this same entity is 65000. On receiving an update from a BGP peer, if you note the route to x:1210::/64 ends in AS 65000, you might think you are safe in using this Continue reading