{"id":28634,"date":"2026-10-05T11:53:29","date_gmt":"2026-10-05T09:53:29","guid":{"rendered":"https:\/\/frnix.org\/?page_id=28634"},"modified":"2026-10-20T15:07:06","modified_gmt":"2026-10-20T13:07:06","slug":"anti-ddos-article-for-peering-networks","status":"publish","type":"page","link":"https:\/\/frnix.org\/en\/ressources\/article-anti-ddos-pour-reseaux-de-peering\/","title":{"rendered":"Article: Anti-DDoS for peering networks"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\n\t\n<\/svg>\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t

Anti-DDoS for peering networks<\/h1>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t

From the advertised capacity to the actual length of track protected<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

This article is a public summary of the briefing note produced by Working Group 002 \u2013 Technical Operations. It sets out <\/span>the key takeaways from six months\u2019 work on Anti-DDoS. The working groups are for members only <\/span>are based on peer-to-peer exchanges, feedback from the field and occasional keynote speeches by external speakers <\/span>to stimulate discussion. The content is anonymised and does not promote any particular supplier or product.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

1. The right place to start: the first bottleneck<\/h2>

Dans un r\u00e9seau de peering, la premi\u00e8re question face au DDoS n\u2019est pas \u00ab quelle capacit\u00e9 de nettoyage ? \u00bb. C\u2019est : qu\u2019est-ce qui sature en premier, et par quel chemin le trafic y arrive-t-il ? Une attaque modeste \u00e0 l\u2019\u00e9chelle d\u2019un r\u00e9seau amont peut suffire \u00e0 saturer un acc\u00e8s client, un firewall, un load balancer ou une API.<\/p>

High cleaning capacity does not protect a service if traffic cannot reach the filter before it becomes overloaded.<\/p>

2. Identifying three problems rather than one<\/h2>

It is useful to distinguish between L3\/L4 volumetric protection, application-level protection and access\/routing resilience. A WAF may be appropriate for an application, but it does not automatically replace protection for a link that becomes overloaded. Volumetric mitigation alone does not resolve an attack targeting an API.<\/p>

Architecture becomes easier to understand when each mechanism has a role, a scope and limits that are explicitly documented.<\/p>

\"\"<\/p>

3. The risk map includes transit and peering<\/h2>

The protection topology must cover transit, IXPs, private interconnections, customer access, backup routes and the return of legitimate traffic following filtering. In a peering context, protection implemented solely at a transit provider\u2019s site may not cover the same exposure.<\/p>

Critical prefixes and services, ingress links, the first point of potential congestion, the diversion mechanism and the return path must be diagrammed and made known to the on-call teams.<\/p>

4. The cleaning point must be accessible<\/h2>

Upstream filtering is preferred because it prevents the attack from consuming access or backbone capacity. However, it is necessary to verify the transport capacity to the cleaning point, the paths actually covered, the activation conditions, the preservation of legitimate traffic and visibility during the incident.<\/p>

The number of cleaning centres is less important than effective coverage: actual route, available capacity and diversion conditions.<\/p>

\"\"<\/p>

5. Redirect traffic without compromising the architecture<\/h2>

DNS, BGP and GRE each have distinct uses. DNS can redirect a service, but cannot protect an IP address that is being directly targeted. BGP requires a clear policy and an understanding of its impact on multihoming. GRE must be assessed in terms of capacity, latency and high-traffic scenarios.<\/p>

The operational question then becomes: which flows are diverted, based on which signal, along which route, with what capacity and to what extent can they be reversed?<\/p>

6. Check before filtering<\/h2>

NetFlow\/sFlow, interface counters, application metrics, baselines and upstream information enable an alert to be turned into a decision. Thresholds must be linked to the resources that can actually be protected: links, pps, sessions, servers, firewalls or APIs.<\/p>

The absence of local symptoms does not prove that no attack has taken place; the traffic may have been filtered out upstream or become saturated before reaching the measurement point. Visibility must therefore cover the transport paths, not just internal equipment.<\/p>

7. Blackholing, filtering and application protection<\/h2>

Blackholing remains a fallback measure: whilst it can protect the infrastructure and other services, it blocks traffic to the targeted destination. Access control lists (ACLs), filtering rules and rule distribution mechanisms only complement a mitigation strategy if their scope, implementation timeframe and operation are properly managed.<\/p>

Application-level protection is an additional layer. It must be assessed on the basis of the services it actually accesses and the technical constraints it entails. Segmenting responsibilities helps to avoid a false sense of security.<\/p>

8. Protection is maintained: runbooks, authorised tests and post-incident procedures<\/h2>

An anti-DDoS system remains effective only if it is properly operated: contact procedures, decision matrix, list of prefixes and critical services, activation rights, crisis communication and structured feedback.<\/p>

Stress tests can help to calibrate detection and procedures, but only in a laboratory setting or with the explicit consent of all parties. Once traffic has been restored, the review must consider both network and security aspects: administrative changes, authentication processes, data outflows and DNS\/BGP modifications may reveal that a DDoS attack was used as a diversion.<\/p>

9. Compare with scenarios, not with a single figure<\/h2>

When comparing a solution or service, start with documented scenarios and actual usage patterns. The advertised capacity alone does not address issues such as coverage, upstream congestion, activation, routing impact, visibility or operations.<\/p>

The aim is not to find a one-size-fits-all solution. It is to ensure that the chosen service is suited to the network, the applications and the team\u2019s actual ability to operate it<\/p>

\"\"<\/p>

\u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Attention<\/h4>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t
Une attaque DDOS n'est souvent pas une fin en soi ! Elle peut servir \u00e0 masquer une autre attaque comme de l'exfiltration de donn\u00e9es.<\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Membres contributeurs du GT 002<\/span><\/h2>\n

Les organisations suivantes ont contribu\u00e9 aux travaux du cycle. Cette liste ne constitue pas un relev\u00e9 de pr\u00e9sence \u00e0 chaque r\u00e9union et n\u2019attribue aucun propos, retour d\u2019exp\u00e9rience ou position \u00e0 une organisation en particulier.<\/span><\/p>\n

\"\"<\/a>\"\"<\/a><\/span>\"\"<\/a>\"\"<\/a>\"\"<\/a><\/span>\"\"<\/a><\/span><\/p>\n

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

Anti-DDoS pour r\u00e9seaux de peering De la capacit\u00e9 annonc\u00e9e au chemin r\u00e9ellement prot\u00e9g\u00e9 Cet article est un r\u00e9sum\u00e9 public de la note de synth\u00e8se du GT 002 – Op\u00e9rations Techniques. Il restitue les principaux enseignements de six mois de travaux sur l\u2019Anti-DDoS. R\u00e9serv\u00e9s aux membres, les groupes de travail s\u2019appuient sur les \u00e9changes entre pairs, […]<\/p>\n","protected":false},"author":351,"featured_media":0,"parent":304,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"hf_cat_page":[463],"class_list":["post-28634","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/pages\/28634","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/users\/351"}],"replies":[{"embeddable":true,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/comments?post=28634"}],"version-history":[{"count":5,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/pages\/28634\/revisions"}],"predecessor-version":[{"id":29125,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/pages\/28634\/revisions\/29125"}],"up":[{"embeddable":true,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/pages\/304"}],"wp:attachment":[{"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/media?parent=28634"}],"wp:term":[{"taxonomy":"hf_cat_page","embeddable":true,"href":"https:\/\/frnix.org\/en\/wp-json\/wp\/v2\/hf_cat_page?post=28634"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}