Résumé

  • Le filtrage des adresses sources pouvait refuser un paquet émis depuis un réseau visité alors que son adresse d’origine appartenait bien au nœud mobile.
  • Le tunnel inverse plaçait le paquet dans une enveloppe dont les adresses convenaient au trajet entre agents, sans remplacer les extrémités de la communication intérieure.
  • Deux modes de remise donnaient des possibilités différentes. Leur négociation, les contrôles de proximité et la vérification des associations ne constituaient ni un chiffrement ni une garantie de livraison.

Une adresse exacte, au mauvais endroit

Un ordinateur peut dire vrai sur son adresse et néanmoins envoyer un paquet que le réseau a de bonnes raisons de refuser. C’est la situation qu’a rencontrée Mobile IPv4 : l’adresse permanente du nœud ne change pas quand il se déplace, mais le point depuis lequel elle apparaît, lui, a changé.

Le RFC 2002, publié en octobre 1996, séparait l’adresse d’origine du nœud de son adresse de rattachement temporaire. Un agent du réseau d’origine pouvait faire suivre les paquets vers ce nouveau point d’arrivée. Le correspondant continuait à joindre la même extrémité logique, tandis que la livraison suivait la mobilité entre sous-réseaux.

Cette adresse temporaire pouvait appartenir à un agent étranger desservant plusieurs nœuds, ou être obtenue directement par le nœud mobile. Dans le premier cas, l’agent terminait le tunnel. Dans le second, le nœud le faisait lui-même. L’histoire des deux modes de remise concerne principalement le premier arrangement ; elle ne suppose pas une adresse IPv4 locale exclusive pour chaque appareil.

La réception nécessitait ainsi un détour organisé. L’émission n’en avait pas nécessairement besoin. Le modèle supposait un acheminement essentiellement fondé sur la destination : le nœud pouvait expédier depuis le réseau visité en conservant son adresse d’origine comme source. Le trajet vers le correspondant n’était pas obligé de repasser par l’agent d’origine.

Or une adresse source est aussi une information que les frontières de réseau peuvent examiner. Le RFC 2827, de mai 2000, recommandait de restreindre les préfixes sources acceptés depuis un réseau client. L’objectif était de réduire l’usurpation, pas de vérifier seulement que la destination existait.

L’adresse du mobile pouvait être authentique mais extérieure aux préfixes attendus sur cette connexion. Le filtre ne tranchait pas une question de propriété personnelle : il vérifiait une cohérence topologique. Le RFC reconnaissait expressément la difficulté pour Mobile IP et désignait le tunnel inverse comme une réponse possible. La continuité d’une adresse et le contrôle d’une entrée réseau devaient pouvoir coexister.

Ce que change une enveloppe extérieure

Le tunnel inverse est décrit dans le RFC 2344, en mai 1998, puis révisé par le RFC 3024, en janvier 2001. Au lieu de partir directement vers son correspondant, le paquet rejoint d’abord l’agent d’origine. Celui-ci le remet ensuite sur son chemin.

Ce détour s’appuie sur une séparation de fonctions. Dans l’encapsulation IP décrite par le RFC 2003, l’en-tête intérieur garde les adresses des extrémités de la communication ; l’en-tête extérieur indique celles du trajet de tunnel. L’agent étranger peut donc envoyer vers l’agent d’origine avec son adresse de rattachement comme source extérieure. Le paquet intérieur reste celui du mobile.

Le réseau visité ne doit plus accepter cette adresse d’origine comme source nue du trajet distant. Il voit une source extérieure adaptée au point d’émission. Cette adaptation ne l’oblige toutefois pas à autoriser n’importe quelle encapsulation. Un filtre supplémentaire peut encore refuser le paquet.

L’image de l’enveloppe a aussi ses limites. Elle ne signifie pas que le contenu est secret : encapsuler n’est pas chiffrer. Elle ne signifie pas davantage que chaque bit intérieur reste intact, puisque des champs liés au transfert, notamment le TTL, peuvent évoluer. Ce qui reste stable ici, ce sont les extrémités de la communication, pas nécessairement chaque octet du paquet.

Le premier emballage n’a pas la même adresse

Le RFC 3024 définit d’abord une remise directe. Le nœud mobile utilise l’agent étranger comme routeur par défaut et lui remet son paquet sans enveloppe supplémentaire. L’agent effectue alors l’encapsulation vers le réseau d’origine. Ce mode prend en charge l’unicast, mais ne fournit pas de tunnel inverse sélectif.

L’autre mode fait commencer le travail chez le mobile. Celui-ci encapsule le paquet à destination de l’agent étranger. L’agent retire cette première enveloppe puis en construit une seconde, destinée à l’agent d’origine.

Les deux enveloppes ne sont pas interchangeables. Sur le petit trajet du mobile à l’agent étranger, la source extérieure est encore l’adresse d’origine du mobile. Sur le trajet suivant, entre les deux agents, elle devient l’adresse de rattachement de l’agent étranger. Attribuer cette seconde source à la première étape reviendrait à faire utiliser au mobile l’adresse de son agent comme si elle était la sienne.

Cette double opération permet au mobile de choisir. Une fois la remise encapsulée négociée, ses paquets non encapsulés ne doivent pas être envoyés dans le tunnel inverse ; ils suivent le transfert ordinaire. Un accès à une ressource locale, par exemple une imprimante, peut ainsi rester sur le réseau visité, si les routes et les autorisations locales le permettent.

L’absence d’enveloppe devient donc un signal pertinent. L’agent ne doit pas « aider » en renvoyant systématiquement chez lui tout ce qui vient du mobile. Ce serait supprimer une distinction expressément introduite par la négociation. Le mode encapsulé sert également au transport inverse de la diffusion et du multicast via l’agent étranger, ce que la remise directe ne couvre pas.

Une capacité annoncée n’est pas un service établi

L’agent annonce la disponibilité du tunnel inverse avec le bit T. Le mobile le demande dans sa requête d’enregistrement avec son propre bit T. Annonce et demande ne sont pas la même preuve : la première décrit une capacité, la seconde sollicite son usage dans une association déterminée.

Pour demander la remise encapsulée, le mobile ajoute une extension de type 130, de longueur nulle. Sans elle, la demande porte sur la remise directe. Elle ne doit pas accompagner une requête dont T est désactivé. Sa position par rapport aux extensions d’authentification est fixée, et l’agent étranger la traite sans la transmettre telle quelle à l’agent d’origine.

Le détail est révélateur du partage des responsabilités. Le choix de remise porte sur la relation locale avec l’agent étranger. Il n’est pas une déclaration générale selon laquelle tous les réseaux ultérieurs savent transporter le paquet.

Les obligations de mise en œuvre ont d’ailleurs changé. En 1998, un agent annonçant le tunnel inverse devait offrir les deux modes. En 2001, la remise directe demeure obligatoire, tandis que la remise encapsulée devient recommandée. Le code 79 permet de signaler qu’un mode de remise n’est pas pris en charge.

Une parenthèse ancienne du RFC 3024 présente encore ce code comme non attribué. Mais la section d’attribution du même document et son annexe de modifications disent le contraire. Le registre Mobile IP d’IANA confirme aujourd’hui l’affectation. Une phrase isolée, même dans une norme, ne suffit pas à établir l’état d’un registre.

L’inscription peut réussir, le paquet rester bloqué

Le RFC 3024 prévient qu’un mobile peut obtenir un enregistrement en retirant sa demande de tunnel inverse après un refus. Cela ne rend pas nécessairement la connexion utilisable. Si le réseau visité exige une source que seul le trajet encapsulé fournit, les données continueront à échouer malgré l’acceptation de l’enregistrement.

Il ne s’agit pas d’une contradiction du protocole. L’enregistrement a accepté un ensemble de conditions moins exigeant ; il n’a pas promis que ces conditions suffisaient au trajet réel. Une reprise apparemment réussie peut donc déplacer le problème, d’un refus explicite vers une absence de données plus difficile à interpréter.

La requête comporte aussi une contrainte de proximité : elle doit partir avec un TTL de 255, et l’agent étranger vérifie cette valeur. Un routeur IP traversé la diminue. Ce contrôle limite certaines tentatives d’usurpation d’enregistrement depuis l’extérieur du lien, mais ne prouve pas l’identité d’un voisin présent sur le même lien.

À l’autre bout, l’agent d’origine doit implémenter une vérification de l’association et devrait l’activer par défaut. La source extérieure doit correspondre à l’adresse de rattachement enregistrée, la source intérieure à l’adresse d’origine du mobile, et le mode d’encapsulation à celui convenu. Un paquet sans association correspondante ou avec une encapsulation incorrecte doit être écarté.

Ces contrôles bornent le service de transit. Ils ne transforment pas chaque paquet en message authentifié cryptographiquement. La précision des messages compte également : un erratum technique vérifié du RFC 3024 corrige, dans le passage sur la mise à jour de l’association, « réponse » en « requête » d’enregistrement. Confondre les deux inverserait le rôle du message dans le changement d’état.

Le contexte ne disparaît pas dans le tunnel

L’annexe du RFC 3024 étend l’analyse à certains espaces d’adresses distincts. Elle n’offre pas une solution universelle aux adresses privées qui se chevauchent. Les agents doivent encore partager un espace dans lequel ils peuvent se joindre, et les adresses intérieures doivent avoir le sens requis dans leurs domaines respectifs.

Des adresses d’origine privées identiques derrière des agents différents peuvent être distinguées à l’aide du contexte approprié. Mais l’agent étranger a aussi besoin d’une association locale sûre avec le bon mobile. La section de sécurité exige une identification fiable au niveau liaison pour cet arrangement et déconseille un Ethernet partagé non authentifié.

Le tunnel ne crée donc pas une identité globale là où il n’y en avait pas. Il transporte un paquet entre contextes, dont les frontières restent importantes. Le RFC 5944, en novembre 2010, renvoie encore au tunnel inverse pour le problème du filtrage d’entrée. Cette continuité documente la persistance du besoin, pas une mesure de déploiement.

La limite la plus nette était présente dès le départ : le RFC 3024 ne prétend pas résoudre de manière générale le franchissement des pare-feu. Il explique comment faire coïncider une source extérieure avec un trajet, pas comment obtenir un droit universel de passage. Deux enveloppes peuvent clarifier les responsabilités ; elles ne les abolissent pas.