Résumé

  • Dans RFC 5204, le RVS sert de point de contact initial : il consulte l’enregistrement du HIT et relaie I1, puis R1, I2 et R2 circulent directement entre les deux hôtes.
  • RVS_HMAC protège la transformation et le champ FROM dans la relation d’enregistrement ; il ne certifie ni le locator actuel, ni la réception d’I1, ni l’achèvement de l’association.
  • Le bon reçu relie l’époque DNS, l’époque d’enregistrement, la transformation exacte, la réception distante, le retour direct, l’échange cryptographique et le résultat du service.

Une adresse enregistrée n’est pas une présence observée

Prenons un cas construit. Un hôte mobile a signalé une adresse à son serveur de rendez-vous. Il change ensuite de réseau, mais sa nouvelle mise à jour n’a pas encore été acceptée. Pendant cet intervalle, un initiateur envoie I1 au RVS. Le serveur trouve un enregistrement encore valable, réécrit le paquet, ajoute un FROM protégé et transmet vers l’ancienne adresse. Son journal affiche un succès impeccable. Le pair, lui, n’a rien reçu.

Le scénario n’est pas un incident documenté. Il montre pourquoi l’état interne cohérent d’un intermédiaire n’est pas automatiquement l’état présent du système réel.

RFC 5204, protocole expérimental de 2008 ensuite remplacé par RFC 8004, améliore le premier contact avec un hôte HIP mobile ou multihébergé. Le client enregistre auprès du RVS un lien entre son Host Identity Tag et une ou plusieurs adresses courantes. Un futur correspondant découvre l’adresse du RVS dans le DNS, y envoie I1 et laisse le serveur consulter sa table.

Le verbe important est « consulter ». Le serveur affirme ce que contient son enregistrement à cet instant. Il ne mesure pas à nouveau l’interface du pair, sa route, son pare-feu ou sa volonté de répondre.

Le RVS quitte rapidement la conversation

Le chemin de RFC 5204 n’est pas un tunnel permanent. I1 va de l’initiateur au RVS, puis au répondant. Le répondant envoie R1 directement à l’initiateur. Les messages I2 et R2 sont eux aussi directs. Le RVS a rendu la première tentative possible ; il n’est pas le témoin obligatoire de la suite.

Cette topologie sépare plusieurs preuves. L’initiateur a joint le RVS. Le RVS a choisi une adresse et émis I1. Le répondant a peut-être reçu I1. Le retour direct a peut-être porté R1. La base exchange a peut-être abouti. Enfin, des données protégées et une transaction applicative ont peut-être réussi.

Un compteur placé au RVS ne peut mesurer que les premières étapes. Si son interface appelle son événement « session établie », elle attribue au serveur un savoir qu’il ne possède pas.

RFC 5204 ne couvre pas non plus le cas général où l’initiateur passerait par son propre RVS pour franchir NAT ou pare-feu. Étendre ce mécanisme à un relais universel sans preuve distincte serait transformer une limite explicite en promesse implicite.

FROM garde la trace d’une réécriture

Le filtrage de sortie peut empêcher le RVS de conserver l’adresse source de l’initiateur. Le serveur peut donc prendre sa propre adresse comme source. Dans ce cas, il doit ajouter FROM pour conserver l’adresse originale et protéger ce paramètre au moyen de RVS_HMAC.

La clé vient de la relation d’enregistrement entre le RVS et son client. Le contrôle prouve qu’un détenteur de cette clé a protégé la transformation transmise au client. Cette propriété est réelle et utile. Elle n’est pourtant pas une signature du pair initiateur, une attestation de tous les routeurs traversés ni un accusé de réception du répondant.

Lorsque plusieurs RVS interviennent, chacun ajoute son FROM après les précédents. L’ordre décrit la chaîne représentée dans le paquet. Il ne faut pas le vendre comme une capture exhaustive du chemin IP. La distinction ressemble à celle entre un bordereau de transport et la télémétrie de chaque étape : chacun répond à une question différente.

L’intégrité de l’intermédiaire et l’authentification des pairs

I1 ne porte pas encore les paramètres HMAC et signature de bout en bout de l’échange HIP. C’est précisément ce qui permet au RVS de modifier les adresses, de recalculer les sommes de contrôle et d’ajouter ses paramètres sans casser une protection qui n’existe pas encore à ce stade.

Le système possède donc deux périmètres. RVS_HMAC couvre la relation d’enregistrement et la transformation du relais. La base exchange HIP authentifie ensuite les deux hôtes. Valider le premier périmètre ne signifie pas que le second est terminé.

Les considérations de sécurité de RFC 5204 évoquent redirection, amplification, réflexion et attaques contre HIP. Un RVS est un point de contrôle puissant parce qu’il reçoit un paquet destiné à une identité et décide vers quel locator l’envoyer. Cette puissance justifie une journalisation précise, pas un badge plus large.

VIA_RVS aide au diagnostic

Après réception d’un I1 relayé, le répondant ajoute VIA_RVS à R1. Le texte donne à ce paramètre un objectif principal de diagnostic. Il permet à l’opérateur de savoir quel serveur était impliqué lors de l’établissement.

Un indice de diagnostic n’est pas un verdict de bout en bout. La construction de R1 est une observation côté répondant ; la réception et la validation de R1 en sont une autre côté initiateur. Puis viennent I2, R2 et l’état de protection. Dans une enquête, ces événements doivent rester corrélables mais séparés.

Deux horloges gouvernent la décision

Le DNS et l’enregistrement RVS évoluent indépendamment. Le premier indique quel point de rendez-vous essayer, avec sa signature éventuelle, son TTL, le cache du résolveur et son heure de lecture. Le second indique quel locator le serveur a accepté pour ce HIT, avec une durée de vie et une dernière mise à jour.

Une adresse DNS fraîche peut mener à un RVS dont l’enregistrement est absent. Un RVS actif peut posséder un locator ancien. Un locator correct peut être momentanément filtré. Aucun de ces cas ne se résume correctement par « hôte hors ligne » ou « hôte joignable ».

Le reçu minimal doit donc capturer les deux époques, puis la décision d’exécution. Il lie le RR DNS utilisé, le HIT demandé, l’identifiant et la durée de l’enregistrement, le locator choisi, l’empreinte d’I1, les en-têtes avant et après réécriture, les valeurs FROM, la vérification de RVS_HMAC et l’émission effective.

Il ajoute ensuite les preuves que le RVS ne peut produire seul : réception par le répondant, R1 direct, validation par l’initiateur, I2/R2, association, trafic protégé et résultat métier.

Une référence de norme ne prouve pas le logiciel exécuté

RFC 5204 est obsolète au profit de RFC 8004. Les RFC 5201, 5203, 5205 et 5206 ont elles aussi des successeurs pour le protocole de base, l’enregistrement, le DNS et la mobilité. Cette histoire est pertinente pour l’inventaire.

Elle ne permet pas d’inférer qu’un équipement particulier utilise l’ancienne version, qu’il est vulnérable ou qu’il a migré. « Compatible HIP rendezvous » doit être décomposé en version, paramètres reconnus, algorithmes, politique et comportement observé. Le document décrit un contrat ; seul le code en fonctionnement révèle lequel est exécuté.

Sources