Résumé

  • Selon Tata Communications, un client était renvoyé vers des portails français alors que l’enregistrement RIR était exact et que plusieurs bases Geo-IP indiquaient la bonne localisation.
  • Deux mois environ de relances n’avaient pas suffi à faire corriger la base externe utilisée par un portail : la qualité du registre et l’exécution de la correction relèvent de deux chaînes différentes.

On imagine volontiers une correction de géolocalisation comme une ligne droite : l’opérateur rectifie son enregistrement, les bases le lisent, les sites cessent de se tromper. Le retour d’expérience exposé pendant le Cooperation SIG d’APNIC 62 ressemble plutôt à une série de portes, chacune gardée par une organisation différente.

Le client évoqué par Tata Communications arrivait sur des portails web français. La vérification du registre RIR n’a pas révélé d’erreur à corriger. Plusieurs bases de l’industrie donnaient elles aussi la localisation attendue. Pourtant, le site nommé GEOLOCATION.com dans les diapositives continuait de placer l’adresse en France. Ce site dépendait d’un fournisseur Geo-IP extérieur. Après environ deux mois de suivi, ce fournisseur n’avait toujours pas intégré la mise à jour, d’après la présentation. Tata n’avait pas la main sur cette dernière opération.

Ce cas restreint mérite précisément de le rester. Les diapositives de Tata Communications ne donnent ni le préfixe, ni le nom du client, ni celui du fournisseur, ni le nombre d’utilisateurs touchés, ni l’issue finale. Le rapport d’APNIC 62 confirme le cadre de la session, pas une enquête contradictoire. On ne peut donc en déduire ni un taux d’erreur, ni une faute juridique, ni même que la situation n’a jamais été résolue.

Il suffit néanmoins à révéler un problème de commande. Le RIR conserve des informations sur les ressources Internet et leur titulaire. Un fournisseur Geo-IP fabrique une estimation à partir de ses propres sources, règles et calendriers. Un portail consomme ensuite une version donnée de cette estimation. Le premier registre peut être impeccable tandis que la deuxième base reste ancienne et que le troisième acteur ignore même la date de sa copie.

Les mécanismes normalisés améliorent le point de départ. RFC 8805 permet à un réseau de publier un flux de géolocalisation. RFC 9632 organise la découverte de ces geofeeds via le RPKI et RFC 9877 leur apporte une validation. Ils rendent une déclaration plus facile à trouver et à authentifier. Ils n’imposent pas aux fournisseurs commerciaux une fréquence de collecte et ne prouvent pas qu’un portail utilise leur dernière édition.

Le projet de rapport d’atelier de l’IAB sur la géolocalisation IP décrit des mises à jour parfois manuelles ou asynchrones, des positions périmées pendant des semaines ou des mois et l’absence d’une boucle de retour normalisée entre FAI et fournisseurs. Le texte a été transmis au RFC Editor mais demeure un Internet-Draft, sans consensus IETF ni statut de position de l’IAB. Il éclaire un mode de défaillance ; il ne mesure pas sa fréquence.

La correction utile n’est donc pas une nouvelle prétention à l’autorité. C’est un accusé de traitement sobre et respectueux de la vie privée. L’opérateur transmettrait une preuve associée à une ressource suffisamment minimisée. Le fournisseur accuserait réception, accepterait ou rejetterait la demande avec un motif, puis indiquerait la version de base dans laquelle la décision apparaîtra. Le portail pourrait déclarer la version qu’il exploite. Entre ces étapes, le silence deviendrait un état visible plutôt qu’un délai indéfini.

Un tel reçu n’exige pas qu’APNIC certifie la position physique d’une adresse. Il distingue au contraire l’information de registre, l’affirmation de l’opérateur, la décision du fournisseur et le déploiement du client. C’est cette séparation qui permet d’attribuer le retard sans fabriquer une responsabilité que les faits ne démontrent pas.

Cette distinction change aussi le diagnostic. Une équipe d’assistance peut avoir vérifié l’inscription RIR, produit un geofeed et reproduit la mauvaise redirection. Le fournisseur peut avoir reçu la demande tout en la réservant à son prochain cycle de collecte. Le portail peut ensuite conserver en cache une édition plus ancienne. Chacun décrit honnêtement son propre état ; personne ne voit l’état complet. Sans référence commune, « reçu », « accepté », « publié » et « déployé » finissent par être confondus.

Une procédure structurée réduirait également la collecte excessive de preuves. Aujourd’hui, un opérateur peut envoyer captures d’écran, traceroutes, adresses et éléments relatifs au client à une boîte de contact générique, sans savoir ce qui sera jugé pertinent. Le fournisseur devrait pouvoir indiquer le type d’affirmation qu’il examine, la preuve retenue et le motif d’un éventuel désaccord. L’objectif n’est pas de rendre l’affirmation de l’opérateur obligatoire, mais de rendre le différend intelligible.

Les rôles peuvent ainsi rester spécialisés. Le système RIR et le RPKI établissent le contrôle d’une ressource et l’origine d’un geofeed. Le fournisseur conserve la liberté de confronter cette déclaration au routage, à la latence, à l’infrastructure et à ses propres observations. Le portail choisit le niveau de fraîcheur qu’il achète et déploie. Le reçu ne centralise pas la vérité ; il relie des décisions qui resteraient autrement invisibles les unes aux autres.

Il faut enfin éviter de renvoyer automatiquement l’utilisateur vers le RIR. Lorsque l’inscription est déjà correcte, ce conseil forme une boucle. Le service qui applique la géolocalisation devrait nommer la source effective de son jugement, donner une voie de recours et prévoir une preuve alternative pour les décisions à forte conséquence. Une préférence de langue et un refus d’accès ne justifient pas le même niveau de confiance.

Sources

Cette distinction change aussi le diagnostic. Une équipe d’assistance peut avoir vérifié l’inscription RIR, produit un geofeed et reproduit la mauvaise redirection. Le fournisseur peut avoir reçu la demande tout en la réservant à son prochain cycle de collecte. Le portail peut ensuite conserver en cache une édition plus ancienne. Chacun décrit honnêtement son propre état ; personne ne voit l’état complet. Sans référence commune, « reçu », « accepté », « publié » et « déployé » finissent par être confondus.

Une procédure structurée réduirait également la collecte excessive de preuves. Aujourd’hui, un opérateur peut envoyer captures d’écran, traceroutes, adresses et éléments relatifs au client à une boîte de contact générique, sans savoir ce qui sera jugé pertinent. Le fournisseur devrait pouvoir indiquer le type d’affirmation qu’il examine, la preuve retenue et le motif d’un éventuel désaccord. L’objectif n’est pas de rendre l’affirmation de l’opérateur obligatoire, mais de rendre le différend intelligible.

Les rôles peuvent ainsi rester spécialisés. Le système RIR et le RPKI établissent le contrôle d’une ressource et l’origine d’un geofeed. Le fournisseur conserve la liberté de confronter cette déclaration au routage, à la latence, à l’infrastructure et à ses propres observations. Le portail choisit le niveau de fraîcheur qu’il achète et déploie. Le reçu ne centralise pas la vérité ; il relie des décisions qui resteraient autrement invisibles les unes aux autres.

Il faut enfin éviter de renvoyer automatiquement l’utilisateur vers le RIR. Lorsque l’inscription est déjà correcte, ce conseil forme une boucle. Le service qui applique la géolocalisation devrait nommer la source effective de son jugement, donner une voie de recours et prévoir une preuve alternative pour les décisions à forte conséquence. Une préférence de langue et un refus d’accès ne justifient pas le même niveau de confiance.

Sources