QUIC acelera dos tipos de clave en IKEv2, pero las claves enormes siguen dando problemas
Embedding Large PQC KEMs in IKEv2 · arXiv:2610.32356
En palabras sencillas
IKEv2 es un protocolo que establece conexiones de red seguras, pero no puede dividir el primer mensaje de su proceso de conexión. Algunas claves poscuánticas son demasiado grandes para caber fácilmente en ese mensaje. El artículo revisa propuestas e introduce tres enfoques, entre ellos el uso de QUIC, una forma fiable de transportar los mensajes de conexión. En las pruebas, el enfoque combinado con QUIC tuvo el menor tiempo medio de conexión para dos de los tres tipos de clave evaluados. Con las claves más grandes, todos los enfoques tuvieron dificultades en redes problemáticas.
La investigación
¿Cómo puede IKEv2 transportar datos de clave poscuántica grandes si no puede fragmentar su primer intercambio a nivel del protocolo? La respuesta importa porque el tamaño de las claves varía mucho y la latencia, el ancho de banda y la pérdida de paquetes pueden determinar si el intercambio termina rápido o provoca congestión.
Los autores revisan propuestas del IETF, añaden tres enfoques de protocolo y comparan cómo transportan claves poscuánticas en redes difíciles.
La pregunta central es cómo puede IKEv2 transportar datos de clave poscuántica grandes cuando su primer intercambio no puede usar la fragmentación del protocolo, sobre todo en enlaces lentos o con pérdidas.
Los autores revisan propuestas del IETF, añaden tres enfoques y comparan su rendimiento y resistencia bajo condiciones de red simuladas.
En las pruebas con ML-KEM y FrodoKEM, el enfoque combinado con QUIC tuvo el menor tiempo medio de negociación entre los evaluados. Esos promedios reúnen los resultados medios de cada configuración entre anchos de banda y latencias para cada nivel de pérdida.
Sin embargo, con claves de Classic McEliece, todos los enfoques tardaban en promedio más de un minuto por negociación o congestionaban la red a medida que empeoraban las condiciones.
Las pruebas usaron autenticación con claves precompartidas estáticas y pérdidas de paquetes aleatorias y dispersas. No miden el tráfico adicional de las firmas y las cadenas de certificados ni muestran cómo funcionan los enfoques cuando las pérdidas se producen en ráfagas.
Qué muestran las pruebas
- El problema de intercambiar claves grandes
El artículo combina una revisión sistemática de las propuestas del IETF para intercambios de claves poscuánticas en IKEv2, tres nuevos enfoques de protocolo y una evaluación comparativa. IKEv2 no puede usar su propio mecanismo de fragmentación en el primer intercambio, que es donde quizá deban transmitirse datos de clave grandes.
Los autores preguntan cómo manejan esa limitación los distintos enfoques en condiciones de red difíciles.
- Tres formas de transportar las claves
Los nuevos enfoques modifican cómo se transportan los mensajes de negociación. Uno añade datos redundantes a los mensajes UDP para ayudar a recuperarse de las pérdidas. Dos usan QUIC, un transporte fiable, para llevar los mensajes de negociación de IKEv2; uno de ellos combina las partes de clave clásica y poscuántica en un solo intercambio. Estos diseños se comparan con las propuestas identificadas en la revisión del IETF.
- Un enfoque destaca para las claves más pequeñas
Los autores midieron 1,296 configuraciones que variaban el tipo de clave, la latencia, el ancho de banda y la pérdida de paquetes, mientras mantenían fijo el reordenamiento. El controlador de pruebas ejecutó 126,500 negociaciones entre dos equipos Linux conectados, con condiciones de red simuladas.
Para ML-KEM y FrodoKEM, QUIKE-composite tuvo la menor duración media de negociación entre los enfoques probados, al promediar los resultados medios de cada configuración entre anchos de banda y latencias para cada nivel de pérdida.
- Las claves más grandes siguen siendo difíciles
Ese resultado tiene un límite claro. Con Classic McEliece, en condiciones de red cada vez peores, todos los enfoques probados tardaban en promedio más de un minuto por negociación o congestionaban la red.
Los autores relacionan la dificultad con el tamaño mucho mayor de los datos de clave: las retransmisiones de datagramas podían añadir congestión, mientras que los enfoques de transporte reducían la velocidad al detectar pérdidas.
- El rendimiento implica compensaciones
Los autores presentan la elección como una compensación para ML-KEM y FrodoKEM. Las extensiones existentes de IKEv2 mantienen la continuidad y la compatibilidad, pero quizá necesiten optimización; cambiar el transporte puede mejorar el rendimiento y simplificar el diseño, a costa de esa continuidad y con nuevas dependencias.
La configuración de las pruebas y el alcance de búsqueda limitado a documentos del IETF acotan la aplicabilidad de estos resultados.
Detalles
- Autores del paper original
- Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger
- Enviado a arXiv
- Licencia
- arXiv non-exclusive