Résumé

  • RFC 5206 et son successeur RFC 8046 protègent l’annonce du locator, mais une adresse apprise commence normalement en état UNVERIFIED. Un nonce renvoyé depuis cette adresse, ou un paquet protégé équivalent, apporte la preuve suivante.
  • Credit-Based Authorization autorise un volume borné avant la vérification. Elle limite l’amplification ; elle ne certifie ni le chemin, ni la continuité de l’application.

La déclaration et son objet

La mobilité HIP conserve une identité cryptographique lorsque l’adresse IP change. Ce découplage évite de traiter chaque déplacement comme une nouvelle relation. Mais il oblige l’observateur à nommer le sujet de chaque preuve.

Le HMAC ou la signature porte sur le message envoyé dans une association HIP. Après validation, le destinataire sait quel pair a déclaré un locator, avec quelle séquence et quelle durée. Il ne sait pas encore si le locator reçoit des paquets maintenant. Un propriétaire légitime peut annoncer une interface éteinte, une adresse dont la route n’a pas convergé ou un point derrière un état NAT expiré.

Le modèle d’état empêche cette confusion. UNVERIFIED signifie que la joignabilité n’est pas établie. ACTIVE signifie que la procédure a réussi ou qu’un trafic qualifiant a été observé. DEPRECATED retire un locator arrivé à expiration. Une interface devrait afficher ces mots au lieu de les compresser en une coche « mobilité ».

Le nonce doit toucher le nouveau sol

La vérification typique envoie un ECHO_REQUEST aléatoire dans un UPDATE destiné à la nouvelle adresse. La réponse correspondante montre que le pair a reçu la valeur et a répondu à cet endroit. La RFC autorise d’autres échanges, à condition qu’ils établissent le même fait.

Un paquet protégé reçu sur une SA nouvellement annoncée peut aussi servir de preuve implicite. Ce n’est pas la signature initiale qui devient soudain suffisante : un nouvel événement est observé sur le nouveau chemin. Il faut conserver son SPI, son résultat d’authentification, son adresse source et son instant.

La création d’une SA, la réception d’un nonce et le succès applicatif restent séparés. Une SA peut être prête sans paquet retour. Le test peut réussir alors qu’un pare-feu bloque ensuite ESP. ESP peut passer tandis que la session applicative échoue. Chaque couche possède son reçu.

« Préféré » exprime un souhait

Le bit de préférence indique où le pair souhaite recevoir le trafic. Il ne mesure rien. Lorsque ce locator est encore UNVERIFIED, RFC 8046 recommande de garder un locator ACTIVE disponible pendant le test. Le basculement définitif vient après la preuve.

La durée du locator n’est pas davantage un bail de disponibilité. Elle borne l’état accepté par le protocole. Elle ne garantit pas l’interface, le réseau d’accès, le routage ou la politique pendant chaque seconde. Un enregistrement vivant peut décrire un chemin mort.

L’exception concernant un locator préféré annoncé dans R1 appartient à un contexte précis du base exchange. Elle ne doit pas devenir une règle générale selon laquelle toute adresse signée est active.

Envoyer sans prétendre savoir

Attendre le retour du nonce peut interrompre un flux. CBA conserve un compteur fondé sur les octets récemment reçus du pair. Le destinataire peut envoyer vers le locator non vérifié tant que le volume reste dans ce crédit, puis le compteur diminue et vieillit.

La nuance est essentielle. CBA ne supprime pas la redirection malveillante ; elle empêche qu’elle fournisse une amplification rentable. Le trafic provisoire reste possible, mais borné. Dans les journaux, l’état correct est envoyé sous CBA, accompagné du crédit initial, des octets dépensés, des paramètres d’âge et du résultat ultérieur du test.

Un tableau qui transforme ces paquets en preuve de joignabilité inverse le mécanisme. Le budget existe précisément parce que la preuve manque encore.

Le reçu de mobilité

Pour chaque changement, conserver : association et algorithmes ; séquence UPDATE ; locators exacts, durées et préférence ; contrôle d’adresse ; état initial ; alternative active ; nonce et retransmissions ; réponse ou paquet protégé ; transition vers ACTIVE ; décision de chemin ; SA installée ; premier payload accepté ; résultat applicatif ; expiration et suppression.

Cette chaîne rend visibles les arrêts. Elle permet aussi d’attribuer le contrôle : le pair annonce, la pile HIP vérifie, IPsec tient la SA, le réseau transporte et l’application juge l’effet. Aucun composant ne devrait signer le succès des autres.

Du protocole expérimental au Standards Track

RFC 5206 date de 2008, est Experimental et obsolète. RFC 8046 la remplace en 2017 sur le Standards Track, renomme LOCATOR en LOCATOR_SET et confie le multihoming à RFC 8047. Le principe de la vérification distincte demeure.

Une référence moderne ne prouve pourtant pas que le code a migré. L’inventaire doit montrer la version, les paramètres compris, les transitions, les temporisateurs et les valeurs CBA observées.

La décision de direction est simple : publier quatre statuts séparés — annonce authentifiée, locator vérifié, chemin protégé actif, application continue. La spécification commune peut authentifier et borner. Seul le code en fonctionnement peut fournir le reçu du chemin.

Sources

  1. Informations RFC 5206
  2. RFC 5206 HTML
  3. RFC 5206 texte
  4. Datatracker RFC 5206
  5. Historique RFC 5206
  6. Références RFC 5206
  7. Errata RFC 5206
  8. Informations RFC 8046
  9. RFC 8046 HTML
  10. RFC 8046 texte
  11. Datatracker RFC 8046
  12. Historique RFC 8046
  13. Références RFC 8046
  14. Errata RFC 8046
  15. RFC 7401 — HIP v2
  16. RFC 7402 — transport ESP HIP
  17. RFC 8047 — multihoming HIP
  18. RFC 6973 — vie privée
  19. RFC 4423 — architecture HIP
  20. Heng Lu — couches de réalité
  21. Heng Lu — spécification initiale minimale
  22. Heng Lu — primauté du code exécuté