Résumé

  • RFC 5201, puis RFC 7401, autorise le répondant à sélectionner une R1 pré-calculée après I1 et à rester sans état spécifique à l’association ; la signature atteste une origine passée, pas une présence instantanée.
  • La frontière d’engagement se déplace avec I2, R2 puis l’association de charge utile : aucun de ces paliers ne doit être transformé en preuve du suivant.

Une réponse authentique, mais pas contemporaine de la promesse

Le schéma I1–R1–I2–R2 paraît linéaire. I1 sollicite, R1 lance l’échange authentifié avec un puzzle et les paramètres du répondant, I2 rapporte la solution et la contribution signée de l’initiateur, R2 clôt l’échange de base. La linéarité des paquets n’implique pourtant pas une montée continue des ressources engagées.

Le répondant peut préparer des R1 avant de connaître l’initiateur. À l’arrivée d’I1, il choisit l’une d’elles, insère les éléments autorisés à varier et l’envoie sans conserver d’état par session. Cette économie est le mécanisme de résistance au déni de service : une adresse source usurpée ne doit pas obliger le pair à réserver mémoire et calcul cryptographique coûteux.

La signature de R1 établit que la clé Host Identity du répondant a produit les parties couvertes. Le texte de RFC 5201 est soigneux : R1 a été générée « une fois » par ce répondant. Comme elle est pré-calculée et ne lie pas toutes les données propres à I1, elle ne suffit pas contre le rejeu. RFC 7401 maintient explicitement cette limite.

Une console qui affiche « pair vivant maintenant » ajoute donc un fait absent. L’heure locale de réception date l’observation de la sonde. Elle ne date ni la création de R1, ni la prise en compte individuelle d’I1, ni l’allocation d’une association.

Le compteur de génération n’est pas une horloge

HIP ajoute un compteur R1 croissant pour permettre à l’initiateur de préférer une génération plus récente de puzzles. Cet outil encadre les rejeux ; il ne fournit pas un temps UTC. Les spécifications prévoient perte d’état, redémarrage et choix entre plusieurs R1. HIPv2 conserve même la décision de ne pas inclure d’horodatage, afin d’éviter une dépendance à la synchronisation mondiale des horloges.

Le reçu doit donc garder deux coordonnées sans les confondre : le compteur de génération annoncé par le pair et l’instant monotone où l’observateur a reçu le paquet. Il faut aussi conserver le HIT du répondant, les algorithmes vérifiés, la durée de vie, la difficulté et la valeur opaque du puzzle. Une fraîcheur déduite doit citer sa règle et son incertitude.

Le puzzle facture un effort, pas une intention

L’initiateur recherche une valeur qui, combinée au défi et aux HIT des deux parties, produit le nombre demandé de bits nuls. Le répondant vérifie ce travail avec un seul calcul de hachage avant d’engager vérification de signature, Diffie–Hellman ou mémoire d’association.

Cette asymétrie permet d’écarter beaucoup d’I2 forgées à faible coût. Elle ne transforme pas l’effort en autorisation. Une solution valide ne prouve ni la légitimité commerciale du demandeur, ni son droit d’accès, ni la disponibilité d’une application, ni la réservation de capacité. Le mot « sincère » employé par la RFC signifie seulement que des cycles de processeur ont été dépensés.

La protection a elle-même une portée précise. Le lien avec le HIT gêne la multiplication de fausses identités à partir d’un seul défi ; il n’arrête pas tout attaquant qui garde un HIT fixe. Une implémentation peut choisir de mémoriser certains échecs. L’opérateur arbitre alors entre mémoire et calcul. Le reçu doit nommer ce choix au lieu de produire un score moral.

I2 ouvre la possibilité de l’état

Une I2 correcte franchit la frontière intéressante. Le répondant peut vérifier d’abord le puzzle, puis la signature et la contribution Diffie–Hellman. S’il accepte, il calcule le secret partagé et crée l’association HIP correspondante. Un journal côté répondant attestant cette transition est plus fort qu’une R1 vue côté initiateur.

Mais ce journal ne prouve pas que R2 est arrivée. À l’autre extrémité, la vérification de R2 prouve que l’initiateur a terminé l’échange de base avec un répondant capable d’utiliser le résultat partagé. Les deux perspectives doivent être corrélées par HIT, génération, paramètres et empreintes, sans prétendre que leurs horloges sont identiques.

Cette séparation explique un cas fréquent d’enquête : la capture contient une R1 parfaitement valide, tandis que la base de sessions du répondant ne contient rien. Si I2 n’a jamais été reçue, si le puzzle a expiré ou si la signature a échoué, l’absence d’état est le fonctionnement attendu.

L’association HIP n’est toujours pas le chemin applicatif

L’échange de base produit l’état HIP et le matériel de clé. Il ne définit pas le format effectif des données utilisateur. RFC 7401 renvoie ce rôle à des spécifications séparées et exige au minimum le transport ESP de RFC 7402. Après un redémarrage, elle décrit la création d’une nouvelle association de charge utile après l’échange de base, puis seulement l’envoi de données.

Il faut ainsi distinguer R2 vérifiée, association de charge utile installée, premier paquet protégé transmis, premier paquet protégé reçu et réponse applicative. Une SPI présente d’un côté ne garantit pas une installation symétrique. Un paquet chiffré émis ne garantit pas le routage retour. Une réponse réseau ne garantit pas l’acceptation métier.

Un test de disponibilité défendable enregistre le format négocié, les suites, les localisateurs, l’époque de clé, le résultat d’installation aux deux extrémités et une requête applicative sûre avec son accusé. Ce n’est qu’à ce dernier niveau qu’une console peut parler de service observé.

Une échelle de preuves pour l’exploitation

Événement Fait étayé Fait encore absent
I1 émise La sonde a envoyé un déclencheur Réception par le répondant
Signature R1 valide La clé du répondant a créé le matériau couvert Présence actuelle et réservation
Puzzle résolu L’initiateur a fourni l’effort demandé Acceptation par le répondant
I2 acceptée La politique du répondant a créé l’état HIP Réception de R2
R2 vérifiée L’échange de base est achevé pour l’initiateur Association ESP et données utiles
Association de charge utile installée Un état de transport nommé existe Succès applicatif bidirectionnel
Requête et réponse protégées Un effet borné a été observé Disponibilité future

Chaque niveau doit porter version d’implémentation, règle de politique, identité des extrémités, temps monotone et motif d’échec. Un seul booléen détruit la causalité nécessaire au diagnostic.

Le statut historique exact

RFC 5201 date d’avril 2008. Elle est Experimental et précise ne définir aucune norme Internet. Sa note IESG signale notamment SHA-1, l’agilité des mécanismes d’authentification, les choix RSA et l’interaction avec les politiques fondées sur l’adresse IP. RFC 6253 l’a ensuite mise à jour pour les certificats.

RFC 7401 l’a rendue obsolète en 2015, a incorporé l’expérience d’implémentation et a placé HIPv2 sur la voie des normes avec une meilleure agilité cryptographique. RFC 8002 et RFC 9374 prolongent encore cette famille. La leçon probatoire demeure, car HIPv2 conserve volontairement la R1 pré-calculée et le répondant sans état.

La spécification minimale d’un tableau de bord doit donc rester modeste : provenance R1, acceptation I2, achèvement R2, état de charge utile, effet applicatif. La clarté consiste à ne jamais promouvoir un symbole technique au rang d’un résultat qu’il n’a pas produit.

Sources

  1. RFC 5201 HTML
  2. RFC 5201 texte
  3. Fiche RFC 5201
  4. Datatracker RFC 5201
  5. Historique RFC 5201
  6. Références RFC 5201
  7. Errata RFC 5201
  8. RFC 7401 — HIPv2
  9. RFC 7401 texte
  10. Fiche RFC 7401
  11. Errata RFC 7401
  12. RFC 7402 — transport ESP pour HIP
  13. RFC 4423 — architecture HIP
  14. RFC 4987 — contre-mesures aux SYN floods
  15. RFC 6253 — certificats HIP
  16. RFC 8002 — certificats HIPv2
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — couches de réalité et pouvoir symbolique
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code en fonctionnement