Résumé

  • RFC 5203 distingue l’annonce REG_INFO, la demande REG_REQUEST, l’autorisation REG_RESPONSE, l’échec REG_FAILED et l’annulation ; aucune de ces étapes ne vaut reçu d’exécution du service.
  • La durée accordée concerne un état d’enregistrement révocable. Le registraire, ou le service rattaché, peut l’annuler avant son échéance.
  • Un état exploitable relie la décision du registraire, l’état du demandeur, l’accusé du service, l’usage effectivement tenté et le résultat observé.

Deux horloges, un seul voyant

À 12 h 00, un hôte reçoit l’autorisation de s’enregistrer pour un service de traversée HIP. La réponse lui accorde 120 secondes. Le tableau de bord calcule l’échéance et allume un voyant vert jusqu’à 12 h 02.

À 12 h 00 min 30 s, un rechargement de configuration efface l’état du composant qui fournit réellement le service. Le registraire demeure actif. Il émet une annulation de durée nulle, mais le message ne rejoint pas le demandeur. À 12 h 01, ce dernier tente d’utiliser le service. La requête échoue ; le voyant reste vert pendant encore une minute.

Ce scénario est construit. Il ne décrit ni produit, ni déploiement, ni panne connue. Il révèle seulement que deux horloges ont été confondues : celle de l’enregistrement conservé par le demandeur et celle de la capacité réellement disponible. La première n’a pas expiré. La seconde a déjà disparu.

Le défaut n’est pas dans la réponse initiale. Elle peut être authentique, intègre et correctement traitée. Le défaut apparaît quand un système transforme « enregistrement accordé pour cette durée » en « service disponible pendant toute cette durée ».

Le protocole générique s’arrête avant l’usage

RFC 5203, publié comme RFC expérimental en 2008, fournit un mécanisme générique d’enregistrement auprès de services HIP, par exemple un serveur de rendez-vous ou un équipement intermédiaire. Il ne décrit pas comment découvrir ces services, trouver leur registraire, ni interagir avec eux après l’enregistrement.

Cette limitation est structurante. Le registraire peut attester une décision d’admission. Il ne peut pas, par la seule réponse générique, attester l’action future d’un service dont les opérations sont définies ailleurs.

Le texte définit l’enregistrement comme un état partagé entre demandeur et registraire, doté d’une durée finie et rafraîchissable. Cet état permet au demandeur de bénéficier d’un service. « Permet » n’est pas « a fourni ». L’accès autorisé est une condition préalable ; l’usage et le résultat viennent ensuite.

La formulation la plus révélatrice indique que le traitement réussi de REG_REQUEST crée un état chez le registraire et éventuellement chez le service. Ce « éventuellement » interdit de fusionner les deux. Un reçu du registraire n’est pas automatiquement un reçu du composant attaché.

L’annonce ne voyage pas jusqu’au résultat

Le premier message de cette chaîne est REG_INFO. Un nœud capable et disposé à agir comme registraire devrait annoncer les types proposés. S’il ne peut temporairement fournir les services, il devrait envoyer un paramètre vide. Lorsque l’offre change, une mise à jour devrait porter le nouvel ensemble disponible.

L’annonce a donc une date et un émetteur. Elle informe sur l’offre au moment de l’envoi. Elle ne réserve pas une capacité, ne crée pas l’état du service et ne promet pas que cette offre sera intacte au moment d’un usage futur.

Le demandeur formule ensuite REG_REQUEST, avec les types souhaités et une durée demandée. Il ne doit pas demander un type absent de la dernière annonce pertinente. La demande prouve une intention protégée par HIP ; elle ne produit pas elle-même une autorisation.

Le registraire authentifie l’identité d’hôte et applique sa politique locale. REG_RESPONSE énumère les types accordés et la durée retenue. REG_FAILED sépare les refus et d’autres échecs. Dans RFC 5203, le code zéro réclame d’autres justificatifs et le code un signale l’indisponibilité du type.

À chaque étape son autorité : offre déclarée, demande, décision, état local. Le résultat opérationnel ne figure dans aucune de ces catégories.

La durée mesure l’état, pas la qualité de service

La durée demandée n’est pas la durée due. Le demandeur doit accepter que le registraire renvoie une valeur différente, y compris lorsque sa demande se situe dans les bornes annoncées. Le champ est négocié par la réponse.

La valeur obtenue conserve une utilité claire. Elle borne l’état d’enregistrement en l’absence d’un autre événement. Elle permet le rafraîchissement et l’expiration. Mais l’état est souple. Une durée nulle l’annule. Le demandeur peut renoncer avant l’échéance. Le registraire ou le service peut également annuler si la capacité n’est plus fournie, par exemple après un changement de configuration. Sous pression de ressources ou lors d’une attaque, le registraire peut supprimer l’état à sa discrétion.

Une supervision correcte ne stocke donc pas seulement expires_at. Elle conserve la création, le dernier rafraîchissement, le dernier signal d’offre, l’annulation émise, l’annulation reçue et l’état du composant de service. Les horloges peuvent diverger sans qu’aucune signature soit falsifiée.

L’absence d’annulation reçue n’est pas une confirmation. Le verbe normatif « devrait » ne garantit ni l’émission dans toutes les défaillances, ni la livraison, ni le traitement. Un silence doit rester un silence.

Une signature protège le propos, pas une interprétation ajoutée

Il serait inexact de dévaloriser REG_RESPONSE. La réponse est protégée dans l’échange HIP. Elle suit l’authentification du demandeur et une décision de politique locale. Pour savoir si le registraire a accepté un type et quelle durée il a accordée, c’est un élément fort.

Sa force cryptographique ne modifie pas son périmètre sémantique. Une signature relie un émetteur à un contenu. Elle n’ajoute pas « et le service fonctionnera » à un contenu qui ne le dit pas. Elle ne maintient pas un état dans un autre processus et ne transporte pas une requête future.

Les architectures de preuve doivent préserver cette modestie. Au lieu d’un booléen global, elles enregistrent le principal, les types, la politique, la durée, l’époque de configuration et l’objet signé. Le service joint ensuite son propre reçu. Le réseau joint l’observation du trafic. L’application joint le résultat.

RFC 8003 a précisé les refus sans effacer la frontière

RFC 8003 a remplacé RFC 5203 en 2016 et a porté l’extension sur la voie des normes. Il a rendu plus explicite la volonté du registraire envers un demandeur donné, ajouté des éléments d’autorisation par certificat et un motif d’échec pour ressources insuffisantes.

Cette évolution améliore le diagnostic au moment de l’admission. L’opérateur peut distinguer plus finement justificatifs manquants, type indisponible, certificat invalide ou manque de ressources. Elle conserve cependant REG_INFO, REG_REQUEST, REG_RESPONSE, REG_FAILED, la durée finie et l’annulation.

Le perfectionnement des codes ne change pas la question posée. Une décision mieux expliquée reste une décision d’enregistrement. Pour prouver l’exécution, il faut franchir la frontière du service.

Il faut aussi résister à une autre extrapolation : la publication de RFC 8003 ne prouve pas la migration d’un parc. Une référence commerciale, un binaire installé, une option activée et un message capturé constituent des faits différents.

Chaque service doit produire son reçu propre

RFC 5203 prévoit que certains types aient besoin de paramètres HIP supplémentaires. Leur sémantique appartient aux documents propres à ces types. C’est une bonne séparation : le tronc commun ne prétend pas connaître toutes les opérations particulières.

Pour un serveur de rendez-vous, la chaîne peut comporter l’enregistrement d’une liaison, la réception ultérieure d’I1, son transfert et la réponse indépendante du correspondant. Pour un pare-feu, elle peut comporter la règle installée, sa portée, son propriétaire, sa durée et les paquets qui l’ont rencontrée. Dans les deux cas, la réponse générique n’est qu’un maillon.

Un modèle de données honnête affiche les maillons :

annoncé → demandé → autorisé → état registraire → état service → usage → résultat.

Si l’interface du service ne fournit aucun accusé, on écrit inconnu. Inventer actif à partir de la seule autorisation ne crée pas de mesure ; cela cache l’endroit où la mesure manque.

Le dossier minimal pour une décision durable

Une preuve opérationnelle compacte comprend :

  • versions HIP et extension, binaire et révision de configuration ;
  • HIT du demandeur et du registraire ;
  • empreinte de REG_INFO, types offerts, bornes de durée et heure ;
  • empreinte de REG_REQUEST, types et durée souhaités ;
  • identité authentifiée, résultat de justificatif, politique et décideur ;
  • empreinte de REG_RESPONSE ou REG_FAILED, résultat par type et durée ;
  • identifiants d’état des deux extrémités, rafraîchissements et échéances ;
  • accusé et identifiant d’état du service rattaché ;
  • annulation, éviction, redémarrage et changement de configuration ;
  • requête propre au service et résultat observé ;
  • lacunes explicites quand l’observation s’arrête.

Cette structure ne retire rien à l’autorité du registraire. Elle lui évite d’être tenu pour garant d’un fait hors de sa vue. Elle localise aussi les incidents : divergence d’état, perte d’annulation, disparition du service ou échec applicatif ne deviennent plus le même problème.

L’enseignement durable de RFC 5203 est une discipline de vocabulaire. Un « oui » valide demeure précieux à condition de conserver la question à laquelle il répondait.

Sources