Anti-DDoS for peering networks

1. The right place to start: the first bottleneck

Dans un réseau de peering, la première question face au DDoS n’est pas « quelle capacité de nettoyage ? ». C’est : qu’est-ce qui sature en premier, et par quel chemin le trafic y arrive-t-il ? Une attaque modeste à l’échelle d’un réseau amont peut suffire à saturer un accès client, un firewall, un load balancer ou une API.

High cleaning capacity does not protect a service if traffic cannot reach the filter before it becomes overloaded.

2. Identifying three problems rather than one

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.

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

3. The risk map includes transit and peering

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’s site may not cover the same exposure.

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.

4. The cleaning point must be accessible

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.

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

5. Redirect traffic without compromising the architecture

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.

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?

6. Check before filtering

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.

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.

7. Blackholing, filtering and application protection

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.

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.

8. Protection is maintained: runbooks, authorised tests and post-incident procedures

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.

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.

9. Compare with scenarios, not with a single figure

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.

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’s actual ability to operate it