Résumé

  • RFC 5269 distingue trois objets : la paire CGA/SEND qui autorise la revendication de l’adresse source, une paire indépendante servant uniquement à transporter la clé, puis la clé partagée qui calcule l’authenticator du FBU.
  • Un MAC correct autorise l’ancien routeur à modifier le forwarding d’une previous care-of CGA déterminée. Il ne prouve pas l’attachement au nouveau lien, la disponibilité de la NCoA, la livraison de paquets, l’identité d’un utilisateur ni l’acceptation d’un binding Mobile IPv6 durable.

Une commande dangereuse exige une autorité précisément nommée

Le risque traité par RFC 5269 tient à une instruction de contrôle très concrète. Un Fast Binding Update peut demander au previous access router de rediriger le trafic encore envoyé vers l’ancienne care-of address d’un nœud mobile. Sans authentification, un émetteur malveillant pourrait détourner les paquets d’une victime en produisant cette commande avant ou pendant le déplacement.

Le protocole ajoute donc un Authorization Data for FMIPv6 : le mobile calcule un MAC avec une clé partagée préparée auparavant, et le PAR vérifie ce MAC avant de toucher au forwarding. S’il ne trouve pas de clé correspondant à l’ancienne CGA, il ne doit pas appliquer la modification.

Ce résultat mérite le mot « autorisé », mais seulement avec son complément : changement de forwarding pour cette adresse, par ce routeur, sous cette clé et pendant cette durée de vie. L’abréviation « handover authentifié » supprimerait précisément les éléments qui rendent la conclusion vraie. Le MAC n’a pas observé la couche radio, n’a pas mené Duplicate Address Detection sur la NCoA et n’a reçu aucun accusé de livraison d’un paquet applicatif.

Trois clés empêchent trois responsabilités de se confondre

La première paire appartient au mécanisme Cryptographically Generated Address et à SEND. La RtSolPr est envoyée depuis la care-of CGA et transporte les options CGA et Signature. Une validation SEND réussie établit que l’émetteur peut revendiquer cette adresse source dans cet échange ; elle ne lui accorde pas une autorité générale sur le réseau.

La deuxième paire est générée spécialement pour chiffrer la clé de handover. Elle emploie le même algorithme et les mêmes paramètres publics que SEND, mais RFC 5269 impose son indépendance. Elle ne doit servir ni à une autre opération de chiffrement ni à une signature. La partie publique est fournie dans la Handover Key Request Option ; la partie privée reste au mobile pour ouvrir la réponse.

La troisième clé est un secret partagé produit ou retrouvé par l’access router. Celui-ci le chiffre pour la deuxième paire et le remet dans une Handover Key Reply Option. Le mobile et le routeur utilisent ensuite ce secret pour l’authenticator du FBU.

Un inventaire qui fusionne ces trois rôles dans un même champ détruit l’explication. Une compromission de la clé SEND, de la clé privée de transport ou du secret partagé n’a ni le même effet ni le même rayon d’action. La création, la rotation, la conservation et l’effacement doivent donc rester attachés au rôle cryptographique exact.

La validation SEND précède toute allocation

La requête RtSolPr contient la clé publique de transport, l’Algorithm Type préféré pour le FBU, les preuves CGA/SEND et un nonce SEND. Le routeur d’accès doit d’abord valider SEND. Une requête invalide ne reçoit pas de Handover Key Reply, ne provoque aucune création de clé et ne doit surtout pas modifier une association déjà valide pour cette adresse.

Cet ordre protège aussi la capacité. Générer un secret aléatoire et réserver une entrée de cache consomme des ressources. Le protocole demande de ne pas engager ce coût avant d’avoir vérifié l’initiateur ; limitation de débit, maîtrise des états en attente et politique de cache restent nécessaires contre l’épuisement, même lorsque les signatures sont correctes.

Il faut donc consigner deux décisions distinctes. La validation cryptographique répond à la question « cette revendication de CGA est-elle acceptable ? ». L’admission répond à « le routeur a-t-il créé ou restitué un état dans les limites prévues ? ». Réduire les deux à un voyant vert rend impossible l’analyse d’une attaque par volume.

Une réponse déchiffrable n’est pas encore une réponse recevable

Après une requête valide, l’access router peut restituer la clé associée à la CGA ou en créer une nouvelle. La PrRtAdv renvoie le secret chiffré, la durée HK-LIFETIME, l’algorithme choisi et le nonce original.

Mais le routeur doit lui aussi prouver sa place dans la chaîne. Il dispose d’un certificat adapté à SEND, signe la réponse avec la clé certifiée et prend en charge la découverte de certificats. Si le chemin n’est pas déjà disponible, les messages CPS/CPA servent à l’obtenir. Le mobile rejette une réponse dont la signature n’est pas reliée à une clé de routeur certifiée selon son trust anchor.

Le nonce relie ensuite la réponse à une requête déterminée. Il permet aussi de sélectionner la bonne clé privée de transport lorsque plusieurs demandes ont été émises. Un nonce sans correspondance signifie rejet, non tentative opportuniste avec toutes les clés locales.

La réception utile est donc une chaîne : demande, paramètres CGA, signature SEND, verdict du routeur, chemin de certification, signature de PrRtAdv, nonce retourné, algorithme choisi, clé privée correspondante et durée de vie. « Déchiffrement réussi » n’en est que l’avant-dernière opération.

L’autorité vit dans une relation, pas dans les octets

Côté routeur, le secret est associé à la CGA du mobile, à un algorithme et à une échéance. Côté mobile, le choix futur dépend de l’identité du previous access router et de la previous care-of CGA utilisée sur ce lien. Le Home Address Option du FBU porte cette ancienne adresse et permet au PAR de retrouver l’entrée.

Cette modélisation est nécessaire dès que le mobile conserve des réponses de plusieurs routeurs ou revient rapidement sur un lien. Deux clés valides peuvent coexister sans être interchangeables. Un index réduit au « terminal actuel » ou au « routeur actuel » peut produire un MAC mathématiquement correct avec la mauvaise relation opérationnelle.

La preuve doit donc transporter ses clés de jointure : identité du routeur, CGA du mobile, génération, algorithme, période de validité et type de message. La cryptographie garantit le calcul demandé ; elle ne répare pas une sélection erronée dans la base de données.

Le choix d’algorithme fait partie du reçu

Le mobile annonce son Algorithm Type préféré. Le routeur le conserve s’il le prend en charge ; sinon il doit choisir une solution de force équivalente ou supérieure. Le mobile emploie la valeur réellement renvoyée.

Avec plusieurs PrRtAdv, plusieurs secrets peuvent rester disponibles. Si aucune offre n’est compatible, une nouvelle requête est possible. En revanche, un routeur compromis ne doit pas réussir un bidding down en poussant la demande suivante sous le niveau de préférence initial.

Un journal qui garde seulement MAC valid ne permet pas de vérifier cette règle. La préférence demandée, la réponse, la version de politique et l’implémentation effective de l’algorithme appartiennent au même dossier de preuve. Une évolution future des politiques ne doit pas changer rétrospectivement le sens d’une validation passée.

La présence en cache n’est pas un renouvellement

RFC 5269 suggère pour la paire de transport une limite de douze heures ou dix handovers, selon le premier terme atteint. Pour le secret partagé, la durée par défaut est également de douze heures, soit 43 200 secondes.

Le routeur génère un secret aléatoire de force suffisante, unique pour chaque clé publique CGA. Les valeurs doivent être non corrélées entre mobiles et sans relation exploitable avec les clés CGA. Le secret peut rester au PAR pendant un déplacement rapide, car le binding Mobile IPv6 ordinaire n’est peut-être pas encore achevé.

Si le mobile revient avec la même care-of CGA, le routeur peut renvoyer le même secret encore valable. Le mobile ne peut toutefois pas considérer sa copie locale comme une nouvelle autorisation : il doit effectivement recevoir la clé à nouveau. Possession locale, non-expiration, conservation distante et reprovisionnement sont quatre faits différents.

Après l’établissement normal du binding au nouveau routeur, le mobile devrait effacer le secret. Le PAR l’efface à l’expiration du forwarding ou de HK-LIFETIME. Conserver une clé au-delà de ces deux bornes transforme un mécanisme provisoire en autorité dormante.

Une clé construite pour un usage ne devient pas une identité universelle

La clé partagée ne chiffre pas les données utilisateur. Elle n’est ni un secret de session applicatif, ni une preuve d’abonné, ni un justificatif de facturation. Elle ne valide pas la NCoA proposée, ne remplace pas Binding Update ou Return Routability de Mobile IPv6 et ne démontre pas qu’un home agent ou un correspondent node a accepté un binding.

RFC 5568 est désormais le texte de base pour Fast Handovers for Mobile IPv6. Il remplace RFC 5268 et continue de s’appuyer sur RFC 5269 pour établir la clé utilisée par l’authenticator du FBU. Une implémentation doit donc lire l’extension avec le format courant, sans importer des détails de messages devenus obsolètes.

Les travaux ultérieurs sur SEND peuvent renforcer la certification et le transport des trust anchors. Ils renforcent l’identité du signataire dans le modèle prévu ; ils n’étendent pas le sens du MAC. Une preuve plus forte d’un fait étroit reste une preuve de ce fait étroit.

Le code exécuté conserve les limites que les tableaux de bord effacent

La Running-Code Primacy de Lu Heng conduit à inventorier les opérations réelles : revendication CGA, vérification SEND, paire publique de transport, réponse de routeur certifiée, nonce corrélé, relation en cache, algorithme retenu, authenticator du FBU et mutation du forwarding.

La discipline des reality layers sépare la possession d’une clé, l’autorisation d’une commande et le résultat du déplacement. Contrôler une clé privée prouve une opération ; valider SEND prouve la revendication d’adresse dans ce contexte ; valider le MAC autorise une redirection. Aucun de ces constats ne mesure la présence physique du terminal ni la continuité du service.

L’abstraction reste réversible si chaque statut peut revenir au message, à la relation, au rôle de la clé, à la génération et au timer qui l’ont produit. Un simple libellé « authentifié » transforme une chaîne vérifiable en croyance administrative.

Sources