6 octobre 2026 · 9 min de lecture

BGP FlowSpec filtre le trafic DDoS au débit de ligne en poussant des règles granulaires directement sur les routeurs. Principe, compatibilité et limites.

En bref : BGP FlowSpec est une extension du protocole BGP (RFC 8955 pour IPv4, RFC 8956 pour IPv6) qui diffuse dans le réseau des règles granulaires de filtrage du trafic. Les routeurs rejettent ou limitent les flux malveillants au débit de ligne, directement dans le plan de transfert (forwarding plane). Au lieu d’envoyer dans un trou noir tout le trafic à destination d’une cible, FlowSpec identifie un trafic précis (par source, destination, protocole, port, longueur de paquet ou flags TCP) et n’agit que sur lui : le service reste ainsi disponible pendant une attaque DDoS.

L’essentiel

  • FlowSpec = filtrage DDoS chirurgical : identifier le 5-tuple, puis rejeter ou limiter uniquement ce trafic.
  • Normalisé par la RFC 8955 (IPv4) et la RFC 8956 (IPv6), qui ont remplacé la RFC 5575 d’origine.
  • Les règles sont transportées par MP-BGP et se transforment en filtres firewall matériels : neutralisation de l’attaque par filtrage après 6–10 s, à l’échelle de tout le réseau.
  • Pris en charge par les plateformes Juniper, Cisco, Arista et Nokia.
  • Sa limite : certains floods aux paramètres aléatoires et certaines attaques adaptatives ne peuvent pas être décrits par une règle concise, et c’est alors le RTBH qui prend le relais.

Qu’est-ce que BGP FlowSpec ?

BGP FlowSpec (Flow Specification) est une extension du Border Gateway Protocol qui permet à un réseau de diffuser des règles de filtrage du trafic de la même façon qu’il diffuse des routes. Définie dans la RFC 8955 (décembre 2020) pour IPv4 et dans la RFC 8956 pour IPv6, elle encode le critère de correspondance (flow specification) et l’action (rejet, limitation de débit, redirection ou marquage) dans la NLRI BGP : une seule annonce peut ainsi programmer les filtres sur tous les routeurs participants à la fois.

La RFC 8955 a remplacé la RFC 5575 d’origine. Ce détail a son importance, car une bonne partie de la documentation sur FlowSpec disponible en ligne cite encore la RFC obsolète. Si vous documentez ou configurez FlowSpec aujourd’hui, référez-vous aux RFC 8955 et RFC 8956.

Comment fonctionne BGP FlowSpec ?

FlowSpec transforme une mise à jour BGP en règle de firewall. Un contrôleur (ou un routeur) crée une route flow décrivant le trafic malveillant ; MP-BGP la propage à l’intérieur de l’AS et entre AS ; chaque routeur qui la reçoit convertit automatiquement la route flow en filtre firewall matériel et l’installe dans le plan de transfert. Sous Junos, par exemple, les routes flow deviennent des filtres firewall pour IPv4 et VPNv4, qui identifient et limitent le trafic en même temps, au débit de ligne.

Une flow specification peut combiner plusieurs critères, notamment :

  • Préfixe source et destination
  • Protocole IP (TCP, UDP, ICMP…)
  • Port source et destination
  • Longueur de paquet, DSCP, bits de fragment et flags TCP

L’action associée est généralement traffic-rate (rejet = rate 0, ou policer en octets par seconde), redirect vers une VRF de scrubbing (nettoyage du trafic) ou mark (DSCP). Le filtre étant appliqué en matériel, l’exécution se fait au débit de ligne, sans latence supplémentaire pour le trafic légitime.

En quoi BGP FlowSpec diffère-t-il du RTBH ?

FlowSpec et le RTBH répondent au même problème (arrêter un flood à la bordure du réseau), mais à des niveaux de précision opposés. Le RTBH (Remotely Triggered Black Hole) rejette tout le trafic à destination de l’adresse IP attaquée : il sacrifie une adresse pour sauver le réseau. FlowSpec ne rejette que le trafic d’attaque et maintient la cible en ligne. FlowSpec est le scalpel ; le RTBH est la solution de secours, rudimentaire mais fiable, lorsque le flood est trop volumineux ou trop aléatoire pour être caractérisé. Une bordure de réseau bien exploitée utilise d’abord FlowSpec, et le RTBH seulement en dernier recours.

Quels constructeurs prennent en charge BGP FlowSpec ?

FlowSpec est largement pris en charge sur les plateformes de classe opérateur, notamment Juniper (Junos), Cisco (IOS XR), Arista (EOS) et Nokia (SR OS). L’étendue du support et la capacité varient selon la plateforme et la carte de ligne, en particulier le nombre maximal de règles flow installables et les critères de correspondance et actions effectivement implémentés : le nombre de filtres utilisable en pratique et les fonctionnalités disponibles dépendent donc de votre matériel. La passerelle de filtrage Juniper MX d’ITORO est construite autour de FlowSpec sous Junos pour cette raison précise : une exécution prévisible au débit de ligne sur le matériel MX.

Quelles sont les limites de BGP FlowSpec ?

FlowSpec est puissant, mais pas illimité. Voici, en toute transparence, où s’arrêtent ses capacités :

  • Nombre de règles / TCAM. Chaque règle flow occupe de la place dans la table matérielle des filtres ; les plateformes limitent le nombre de règles installables, si bien qu’un très grand nombre de signatures d’attaque distinctes peut saturer la table.
  • Validation et sécurité. FlowSpec comporte une procédure de validation (et les déploiements inter-AS exigent des frontières de confiance soigneusement définies) afin qu’une règle erronée ou détournée n’envoie pas le trafic légitime dans un trou noir à l’échelle de tout le réseau.
  • Attaques impossibles à décrire. FlowSpec ne peut bloquer que ce qu’une règle permet de décrire. Les floods à source ou à port aléatoires et les attaques adaptatives échappent aux règles concises, car il est impossible d’énumérer des millions de sources usurpées. Ce sont précisément les cas où le RTBH ou le scrubbing chez l’opérateur amont prend le relais.

Connaître ces limites fait la différence entre une stratégie de filtrage qui résiste à une véritable attaque et une stratégie qui cède.

Comment automatiser BGP FlowSpec pour la protection DDoS ?

Écrire des règles FlowSpec à la main pendant une attaque en cours est trop lent, car les floods saturent les liens amont (uplink) en quelques dizaines de secondes. En production, FlowSpec est piloté par un système de détection qui reconnaît l’attaque et génère la règle automatiquement. C’est exactement ainsi que fonctionne WanGuard anti-DDoS : il détecte l’attaque, construit la règle FlowSpec correspondante et la pousse vers vos routeurs ; avec le port mirroring en DPDK, le filtrage sélectif agit après 6–10 s et le RTBH, si nécessaire, après environ 1 s. Les flux malveillants sont rejetés au débit de ligne pendant que vos clients restent en ligne, et WanGuard ne passe au RTBH que lorsque le flood dépasse ce que le filtrage peut absorber.

Le fonctionnement d’un tel système côté déploiement est décrit dans l’article qu’est-ce que WanGuard. ITORO l’installe et le paramètre de bout en bout pour les FAI, les opérateurs télécoms et les data centers ; consultez la grille tarifaire actuelle et le calculateur.

Questions fréquentes

À quoi sert BGP FlowSpec ?

BGP FlowSpec sert à diffuser dans le réseau des règles de filtrage du trafic, afin que les routeurs rejettent ou limitent des flux précis au débit de ligne. L’usage le plus courant est la neutralisation chirurgicale d’une attaque DDoS, sans envoyer toute la cible dans un trou noir. FlowSpec peut aussi rediriger le trafic vers un chemin de scrubbing ou en modifier le marquage.

Quelle RFC définit BGP FlowSpec ?

La RFC 8955 (décembre 2020) définit BGP FlowSpec pour IPv4 et remplace la RFC 5575 d’origine. La RFC 8956 étend FlowSpec à IPv6. Pour documenter ou configurer FlowSpec aujourd’hui, référez-vous aux RFC 8955 et RFC 8956, et non à la RFC 5575, devenue obsolète.

Quelle est la différence entre BGP FlowSpec et RTBH ?

FlowSpec rejette ou limite uniquement le trafic malveillant et maintient le service attaqué en ligne. Le RTBH envoie dans un trou noir tout le trafic à destination de l’adresse IP attaquée. FlowSpec est chirurgical et s’utilise en premier ; le RTBH est un dernier recours rudimentaire pour les attaques trop volumineuses ou trop aléatoires pour être filtrées de manière granulaire.

BGP FlowSpec arrête-t-il toutes les attaques DDoS ?

Non. FlowSpec ne peut bloquer que le trafic qu’une règle permet de décrire, et le matériel limite le nombre de règles qu’un routeur peut maintenir. Les floods à source ou à port aléatoires échappent aux règles concises, et un volume supérieur à la capacité de votre lien amont (uplink) ne peut pas être filtré localement ; dans ces cas, on passe au RTBH ou à un centre de scrubbing externe.

Quels routeurs prennent en charge BGP FlowSpec ?

FlowSpec est pris en charge par les plateformes de classe opérateur de Juniper (Junos), Cisco (IOS XR), Arista (EOS) et Nokia (SR OS), même si le nombre maximal de règles et l’ensemble exact des critères de correspondance et actions implémentés varient selon la plateforme et la carte de ligne.

Comment repousser une attaque DDoS ?

On ne peut repousser efficacement une attaque que là où il reste de la bande passante, c’est-à-dire en amont de votre lien. BGP FlowSpec permet de diffuser une règle précise (adresse, protocole, port, taille de paquet) vers les routeurs de bordure et vers l’opérateur, qui rejettera le trafic dans son propre réseau. Contrairement au blackholing, le service reste disponible pour le trafic légitime.

Faut-il signaler une attaque filtrée par FlowSpec ?

Une règle FlowSpec met fin à l’incident sur le plan technique, mais ne dispense pas des obligations d’information. Les entités relevant de la directive NIS2 et de sa transposition en droit français sont soumises à des délais de notification réglementaires auprès de l’ANSSI, et toute victime peut porter plainte.


Sources

  • IETF : RFC 8955, Dissemination of Flow Specification Rules (IPv4) : https://www.rfc-editor.org/info/rfc8955/
  • IETF : RFC 8956, Dissemination of Flow Specification Rules for IPv6 : https://datatracker.ietf.org/doc/rfc8956/
  • Juniper Networks : documentation BGP Flow-Specification (Junos) et « Day One: Deploying BGP Flowspec » : https://www.juniper.net/documentation/en_US/day-one-books/DO_BGP_FLowspec.pdf
  • NANOG 63 : « DDoS Mitigation Using BGP Flowspec » (Ryburn) : https://archive.nanog.org/sites/default/files/tuesday_general_ddos_ryburn_63.16.pdf