Résumé

  • La communauté BLACKHOLE de la RFC 7999 exprime une demande de rejet du trafic destiné au préfixe annoncé. Elle n’oblige pas le voisin à agir : chaque opérateur choisit de l’honorer dans une politique explicitement convenue.
  • Le RTBH de destination installe une route vers une interface de rejet. Il soulage le lien attaqué en supprimant à la fois le trafic hostile et le trafic légitime de la cible.
  • La preuve doit relier UPDATE brut, droit d’annonce, décision d’incident, ROV, politique d’import, confinement, RIB, FIB, compteurs, paquets, retrait et retour du service. Une session BGP saine ne prouve aucune de ces étapes.

Sauver le lien, condamner l’adresse

Prenons un cas synthétique. Un client de transit subit une attaque volumétrique contre 203.0.113.19. Le lien d’accès sature avant que les équipements placés chez le client puissent filtrer utilement. Le client annonce alors 203.0.113.19/32 à son fournisseur avec la communauté BLACKHOLE. La session est inscrite au service et le fournisseur sait que le client est autorisé à annoncer 203.0.113.0/24.

La route /32 est acceptée. Les routeurs d’entrée la résolvent vers une action de rejet. Le flot d’attaque ne traverse plus le lien contraint ; les connexions légitimes vers cette adresse non plus. Le reste du /24 continue de fonctionner. Le réseau n’a pas sauvé la cible : il l’a sacrifiée pour préserver le voisinage.

Quelques heures plus tard, une automatisation choisit par erreur 203.0.113.91/32, adresse d’un autre service dans le même /24. Le pair est autorisé, le préfixe est couvert et l’attribut est exact. Tous les contrôles grossiers passent. Si aucun registre d’incident ne lie la demande au service réellement attaqué, une annonce techniquement recevable détruit une joignabilité saine.

La scène n’est pas le compte rendu d’une panne réelle. Elle sert à isoler le mécanisme : le protocole peut rester stable pendant que l’organisation exerce un pouvoir d’indisponibilité.

Une sémantique mondiale, une décision locale

La RFC 7999 définit une communauté BGP transitive bien connue, enregistrée par l’IANA sous 0xFFFF029A et couramment écrite 65535:666. Sa signification est simple : le réseau voisin est invité à jeter le trafic destiné au préfixe marqué.

Le mot important est « invité ». Accepter et honorer la communauté, ou l’ignorer, relève de chaque opérateur. Dans une relation bilatérale, les deux réseaux doivent s’être accordés avant son utilisation. Un équipement ne devrait pas rejeter du trafic sans directive de configuration explicite.

La normalisation ne transforme donc pas l’émetteur en administrateur du réseau récepteur. Elle réduit les dialectes de communautés, facilite l’exploitation et donne un sens commun à un code. L’acte reste local : une politique d’import reconnaît la relation, valide le préfixe, modifie la route puis fait programmer la FIB.

Deux réseaux peuvent recevoir la même annonce et réagir différemment sans contradiction. Celui qui offre le service la traite ; celui qui ne l’offre pas ignore le signal. Un collecteur peut conserver la communauté sans acheminer aucun paquet. La publication crée un langage commun, pas une obligation universelle.

Cette séparation rejoint directement la « décision future localisée » de Heng Lu. Le socle partagé doit être minimal et vérifiable. Le choix commercial, le périmètre d’exécution, la durée et les conditions de refus restent chez ceux qui exploitent le code.

Quand « meilleure route » signifie « ne pas livrer »

Le RTBH de destination détourne volontairement le vocabulaire habituel de la joignabilité. La RFC 5635 décrit une route de rejet dont le prochain saut se résout vers une interface nulle. Une annonce plus spécifique pour la cible distribue cette disposition aux routeurs participants. Les paquets sont jetés près des entrées du réseau plutôt qu’après avoir consommé la capacité jusqu’au client.

La route peut donc être valide, gagner le processus de décision et apparaître dans la Loc-RIB. Son installation ne promet pourtant pas la livraison. Elle programme exactement l’inverse. Seule l’inspection de la FIB et de la résolution du prochain saut montre si l’instruction exécutable est bien un rejet.

La mesure du succès doit être bifocale. La baisse d’utilisation du lien prouve que le trafic n’atteint plus le client. Elle peut confirmer la protection de l’infrastructure et des services adjacents. Elle ne prouve pas que la cible est disponible. Pour celle-ci, le RTBH de destination achève l’effet de l’attaque : paquets hostiles et légitimes disparaissent ensemble.

Cette asymétrie doit figurer dans la décision de crise. Le fournisseur réduit son risque partagé ; le client supporte la perte complète de la destination. Une équipe qui affiche uniquement le volume filtré masque le coût payé pour obtenir ce résultat.

Deux verrous normatifs, puis un verrou d’exploitation

La RFC 7999 exige deux conditions dans une relation bilatérale.

Le préfixe blackholé doit d’abord être couvert par un préfixe égal ou moins spécifique que le voisin est autorisé à annoncer. Un client ne doit jamais pouvoir placer une adresse étrangère dans l’interface nulle du fournisseur.

Le récepteur doit ensuite avoir accepté d’honorer la communauté sur cette session précise. Le contrôle de l’espace d’adresses ne suffit pas ; la relation doit déléguer ce type d’action.

Ces verrous bloquent une grande classe d’abus, mais pas l’erreur interne à l’espace autorisé. L’adresse erronée de notre scénario appartient encore au bon /24. Un compte compromis peut utiliser le bon pair. Une ancienne demande peut être rejouée. BGP ne transporte pas un ordre de mission universellement vérifiable indiquant le responsable, le service, le motif et l’heure d’expiration.

Il faut donc un troisième verrou hors du protocole. Chaque activation doit conserver l’identité du demandeur, l’incident, le préfixe exact, le service concerné, le périmètre, l’heure, l’expiration et le propriétaire du retrait. Ce dossier doit être relié au pair, à l’AFI/SAFI et à la version de politique qui ont admis l’UPDATE.

Le filtre de préfixes répond à « ce client peut-il annoncer dans cet espace ? ». Le registre d’incident répond à « une personne habilitée veut-elle vraiment sacrifier cette adresse maintenant ? ». Une approbation humaine sans filtre déterministe expose aux fautes de saisie ; un filtre sans décision d’incident confère à l’automatisation un pouvoir permanent.

La précision du /32 crée une exception dangereuse

La RFC recommande le préfixe le plus spécifique possible, typiquement /32 en IPv4 et /128 en IPv6. Cette granularité réduit le dommage collatéral. Elle traverse néanmoins une frontière opérationnelle : le routage public filtre fréquemment les annonces plus longues que /24 et /48.

Le fournisseur RTBH doit ouvrir une exception contrôlée. Il accepte le host route du client pour son usage local tout en l’empêchant de devenir une route Internet ordinaire. Cette exception associe au minimum : liste des agrégats autorisés, longueurs admises, communauté exacte, session approuvée, action locale et périmètre de propagation.

Un préfixe très spécifique n’est pas automatiquement sans risque. Une seule mauvaise adresse peut être un résolveur, un point d’authentification ou une interface de contrôle critique. À l’inverse, blackholer un /24 peut être justifié face à une attaque distribuée, mais supprime 256 adresses d’un coup. La longueur est un choix de rayon d’impact.

Les limites quantitatives ordinaires ne suffisent pas. Une seule route destructrice peut être plus grave que des milliers d’annonces classiques. Il faut aussi limiter le nombre de blackholes simultanés, exclure les destinations protégées, borner leur durée et préciser les régions d’entrée qui les appliqueront.

Enfermer la route destructive

La RFC 7999 recommande d’ajouter NO_ADVERTISE, NO_EXPORT ou un contrôle analogue. La RFC 1997 ne leur donne pas le même effet. NO_ADVERTISE interdit toute retransmission à un autre pair. NO_EXPORT autorise la distribution interne, mais bloque la sortie de l’AS ou de la confédération.

Le fournisseur peut avoir besoin d’envoyer la route à tous ses bords d’entrée, ou seulement à certaines régions. Le confinement doit donc reproduire le graphe réel d’exécution. Une valeur choisie par habitude peut être trop étroite pour soulager le bon lien ou trop large pour contenir la route.

La fuite d’un host route cumule deux dangers. Grâce à la règle du préfixe le plus long, il peut attirer du trafic même si le réseau lointain ignore BLACKHOLE. S’il honore la communauté, il peut jeter ce trafic. Les filtres d’export sont ainsi un contrôle autonome, pas une propriété implicite du signal.

La documentation actuelle de FRRouting indique que l’implémentation ajoute automatiquement NO_ADVERTISE à la réception de BLACKHOLE. Cette observation vaut pour FRR. Elle ne permet aucune généralisation à un autre logiciel ni à une autre version. Une politique peut aussi remplacer l’ensemble des communautés et supprimer par accident la protection ajoutée.

La preuve de confinement est une vue Adj-RIB-Out après politique pour chaque classe de voisin. Une ligne de configuration décrit une intention ; l’annonce de sortie montre l’état que le routeur allait réellement diffuser.

RPKI valide l’origine, pas l’intention de jeter

La communauté classique est modifiable selon la politique locale. La RFC 7999 rappelle qu’un intermédiaire peut ajouter, retirer ou altérer des communautés sans que le destinataire puisse nécessairement détecter l’opération. BGPsec ne couvre pas cette intégrité. L’ajout illégitime de BLACKHOLE peut donc devenir une attaque par déni de joignabilité.

Protéger la session reste utile, mais authentifie un canal et un pair, non le choix opérationnel de la cible. RPKI répond encore à une autre question : l’AS d’origine est-il autorisé pour ce préfixe selon les VRP couvrants et leur longueur maximale ? La validation d’origine ne signe pas la communauté.

Il existe en plus une tension de longueur. Le /32 de blackhole peut être RPKI Invalid si la ROA autorise l’AS pour le /24 sans étendre maxLength jusqu’au host route. La RFC 7999 demande d’éviter qu’une validation d’origine bloque par inadvertance un signal légitime. Exempter toute route marquée serait pourtant dangereux : un attribut modifiable deviendrait un passe-droit ROV. Étendre toutes les ROA jusqu’à /32 ou /128 élargit aussi la classe des routes plus spécifiques susceptibles d’être valides.

Un Internet-Draft individuel de 2022 a proposé une Discard Origin Authorization signée afin de séparer l’autorisation de rejet de l’autorisation d’origine ordinaire. Le texte a expiré et ne possède aucun statut formel de l’IETF. Il documente le problème ; il ne fournit pas une protection sur laquelle un opérateur peut aujourd’hui s’appuyer par défaut.

Le contrôle actuel reste donc composite : identité du pair, filtre exact, état ROV expliqué, communauté, décision d’incident, politique locale et résultat FIB. Aucun feu vert unique ne couvre l’ensemble.

RTBH de destination n’est pas un nom générique

Le RTBH de destination jette tous les paquets visant l’adresse. Le RTBH par source utilise uRPF et la résolution d’une route de rejet pour faire échouer le contrôle de l’adresse source aux entrées choisies. La RFC 5635 demande de ne pas réutiliser la communauté de destination pour cette fonction et recommande de ne pas accepter ces déclencheurs source depuis l’extérieur comme de simples annonces client.

FlowSpec distribue des règles de correspondance et des actions sur les flux. La RFC 7999 exclut son usage pour les NLRI FlowSpec. Un sinkhole détourne le trafic vers un dispositif d’observation. Un service de nettoyage cherche à séparer le trafic légitime de l’attaque. Le blackhole de destination n’analyse ni ne nettoie : il supprime.

Nommer précisément le mécanisme empêche de promettre un résultat impossible. Si l’objectif est la continuité de la cible, le RTBH n’est qu’un dernier recours destiné à sauver la capacité commune.

La chaîne de preuve, de l’UPDATE au silence

Avant toute activation, le contrat machine-lisible doit fixer client, session, AFI/SAFI, agrégats, longueurs, communauté, exclusions, régions, interaction ROV, durée et responsable du retrait.

Pour chaque préfixe, conserver ensuite :

  1. UPDATE brut, heure, pair, AS_PATH, origine, prochain saut et communautés complètes ;
  2. entrée exacte du filtre d’autorisation et sa source ;
  3. état ROV et règle explicite appliquée ;
  4. terme de politique d’import, ajouts de confinement et modification du prochain saut ;
  5. état Adj-RIB-In, sélection Loc-RIB et motif de préférence ;
  6. FIB de chaque classe d’entrée avec résolution vers le rejet ;
  7. compteurs de pertes avec leur sémantique et leur référence ;
  8. paquets observés avant et après la frontière de rejet ;
  9. Adj-RIB-Out de chaque voisin qui ne doit pas recevoir la route ;
  10. retrait, disparition FIB, retour de la route normale et tests de service.

Ces preuves ne sont pas redondantes. Le message dit ce qui est arrivé, le journal de politique pourquoi il a été admis, la RIB ce qui a gagné, la FIB ce qui sera exécuté et les paquets ce qui s’est produit. La sortie prouve le confinement. Le test final prouve la restitution du pouvoir d’acheminer.

Un indicateur « blackhole actif » ne distingue pas une route non sélectionnée, un prochain saut mal résolu, une moitié de flotte non programmée ou un retrait encore présent dans la FIB. La RFC 7999 encourage la conservation à long terme des UPDATE marqués ; l’audit doit aussi retenir politiques, compteurs et état de transfert.

Tester le sacrifice, vérifier la restitution

Le service doit disposer d’un préfixe canari dont la portée ordinaire et le rejet peuvent être mesurés sans risque. Le test couvre chaque classe de client, famille d’adresses, région, routeur, logiciel et frontière de sortie.

Il doit démontrer qu’une route autorisée est acceptée, qu’un préfixe étranger ou trop large est refusé, qu’une mauvaise session ne peut agir, que le confinement apparaît, que toutes les FIB visées rejettent, que les compteurs attendus augmentent et que le retrait restaure la route normale.

Suspendre l’activation si le préfixe n’a pas d’incident ouvert, touche une destination protégée, produit un état ROV inexpliqué, perd sa communauté de confinement, dépasse la région autorisée ou n’a ni expiration ni propriétaire du retrait. Revenir en arrière en cas de perte du mauvais service, fuite externe, désaccord entre équipements ou dommage au-delà du préfixe.

Le retrait n’est que le début du retour. Il faut vérifier la disparition de l’entrée de rejet sur chaque équipement, la resélection de la route attendue, la réussite des sondes et l’absence de nouvelle saturation. L’action est techniquement réversible ; son histoire devient irréversible si les preuves expirent avant l’examen.

Sources