Weekend Reads 071318: Nice to Haves

I had about four hours of highway driving yesterday. Even though I probably could’ve navigated it on my own, I opted to use Apple Maps, which is integrated with my car’s Apple CarPlay “infotainment center.” It was nice. It told me how many miles I had remaining and my expected time of arrival. But it wasn’t a life changer. @The Old Reader

More than ever before Internet users are now interacting with people living/working in other economies. And as a result of these interactions, there are an increasing number of ‘legal contracts’ (intentional or not). Internet policy researchers and academics debate about the changing landscape and the boundaries of the international and domestic laws, without conclusive agreements. —Yeseul Kim @APNIC

The plague that is Spectre continues to evolve and adapt, showing up in two new variants this week dubbed Spectre 1.1 and Spectre 1.2 that follow the original Spectre’s playbook while expanding on the ways they can do damage. —Curtis Franklin Jr. @Dark Reading

These vast routing events that are propagated globally already provide a hint that some ISPs do not set filters at all, or there are vastly malformed AS-SETs. We decided to measure the number of filters that were already bypassed by routing anomalies. To do so, we checked the way route leaks were propagated: if a route leak is received from a customer link and it does not belong to the customer cone then IRR filters were malformed. —Alexander Azimov @APNIC

Recently, a CEO of a roaring unicorn in Silicon Valley drew my attention to the following: “If you compare Amazon’s stock price over the recent years against the cost of housing and the rise of homelessness in Seattle, the progression is identical…” —Frederic Filloux @MondayNote

Why do many problems in life seem to stubbornly stick around, no matter how hard people work to fix them? It turns out that a quirk in the way human brains process information means that when something becomes rare, we sometimes see it in more places than ever. —David Levari @The Conversation

Two web-based attacks against IoT devices made the rounds this week. Researchers Craig Young and Brannon Dorsey showed that a well known attack technique called “DNS rebinding” can be used to control your smart thermostat, detect your home address or extract unique identifiers from your IoT devices. —Gunes Acar

Reaction: Some Sayings that Sum Up Networking

Over at the CIMI blog, Tom Nolle has a mixed bag of sayings and thoughts about the computer networking world, in particular how it relates to the media. Some of these were interesting enough that they seemed worth highlighting and writing a bit more on.

“News” means “novelty”, not “truth”. In much of the computer networking world, news is what sells products, rather than business need. In turn, Novelty is what drives the news. The “straight line” connection, then is from novelty to news to product, and product manufacturers know this. This is not just a vendor driven problem, however; this is also driven by recruitment, and padding resumes, and many other facets of the networking nerd culture.

On the other hand, novelty is never a good starting place for network design. Rather, network design needs to start with problems that need to be solved, proceeds by considering how those problems can be solved with technologies, then builds requirements based on the problems and technologies, and finally considers which products can be used to implement all of this at the lowest long term cost. This is not to say novelty is not useful, or is not justified, but rather that novelty is not the point.

How can you overcome the drive to novelty through the news cycle? Go back to basics. Every “novel” thing you are looking at in the latest news story is something that has been invented and implemented before in a different package, and with a different name. Apply rule 11 liberally to all marketing claims, look for the problem to be solved, push back on the requirements, think systemically, manage your own expectations, and go back to basics.

To a user, “the network” is whatever isn’t on their desk or in their device. This is a point folks who work on the network for a living often forget. Talking to a non-networking person about networking technology is often like talking to someone who commutes on the train about how the train works; it might be interesting, but they often just do not care. There are several implications here: the first is that if your business relies on the network (and most do, whether or not they realize it), as the network engineer, you need to go beyond just making the train work, to helping others understand that why and how the network (the train) runs is important to reaching the overall business goals. There is an entire movement within the networking world that would say: “networks are a commodity, just like the train is, just move the packets and shut up.” I do not tend to agree with this; for a city, a train is not a commodity, it is a vital resource that grows business and interacts with people’s lives. The network is like the train to a city; it might be a commodity for the person riding it, but it is not for the overall business.

There’s no substitute for knowing what you’re doing. But what does it mean to “know what you are doing?” In a large complex system, you can know what is on “your layer,” or “your piece of the system,” plus one or two levels above and below. The rest is rumor and pop psychology.

In a world where there is just too much information, how can you “know what you are doing?” First, you can use rule 11 to your advantage, and realize that everything that is, has been before. If you know the underlying technology, then the implementation is much easier to learn (if you need to learn it at all!). If you know the pattern, then you can see the details much more easily. Second, you can insist on radical simplicity, which will make the process of knowing the entire system much easier. Third, you can intentionally think systematically, and functionally, rather than orienting yourself to products.


July 2018

The Protocol Series: MPLS Part 2

In this community roundtable over at the Network Collective, Jordan, Eyvonne, Nick, and I discuss some interesting use cases for

June 2018