Comment vérifier qui annonce un préfixe IP dans BGP

Ne pas confondre observation, enregistrement et autorisation

BGP montre une route visible, RDAP un enregistrement et RPKI une autorisation d’origine précise.

Les exemples sont pédagogiques ; ils ne décrivent pas une observation de production.

Commencer par observer l’origine du préfixe

Pour savoir quel réseau annonce un préfixe, il faut observer la route et conserver l’heure de la mesure. BGP révèle l’ASN visible à l’origine, sans décider à lui seul qui détient ou peut utiliser la ressource.

IP Prefix: 203.0.113.0/24
Observed BGP Origin: AS64500

203.0.113.0/24
AS64510 AS64520 AS64500

Origin ASN: AS64500

Prefix: 192.0.2.0/24
Origin ASN: AS64500

Étape 1 : noter le préfixe exact

Écrivez le préfixe CIDR, le registre concerné, la date et le point de mesure. Une adresse, une plage enregistrée et un préfixe annoncé peuvent avoir des périmètres différents.

203.0.113.45

203.0.113.0/24

Registered range:
203.0.112.0/23

203.0.112.0/24
203.0.113.0/24

203.0.112.0/23

Étapes 2–3 : consulter les données BGP et identifier l’ASN d’origine

Interrogez plusieurs services de données de routage. Dans un AS path ordinaire, le dernier ASN est généralement l’origine observée ; les AS_SET, les confédérations et les différences de collecte doivent rester explicites.

203.0.113.0/24
AS3356 AS1299 AS64500

AS64500

Étape 4 : comparer BGP et RDAP

RDAP décrit l’enregistrement ; BGP décrit l’annonce courante. Une organisation enregistrée peut confier l’annonce à un fournisseur, et aucune de ces deux sources ne résout seule toute la question juridique.

RDAP:
Prefix: 203.0.113.0/24
Organization: Example Network Ltd.

BGP:
Origin ASN: AS64500

RDAP organization:
Example Enterprise Ltd.

BGP origin:
AS64496 — Example Transit Provider

Étape 5 : vérifier l’autorisation RPKI

Une ROA RPKI autorise un ASN précis pour un préfixe et une longueur maximale. Valid, Invalid et NotFound décrivent la validation de cette relation, pas la sécurité complète du chemin.

ROA:
Prefix: 203.0.113.0/24
Authorized ASN: AS64500

203.0.113.0/24 → AS64500

Expected origin
        ↓
ROA authorization
        ↓
Observed BGP origin

ROA:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64500

Valid

ROA:
203.0.113.0/24 → AS64500

Observed BGP:
203.0.113.0/24 → AS64501

BGP:
203.0.113.0/24 → AS64500

ROA:
None found

Étape 6 : examiner les objets IRR

Les objets IRR décrivent une intention de routage enregistrée. Ils peuvent être anciens ou incomplets : utilisez-les pour corroborer une observation BGP, jamais pour la remplacer.

route: 203.0.113.0/24
origin: AS64500

Étape 7 : rechercher les préfixes plus spécifiques

Une route plus spécifique peut détourner une partie du trafic. Comparez la route annoncée et les routes plus étroites avant de conclure qu’un préfixe entier suit la même origine.

203.0.112.0/23 → AS64500

203.0.113.0/24 → AS64501

Étape 8 : comprendre les origines multiples

Plusieurs origines peuvent être normales lors d’une migration, d’un service anycast ou d’un réseau multihomé. Cherchez l’explication attendue avant de qualifier la situation d’incident.

203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64501

Étape 9 : confronter plusieurs vues BGP

Une vue de collecte ne représente pas toute l’Internet. Répétez la mesure depuis plusieurs collecteurs, régions et moments, et conservez les horodatages.

Étape 10 : relire l’historique

L’historique met en relation les changements d’origine avec les opérations prévues, les incidents et les changements de fournisseur. Il fournit un contexte, pas une preuve automatique de cause.

January:
203.0.113.0/24 → AS64500

May:
203.0.113.0/24 → AS64501

Séparer registre, routage et autorisation

L’état du registre, l’état du routage, l’autorisation RPKI et l’attente interne sont des faits distincts. Les documenter ensemble évite les conclusions trop rapides.

Registry:
Example Company Ltd.

Expected ASN:
AS64500

RPKI:
AS64500 authorized

Live BGP:
AS64501

Ce que BGP ne démontre pas

Une origine BGP ne prouve ni la propriété, ni le droit contractuel, ni l’intention de l’organisation enregistrée. Chaque question demande sa propre source.

Registered organization:
Enterprise A

Origin ASN:
Transit Provider B

Enquêter sur un changement inattendu

Un changement peut venir d’une migration, d’un ASN déplacé, d’une mitigation DDoS, d’anycast, d’une erreur, d’un route leak ou d’une annonce non autorisée. Commencez par établir les faits.

Que faire si l’origine paraît incorrecte ?

Confirmez le préfixe, comparez plusieurs vues, consultez RDAP, RPKI et IRR, relisez l’historique, cherchez les more-specifics puis contactez le réseau concerné avec un relevé daté.

Observed ASN
vs
Authorized ASN

Surveiller ses propres annonces

Une petite liste des préfixes attendus, ASN, états RPKI et origines inconnues rend les écarts détectables avant qu’ils ne deviennent une panne.

Vérifier le routage pendant un transfert

Lors d’un transfert, vérifiez simultanément les données du registre, les ROA, les objets IRR, le reverse DNS, les contacts et les filtres amont. Une mise à jour administrative ne déploie pas une route.

Le schéma de vérification essentiel

Comparez toujours l’origine observée, l’ASN autorisé, l’organisation enregistrée et le dossier interne, puis répétez depuis plusieurs points de vue.

1. Identify the prefix
        ↓
2. Check RDAP
        ↓
3. Check live BGP
        ↓
4. Identify origin ASN
        ↓
5. Check RPKI
        ↓
6. Review IRR
        ↓
7. Compare with internal records

Checklist pratique

Cette liste transforme l’enquête en dossier transmissible : préfixe, visibilité, origine, chemin, more-specifics, MOAS, RDAP, RPKI, IRR, historique et responsable de correction.

Pourquoi cela compte pour les ressources Internet

La continuité dépend de ressources numérotées qui restent observables, autorisées et administrables. Cela touche à la fois l’exploitation et la capacité à participer à la gouvernance.

Cinq questions sur la vérification de l’origine BGP

1. Qui annonce ce préfixe ?

Interrogez RIPEstat, RIS ou RouteViews et conservez les résultats de plusieurs points de collecte.

2. Qu’est-ce qu’un ASN d’origine BGP ?

C’est généralement l’ASN situé à l’extrémité d’origine du chemin AS observé.

3. L’ASN d’origine est-il le propriétaire ?

Pas nécessairement : origine technique, registre, contrat et droit juridique peuvent différer.

4. RDAP montre-t-il l’origine actuelle ?

Pas de façon fiable. RDAP et les données BGP actuelles répondent à deux questions différentes.

5. Comment vérifier l’autorisation d’une annonce ?

Vérifiez une ROA RPKI correspondante, puis confrontez registre, IRR, dossier interne et route observée.

Source et méthode

Ann Yong a publié cet article le 24 septembre 2026 et la source a été mise à jour le même jour. Cette édition a été réécrite pour une lecture technique francophone ; les exemples, tableaux et cinq réponses FAQ de la source sont conservés.

Références techniques

Lire un enregistrement RDAP · ASN et adresse IP · RFC 4271 — BGP-4 · RFC 6811 — validation de l’origine · RFC 9582 — ROA · Documentation RIPEstat · Route Views

De l’observation à la continuité

Commencez par réunir les faits. NRS Shield et une POA de représentation sont deux décisions distinctes ; lire ou demander de l’aide ne crée pas de mandat.

Découvrir NRS Shield · Comprendre la POA · Voir les actions en cours