FR
QUIC accélère deux types de clés dans IKEv2, mais les plus grandes restent difficiles
Embedding Large PQC KEMs in IKEv2 · arXiv:2610.32356
En termes simples
IKEv2 est un protocole qui établit des connexions réseau sécurisées, mais il ne peut pas découper le premier message de sa négociation. Certaines clés post-quantiques, conçues pour résister aux ordinateurs quantiques, sont trop grandes pour tenir facilement dans ce message.
L’article passe en revue des propositions et présente trois approches, dont l’utilisation de QUIC, un moyen fiable de transporter les messages de négociation. Lors des tests, l’approche QUIC qui regroupe les deux clés a obtenu la durée moyenne de négociation la plus courte pour deux des trois types de clés testés. Avec les clés les plus grandes, toutes les approches ont rencontré des difficultés sur les liaisons réseau dégradées.
La recherche
Comment IKEv2 peut-il transporter de grandes données de clés post-quantiques si son premier échange ne peut pas être fragmenté au niveau du protocole ?
La réponse compte, car la taille des clés varie fortement et le délai, la bande passante et les pertes de paquets peuvent déterminer si l’échange se termine rapidement ou provoque de la congestion.
Les auteurs passent en revue les propositions de l’IETF, ajoutent trois approches protocolaires et comparent leur transport de clés post-quantiques sur des réseaux difficiles.
La question centrale est de savoir comment IKEv2 peut transporter de grandes données de clés post-quantiques lorsque son premier échange ne peut pas utiliser la fragmentation au niveau du protocole, surtout sur des liaisons lentes ou sujettes aux pertes.
Les auteurs passent en revue les propositions de l’IETF, ajoutent trois approches et comparent leurs performances et leur résistance aux pertes dans des conditions réseau simulées.
Dans les tests avec ML-KEM et FrodoKEM, l’approche qui combine les deux clés dans un échange QUIC a eu la durée moyenne de négociation la plus courte parmi celles testées. Ces moyennes regroupent les résultats moyens par configuration pour différentes bandes passantes et différents délais, à chaque niveau de perte.
Avec les clés Classic McEliece, cependant, toutes les approches dépassaient en moyenne une minute par négociation ou congestionnaient le réseau lorsque les conditions se dégradaient.
Les tests utilisaient une authentification statique par clé prépartagée et des pertes de paquets réparties au hasard. Ils ne mesurent ni le trafic supplémentaire dû aux signatures et aux chaînes de certificats, ni les performances des approches en cas de pertes en rafale.
Ce que montrent les preuves
- Le défi des échanges de grandes clés
L’article associe une revue systématique des propositions de l’IETF pour les échanges de clés post-quantiques dans IKEv2, trois nouvelles approches protocolaires et une évaluation comparative. IKEv2 ne peut pas utiliser son propre mécanisme de fragmentation lors du premier échange, au moment où de grandes données de clés peuvent devoir être transmises.
Les auteurs examinent comment les différentes approches gèrent cette contrainte dans des conditions réseau difficiles.
- Trois façons de transporter les clés
Les nouvelles approches modifient la façon dont les messages de négociation sont transportés. L’une ajoute des données redondantes aux messages UDP pour faciliter la récupération après une perte. Deux utilisent QUIC, un transport fiable, pour acheminer les messages de négociation d’IKEv2 ; l’une d’elles regroupe les clés classiques et post-quantiques dans un seul échange. Ces conceptions sont comparées aux propositions repérées dans la revue de l’IETF.
- Une approche favorisée avec les clés plus petites
Les auteurs ont mesuré 1 296 configurations, en faisant varier le type de clé, le délai, la bande passante et les pertes de paquets, avec un réordonnancement fixé. Le contrôleur de test a exécuté 126 500 négociations entre deux hôtes Linux connectés, avec des conditions réseau simulées.
Pour ML-KEM et FrodoKEM, QUIKE-composite a eu la durée moyenne de négociation la plus courte parmi les approches testées, en moyennant les durées moyennes par configuration sur les bandes passantes et les délais pour chaque niveau de perte.
- Les clés les plus grandes restent difficiles à gérer
Ce résultat a une limite nette. Avec Classic McEliece, dans des conditions réseau de plus en plus difficiles, chaque approche testée dépassait en moyenne une minute par négociation ou congestionnait le réseau.
Les auteurs attribuent cette difficulté aux données de clés bien plus volumineuses : les retransmissions de datagrammes pouvaient ajouter de la congestion, tandis que les approches fondées sur un transport ralentissaient en réaction aux pertes.
- Les performances impliquent des compromis
Les auteurs présentent le choix comme un compromis pour ML-KEM et FrodoKEM. Les extensions existantes d’IKEv2 préservent la continuité et la compatibilité, mais peuvent nécessiter une optimisation ; changer de transport peut améliorer les performances et simplifier la conception, au prix de cette continuité et de nouvelles dépendances.
Le protocole de test et le périmètre limité aux documents de l’IETF dans la revue restreignent la portée de ces conclusions.
Détails
- Auteurs de l’article original
- Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger
- Soumis à arXiv
- Licence
- arXiv non-exclusive