Résumé

  • RFC 3102 donnait à un hôte privé une adresse publique entière, ou une adresse partagée accompagnée de ports, tout en laissant à la passerelle le pool, le bind, le bail et la politique.
  • L’adresse devenait visible dans la pile de l’hôte, mais elle ne disait toujours ni qui possédait durablement la ressource, ni quel chemin était local, ni si les paquets revenaient.

Un prêt au lieu d’une réécriture cachée

Le NAT traditionnel faisait disparaître la décision dans l’équipement frontal. L’hôte émettait avec une adresse privée ; le traducteur modifiait l’en-tête et tentait de retrouver l’opération inverse au retour. Cette commodité se payait dès qu’un protocole transportait une adresse dans sa charge utile ou exigeait que certains champs restent intacts.

Les RFC 3102 à 3105 ont essayé une autre répartition. Avant d’ouvrir une communication, l’hôte RSIP s’enregistrait auprès d’une passerelle située entre deux domaines d’adressage. Celle-ci lui prêtait des paramètres du domaine public. L’hôte les installait dans sa propre pile, construisait le paquet avec la source publique et l’encapsulait jusqu’à la passerelle. Celle-ci décapsulait puis acheminait le paquet sans réécrire cette source intérieure.

Deux méthodes fixaient l’étendue du prêt. RSA-IP attribuait une adresse publique unique à un hôte pendant une période donnée. RSAP-IP permettait à plusieurs hôtes de partager la même adresse, chacun recevant des ports qui lui étaient réservés sur cette adresse. Dans les deux cas, l’hôte voyait la ressource. Dans aucun, il n’en devenait le propriétaire permanent.

Cette nuance change la lecture historique. RSIP ne supprimait pas l’intermédiaire ; il déplaçait une partie de l’état vers l’extrémité. L’hôte avait une présence publique provisoire, tandis que la passerelle conservait le réservoir, les règles d’attribution et la capacité d’interrompre le prêt.

Le protocole séparait les preuves

RFC 3103 détaillait une succession d’actes. L’enregistrement produisait un identifiant client. Une réponse d’attribution contenait adresse, ports éventuels, identifiant de liaison, durée du bail, tunnel et politique de flux. D’autres messages servaient à prolonger, interroger, écouter, libérer ou clore la relation.

Chaque acte prouvait quelque chose de limité. Un identifiant client prouvait que la passerelle connaissait une session d’enregistrement. Un bind reliait l’identité locale aux paramètres accordés. Le bail bornait cette relation dans le temps. La politique indiquait les destinations admises. Aucun de ces éléments ne prouvait qu’une route avait été installée, que le tunnel fonctionnait ou que le correspondant avait répondu.

L’autorité restait donc dissymétrique. L’hôte pouvait suggérer une adresse ou un port ; la passerelle pouvait refuser parce que la ressource était occupée, indisponible ou interdite. Si l’hôte utilisait une adresse, un couple adresse-port, une destination ou un tunnel hors de son accord, le paquet devait être rejeté. L’hôte écrivait la source publique ; la passerelle validait l’usage.

Cette architecture donne une règle d’enquête toujours utile : ne jamais condenser demande, attribution, installation et résultat dans une seule colonne « actif ». Il faut suivre le client, le bind, le bail, le chemin et les deux sens du trafic.

La localité devait être décidée avant l’envoi

La connaissance du paramètre public posait une question que la traduction cachée pouvait masquer : faut-il joindre la destination directement dans le réseau privé ou passer par l’interface RSIP et son tunnel ? Sur un sous-réseau simple, le masque suffisait. Dans une topologie plus riche, la passerelle pouvait conserver la liste des réseaux privés et répondre à des requêtes de localité.

Lorsque les routes évoluaient plus vite que la session, l’hôte risquait de devoir interroger la passerelle pour chaque nouvelle destination. RFC 3102 reconnaissait qu’aucune solution générale robuste n’avait été trouvée et que l’ampleur réelle du problème restait inconnue.

Les applications multipartites révélaient le cas le plus difficile. Une partie pouvait transmettre une adresse à une autre en supposant qu’il s’agissait d’un identifiant global. Or le bon choix dépendait du domaine depuis lequel le destinataire regardait. Une adresse privée pouvait être inutile à l’extérieur ; l’adresse publique pouvait obliger deux voisins locaux à repasser par la frontière. Le document ne proposait pas de remède universel.

Ainsi, la localité n’était plus seulement une propriété du routage. Elle devenait une information que l’hôte devait obtenir, dater et appliquer. Une adresse identique n’avait pas la même signification pour tous les participants.

Le bail expirait avant certains états

Le bail limitait le pouvoir de l’hôte et rendait possible la récupération des ressources rares. Il pouvait être prolongé ou libéré ; la passerelle pouvait le laisser expirer ou désallouer le bind. Mais l’horloge administrative n’effaçait pas immédiatement l’état des transports.

TCP pouvait encore conserver un ancien quadruplet dans TIME_WAIT. Réattribuer aussitôt le même port à un nouvel hôte exposait la nouvelle relation aux traces de l’ancienne. La fin du bail et la sécurité de la réutilisation étaient donc deux événements distincts.

Les pannes créaient une autre divergence. Après le redémarrage de l’hôte, la passerelle pouvait garder des liaisons oubliées par celui-ci. Après le redémarrage de la passerelle, l’hôte pouvait croire valides des paramètres que le serveur ne connaissait plus. RFC 3103 prévoyait des échanges de récupération, sans pouvoir faire de la mémoire d’un seul côté une vérité suffisante.

Une vérification sérieuse doit aligner l’heure d’attribution, les prolongations, la libération ou l’expiration, les redémarrages et le premier trafic accepté après réconciliation. Le numéro peut être le même alors que l’autorité a changé.

Une adresse partagée ne pouvait plus désigner un seul acteur

Avec RSA-IP, une mise à jour DNS dynamique ressemblait au cas DHCP : un hôte détenait toute l’adresse pendant son bail. Avec RSAP-IP, plusieurs noms complets pouvaient aboutir à la même adresse, alors que les ports appartenaient à des machines différentes. Le public pouvait supposer, à tort, que tous les services de l’adresse relevaient d’un seul hôte logique. RFC 3102 recommandait donc une grande prudence entre DNS dynamique et partage par ports.

RFC 3104 appliquait la même discipline à IPsec. Plusieurs clients partageant une adresse publique pouvaient initier IKE et IPsec vers un pair ignorant RSIP. L’adresse visible ne pouvait pas servir d’identité du pair. Les identifiants IKE devaient distinguer l’acteur réel.

Au retour, la passerelle séparait les échanges IKE avec le port de destination, le cookie d’initiateur et l’adresse de destination. Pour AH ou ESP, elle utilisait protocole, SPI et adresse. Le SPI devait être unique à la fois chez le client et à la passerelle. L’adresse restait un point de présence, non une preuve d’identité.

Le mécanisme ne couvrait d’ailleurs pas tous les scénarios d’initiation depuis l’extérieur. Il exigeait des adaptations IPsec, et les implémentations « bump-in-the-stack » n’étaient pas censées fonctionner telles quelles. La conservation de l’en-tête ne garantissait donc pas la transparence de l’application.

Trouver une passerelle ne donnait aucun droit sur elle

RFC 3105 utilisait SLP pour annoncer un service service:rsip, ses capacités, sa durée de vie et éventuellement sa charge. Des portées orientaient les clients vers certains serveurs ; un client pouvait choisir celui qui déclarait le moins de connexions.

Cette découverte restait une étape de sélection. Une portée SLP n’était pas un contrôle d’accès. Une annonce ne prouvait pas que le client serait accepté. La mesure de charge pouvait vieillir pendant la décision. Il fallait encore s’enregistrer, recevoir un accord, installer le chemin et observer les paquets.

La chaîne de contrôle était donc distribuée sans être diffuse. L’administrateur influençait la découverte. La passerelle accordait et retirait les paramètres. L’hôte choisissait le chemin local ou public. Le pair distant interprétait l’adresse et les identifiants. Aucun de ces acteurs ne possédait seul la preuve d’un service fonctionnel.

Une expérience qui documentait elle-même ses limites

Les quatre RFC restaient Experimental. La note de l’IESG soulignait les modifications importantes nécessaires aux hôtes et aux passerelles, les difficultés causées par les ports flottants et la complexité opérationnelle. RFC 3102 présentait RSIP comme une correction possible de certains défauts du NAT, non comme une solution durable à la pénurie IPv4. Les sources retenues ne démontrent ni adoption massive ni remplacement du NAT.

L’épisode est néanmoins précieux. Il montre que le partage d’adresses est d’abord une distribution d’état et d’autorité. Rendre l’adresse publique visible à l’hôte obligeait à expliciter inscription, bail, politique, découverte, reprise et localité.

L’adresse prêtée pouvait situer un paquet dans le domaine public. Elle ne disait pas à elle seule qui détenait durablement la ressource, quel chemin convenait, si le pair IPsec était authentique ou si une réponse revenait. La passerelle prêtait l’adresse ; seule une chaîne d’états concordants et de paquets observés rendait ce prêt opérationnel.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html