Résumé
- La requête
190.147.255.0a renvoyé l’objet parent190.144.0.0/14avec deux valeursaut-num, AS14080 et AS10620. Ces valeurs décrivent une projection, non une route en temps réel. - La photographie RPKI voisine comptait quatre VRP de couverture. RIPE RIS observait AS10620 à l’origine de
190.147.255.0/24, et cette route particulière était ROV Valid.
La politique a rapproché WHOIS de RPKI
La section 3.4 du manuel de LACNIC prévoit que l’ASN d’origine des préfixes interrogés figure dans la réponse WHOIS lorsque l’information existe. Le texte issu de LAC-2021-1, mis en œuvre le 28 mars 2022, autorise son extraction du dépôt RPKI en retenant l’origine indiquée dans le ROA.
L’objectif était concret. Une valeur descriptive saisie par un membre pouvait rester inchangée alors qu’un ROA avait été actualisé. Recourir à RPKI réduit ce décalage. En contrepartie, le champ devient le résumé d’un ensemble d’autorisations daté, et non plus seulement une propriété statique du dossier d’allocation.
Un résumé peut être juste sans être vérifiable à lui seul. Il faut encore connaître l’ensemble qui a été résumé et la règle appliquée.
Deux lignes masquent quatre tuples
Le 19 septembre 2026 à 21:59:47 UTC, whois.lacnic.net a répondu à la requête 190.147.255.0 par l’objet alloué 190.144.0.0/14. Deux lignes y figuraient :
aut-num: AS14080aut-num: AS10620
L’exemple interdit deux raccourcis. La sortie actuelle n’écrase pas toujours la pluralité, et l’ordre des lignes ne permet pas de désigner un ASN principal ou unique.
À 21:52:52 UTC, le résultat étendu de LACNIC Routinator pour 190.147.255.0/24 montrait quatre VRP :
| Préfixe VRP | maxLength | Origine autorisée |
|---|---|---|
190.147.0.0/16 |
24 | AS10620 |
190.147.0.0/16 |
24 | AS14080 |
190.144.0.0/14 |
24 | AS10620 |
190.144.0.0/14 |
24 | AS14080 |
Chaque ligne RPKI possédait en outre l’URI de son ROA et ses périodes de validité. Les deux aut-num étaient donc compatibles avec l’état observé. Le problème n’est pas une valeur fausse : c’est l’absence, dans la réponse, des deux niveaux de préfixe, du maxLength 24, de l’identité de la photographie et de la règle de projection.
Une autorisation n’est pas une annonce
RFC 6811 définit un VRP par un préfixe, une longueur maximale et un ASN d’origine. Une route est Valid lorsqu’au moins un VRP la couvre et correspond à sa longueur ainsi qu’à son origine. RFC 9582 précise qu’un ROA identifie un AS autorisé ; deux origines autorisées supposent donc plusieurs ROA.
La photographie BGP apporte une autre information. La réponse BGP-state de RIPEstat contenait 327 chemins observés pour 190.147.255.0/24, tous terminés par AS10620. Pour cette route, les deux VRP d’AS10620 correspondaient ; ceux d’AS14080 couvraient toujours le préfixe mais ne correspondaient pas à l’origine. Routinator a rendu Valid.
AS14080 aurait lui aussi produit Valid s’il avait été l’origine de la route testée. Cela ne signifie pas que les deux AS annonçaient le /24 au moment observé. L’un était vu dans BGP ; les deux étaient autorisés dans RPKI.
Il faut donc conserver cinq objets distincts : le champ WHOIS, l’ensemble complet des VRP de couverture, chaque tuple préfixe/maxLength/ASN, l’origine BGP effectivement vue et le résultat ROV calculé pour cette route. Les confondre transforme une permission en observation.
Le reçu d’une projection
WHOIS n’a pas à devenir un collecteur BGP, et LACNIC n’a pas à choisir les routes d’un opérateur. Un reçu compact suffit. Il doit enregistrer la requête et le préfixe normalisé, l’objet d’allocation renvoyé, puis tous les tuples ayant participé à la projection. Il doit lier cet ensemble au validateur, à l’heure de génération, à une identité de session ou de photographie et à une empreinte de l’ensemble. L’URI ou l’empreinte du ROA peut compléter la provenance.
Le reçu doit aussi nommer son état : vide, unique, multiple, partiel ou périmé. Une échéance empêche une ancienne liste de survivre indéfiniment à ses autorisations. Une référence de remplacement préserve l’histoire sans faire passer l’ancien état pour le présent.
Enfin, il doit annoncer sa limite : pas d’observation BGP, pas de preuve que tous les ASN autorisés annoncent, pas de préférence de route et pas de décision locale. L’origine observée et ROV restent une comparaison séparée.
Conserver le pluriel, montrer sa preuve
Dans ce cas, LACNIC a conservé les deux origines autorisées. L’amélioration souhaitable n’est donc pas d’en élire une, mais d’expliquer le pluriel. Aujourd’hui, il faut rapprocher WHOIS, Routinator et RIPE RIS pour reconstituer la chaîne. Un reçu leur donnerait un identifiant et une borne temporelle communs sans fusionner leurs fonctions.
Le champ dit AS14080 et AS10620. Le reçu ajouterait les couvertures /16 et /14, le maxLength 24, les objets sources et la règle de sélection. BGP indiquerait ensuite AS10620 comme origine vue, et ROV dirait que cette route correspond à au moins une autorisation. Chaque couche devient plus fiable lorsqu’elle cesse de parler au nom des autres.
Sources
- Proposition LAC-2021-1 de LACNIC
- Manuel des politiques de LACNIC, section 3
- Manuel des politiques de LACNIC v2.21 en PDF
- Présentation du WHOIS de LACNIC
- État de LACNIC Routinator
- Résultat VRP étendu de LACNIC Routinator
- Validation d’AS10620 pour 190.147.255.0/24
- Validation d’AS14080 pour 190.147.255.0/24
- État BGP RIPEstat de 190.147.255.0/24
- RFC 6811 : validation de l’origine des préfixes BGP
- RFC 9582 : profil des autorisations d’origine
- RFC 7115 : exploitation de la validation d’origine fondée sur RPKI
- RFC 8210 : protocole RPKI-Router
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
