IPSec — túneles entre sedes

Cifrar capa 3, no aplicación por aplicación

IPSec resuelve un problema distinto al de TLS y SSH. No protege "una conexión HTTP" ni "una shell": protege todo el tráfico IP que pasa entre dos extremos, sea cual sea la aplicación. Por eso vive en el kernel, no en la aplicación.

IPSec no es un protocolo, son dos: IKE (Internet Key Exchange, hoy IKEv2 — RFC 7296) que es la fase de control donde se autentican los peers y se acuerdan las claves; y ESP (Encapsulating Security Payload — RFC 4303) que es el protocolo de datos que cifra y autentica cada paquete IP. El esquema mental es: IKE habla por UDP/500 para negociar, ESP encapsula los datos en paquetes propios (protocolo IP 50).

El uso típico empresarial es tunnel mode entre dos firewalls: la sede de Madrid quiere hablar con la sucursal de Barcelona, sus firewalls levantan un túnel IPSec y todo el tráfico 10.0.0.0/8 ↔ 192.168.0.0/16 viaja cifrado por Internet como si fuera una LAN privada. El usuario en cada sede no sabe que existe — su HTTP normal va por debajo del túnel sin enterarse.

IPSec tiene dos casuísticas de cifrado distintas que conviene tener en mente: el plano de control (IKEv2, donde se hacen el handshake y se renegocian claves) y el plano de datos (ESP, donde viajan los paquetes ya cifrados). Cada uno tiene su criptografía y la migración PQC les afecta de forma distinta.

De IKEv1 al draft de ML-KEM

IPSec lleva 30 años en producción. La cronología tiene más cicatrices que la de TLS — IKEv1 fue particularmente complicado de implementar y se mantuvo demasiado tiempo en redes empresariales.

• 1995
  RFC 1825 · IPsec original
  Primera arquitectura IPSec. Sentó las bases de AH/ESP pero la gestión de claves quedó pendiente.
• 1998
  RFC 2409 · IKEv1
  Internet Key Exchange v1. Famoso por ser difícil de implementar bien. Modos main / aggressive, fases 1 y 2. Vulnerable a múltiples ataques.
• 2005
  RFC 4306 · IKEv2
  Reescritura completa. Más robusto, más simple, NAT traversal de serie. Reemplaza a IKEv1 progresivamente.
• 2014
  RFC 7296 · IKEv2 consolidado
  Versión estable y actualizada de IKEv2 que es la referencia actual. Curvas elípticas como estándar.
• 2020
  RFC 8784 · Post-quantum Preshared Keys (PPK)
  Primera respuesta a la amenaza cuántica: añadir una PSK con suficiente entropía a la derivación de claves. No es PQC real, pero protege contra harvest-now-decrypt-later si se gestiona bien.
• 2023
  RFC 9370 · Multiple Key Exchanges en IKEv2
  El framework: permite negociar hasta 7 KEMs adicionales a la DH/ECDH clásica. Es la infraestructura técnica que hace posible meter ML-KEM más adelante.
• Dic 2024
  strongSwan 6.0 · ML-KEM en producción
  Primera implementación open-source mainstream con soporte de ML-KEM vía RFC 9370. Marca el inicio real del despliegue.
• Jun 2025
  RFC 9794 · Terminología PQ/T Hybrid
  Vocabulario oficial: "Post-Quantum Traditional Hybrid". Distingue entre PQC puro y combinación con criptografía clásica.
• 2025-2026 →
  draft-ietf-ipsecme-ikev2-mlkem
  Especificación oficial de ML-KEM en IKEv2. Todavía draft (versión 05 en marzo 2026). Cloudflare anunció GA de IPSec post-cuántico interoperable con Cisco, Fortinet y strongSwan.

Lo que hoy se considera "bien hecho"

Una configuración IPSec sólida en 2026, sin meternos todavía en PQC, separa claramente las dos fases (control y datos) y elimina todo lo legacy de IKEv1.

Esto define el "bien hecho" clásico. Importante: IPSec tiene una superficie de configuración brutalmente grande comparado con TLS. Es donde más fácil es meter la pata sin darse cuenta.

Túneles que duran décadas, capturas que nunca expiran

IPSec es probablemente el caso más sangrante de harvest-now-decrypt-later. Un túnel site-to-site lleva años activo, transporta de todo (correo interno, SAP, AD, código fuente, bases de datos), y la criptografía clásica que lo protege caerá entera con Shor.

Tu túnel IPSec lleva 8 años activo. Cualquier estado-actor con acceso a un proveedor de tránsito ya tiene capturas de todo el tráfico. El día Q descifrarán también el correo de hace ocho años.

Aquí hay un agravante específico de IPSec: el plano de control (IKE) se renegocia cada pocas horas, pero la identidad de los peers (certificados X.509) puede llevar años. Si alguien falsifica una CA con Shor el día Q, puede impersonar tu firewall retroactivamente y proactivamente. Esto se solapa con el problema de las CAs internas — un agujero criptográfico que muchas empresas tienen sin saberlo, con CAs raíz emitidas en 2015 y válidas hasta 2045.

Un puente, un framework y un draft

IPSec llegó tarde a PQC respecto a TLS y SSH, pero por una vez tarde tuvo ventajas: el camino se hizo en tres pasos limpios — un puente temporal (PPK), un framework (RFC 9370), y la espec final (draft ML-KEM IKEv2).

¿Por qué IPSec llegó 4 años tarde?

Una respuesta concreta: el MTU. Las claves públicas y ciphertexts de ML-KEM son grandes — ML-KEM-1024 incluye una clave pública de 1568 bytes. El paquete UDP típico de IKE difícilmente acepta eso sin fragmentación IP, que es problemática en muchas redes (firewalls que tiran fragmentos, NAT que no reensambla bien). RFC 9370 introdujo IKE_INTERMEDIATE — rondas adicionales antes de la autenticación — específicamente para mover claves PQC con fragmentación a nivel de IKE en lugar de a nivel de IP.

TLS no tuvo este problema porque va sobre TCP y no le importa el MTU UDP. SSH tampoco. IPSec sí, y por eso necesitó tres años de trabajo IETF para resolverlo bien.

Estado real por frente

Los 6 criterios de la auditoría

Los criterios para IPSec tienen una particularidad: el escalón Hybrid-Ready tiene dos puertas distintas para llegar — vía PPK (RFC 8784) o vía multiple KEX (RFC 9370). Las dos cuentan, porque las dos protegen contra harvest-now-decrypt-later.

Mapeo a badge: 0–30 Classical · 31–55 Hybrid-Ready · 56–75 Quantum-Safe · 76–90 Q-Day Proof. La ruta práctica recomendada hoy para empresas: activar PPK donde se pueda (es config estándar, mitiga harvest-now-decrypt-later) mientras se planifica la migración a ML-KEM cuando los firewalls de producción lo soporten — Cisco, Fortinet, Palo Alto y strongSwan ya están en ello.