The role of ISPs in DDoS mitigation

ISPs sit at the crossroads of DDoS traffic

Every DDoS attack traverses at least one ISP network, usually several. Attack traffic originates from compromised devices on ISP networks, travels through transit ISPs, and arrives at the target via the victim's ISP. This means ISPs are involved in every phase of a DDoS attack, whether they realize it or not.

This unique position gives ISPs both the opportunity and the responsibility to mitigate DDoS attacks more effectively than any other entity in the chain. An enterprise can only defend its own perimeter. A cloud scrubbing service can only filter traffic that is routed through its network. But ISPs can filter attack traffic at the source before it ever reaches the broader internet, and they can protect their customers from inbound attacks before the traffic saturates downstream links.

Despite this leverage, many ISPs still treat DDoS protection as someone else's problem. The customer should buy their own protection. The upstream provider should filter the traffic. The argument is understandable given the cost and complexity involved, but it is increasingly untenable as attacks grow larger, regulators pay closer attention, and customers demand more from their connectivity providers.

Source-side responsibility: BCP38 and BCP84

The most impactful thing an ISP can do for the global DDoS ecosystem is implement source-address validation. BCP38 (RFC 2827) and BCP84 (RFC 3704) define best current practices for filtering packets with spoofed source IP addresses at the network edge.

Why source-address validation matters

IP spoofing is the enabler for the most devastating DDoS attack categories. Amplification attacks (DNS, NTP, memcached, CLDAP) work because attackers send small requests to reflector servers with the source address spoofed to be the victim's IP. The reflector sends its large response to the victim, amplifying the attack traffic by factors of 10x to 50,000x depending on the protocol.

Without IP spoofing, amplification attacks simply do not work. The responses would go back to the attacker, not the victim. If every ISP implemented BCP38 filtering, the entire category of reflection/amplification attacks would effectively disappear.

Implementation approaches

BCP38 filtering can be implemented at different points in an ISP's network:

• Customer-facing interfaces: Apply ingress filters on customer ports that only allow traffic with source addresses from the customer's assigned IP ranges. This is the most effective approach because it stops spoofed traffic at the earliest possible point.
• Strict uRPF (Unicast Reverse Path Forwarding): Enable strict uRPF on customer-facing interfaces. The router checks whether the source address of each incoming packet would be routed back out the same interface. If not, the packet is dropped. This is simple to configure but can cause issues with asymmetric routing.
• Feasible-path uRPF: A more flexible version of uRPF that accepts packets if the source address appears in any valid routing path, not just the best path. This handles asymmetric routing scenarios while still blocking obviously spoofed addresses.
• ACL-based filtering: Explicit access control lists on customer interfaces that permit only traffic from the customer's assigned prefixes. More maintenance-intensive but most precise.

The adoption gap

Despite BCP38 being published in 2000, adoption remains incomplete. Various measurement projects estimate that 20-30% of internet networks still allow spoofed traffic to leave their networks. This minority of non-compliant networks enables the majority of amplification attacks globally.

The reasons for non-adoption include perceived complexity, concern about breaking legitimate traffic, and the "tragedy of the commons" dynamic where the benefit of filtering accrues to others while the cost is borne by the implementing ISP. These concerns are largely outdated. Modern router hardware handles uRPF with negligible performance impact, and the operational practices for managing prefix filters are well-established.

ISPs that implement BCP38 protect the entire internet, not just their own network. It is one of the highest-leverage security investments an ISP can make.

Protecting customers from inbound attacks

Beyond source-side filtering, ISPs have a responsibility (and a business incentive) to protect their customers from inbound DDoS attacks. When a customer gets hit by a DDoS attack, the ISP's infrastructure carries that attack traffic. If the attack is large enough, it affects other customers sharing the same transit paths.

Detection at the ISP level

ISPs need detection systems that identify attacks targeting their customers quickly enough to mitigate before collateral damage occurs. Two complementary approaches are needed:

Flow-based network monitoring: Sampling-based analysis of NetFlow/sFlow/IPFIX data from core routers gives network-wide visibility. This catches large volumetric attacks but has detection latency measured in tens of seconds to minutes due to sampling and export intervals.

Per-endpoint agent-based monitoring: Where the ISP manages customer infrastructure (hosting, managed services, CPE), lightweight agents like Flowtriq provide 1-second detection with automatic attack classification. This is the fastest possible detection method because it operates directly on the target, with zero sampling delay.

Flowtriq's agent monitors packets per second at the kernel level, establishes dynamic baselines unique to each endpoint, and classifies attacks into eight categories the moment detection triggers. For ISPs, this per-endpoint granularity is essential for identifying which specific customer is being targeted and what type of attack they are facing.

Automated mitigation responses

Detection without automated response leaves a gap that costs your customers downtime. ISPs need mitigation that activates within seconds of detection, not minutes after a human reviews an alert.

Flowtriq's auto-mitigation chain is designed for ISP environments:

1. On-server mitigation: Where agents are deployed on managed infrastructure, targeted iptables/nftables rules deploy automatically to filter attack traffic at the kernel level. This handles the majority of attacks without any network-level changes.
2. BGP FlowSpec: For attacks exceeding on-server capacity, Flowtriq generates FlowSpec rules and announces them to your BGP route server. Your routers install the filtering rules and drop matching traffic across your network. FlowSpec is surgical, allowing you to filter specific protocols, ports, or source ranges while keeping legitimate traffic flowing.
3. RTBH (Remote Triggered Black Hole): For attacks threatening transit link saturation, RTBH signals your upstream providers to null-route traffic to the target. This sacrifices the target customer's connectivity to protect the rest of your network. It is a last resort, but sometimes the only option for attacks exceeding your total upstream capacity.

ISP-to-ISP coordination

DDoS mitigation at the ISP level often requires coordination between networks. Attack traffic crosses multiple AS boundaries, and effective mitigation sometimes requires action upstream of your own network.

RTBH communities

Most transit providers and IX peers support RTBH communities. When you announce a /32 route with the agreed-upon RTBH community, your upstream provider null-routes traffic destined for that IP before it enters your network. This is the most common form of ISP-to-ISP DDoS coordination and is usually implemented via BGP community attributes.

Establishing RTBH communities with your upstream providers and IX peers should be part of your standard peering setup. Test these communities during non-emergency periods to verify they work correctly. During an active attack is the worst time to discover that your RTBH community is not being honored.

FlowSpec propagation

Some transit providers and IX peers also support FlowSpec rule propagation. This allows more surgical filtering at the upstream level, dropping specific attack traffic while allowing legitimate traffic through. FlowSpec propagation is less universally supported than RTBH but is growing in adoption.

DDoS mitigation signaling

Beyond BGP-based mechanisms, some ISPs participate in formal DDoS mitigation signaling frameworks. These frameworks enable automated or semi-automated communication between ISPs during active attacks, facilitating faster coordinated response. The DOTS (DDoS Open Threat Signaling) protocol, standardized by the IETF, is designed specifically for this purpose.

Protecting ISP infrastructure

ISP infrastructure itself is a high-value DDoS target. Attacks against DNS resolvers, mail servers, customer portals, RADIUS/DHCP servers, and network management systems can disrupt service for the entire customer base without targeting any individual customer.

Critical infrastructure monitoring

Deploy Flowtriq agents on all customer-facing ISP infrastructure: recursive DNS resolvers, authoritative DNS servers, mail relays, web portals, RADIUS servers, and any other services exposed to customer traffic. These are your most attack-sensitive assets, and agent-based monitoring gives you the fastest possible detection.

Redundancy and anycast

Critical ISP services should be deployed with redundancy and, where possible, anycast addressing. Anycast distributes attack traffic across multiple instances, making it harder for attackers to overwhelm any single instance. DNS resolvers are the most common candidate for anycast deployment in ISP environments.

Rate limiting and access control

Apply rate limiting on all ISP infrastructure services. DNS resolvers should limit queries per source IP. RADIUS servers should limit authentication attempts. Web portals should implement connection rate limits and challenge-response mechanisms. These controls do not stop large DDoS attacks but they limit the effectiveness of application-layer attacks and reduce the blast radius of smaller floods.

The business case for ISP DDoS mitigation

ISP DDoS mitigation investment is justified by several business factors:

Customer retention

Customers who experience DDoS-related service disruptions are significantly more likely to churn. Enterprise and business customers with SLAs are especially sensitive. The cost of losing a single enterprise customer often exceeds the annual cost of DDoS protection for your entire managed infrastructure.

Transit cost optimization

Attack traffic consumes transit bandwidth. On 95th-percentile billing, sustained DDoS traffic can measurably increase your monthly transit costs. Mitigating attacks before they consume transit capacity directly reduces your bandwidth expenses.

Revenue from DDoS protection services

DDoS protection can be offered as a premium service to customers. Flowtriq's white-label program lets ISPs offer branded DDoS dashboards and alerting under their own name. At $9.99/node/month cost (or $7.99/node/year on annual billing), ISPs have margin to price the service attractively while generating meaningful recurring revenue.

Regulatory compliance

Telecommunications regulators in many jurisdictions are increasingly requiring ISPs to implement reasonable security measures, including DDoS protection. Having a documented, automated detection and response system demonstrates compliance and reduces regulatory risk.

Practical steps for ISPs getting started

If your ISP does not have comprehensive DDoS protection today, here is a prioritized path forward:

1. Implement BCP38 filtering on all customer-facing interfaces. This is the single highest-impact action you can take for both your network and the broader internet. Use uRPF or ACL-based filtering depending on your router capabilities and routing topology.
2. Deploy detection on critical infrastructure. Install Flowtriq agents on your DNS resolvers, mail servers, customer portals, and other exposed services. This gives you immediate visibility into attacks targeting your own infrastructure.
3. Establish RTBH communities with your upstream providers and IX peers. Test them in non-emergency conditions. Document the process for activating RTBH during an attack.
4. Extend detection to managed customer infrastructure. Deploy agents on hosting customers and managed CPE. Configure per-customer workspaces and alerting.
5. Enable BGP FlowSpec integration for automated surgical mitigation. Connect Flowtriq's auto-mitigation engine to your route server for automatic FlowSpec rule deployment.
6. Offer DDoS protection as a service. White-label Flowtriq and market it to your customer base as a premium add-on.

Each step builds on the previous one, and each delivers standalone value. You do not need to implement everything at once. Start with BCP38 and critical infrastructure monitoring, then expand as your capabilities and customer demand grow.

Back to Blog

Related Articles