Résumé

  • Le 8 septembre 2026, le RFC Editor a enregistré l’accord de l’auteur et indiqué que le futur RFC 10040 pouvait être préparé pour publication. Le 9 septembre, le texte restait néanmoins en Final Review : il ne s’agit pas encore d’un RFC publié.
  • Le nouveau type Geo-Location du LISP transporte un point, un Geo-Prefix plus grossier et une incertitude explicite. Politique d’accès, chiffrement et signature LISP-SEC protègent chacun une partie de la distribution.
  • La signature rattache la Map-Reply au Map-Replier ; elle ne certifie ni l’origine de la mesure, ni sa date, ni la méthode qui fonde l’incertitude. Toute décision reposant sur la réalité physique du lieu devrait conserver un reçu de provenance du positionnement.

Une dernière validation éditoriale, pas une validation du terrain

Le jalon du 8 septembre est précisément délimité. La Final Review de draft-ietf-lisp-geo a commencé le 31 août. La file du RFC Editor note l’accord de l’Area Director et la mise à jour du registre IANA le 4 septembre, puis l’accord de Dino Farinacci le 8. L’indication opérationnelle est désormais « Ready to prepare document for publication ». Pourtant, l’état demeure « In Final Review ». Le texte est donc le futur RFC 10040, destiné au statut Experimental, et non un RFC déjà publié ou un Proposed Standard.

Cette étape sert à stabiliser le document. Les auteurs et le RFC Production Center règlent les questions éditoriales ; une modification réellement technique doit remonter au responsable du flux. Les points visibles—terminologie, référence à WGS 84, section citée par IANA, formulation de la signature—montrent un texte presque sorti de l’atelier institutionnel.

Cette finition crée aussi un risque d’interprétation. Un numéro de type, un schéma binaire et une signature donnent à l’objet l’apparence d’une preuve homogène. Or les propriétés n’ont pas toutes la même source. Une Map-Reply peut être authentique et son contenu inaltéré, tandis que la latitude qu’elle transporte reste une déclaration dont l’observation physique n’est pas documentée dans le protocole.

Le type 17 encode une affirmation géographique

Le futur RFC définit le type 17 du LISP Canonical Address Format et remplace l’ancien mécanisme Geo-Coordinates du RFC 8060. Une entrée peut représenter un Geo-Point ou un Geo-Prefix. Le premier conserve la précision d’un point ; le second désigne volontairement une zone. Le champ Location Uncertainty, exprimé en centimètres, permet d’indiquer une incertitude de rayon et d’altitude.

Ces choix améliorent la description. Ils ne racontent pas la fabrication de la donnée. Une coordonnée peut venir d’un instrument de géomètre, d’un récepteur GNSS, d’un inventaire configuré, d’un fournisseur ou d’une saisie humaine. Une valeur d’incertitude peut résulter d’un calcul, d’une marge de prudence ou d’une estimation. Le format accueille chacune de ces valeurs sans pouvoir les rendre équivalentes.

Il faut donc conserver la chaîne des actes. Un système de positionnement produit l’observation. Un mapper l’associe à un EID ou à un RLOC. Un Map-Replier signe la réponse construite. Appeler l’ensemble « position signée » efface les responsabilités intermédiaires et prête à la cryptographie une connaissance du terrain qu’elle ne possède pas.

Le RFC 6280 distingue justement positionnement, distribution et utilisation. L’authenticité de la transmission depuis un créateur ne suffit pas à établir la vérité matérielle de ce qu’il a créé. Cette séparation, abstraite dans un modèle d’architecture, devient concrète dès qu’une coordonnée peut guider une opération réseau ou une décision administrative.

LISP-SEC ferme un lien de confiance, pas toute la chaîne

Le projet prévoit que la décision d’accès soit normalement prise par la politique locale du xTR. Si un Mapping Service Provider répond à sa place, il doit appliquer cette politique. Un requérant autorisé peut recevoir une Map-Reply signée selon LISP-SEC et, si le déploiement le prévoit, chiffrée. L’origine de la réponse, son intégrité et la limitation de sa diffusion gagnent ainsi des protections sérieuses.

Mais la signature ne dit pas si la mesure date de quelques secondes ou de plusieurs mois. Elle ne montre pas l’étalonnage du capteur, le déplacement éventuel de l’actif, une faute de transcription ou le calcul réel du rayon d’incertitude. L’autorisation répond à « qui peut lire cette affirmation ? ». Elle ne répond pas à « cette affirmation décrit-elle encore le monde ? ».

Le texte reconnaît d’ailleurs plusieurs relations de confiance. Il avertit que des coordonnées peuvent suivre des hôtes lorsque les EID sont attribués aux hôtes. Geo-Prefix, TTL court, authentification et contrôle d’accès permettent de réduire la précision, la durée et le cercle de divulgation. L’applicabilité ordinaire évoque des bâtiments publics et des repères, non des personnes, véhicules ou équipements. La minimisation est utile ; elle ne remplace ni la provenance ni les règles d’usage ultérieur rappelées par le RFC 6973.

Joindre un reçu au moment où le lieu devient une preuve

Le complément nécessaire n’a pas à alourdir le protocole de cartographie. Il peut prendre la forme d’un reçu portable, adjacent à la Map-Reply. Dès qu’un opérateur, un assureur, un service d’urgence, un régulateur ou un automate agit parce qu’un actif est déclaré à un endroit, il doit pouvoir connaître la qualité de l’observation qui fonde cette déclaration.

Le reçu devrait nommer le sujet ou l’actif, la méthode de positionnement, le capteur ou la source amont, l’heure d’observation, le référentiel de coordonnées, la méthode d’estimation de l’incertitude, le mapper, le signataire, l’époque de la politique d’accès, la règle d’expiration et le résultat de toute vérification postérieure. Les traces brutes peuvent rester confidentielles. Une classe d’assurance, un engagement cryptographique ou une référence d’audit peut suffire selon le contexte. Il faut surtout empêcher que la condition de production disparaisse au moment de la décision.

C’est ma proposition de gouvernance, et non une exigence de l’IETF. Imposer au futur RFC 10040 de certifier tous les capteurs ferait sortir un format d’interopérabilité de son rôle. Déduire la vérité physique d’une signature valide ferait sortir la signature du sien.

Le miroir politique décrit par Heng Lu permet de suivre le transfert. Le mapper choisit source et précision ; le xTR ou son mandataire choisit la divulgation ; le Map-Replier signe ; l’utilisateur supporte les effets d’une coordonnée périmée ou faiblement sourcée. Le reçu remet ces choix dans le même dossier que leurs conséquences. Il respecte aussi une discipline de running code : garder le mécanisme commun étroit, puis ajouter une preuve explicite là où le code acquiert un pouvoir institutionnel.

Sources