Résumé

  • draft-ietf-lisp-site-external-connectivity-05 prévoit qu’un système de cartographie LISP renvoie un ensemble non vide de localisateurs pETR quand la destination est externe, inconnue ou connue mais non enregistrée.
  • Cette réponse établit une sortie admissible dans un IID et sous une politique donnée. Elle ne transforme pas le trou de cartographie en connaissance de la destination et ne certifie pas le chemin natif après le pETR.
  • Un audit utile doit séparer l’enregistrement, la décision du serveur, l’état du cache de l’ITR, la décapsulation à la passerelle et le résultat applicatif.

Imaginons un ITR qui reçoit un paquet vers une adresse dont aucune entrée LISP plus précise n’existe. Le système de cartographie ne sait pas si cette adresse correspond à un EID actif. Pourtant, il renvoie plusieurs RLOC de passerelles de sortie, assortis de priorités et de poids. L’ITR installe l’entrée, encapsule le trafic et annonce une résolution réussie.

Le mot « résolution » est alors trop généreux. Le mécanisme a résolu une question locale — par quelle porte essayer de sortir — et laissé intactes les questions externes : l’adresse existe-t-elle, le pETR possède-t-il encore une route, un filtre laissera-t-il passer le paquet, le service distant répondra-t-il ?

La révision 05, déposée le 30 septembre 2026 comme travail expérimental, rend cette frontière particulièrement visible. Elle réutilise les procédures de réponse négative de RFC 9301 pour calculer un « trou » non-LISP, puis exige un nombre de RLOC non nul dans la réponse : les localisateurs désignent des pETR capables, selon l’enregistrement ou la politique, de relayer le trafic vers l’extérieur.

Une absence devenue décision de routage

Dans RFC 9301, une réponse négative possède un ensemble de localisateurs vide et une action bornée dans le temps. Elle peut notamment inviter à transmettre nativement, à abandonner ou à renouveler la recherche. La nouvelle proposition ne prétend pas que l’EID manquant est soudain enregistré. Elle associe la classe « externe ou inconnue » à une sortie proxy.

Ce geste ressemble à une route par défaut, avec une différence de gouvernance : la politique, les inscriptions de pETR et les notifications du système de cartographie peuvent modifier le choix sans reconfigurer chaque ITR. La souplesse est réelle. Le déplacement d’autorité l’est aussi.

Il faut donc conserver la qualification initiale. Une base ne devrait pas remplacer destination_status=unknown_or_unregistered par resolved=true. Elle devrait ajouter external_exit_selected, avec l’IID, le nom distingué, le préfixe trou ou défaut, la version de politique, les candidats et l’horodatage.

L’inscription atteste une déclaration, pas l’Internet

Un pETR disposant d’une connectivité externe peut s’inscrire pour un IID de VPN. L’enregistrement contient un nom distingué configurable, un ensemble de RLOC et, éventuellement, un encodage propre au VPN. Il peut aussi transporter des données LCAF spécifiques à un fournisseur : localisation, ressources disponibles ou éléments de performance.

L’inscription prouve qu’un principal admis a envoyé ces éléments et que le serveur les a acceptés. Elle ne prouve pas que la route externe est encore présente au moment du paquet. L’authentification répond à « qui a parlé ? » ; l’autorisation répond à « pouvait-il annoncer une sortie pour cet IID ? » ; la mesure répond à « la sortie fonctionne-t-elle maintenant ? ». Une signature ne fusionne pas les trois réponses.

RFC 9306 fournit l’enveloppe LCAF spécifique au fournisseur, mais laisse à celui-ci l’évaluation des implications de sécurité du format. Les mots « performance » ou « disponibilité » ne définissent donc ni unité commune, ni fenêtre, ni horloge, ni niveau de confiance. Une valeur de configuration et une mesure récente peuvent porter la même étiquette.

Si ces métadonnées influencent le trafic, il faut garder leur producteur, leur schéma, leur méthode, leurs unités, leur instant de collecte et leur durée de validité. Sans cela, elles restent un indice de politique, pas une mesure comparable.

Priorité et poids ne sont pas une preuve de capacité

RFC 9300 donne à chaque localisateur une priorité et un poids. La plus faible priorité gagne ; les localisateurs à priorité égale peuvent recevoir une part relative du trafic. Ces champs commandent le choix de l’ITR. Ils ne démontrent ni la capacité du pETR, ni l’indépendance des chemins, ni la répartition effectivement observée.

Deux RLOC peuvent mener au même châssis ou au même opérateur. Un poids 70/30 peut refléter une intention commerciale plutôt qu’une mesure. Un changement de priorité peut déplacer la juridiction, le coût et le point d’observation sans modifier l’adresse demandée par l’application.

Le reçu de décision devrait donc préserver la liste avant filtrage, les motifs d’exclusion, la valeur de chaque métadonnée, le résultat du classement et la distribution attendue. Les compteurs d’encapsulation, de décapsulation et de transmission native pourront ensuite montrer ce que cette intention est devenue.

L’accusé de notification s’arrête au plan de contrôle

RFC 9437 permet de publier les changements par Map-Notify et d’en accuser réception par Map-Notify-Ack, avec association de sécurité et nonce. À défaut, le projet propose un TTL plus court pour rafraîchir le cache.

Un ACK indique qu’un message de contrôle a été reçu et traité selon ce protocole. Il n’est pas un reçu de programmation matérielle, encore moins de livraison. Un TTL court borne l’âge autorisé de l’état ; il ne garantit pas qu’un nouveau message arrivera. La chaîne opérationnelle complète reste : notification reçue, portée vérifiée, cache écrit, lecture conforme, paquet témoin décapsulé, routage externe observé, canari applicatif réussi.

L’ordre est important. Si la cartographie est saine et le canari applicatif échoue, la divergence situe l’incident après le choix de sortie. Répéter uniquement le contrôle LISP produit davantage de preuves de la première étape, pas la preuve manquante.

Le défaut amplifie la portée

La révision 05 autorise une entrée de trou ou une entrée par défaut. Elle recommande de maintenir des blocs EID connus plus précis afin qu’ils déclenchent toujours une Map-Request. Cette précaution évite qu’un défaut externe absorbe une destination qui devait suivre la résolution LISP ordinaire.

Une entrée par défaut réduit la configuration, mais agrandit le rayon d’impact. Une seule annonce peut déplacer des flux sans rapport entre eux. Le déploiement devrait commencer sur un IID restreint, protéger les préfixes connus, limiter la durée de vie, utiliser quelques ITR canaris et prévoir une démotion ciblée du pETR. Purger tous les caches pour corriger une seule sortie serait transformer une erreur locale en panne générale.

Le registre Datatracker ne fournit encore ni preuve d’implémentation interopérable, ni mesure de convergence, ni adoption. Le cas des infrastructures d’IA cité dans le texte reste un cas d’usage. La conclusion honnête est plus modeste et plus utile : le protocole peut distribuer une décision de sortie pour l’inconnu. Il ne doit pas effacer l’inconnu.

Le principe de spécification initiale minimale de Lu Heng convient ici : normaliser le petit objet nécessaire à l’interopérabilité, laisser les décisions ultérieures locales et observables, et ne pas attribuer au standard l’autorité de certifier la réalité extérieure.

Sources