Résumé

  • RFC 3519 plaçait les données Mobile IPv4 dans UDP et utilisait comme localisateur care-of effectif l’adresse et le port sources observés par l’agent d’origine après traduction.
  • L’authentification Mobile IP protégeait l’adresse interne de l’enregistrement, pas le tuple extérieur réécrit. Durées courtes, keepalive et IPsec limitaient certains effets sans authentifier ce tuple.

Mobile IPv4 et NAPT avaient deux besoins incompatibles. Le premier voulait tunneliser vers une adresse care-of globalement routable. Le second séparait plusieurs machines privées grâce aux ports TCP ou UDP d’une adresse publique commune. Un tunnel IP-in-IP n’offrait aucun port ; la signalisation Mobile IP, déjà en UDP, pouvait pourtant franchir le traducteur.

RFC 3519 réutilisa ce passage. Une UDP Tunnel Request annonçait la capacité et le format souhaité. Une UDP Tunnel Reply donnait ou refusait l’assentiment et proposait un intervalle de keepalive. Les données pouvaient ensuite porter IP, GRE ou l’encapsulation minimale dans UDP, en conservant le port source de la demande et le port 434 de l’agent d’origine.

L’assentiment concernait une liaison et un mode. Il ne certifiait ni la propriété du mapping NAT, ni sa durée, ni la livraison suivante. Pour soupçonner un NAT, l’agent d’origine comparait l’adresse source extérieure et l’adresse care-of contenue dans la demande. En cas de différence et d’acceptation, la source observée devenait normalement le localisateur effectif.

Deux domaines de preuve se rejoignaient alors. L’extension d’authentification Mobile-Home ou Foreign-Home couvrait les champs de l’enregistrement. Le NAT pouvait modifier l’adresse IP et le port UDP extérieurs, qui n’étaient pas couverts. Or ces valeurs non authentifiées guidaient le trafic de retour.

Le RFC décrit l’attaque sans euphémisme. Un adversaire sur le chemin pouvait modifier les en-têtes de la demande et faire installer un binding redirigé. Après cette seule modification, il pouvait cesser d’intervenir ; l’état faux persistait jusqu’à la prochaine inscription ou expiration.

Le cas passant par un foreign agent ajoutait un état half-bound. La demande suivait l’agent, mais le tunnel devait aboutir au port du mobile. L’agent d’origine attendait donc le premier keepalive. Un observateur pouvait le devancer par un faux message. Exiger la même adresse source limitait le choix à un autre port de cette adresse, sans authentifier ce port.

Les keepalive bidirectionnels, des Echo Request/Reply ICMP encapsulés dans UDP, rendaient aussi la perte du mapping visible. Après plusieurs absences de réponse, le mobile pouvait se réinscrire et raccourcir son intervalle, jamais sous dix secondes. La valeur par défaut était 110 secondes.

L’agent d’origine ne devait pas adapter dynamiquement cet intervalle : il ne possédait pas assez d’information. Le mobile, proche du signal de panne, décidait. Une durée de binding encore valide pouvait donc coexister avec un mapping disparu et un nouveau tuple que l’agent ne connaissait pas.

Les durées courtes étaient une limitation de dégâts. Elles réduisaient le temps d’une redirection après la fin de l’action hostile ou d’un mouvement non détecté. Elles ne rendaient pas les en-têtes authentiques.

IPsec protégeait la confidentialité du trafic détourné, mais RFC 3519 disait explicitement qu’il ne bloquait pas ces redirections. La sécurité du contenu ne prouvait pas l’autorité du localisateur.

L’analyse UNSAF reconnaissait la fragilité. Une solution plus forte aurait découvert chaque traduction, validé l’autorité de chaque NAT et inclus l’adresse pertinente dans la demande signée. Le mécanisme publié choisissait la compatibilité avec les NAT existants, tout en nommant sa dette de confiance.

Le registre IANA fixe les valeurs du message, des extensions et du code d’erreur. Cette autorité rend l’interopérabilité possible ; elle ne témoigne d’aucun mapping vivant. L’héritage de RFC 3519 tient à cette leçon : un enregistrement authentique et un localisateur faux peuvent produire ensemble un état opérationnel parfaitement accepté.

Sources