Résumé

  • RFC 2356 permettait à un pare-feu de rechercher l’identité d’un nœud mobile à partir d’un couple NSID/MKID stable plutôt qu’à partir de son adresse temporaire.
  • Le premier paquet authentifié pouvait être relayé sans négociation préalable, mais seulement si les composantes publiques, la liste d’accès nomade, la liaison dynamique et le chemin Mobile IP étaient cohérents.

Le pare-feu voyait arriver une adresse inconnue. L’organisation, elle, croyait reconnaître son ordinateur. Entre ces deux affirmations s’ouvrait tout le problème traité par G. Montenegro et V. Gupta dans le document informatif publié en juin 1998.

Mobile IP avait déjà séparé deux fonctions. L’adresse permanente, dite adresse mère, conservait le nom réseau du nœud. L’adresse temporaire, ou care-of address, indiquait son point de rattachement du moment. Ce dédoublement permettait à un agent mère d’intercepter puis d’encapsuler les paquets, mais il déstabilisait une politique de filtrage fondée sur l’adresse source. À chaque déplacement, le même équipement pouvait ressembler à un nouvel expéditeur.

RFC 2356 ne prétendait pas établir une norme Internet. Il décrivait une proposition de Sun Microsystems pour un cas précis : une machine appartenant à un réseau privé protégé, connectée provisoirement à l’Internet public avec une adresse temporaire co-localisée. Il ne traitait pas le cas symétrique d’un mobile situé derrière un autre réseau privé. Cette limite importe, car elle empêche de transformer une solution située en architecture universelle.

Le texte opposait d’abord deux manières de franchir la frontière. SOCKS 5 relayait les applications et ajoutait des échanges de contrôle. SKIP, mécanisme de gestion de clés sans session préalable, permettait d’emporter dans chaque paquet de quoi être authentifié. Le pare-feu pouvait donc agir dès le premier paquet authentifié. Mais l’absence d’aller-retour initial n’effaçait pas le travail antérieur : les composantes publiques Diffie-Hellman devaient être préconfigurées ou découvertes dans un annuaire de certificats.

L’innovation utile tenait à un détour. Au lieu d'utiliser l’adresse source comme indice de l’association de sécurité, l’en-tête SKIP pouvait fournir un identifiant de clé composé d’un NSID et d’un MKID. Avec NSID 1, le MKID pouvait reprendre l’adresse mère stable tandis que l’en-tête extérieur transportait l’adresse temporaire. Avec NSID 8, l’identifiant dérivait d’une composante publique Diffie-Hellman non signée; sans autorité de certification, le nom du principal devait néanmoins être communiqué par un canal sûr.

Le pare-feu pouvait alors porter une règle nomadic. Elle ne disait pas : toute adresse est autorisée. Elle disait : quelle que soit l’adresse d’origine observée, examiner ce paquet au titre de cette identité de clé. L’authentification AH — ou un mode ESP assurant aussi cette fonction — devait encore réussir. La politique devait encore permettre la destination et le service demandés. Reconnaître un nom cryptographique ouvrait une évaluation; cela ne donnait pas un droit général.

Lorsque le mobile prenait l’initiative, le pare-feu apprenait une liaison entre l’identité de clé, l’adresse mère et l’adresse temporaire courante. Cette liaison lui permettait de chiffrer ou d’authentifier le trafic de retour vers la bonne interface. Elle restait volontairement simple : la dernière Registration Request remplaçait l’association précédente. Les liaisons Mobile IP simultanées ne fonctionnaient pas sans une compréhension plus profonde du protocole par le pare-feu.

Cette mémoire imposait aussi une géographie d’exécution. Si un pare-feu apprenait la liaison à l’aller, la Registration Reply devait normalement ressortir par le même équipement. Dans une enceinte protégée par plusieurs pare-feux, un trajet asymétrique pouvait rencontrer une frontière dépourvue de l’état nécessaire. Un pare-feu conscient de Mobile IP pouvait reconstruire davantage d’informations depuis la réponse, au prix d’une intelligence protocolaire accrue au milieu du chemin.

La distinction intérieur/extérieur formait une autre décision. Des plages d’adresses pouvaient fournir une règle approximative, mais RFC 2356 reconnaissait que la topologie réelle rendait parfois le verdict ambigu. L’intervention de l’utilisateur était même jugée utile : une personne pouvait savoir qu’elle se trouvait hors du réseau privé alors que l’adresse ne le démontrait pas. L’adresse décrivait une attache; elle ne certifiait ni un lieu physique ni un statut organisationnel.

L’agent mère, qui n’observait pas directement le branchement, recevait des indications grâce à une Traversal Extension ajoutée aux demandes et réponses d’enregistrement. L’extension pouvait décrire les points de passage dans les deux sens et plusieurs pare-feux successifs. Certaines valeurs étaient des indices reçus du sens opposé. Elles annonçaient qu’un passage devait peut-être être ciblé et encapsulé. Elles ne prouvaient pas que le passage avait eu lieu.

Le texte examinait ensuite quatre placements possibles de la confiance. Le chiffrement pouvait couvrir seulement le côté public. Il pouvait rester de bout en bout et réduire le pare-feu au rôle de relais, laissant l’authentification à l’agent mère. Le pare-feu pouvait authentifier une communication chiffrée de bout en bout, mais recevait alors un secret partagé de longue durée. Enfin, deux associations chiffrées séparées pouvaient se terminer au pare-feu, qui voyait le contenu avant de le reprotéger. Un tunnel additionnel pouvait rendre au mobile et à l’agent mère une confidentialité vis-à-vis du pare-feu.

Ces configurations rappellent qu’un paquet chiffré n’est pas nécessairement opaque à chaque intermédiaire. Elles rappellent aussi que l’encapsulation RFC 2003, l’authentification et le chiffrement répondent à des questions différentes. L’encapsulation rend une destination interne transportable à travers une zone où elle n’est pas routée. L’authentification atteste l’origine cryptographique d’un état. Le chiffrement réduit ceux qui peuvent lire. Aucun des trois ne prouve qu’un correspondant a traité la requête.

La partie sécurité plaçait enfin le mobile dans le périmètre étendu du réseau privé. Comme il pouvait simultanément échanger en clair avec l’extérieur pour DHCP ou la facturation, il devait posséder son propre filtrage. Sa compromission ne devenait pas anodine parce que ses paquets étaient authentifiés; elle pouvait au contraire transformer une identité reconnue en passage vers l’intérieur.

L’héritage de RFC 2356 tient dans cette comptabilité. Adresse extérieure observée, adresse mère revendiquée, identifiant de clé, origine de la composante publique, résultat AH ou ESP, décision de la liste d’accès, création de liaison, classification intérieur/extérieur, extension de traversée, enregistrement, relais, remise au correspondant : chacune est une preuve distincte. Dire « le mobile était fiable » les écraserait toutes.