Site Work

I spent some time this week moving to a new theme, specifically Beaver Builder. It was a bit more work than I expected because of some serious limitations with the way Beaver Builder works—had I known about these limitations, I probably would have worked with another product, but by the time I discovered them, it was either find a way around the limitations, or spend a lot more time and/or money working through them.

In the process, I completely rebuilt the menu, and cleaned up the categories.

The site should be a good bit faster now. I’m not entirely certain the social sharing bits are working, and I will likely find a few things wrong here and there that need to be fixed over the next few weeks. I just discovered, for instance, that I lost all the work on the papers and topical pages I’d done earlier today, so those need to be redone, which will take a good bit of time.

Network Troubleshooting at Safari Books Online

I am giving my network troubleshooting class over at Safari Books Online on the 6th of December for those who are interested. I consider this a foundational session, covering the time components of an outage, a taxonomy of reactions to outages, the half-split method of searching for the root cause, and how models can help you understand the right questions to ask to narrow a problem down quickly. A lot of this course is based on formal methods of troubleshooting I learned in electronic engineering, adapted for the networking world.

This is one of three webinars I give at Safari Books on a periodic basis; I hope to be adding a fourth in the near future.

Worth Reading: SIGPIPE

There is a spectre haunting the Internet — the spectre of SIGPIPE errors. It’s a bug in the original design of Unix networking from 1981 that is perpetuated by college textbooks, which teach students to ignore it. @Errata Security

History of Networking: White Box an The Backpack

Worth Reading: BGP LLGR

However, when BFD runs in a process on top of a generic kernel, notably when running BGP on the host, it is not unexpected to loose a few BFD packets on adverse conditions: the daemon handling the BFD sessions may not get enough CPU to answer in a timely manner. —Vincent Bernat

Worth Reading: Twisted Light

new development in fibre optics could make internet speeds up to 100 times faster – by detecting light that has been twisted into a spiral. —Naaman Zhou @The Guardian

Ossification and Fragmentation: The Once and Future ‘net

Mostafa Ammar, out of Georgia Tech (not my alma mater, but many of my engineering family are alumni there), recently posted an interesting paper titled The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet. I have argued elsewhere that we are seeing the fragmentation of the global Internet into multiple smaller pieces, primarily based on the centralization of content hosting combined with the rational economic decisions of the large-scale hosting services. The paper in hand takes a slightly different path to reach the same conclusion.

 
The author begins by noting networks are designed to provide a set of services. Each design paradigm not only supports the services it was designed for, but also allows for some headroom, which allows users to deploy new, unanticipated services. Over time, as newer services are deployed, the requirements on the network Continue reading

Worth Reading: Paying for BGP security in coin

Last week I learned something about BitCoin that entirely changed my view on the urgency for implementing uniform security in the global routing system. —Leslie Daigle @thinkingcat

At Rest

Weekend Reads ‭190DA‬

By now pretty much all of online advertising is adtech, which doesn’t sponsor publishers. Instead it uses publishers to mark and track eyeballs wherever they might go. It does that by planting tracking beacons (mixed like poison blueberries into those cookies sites now require “consent” to) on readers’ browsers or phones, and then shoots the readers’ eyeballs with ads when they show up elsewhere on the Web, preferably on the cheapest possible site, so those eyeballs can be hit as often as possible within the budget the advertiser has paid adtech intermediaries. @Doc Serls Weblog

Consider, then, that most useful work relies on TCP/IP, which itself relies on the Domain Name System (DNS). We should know as much as possible about our use of the DNS, but most IT administrators are much too busy learning their specialized craft to also become experts on every enabling technology. —Paul Vixie @Dark Reading

The technology products that drive today’s businesses are increasingly produced through a highly diversified and complex international supply chain. Whether it is standard networking gear or a more specialized device like a human-machine interface or remote terminal unit, equipment is often developed through an elaborate web of OEMs, chip makers, Continue reading

Worth Reading: Spanning clouds with Kubernetes

The use of Kubernetes and other opens standards also means that enterprises can place workloads not only on IBM’s private or public clouds, but into environments of other cloud providers that conform to the container orchestration platform. —Jeffrey Burt @The Next Platform

Worth Reading: Banning Chinese phones won’t fix the supply chain problem

All of our computerized systems are deeply international, and we have no choice but to trust the companies and governments that touch those systems. And while we can ban a few specific products, services or companies, no country can isolate itself from potential foreign interference. —Bruce Schneier @The Washington Post

Worth Reading: Service providers should adapt to open source

Network operators also need to learn the ways of the open source community, and not assume that using open source software is automatically going to save money. Benefiting from open source requires a different type of investment, in time and talent, panelists said, rather than in capex dollars paid directly to vendors. —Carol Wilson @Light Reading

Imposter Syndrome

Worth Reading: Paying for the bleeding edge

It is a good thing they still want to offload responsibility to IBM, Intel, and a few others, because it is only through such vendors that there is any hope that technologies will be advanced for the bleeding edge and eventually become the leading edge for enterprises. Which is, after all, the real point of having the technology in the first place. It is for everyone to advance, not just for the upper echelon of computing in each country. —Timothy Prickett Morgan @The Next Platform

Worth Reading: BGP DFZ Security

If a certificate is published with an incorrect set of number resources then there is the possibility that its subordinate certificates cannot be validated, which, as we’ve noted has implications for the reachability of services on the Internet through the connection to the routing system. Thus, certificate issuance is not without its potential legal liabilities, and it is not unusual for certificate authorities to limit their liabilities. —Geoff Huston @CircleID

Problems and Solutions

Worth Reading: Cleaning up ROAs

As of 14 September 2018, there are more than 6,700 INVALID prefix-origin pairs (IPv4 + IPv6). But how many prefixes would actually become unreachable in a ROV environment? —Nusenu @APNIC

Worth Reading: 3 out of 4 employees are a security risk

Some 75% of respondents today pose a moderate or severe risk to their company’s data, according to MediaPRO’s third annual State of Privacy and Security Awareness Report, and 85% of finance workers show some lack of data security and privacy knowledge. —Steve Zurier @Dark Reading

Reaction: The Importance of Open APIs

Over at CIMI, Tom Nolle Considers whether the open API is a revolution, or a cynical trap. The line of argument primarily relates to accessing functions in a Virtual Network Function (VNF), which is then related to Network Function Virtualization (NFV). The broader point is made in this line:

One important truth about an API is that it effectively imposes a structure on the software on either side of it. If you design APIs to join two functional blocks in a diagram of an application, it’s likely that the API will impose those blocks on the designer.

This is true—if you design the API first, it will necessarily impose information flow between the different system components, and even determine, at least to some degree, the structure of the software modules on either side of the API. For instance, if you decide to deploy a single network appliance vendor, then your flow of building packet filters will be similar across all devices. However, if you add a second vendor into the mix, you might find the way packet filters are described and deployed are completely different, requiring a per-device module that moves from intent to implementation.

While this problem will always Continue reading