Résumé

  • La RFC 7999 définit la communauté bien connue BLACKHOLE, enregistrée comme 65535:666, afin qu'un réseau d'origine puisse demander à un voisin d'abandonner le trafic destiné à un préfixe.
  • L'étiquette reste consultative : le destinataire ne devrait l'honorer qu'après accord, pour un espace que le voisin est autorisé à annoncer, au moyen d'une politique locale explicite et confinée.

Un signal qui demande une panne volontaire

La plupart des annonces de routage cherchent à maintenir la joignabilité. BLACKHOLE demande l'inverse. Lorsqu'une attaque remplit un lien amont, rendre une adresse ciblée indisponible peut protéger la capacité utilisée par d'autres services. Le trafic légitime vers la cible disparaît avec le trafic hostile : il s'agit d'un sacrifice contrôlé, pas d'un rétablissement.

La RFC 7999 attribue à cette demande une communauté commune. L'IANA enregistre BLACKHOLE sous 0xFFFF029A, généralement noté 65535:666. L'AS d'origine l'attache à un préfixe couvrant la victime ; un voisin participant peut alors interpréter le signal comme une demande d'abandon.

Le partage du code ne partage pas l'autorité. L'émetteur désigne la destination sacrifiable, mais le destinataire possède les équipements qui exécutent l'abandon. Traiter la communauté comme une commande automatique permettrait à un pair de transformer une annonce ordinaire en pouvoir distant sur la perte de paquets. La RFC ne l'autorise pas.

L'accord précède l'activation

Dans une relation bilatérale, les deux réseaux doivent convenir de l'usage de BLACKHOLE avant son annonce. Sans directive de configuration explicite, un équipement ne devrait pas abandonner du trafic uniquement parce que l'étiquette apparaît. Reconnaître la valeur normalisée n'est donc pas consentir à l'exécuter.

Une seconde limite concerne l'espace d'adressage. Le destinataire ne doit honorer l'annonce que si le préfixe est couvert par un préfixe égal ou plus court que le voisin est autorisé à annoncer, et si la session est autorisée à employer le mécanisme. Un accord n'accorde pas le droit de neutraliser l'espace d'un tiers.

La précision répartit le coût

Le préfixe devrait être aussi précis que possible, typiquement /32 en IPv4 ou /128 en IPv6. Une agrégation trop large rendrait indisponibles des adresses voisines qui ne subissent pas l'attaque. La victime, les liens amont et les services adjacents peuvent bénéficier du filtrage, mais la destination choisie paie par la perte de tout trafic, y compris légitime.

Les sources ne mesurent ni le gain de capacité, ni la durée, ni le déploiement chez un opérateur nommé. La communauté n'authentifie pas non plus le récit d'attaque. L'autorisation réelle provient de la session, des filtres de préfixes et de la politique du destinataire.

La propagation doit rester bornée

Le destinataire devrait ajouter NO_ADVERTISE, NO_EXPORT ou une contrainte équivalente choisie localement. La fuite d'une route plus spécifique portant un ordre d'abandon pourrait toucher des réseaux qui n'ont jamais accepté ce pouvoir. La RFC 7999 encourage donc aussi la conservation des mises à jour pour l'analyse et l'audit.

Une preuve utile relie pair demandeur, préfixe, route couvrante autorisée, accord de session, action appliquée, limite de propagation, heure d'activation et retrait. Le succès suppose à la fois l'abandon voulu et l'absence d'effet hors périmètre.

Preuves et limites

La RFC 7999 établit les conditions opérationnelles ; la RFC 1997 décrit les communautés BGP, la RFC 4271 le protocole, et le registre IANA la valeur. En déduire que BLACKHOLE doit être gouverné comme une capacité d'urgence étroite est une analyse de leadership. Aucun de ces textes ne prouve un déploiement, une attaque ou un résultat chez un acteur nommé ; aucune allégation n'est formulée.

Sources