Effective DDoS protection for an ISP operator usually has several layers. The first works locally, in the operator's network: LiveShield detects the attack on a copy of the traffic and applies BGP FlowSpec filtering rules, while AIF filters traffic bidirectionally and tracks the state of TCP connections. The second is signalling to the upstream - FlowSpec or, as a last resort, blackholing (RTBH), if the upstream offers it. The third is the scrubbing center, an external infrastructure with large, aggregated bandwidth, to which traffic for the attacked prefix can be redirected when the attack volume threatens to saturate the link. The layers do not compete with each other - each covers a different dimension of an attack: filtering precision or capacity.
Why should DDoS protection start in the operator's network?
Local protection has three properties that no external layer can replace: it reacts inside the operator's network without an additional hop in the path, it gives the operator full control over the rules, and it does not require sending traffic outside the network. For the vast majority of attacks ISP operators face, a precise rule applied within seconds of detection is the simplest and fastest solution.
That is why, in a layered architecture, local protection is the starting point. The other layers extend it where local mechanisms have no influence on what happens outside the operator's network.
How does LiveShield protect the network locally?
LiveShield analyses a copy of the traffic (SPAN/TAP), so it does not sit in the production path. When a threshold is exceeded for a prefix, an address or a subnet, it generates rules in a fixed order: first BGP FlowSpec as the primary mechanism. Selective blackholing (RTBH) is always a last resort - within a given attack it is activated only when the earlier steps are not enough, because it drops all traffic to the targeted address. The bps and pps thresholds can be set separately for individual IP addresses and for the whole subnet, which also makes it possible to detect attacks spread across many addresses (carpet bombing).
This approach is precise because a FlowSpec rule affects only traffic matching the attack pattern, while legitimate traffic to the same address keeps flowing.
What is AIF for and how does it complement FlowSpec rules?
AIF is a LiveShield component placed inline, between the edge router and the BRAS or concentrator. It filters traffic bidirectionally and tracks the state of TCP connections. This lets it recognise traffic that should not appear, for example SYN-ACK, ACK or RST packets without a prior SYN sent from the operator's network. This is a typical pattern of reflection attacks, which are hard to describe with a simple rule based on address or port. The operator can define allowlist prefixes, and AIF has bypass modes.
AIF therefore handles stateful attacks, where connection context matters. It does not change the capacity of the upstream links - the other layers take care of that.
How do rules reach the upstream?
If the upstream offers FlowSpec or RTBH, LiveShield can send rules to it, so that attack traffic is dropped earlier than on the operator's own link. Whether and on what terms an upstream accepts such signals must be confirmed separately with each upstream.
Blackholing (RTBH) remains a last resort in every instance of an attack: LiveShield uses it only when the earlier steps, meaning FlowSpec rules and the other protection mechanisms, are not enough. When it is needed, a selective variant is supported: upstreams are distinguished by 802.1Q VLAN, each has its own blackholing community, and sending can be restricted to selected BGP routers. This way the operator decides which upstream receives the signal for a given prefix.
How does a scrubbing center complement local protection?
A scrubbing center is external infrastructure to which traffic directed at the attacked address is redirected. There it is cleaned of attack packets, and the clean traffic returns to the operator's network. Its main advantage is capacity: aggregated bandwidth many times larger than the links of a single operator.
This matters in one scenario: when the attack volume approaches the bandwidth of the operator's links and threatens to saturate them. Local filtering acts on traffic that has already reached the network, so it does not increase bandwidth at the entry point. The scrubbing center takes over traffic before that point and adds capacity the network does not have. Day to day, with ordinary attacks, it is not needed and should not be the default path for all traffic. We describe the differences between the two models in more detail in our article on how LiveShield works with a scrubbing center.
How does LiveShield trigger traffic redirection?
Redirection to a scrubbing center is a configuration option on the operator's side in LiveShield. The operator specifies in advance which prefixes should be covered by redirection and which scrubbing center the traffic should go to. The system triggers it automatically when it detects an attack and the configured thresholds are exceeded, not on every event.
This is not a ready-made integration with a single chosen provider. The way traffic is handed over is adapted to the operator's network and to the arrangements with the scrubbing center, so the operator keeps the freedom of choice.
How can redirection be tied to link capacity?
The moment of redirection is decided by thresholds set by the operator. They can be set so that redirection starts when traffic to a prefix approaches the link capacity, rather than on every detected attack. Thresholds can be defined separately for individual addresses and for whole subnets.
As a result, local rules handle smaller attacks, and the scrubbing center comes into play only at volumes that matter for capacity. Traffic can return automatically after the attack ends.
Can a custom script be used for redirection?
Yes. Redirection can be implemented with the operator's own script, run in response to events in LiveShield such as the start or end of an attack. LiveShield does not provide its own ready-made script - the operator prepares it for their network and for the arrangements with the scrubbing center.
How do you prepare the network so both layers work together?
Redirection is best planned before it is needed:
Choose the prefixes that should be covered by redirection.
Agree with the scrubbing center how traffic will be handed over and plan it together with the network configuration.
Set volume thresholds relative to link capacity, separately for addresses and subnets.
Confirm with the upstreams whether they accept FlowSpec or RTBH, and prepare selective blackholing as a last resort in case the earlier steps are not enough.
Test the whole setup on a selected prefix and define the procedure for returning traffic.
With any redirection it is worth taking into account the change in traffic path and the latency that comes with it, which is why a scrubbing center is activated selectively.
Local DDoS protection and a scrubbing center cover different dimensions of an attack. LiveShield handles precision: it detects the attack, applies FlowSpec rules, filters traffic statefully through AIF and sends signals to the upstream, keeping blackholing as a last resort. The scrubbing center adds capacity when volume threatens to saturate the link, and redirection can be tied to thresholds that reflect link capacity. This way the operator uses external infrastructure only when it is justified, and handles attacks in its own network day to day. Data on each of them, including time to mitigation, goes into the KSC report, which helps prepare an incident notification under the National Cybersecurity System (Krajowy System Cyberbezpieczeństwa, KSC).
Frequently asked questions
Does LiveShield replace a scrubbing center? No. They are complementary layers: LiveShield filters attacks locally, and the scrubbing center adds capacity outside the operator's links.
When should traffic be redirected to a scrubbing center? When the attack volume threatens to saturate the operator's link. The redirection threshold can be set relative to link capacity.
What is needed for LiveShield to redirect traffic to a scrubbing center? The operator specifies the prefixes and the redirection target and sets the thresholds, and agrees the way traffic is handed over with the scrubbing center. The configuration is adapted to the operator's network.
Does redirection start automatically? Yes, after an attack on the prefix is detected, according to the configured thresholds.
Does traffic return automatically after the attack? Yes, traffic can return automatically after the attack ends.
When does LiveShield use blackholing (RTBH)? Blackholing is always a last resort. Within a given attack, LiveShield uses it only when the earlier steps, including FlowSpec rules, are not enough.
Can a custom script be used for redirection? Yes. LiveShield does not provide its own script; the operator prepares it for their network.
Does LiveShield offer its own scrubbing center? No. LiveShield enables redirection of traffic to a scrubbing center chosen by the operator. This requires configuration on the side of the operator and of the scrubbing center provider.
Does AIF help with volumetric attacks? AIF handles stateful attacks. For a volumetric attack that threatens to saturate the link, the capacity role is taken by the upstream and the scrubbing center.
Related articles
Don't wait for the next DDoS attack.
Contact us today!
