Résumé

  • Si toutes les associations de sécurité RSVP applicables sont expirées, le projet recommande d’alerter l’administrateur et de donner une durée de vie infinie à la dernière jusqu’à sa prolongation, sa suppression ou son remplacement.
  • Ce maintien n’absout pas la vieille clé : il évite à la fois le retour à des messages non authentifiés et une rupture brutale de réservations susceptible d’amplifier une panne.
  • La rotation n’est achevée que lorsque l’association remplaçante est active sur le bon périmètre et que chaque récepteur a terminé son échange d’initialisation de séquence.

L’heure de fin est passée. Pourtant, les messages continuent d’être vérifiés avec la même clé. Ce qui ressemble à une violation de politique est, dans un cas très précis, le comportement recommandé par le texte aujourd’hui soumis à l’examen du groupe TEAS de l’IETF.

La révision 02 de RSVP Cryptographic Authentication Version 2, publiée le 27 septembre 2026, se trouve en Working Group Last Call. Elle vise une éventuelle publication comme Proposed Standard, mais reste un Internet-Draft. Elle n’atteste aucun déploiement. Si elle aboutit, elle remplacerait RFC 2747 et RFC 3097.

Le passage décisif porte un titre sans détour : « Pathological Case ». Toutes les associations de sécurité pouvant protéger l’échange RSVP ont expiré. Revenir à un état sans authentification est jugé inacceptable. Interrompre les réservations en cours pourrait, lui aussi, provoquer un incident plus large. Le système devrait donc envoyer une notification d’expiration de la dernière association, tout en la considérant comme valable sans limite jusqu’à ce que l’exploitation allonge sa durée, la supprime ou configure une remplaçante.

Cette règle figurait déjà dans la révision 01. La révision 02 ne l’invente pas. L’événement éditorial est le passage du texte, avec ce compromis intact, à son stade actuel de revue. C’est une distinction essentielle : on n’annonce pas une nouveauté de protocole, on examine une décision de continuité qui cherche maintenant le consensus du groupe.

RSVP signale des réservations de ressources, selon RFC 2205, puis ses extensions de trafic engineering dans RFC 3209. Le projet v2 protège ses messages saut par saut au moyen d’un objet INTEGRITY. Le « sender » et le « receiver » du texte sont les voisins RSVP du saut considéré, pas forcément les extrémités applicatives.

L’objet comprend un identifiant de clé de 48 bits, un numéro de séquence de 64 bits et les données d’authentification. L’adresse de l’émetteur et l’identifiant sélectionnent ensemble l’association exacte. Celle-ci fixe aussi la transformation cryptographique, le secret, les interfaces ou pairs concernés, et ses dates de début et de fin. Une association est unidirectionnelle.

Cette mécanique prouve quelque chose de limité mais utile : le voisin possédant la clé a produit un message que le récepteur juge frais. Elle ne chiffre pas RSVP. Elle ne confirme ni l’autorité métier du demandeur, ni l’application de la politique d’admission, ni le passage réel des paquets. Une preuve de message ne doit pas être promue en preuve globale de service.

Le numéro de séquence rend le redémarrage particulièrement sensible. Il doit rester unique et croître durant toute la vie de la clé. Un récepteur qui redémarre sans connaître la position actuelle risque d’accepter un ancien message. Le projet impose donc la prise en charge d’un Integrity Handshake et recommande de l’activer par défaut. Le récepteur émet un cookie imprévisible ; l’émetteur le renvoie, avec sa séquence courante, dans une réponse authentifiée.

Chaque session doit s’appuyer soit sur cet échange, soit sur une conservation stable de la séquence. Les recommandations d’aléa de RFC 4086 et RFC 8937 renforcent le cookie. Elles ne disent pas quels récepteurs ont effectivement accompli le geste opérationnel.

La rotation est donc une période, pas une bascule ponctuelle. Une mise en œuvre doit accepter au moins deux associations simultanées. La nouvelle commence avant la fin de l’ancienne ; leur chevauchement devrait dépasser deux fois l’incertitude des horloges, cinq minutes étant présenté comme une valeur souvent suffisante. Surtout, chaque récepteur doit effectuer le handshake sur la nouvelle association.

« Clé installée » n’est alors qu’un état intermédiaire. La remplaçante doit viser les mêmes pairs ou interfaces, être valide selon une heure fiable, être choisie par l’émetteur, reconnue par le récepteur et disposer d’un point de départ de séquence sûr. L’absence d’un seul de ces reçus transforme une rotation apparemment terminée en exception de dernière clé.

L’horloge fait partie de la surface de confiance. Le projet exige une synchronisation suffisante et recommande d’authentifier la distribution du temps. RFC 5905 décrit NTPv4 ; la simple présence d’une configuration NTP ne prouve toutefois ni l’écart réel ni la santé de la source.

Le traitement ordinaire d’une association expirée est sévère. S’il existe une autre association applicable et valide, le paquet nommé par l’ancienne doit être rejeté avant même le calcul cryptographique, et l’erreur de sécurité devrait être journalisée avec limitation de débit. L’émetteur ne peut ainsi choisir indéfiniment l’ancien secret lorsqu’un successeur fonctionne.

Sans successeur valide, le résultat s’inverse : le récepteur utilise l’association expirée comme si elle ne l’était pas. Le choix est fail-operational. Il conserve le dernier lien authentifié connu plutôt que d’accepter des messages nus ou de faire tomber une réservation à la seule lecture du calendrier.

Son avantage est immédiatement visible : le réseau reste en service. Son coût l’est beaucoup moins. Une alarme peut être acquittée sans que la rotation soit réparée ; le fonctionnement normal retire l’urgence ; l’exception se fossilise. Le mot « infinite » est donc une allocation de pouvoir. Seule une action de gestion met fin à l’état.

Le projet ne définit pas la gestion des clés. Il exige la possibilité d’une distribution manuelle, autorise une durée manuelle infinie tout en la déconseillant, et prévoit l’agilité par un registre IANA des transformations. La compatibilité historique avec HMAC-MD5 demeure visible, tandis que RFC 6151 rappelle les limites de cette famille. Changer d’algorithme ne distribue pas pour autant une nouvelle clé aux bons voisins.

Un registre d’exploitation utile doit suivre la transition elle-même : identifiant et adresse émettrice, périmètre d’interface ou de pair, transformation, dates prévues, successeur, intervalle de chevauchement, incertitude horaire, liste des récepteurs, handshake de chacun, premier message accepté après expiration, émission et acquittement de l’alerte, puis action ayant clos l’exception. Le secret n’a pas à figurer dans ce registre ; la provenance de l’état, si.

Ce registre sépare quatre réalités souvent confondues : la création d’une clé, l’activation d’une association, l’initialisation sûre d’un récepteur et la disparition de l’ancienne comme seul chemin utilisable. La rotation n’est terminée qu’au quatrième reçu.

La primauté du code en fonctionnement formulée par Heng Lu donne ici une méthode : la date configurée est un symbole, le traitement effectif des paquets est la réalité. La spécification initiale minimale permet au protocole commun de rester étroit tout en laissant l’arbitrage local. Les couches de réalité empêchent enfin de prendre « expirée » pour la preuve que la confiance a cessé.

Le projet ne résout pas cette contradiction à la place de l’opérateur. Il maintient le dernier chemin authentifié, signale son anomalie et rend visible la personne qui doit désormais décider.

Sources