Post-quantum cryptography (algorithms resistant to quantum computer attacks) is quickly turning into another steaming pile of hype vigorously explored by various security vendors.

Christoph Jaggi made it his task to debunk at least some of the worst hype, collected information from people implementing real-life solutions in this domain, and wrote an excellent overview article explaining the potential threats, solutions, and current state-of-the art.

You (RFC 6919) OUGHT TO read his article before facing the first vendor presentation on the topic.

The mission of ipSpace.net is very simple: explain new networking technologies and products in a no-nonsense marketing-free and hopefully understandable way.

Sometimes we’re probably way off the mark, but every now and then we get it just right as evidenced by this feedback from one of our subscribers:

I was given short notice to present a board-level overview of VMWare NSX-T for an urgent virtualization platform change from Microsoft. Tech execs needed to understand NSX-T’s position in the market, in its product lifecycle, feature advantages, possible feature deficits, and an idea of the level of effort for implementation.

Got this interesting question from one of my readers

Based on my experience, the documentation regarding Linux networking is either elementary man pages for user-space utilities or very complicated Linux kernel source code. Does getting deep into Linux networking mean reading source code?

It all depends on how deep you plan to go:

Russ White published an interesting story explaining why we’re using IP and not CLNS to build today’s Internet.

Let’s start with a few minor details he missed that I feel obliged to point out (apologies to Russ for being too pedantic, but you know me…):

In one of his recent blog posts Tom Hollingsworth described what I semi-consciously felt about the CCIE lab exam for at least 25 years: it’s full of contrived scenarios that look more like Iron Chef than real life.

I understand they had to make the lab harder and harder to stop cheating (because talking with candidates and flunking the incompetents is obviously not an option), and there’s only so much one can do with a limited set of technologies… but forcing networking engineers to find ever-more-devious ways to solve overly-complex problems is nothing else but fuel for rampant MacGyverism.

Anyway, I don’t think this mess will ever be fixed, so the only thing we can do is to enjoy the rant.

If you’re working solely with IP-based networks, you’re likely assuming that hop-by-hop destination-only forwarding is the only packet forwarding paradigm that makes sense. That is not true; even today’s networks use a variety of forwarding mechanisms, most of them called some variant of routing or switching.

What exactly is the difference between the two, and what is bridging? I’m answering these questions (and a few others, like what’s the difference between data-, control- and management planes) in the Bridging, Routing, and Switching Terminology video.

In March I explained why it’s unrealistic to expect to use machine learning to solve unknown problems in today’s snowflake networks… but are there other problems that could be solved?

Here’s an idea Paul Greenberg pointed me to: machine learning on public DNS data. Let’s see whether it might make sense:

Peter Welcher identified the biggest network security hurdle faced by most enterprise IT environments in his comment to Considerations for Host-based Firewalls (Part 1) blog post:

I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.

His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:

Getting Docker to work with IPv6 is an interesting and under-documented (trying to stay diplomatic) adventure, but there’s a shortcut to the promised land: even if your Docker environment is pure IPv4 morass, you can still reach published container ports over IPv6 thanks to the userland proxy I described last week. The performance is obviously commensurate with traversing kernel-user boundary too many times.

New to this rabbit hole? Start here.

Finally, you don’t have to tell me (again) that Docker is dead and we should all use K8s. It’s as useful as telling me CloudStack is dead and we should all use OpenStack. Different challenges deserve different tools.

Remember my rants about VMware and firewall vendors promoting crazy solutions that work best in PowerPoint and cause more headaches than anything else (excluding increased vendor margins and sales team bonuses, of course)?

Here’s another we-don’t-need-all-that-complexity real-life story coming from one of my long-term subscribers: