Résumé

  • Un article du blog de LACNIC sépare les adresses martiennes, les bogons liés au statut des ressources et les annonces RPKI Invalid. Il s’agit d’une contribution d’expert dont l’auteur précise que ses opinions ne représentent pas nécessairement LACNIC.
  • La même chaîne de filtrage peut rencontrer ces trois catégories, mais chacune dépend d’une preuve différente : registre d’adresses à usage spécial, état des ressources et vue de validation RPKI.
  • RFC 6811 rattache l’état Invalid aux données ROA validées par le cache du routeur ; le document laisse la réponse de politique locale à l’opérateur et ne valide pas le chemin AS.
  • Un compte rendu agrégé devient vérifiable s’il garde l’horodatage, la source et le contexte de décision de chaque catégorie, sans révéler préfixes, voisins, clients ou configurations.

Une liste n’est vraie qu’à une date donnée

Le texte de LACNIC consacré aux martiens, bogons et RPKI Invalids propose une précaution simple : ces mots ne décrivent pas le même fait. Les martiens renvoient à des adresses réservées à des usages particuliers. Les bogons, dans l’emploi décrit par l’auteur, renvoient notamment à de l’espace dont le statut de délégation ou d’attribution n’est pas celui attendu. Les RPKI Invalids concernent une annonce et l’autorisation de son origine par rapport aux ROA disponibles.

Cette clarification ne doit pas être transformée en règle attribuée à LACNIC. Sergio Kleiman signe l’article en son nom et indique expressément que les opinions présentées ne reflètent pas nécessairement celles de LACNIC. Le billet ne démontre pas non plus qu’un opérateur de la région applique une politique donnée, qu’un incident a eu lieu, ou qu’un volume déterminé a été filtré. Il fournit plutôt un bon test de méthode : avant de tirer une conclusion d’un refus, identifier le registre ou le cache qui soutenait ce refus et l’instant auquel il a été consulté.

Pour les martiens, cette preuve est liée à un registre de propriétés. Le registre IANA des adresses IPv4 à usage spécial expose la surface d’autorité pertinente pour IPv4. Une procédure de filtrage peut s’appuyer sur ces propriétés ; son reçu devrait alors conserver la version, ou au moins le moment de récupération, qui était applicable. Dire qu’une adresse était classée à usage spécial sans dater la donnée fait disparaître une partie du fait.

Pour les bogons de statut, le temps est différent. Le billet rappelle que les données évoluent lorsque les registres mettent des ressources à disposition ou les délèguent. Une liste fondée sur cet état doit donc pouvoir être rapprochée d’un instantané de ressource. Une entrée retirée aujourd’hui peut expliquer une décision d’hier, sans rendre cette décision automatiquement juste ou fausse après coup. Le point important n’est pas qu’une liste soit « bonne » en général, mais qu’elle soit identifiable pour l’observation concernée.

Pour RPKI, l’horloge est celle de la vue validée du routeur. RFC 6811 définit Invalid lorsqu’une annonce est couverte par des données ROA validées mais qu’aucune autorisation d’origine ne correspond à la paire préfixe-AS observée. Le RFC prévoit aussi que les caches locaux puissent diverger selon leurs mises à jour ou leurs récupérations. Deux limites doivent rester visibles : le traitement d’un résultat est un choix de politique locale, et la validation d’origine ne constitue pas une validation du chemin.

Un seul compteur peut avoir une utilité de supervision. Il ne permet pas, à lui seul, de conclure que des routes ont eu la même cause, qu’elles présentent le même risque, ou qu’elles exigent la même correction. La fusion des catégories devient surtout trompeuse lorsque le compteur se transforme en preuve de protection uniforme. La donnée de base devrait laisser un lecteur distinguer le changement d’une source, celui d’une vue RPKI et celui d’une règle locale.

Un reçu discret vaut mieux qu’une divulgation de réseau

Il n’est pas nécessaire de publier une table BGP, des noms de pairs, des tickets ou une configuration pour produire cette distinction. Un reçu agrégé peut indiquer, pour chaque catégorie, le type de source et sa version ou son instantané, l’heure de récupération et l’heure de l’observation, la famille d’adresses, le sens entrant ou sortant, une classe large de voisin, l’action locale et une classe d’exception. Il peut ajouter un nombre global, le rythme de rafraîchissement et un canal de correction.

Ce format est suffisamment précis pour qu’une évolution soit examinée, tout en restant prudent pour les personnes et les réseaux concernés. Il évite surtout une erreur de remédiation : un changement de statut de ressource, une autorisation d’origine à examiner et une propriété d’adresse spéciale ne se corrigent pas au même endroit. Une statistique commune peut rester en tête de tableau, mais son reçu doit conserver ces trois horloges.

Sources