Skip to content

SYSTEM Cited by 1 source

Palo Alto Networks IPsec

What

Palo Alto Networks (PANW) is a major enterprise network-security vendor whose PA-Series firewalls and Prisma SD-WAN appliances implement IPsec as a standard branch-connector / VPN capability.

On the sysdesign-wiki, PANW's IPsec implementation appears as the canonical non-interoperable case for Cloudflare's 2026-04-30 post-quantum IPsec GA — the concrete example of ciphersuite bloat that the standards- convergence-over-vendor-extension pattern warns against.

(Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The non-interop story

Cloudflare's explicit framing in the 2026-04-30 IPsec PQ GA post:

"Cloudflare IPsec does not yet interoperate with Palo Alto Networks' RFC 9370–based implementation, because it was launched before draft-ietf-ipsecme-ikev2-mlkem was available." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The chain of events:

  1. RFC 9370 (2023) opened the door to PQ key-exchange in IPsec, allowing up to seven additional key exchanges in parallel with classical DH. RFC 9370 did not specify which ciphersuites should be used.
  2. PANW shipped an early RFC 9370-based PQ IPsec implementation using vendor-chosen ciphersuites, some of which are not NIST-standardised.
  3. draft-ietf-ipsecme-ikev2-mlkem (late 2025) later named hybrid ML-KEM as the canonical PQ ciphersuite to use inside RFC 9370's mechanism.
  4. Cloudflare's 2026-04-30 GA implements the draft; PANW's earlier non-draft implementation produces empty-intersection handshake failures at PQ negotiation.

The consequence is a canonical ciphersuite-bloat case study: "this is exactly the kind of 'ciphersuite bloat' NIST SP 800 52r2 warned against."

Cloudflare's expected convergence path

Cloudflare frames the non-interop gently — as an industry convergence in progress, not a vendor conflict:

"We hope to add Palo Alto Networks to the list of interoperable post-quantum branch connectors as the industry continues to consolidate around draft-ietf-ipsecme-ikev2-mlkem."

The implicit expectation: PANW eventually ships an updated implementation aligned with the draft, and cross-vendor PQ IPsec tunnels between Cloudflare and PANW-fronted enterprise branches work. No timeline disclosed.

Why this matters as a canonical example

Enterprise customers with Palo Alto Networks branch connectors cannot currently establish PQ IPsec tunnels to Cloudflare — a real operational cost paid by Cloudflare, PANW, and the customers caught in the middle. The cost is attributable structurally to the IPsec standards community not following TLS's early-convergence blueprint.

For the wiki this is the material proof that ciphersuite bloat is not a theoretical risk — it's the actual 2026 state of enterprise PQ IPsec deployments.

Caveats

  • The 2026-04-30 Cloudflare post does not name the specific PANW ciphersuites that cause the non-interop. The post identifies that PANW shipped under RFC 9370 with vendor-specific ciphersuites, some non-NIST-standardised, but does not enumerate them.
  • PANW's own position on draft-ietf-ipsecme-ikev2-mlkem convergence is not captured in this post — PANW may have public statements or a published roadmap on when they'll support the draft; that's not in the Cloudflare GA post.
  • This page is a scoped stub focused on the non-interop case study for ciphersuite-bloat canonicalisation. Detailed PA-Series firewall architecture, Prisma SD-WAN orchestration, or non-IPsec PANW features are not covered here.
  • Framing is Cloudflare's. The RFC 9370-before-named-standard narrative is Cloudflare's reading of the IPsec community dynamics. A PANW source would presumably frame the early RFC 9370 shipping as protocol-agility leadership; the post-hoc interoperability cost is what the wiki captures from the Cloudflare side.

Seen in

Last updated · 433 distilled / 1,256 read