Résumé

  • La documentation officielle de l'API Abuse Contact Finder de RIPEstat prévient elle-même que le contact d'abus retourné est « dans de nombreux cas incorrect ou non disponible ».
  • Avant 2015, l'outil affichait une fiabilité de une à cinq étoiles selon l'origine de la donnée ; cette notation a été retirée, laissant une seule adresse non qualifiée.
  • La recherche fonctionne de bas en haut et retourne le premier abuse-c trouvé dans la hiérarchie, pas nécessairement celui de l'opérateur capable d'agir.
  • Des bugs documentés ont fait retourner abusivement l'adresse de remplacement du registre à cause de données d'espace réservé.
  • L'exactitude de la couche d'acheminement n'a fait l'objet d'aucune mesure indépendante publiée depuis la retraite de la notation.

L'avertissement qui figure dans la documentation officielle

Le point d'entrée Abuse Contact Finder de l'API de données RIPEstat a une fonction unique : retourner, pour un préfixe, une adresse IP ou un ASN, les adresses de contact d'abus dédiées et le RIR faisant autorité. Sa documentation comporte une phrase que peu d'outils d'infrastructure critiques s'autorisent : le but principal est de retourner les informations de contact d'abus, et « notez que cette information est dans de nombreux cas incorrecte ou non disponible » [0].

Ce disclaimer n'est pas une réserve de forme. Il résume une décennie d'histoire technique que le RIPE NCC a lui-même documentée : une couche d'acheminement construite sur des données déclaratives, dont la qualité n'a jamais été mesurée de façon indépendante, et dont l'unique indicateur public de fiabilité a été supprimé.

L'échelle à cinq étoiles qui a été retirée

Avant 2015, l'Abuse Contact Finder de RIPEstat affichait une cote de fiabilité à cinq étoiles, fondée sur l'endroit de la base de données où le contact avait été trouvé. Cinq étoiles : un abuse-c conforme à ripe-563 sur l'adresse IP interrogée. Quatre : un abuse-mailbox dans un objet connexe. Trois : un contact trouvé uniquement dans un attribut remarks. Deux : un abuse-mailbox trouvé seulement dans un objet plus spécifique ou en amont, qui « pourrait ne pas être le contact correct ». Une : un contact « peu probable » d'être correct [1].

Depuis 2015, l'outil « ne fournit plus d'heuristiques de notation. Il affiche uniquement l'adresse e-mail du abuse-c telle que spécifiée dans le document RIPE 563 » [1]. L'incertitude n'a pas disparu avec l'échelle ; c'est l'affichage de l'incertitude qui a disparu. Le plaignant reçoit désormais une adresse non qualifiée, accompagnée d'un disclaimer général au niveau de l'API.

Le premier abuse-c trouvé n'est pas forcément le bon destinataire

Les outils de recherche de contact d'abus du RIPE NCC fonctionnent de bas en haut : ils cherchent les références abuse-c dans les objets ORGANISATION liés aux objets INET(6)NUM et « retournent le premier trouvé. Si une référence abuse-c est trouvée, seule celle-ci sera retournée » ; les attributs abuse-mailbox historiques ne sont pas considérés [2].

Ce choix mécanique a une conséquence structurelle : le contact retourné est le plus spécifique enregistré dans la base, pas nécessairement celui de l'opérateur qui peut effectivement bloquer l'abus. Pour une IP revendue ou louée, le plus spécifique peut être un client final dont le mailbox est inactif, alors que l'opérateur en amont contrôle le trafic. La base ne distingue pas les deux.

L'histoire documentée des bugs

L'ancien Abuse Finder heuristique effectuait de 30 à 150 requêtes distinctes dans la base RIPE par consultation [3]. Deux bugs documentés illustrent la fragilité de cette chaîne : des données d'espace réservé « ont fait que l'outil retournait fréquemment et incorrectement l'adresse d'abus de repli du registre », et des résultats sans rapport avec l'entrée étaient retournés parce que les clés primaires et indexées ne sont pas uniques entre les types d'objets [3].

Le RIPE NCC a lui-même qualifié l'ancien comportement de « suggestion du mieux possible », qui « s'est avérée peu fiable et contestée » [2]. Il déconseille de contourner l'outil en interrogeant directement la base et en envoyant la plainte à toutes les adresses trouvées, jugeant ce contournement contre-productif [2], et sa documentation précise qu'une plainte « ne sera pas traitée plus rapidement en copiant votre message à toute autre adresse e-mail trouvée dans la base » [4].

Ce que la validation mesure — et ne mesure pas

La proposition de politique 2017-02 a documenté le problème d'exactitude derrière l'abuse-c : ripe-563 ne prévoyait aucune validation, le RIPE NCC recevait plusieurs centaines de signalements de contacts invalides chaque année, et un test préliminaire aléatoire indiquait que 10 % à 25 % des attributs abuse-mailbox « pourraient être incorrects ou inactifs », sur environ 70 000 attributs distincts [5].

La validation automatisée introduite par 2017-02 vérifie la syntaxe, le domaine et la configuration du serveur de messagerie, et reconnaît elle-même « des faux négatifs et des faux positifs possibles » [5]. Le RIPE NCC l'a formulé sans détour : « la nature de notre validation est de vérifier qu'il y a un e-mail fonctionnel dans la base RIPE et qu'il correspond à un serveur qui peut accepter des e-mails. Nous n'avons rien à dire sur ce que les opérateurs font des rapports d'abus qu'ils reçoivent » [6].

À RIPE 80 en 2019, 71 711 des 77 168 adresses distinctes (93 %) passaient la validation automatisée, 5 457 (7 %) l'échouaient — et les modes de défaillance listés incluaient des faux e-mails d'une autre organisation, des boîtes jamais lues et des employés inexistants [7].

Autrement dit : la validation mesure la délivrabilité ; l'exactitude de l'acheminement — est-ce la bonne boîte, la bonne entité — n'est testée par aucun mécanisme. Un abuse-c valide dans la base « ne garantit pas que le contact soit la destination correcte ou efficace d'une plainte » [6].

Une correction jamais encadrée

Sur la page RIPE Labs consacrée à l'outil, une réponse du personnel du RIPE NCC reconnaissait qu'il n'existait « aucune procédure permettant aux utilisateurs ou au RIPE NCC de corriger ou valider les contacts d'abus » fournis par les détenteurs de ressources [1]. Aujourd'hui, le RIPE NCC propose un formulaire pour signaler un contact invalide ou manquant [8] ; mais la correction d'un contact valide mais erroné — le cas le plus insidieux pour le plaignant — reste non documentée.

Ce que cela signifie pour le plaignant

La guidance publique du RIPE NCC prévient : le contact affiché par RIPEstat est celui du réseau auquel l'adresse IP appartient — « un FAI ou un autre opérateur de réseau, pas le fauteur d'abus ! » [8]. Trois couches d'incertitude se superposent donc : l'outil retourne-t-il la bonne entité (exactitude d'acheminement, jamais mesurée) ; le mailbox existe-t-il (délivrabilité, validée annuellement) ; quelqu'un le lit-il (réponse, jamais testée). Un plaignant n'a aucun moyen public de distinguer ces trois défaillances après coup.

C'est le même fil que celui documenté dans la couverture antérieure de BTW sur la validation annuelle, la séparation mesure/remède et la chaîne de recours RIPE-858 — vu ici depuis la couche que le plaignant touche en premier : l'outil de recherche lui-même. Sa précision est le maillon non mesuré d'une chaîne dont tous les autres maillons ont au moins un indicateur.