The RPKI Paradox: why invalid routes keep showing up

RPKI was supposed to be the fix for one of BGP’s oldest problems: nothing stops a network from announcing someone else’s IP addresses, on purpose or by accident. More than a decade into the project, adoption numbers finally look good, and yet RPKI invalid routes haven’t gone away. Route hijacks still happen, leaks still happen, and (this is the part that surprised me when I dug into the research) the tools built to catch all this still cry wolf constantly.
Here’s the short version: RPKI did its job. It just wasn’t as big a job as everyone hoped, and thousands of invalid routes a day are proof that the story doesn’t end at “deployed.”

The good part: RPKI actually got deployed

A Route Origin Authorization (ROA) is a cryptographic statement from an IP address holder saying, “this AS, and only this AS, is allowed to originate this prefix.” Routers that check incoming announcements against ROAs sort them into three buckets (Valid, Invalid, or Not Found) through a process called Route Origin Validation (ROV).

That’s the whole mechanism. Simple in concept, it took the industry years to actually roll it out at scale. It’s happened now: a majority of Continue reading

LIU018: Why You Should Attend Tech Conferences

Alexis and Kevin talk about their experiences attending Cisco Live alongside return guest Melina Bertholf. They offer different perspectives about the event while highlighting the importance of building professional relationships and community through in-person gatherings. They also share personal anecdotes and advice for those looking to maximize their social and professional networking efforts at tech... Read more »

NVIDIA OpenShell Secures the Agent. Who Governs the Fleet?

In short: At GTC 2026, NVIDIA released OpenShell, an open source runtime that sandboxes autonomous AI agents with kernel-level policy: what files they can touch, what processes they can spawn, where their traffic can go. It is a serious piece of engineering and it validates something we have argued all year: agent security belongs in the environment, not in the prompt. But agent identity, agent-to-agent governance, and cross-sandbox communication all sit outside its scope today. This post covers what OpenShell does, where it stops by design, and three integration patterns that close the gap with Tigera Lynx.

Most attempts to control AI agents work at the model layer (alignment, system prompts) or the application layer (guardrail libraries, output filters). Both share a flaw: the thing being secured is also the thing doing the securing. A sufficiently confused or sufficiently compromised agent can talk its way past its own instructions.

OpenShell takes a different position, and it is the right one. Put the controls in the environment, where the agent cannot negotiate with them. An agent inside an OpenShell sandbox cannot leak a credential it never received, and cannot call an endpoint the kernel refuses to route.

If that argument sounds Continue reading

Content: New Parameter in Multiple something_config Ansible Modules

Last December, I wrote a pretty ranty post explaining how Ansible release 12 broke (some?) network device configuration playbooks. The inevitable anonymous troll (why are they always anonymous?) couldn’t resist asking whether I opened an issue on GitHub. I didn’t (more about that later), but when the solution to that rant was “we’re deprecating using templates in src” parameter, I opened an issue arguing why that’s not a good idea.

What happens when your VPN meets 200 AI agents

Providing secure access for your human staff is no simple task. For one, traditional VPNs often grant unnecessarily broad access, so you may have replaced that aging technology with a newer zero-trust network access (ZTNA) solution. And you may have hammered your human-centered privileged access management (PAM) tools into working order, so your engineers are just as happy as your security auditors. But what happens when you add dozens or hundreds of AI agents to the equation? We know that today’s enterprise is racing to become agentic. Or what if you want to run continuous integration (CI) and continuous deployment (CD) jobs? After all, you want a modern DevOps stack! You’ll learn quickly that the tools you built and tuned for human access come up short. Checking identity upfront isn’t enough to securely control access. You need to be able to tailor access based on need, not merely identity. And you’ll need to be able to revoke access when work is completed and provide an audit trail to boot. Even more, you don’t want to run separate access architecture for humans and agents.  To support both human and agentic network access, companies need a unified architecture that can handle Continue reading

A broken DNSSEC rollover took down .al. Now 1.1.1.1 tells you when validation is bypassed

On July 3, 2026, the Albanian communications authority (AKEP), the operator of the .al country-code top-level domain (TLD) of Albania, attempted a DNSSEC key rollover. Something went wrong, resulting in DNSSEC validation failures. Any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them and return errors to clients. That includes 1.1.1.1, the public DNS resolver operated by Cloudflare.

The .al TLD is the online home of Albanian government services, banks, and media; it ranks #191 on Cloudflare Radar's TLD ranking. Anyone trying to visit those sites, using a validating resolver, found them unreachable during the incident. The failure had the potential to affect every .al domain, regardless of where it was hosted or which authoritative nameservers served it.

Just two months earlier, a similar incident struck .de, the TLD of Germany. As we described in our blog post on the incident, our response was to install a Negative Trust Anchor (NTA) for .de, temporarily suspending DNSSEC validation in 1.1.1.1 to keep domains reachable while the registry resolved the issue. We did the same for .al.

NTAs restore resolution, but silently. A client receiving a Continue reading

Source Specific Multicast (SSM) VII

Source Specific Multicast (SSM) VII

In this post, we will look at Source Specific Multicast, or SSM. This is a different approach to multicast that simplifies the overall architecture by removing the need for an RP entirely.

In the previous posts, we covered PIM Sparse Mode, where receivers join a shared tree rooted at the RP and then optionally switch to the shortest path tree toward the source. We also looked at Auto-RP and BSR, which solve the problem of dynamically distributing RP information to all routers. SSM takes a different approach by eliminating the shared tree concept altogether.

Multicast PIM Sparse Mode
Sparse Mode only sends traffic to parts of the network that explicitly request it. Routers with interested receivers send Join messages toward

Any Source Multicast (ASM)

Before we look at SSM, let's briefly talk about Any Source Multicast, or ASM. This is the traditional multicast model we have been using throughout this series.

With ASM, receivers join a multicast group without specifying a source. They simply say 'I want traffic for group 239.1.1.1' and the network figures out how to deliver traffic from any source sending to that group. This is why it is called Any Source Multicast.

Continue reading

NB582: Infoblox Adds Network Observability with Kentik Buy; Satellite Data Centers vs. the Environment

Take a Network Break! We start with a critical vulnerability in Adobe Coldfusion. On the news front, Infoblox acquires Kentik to add network observability to its portfolio, data center electricity consumption jumps worldwide, and Exabeam rolls out AI-agent focused detection in its Agent Behavior Analytics platform. DriveNets and WhiteFiber connect two AI data centers over... Read more »