ISP-integrated DDoS protection: complete implementation guide

Architecture overview

An ISP-integrated DDoS protection system has four core components that work together in a detection-to-mitigation pipeline:

1. Flow collection: Edge and core routers export traffic telemetry (sFlow, NetFlow v9, or IPFIX) to a central collector. This provides network-wide visibility without inline hardware.
2. Detection engine: The collector analyzes flow data against baselines and thresholds to identify attack traffic. Detection triggers within seconds of attack onset.
3. Automated mitigation: When an attack is confirmed, the system generates BGP FlowSpec rules or RTBH announcements and advertises them to edge routers. Routers install filtering rules in their forwarding plane within seconds.
4. Notification and reporting: Customers receive automated alerts with attack details, access to a real-time dashboard, and post-attack forensic reports.

This architecture operates entirely within the ISP's network. No traffic is rerouted to external scrubbing centers for attacks within the ISP's mitigation capacity. For volumetric attacks that exceed local capacity, the system can automatically trigger upstream diversion to a cloud scrubbing partner.

Step 1: Flow collection

Flow collection is the foundation of detection. Every router in the ISP network that handles customer or transit traffic should export flow data to a central collector.

Choosing a flow protocol

Recommendation for ISP DDoS detection: Use sFlow as the primary detection protocol. Its packet-sampling model means samples arrive at the collector immediately, providing sub-10-second visibility into traffic changes. Set the sampling rate to 1:1000 to 1:2048 on edge-facing interfaces and 1:4096 to 1:8192 on core interfaces. These rates provide sufficient statistical accuracy for DDoS detection while keeping export volume manageable.

If your routers support both sFlow and NetFlow/IPFIX, run both: sFlow for real-time detection and NetFlow/IPFIX for traffic accounting, capacity planning, and billing.

Router configuration essentials

Key configuration points for flow export across router vendors:

• Export from all customer-facing and transit-facing interfaces. Internal backbone links between your own routers are lower priority. Focus on interfaces where external traffic enters and exits your network.
• Use consistent sampling rates across all edge routers. Inconsistent sampling rates make it difficult to compare traffic volumes between ports accurately.
• Include interface index (ifIndex) in exports. This allows the detection engine to map traffic to specific customer ports and transit links.
• Export to multiple collectors for redundancy. If your detection system goes down, you should have a secondary collector maintaining visibility.
• Configure the collector IP as a loopback address to ensure flow data reaches the collector regardless of which physical interface provides connectivity.

Collector sizing

The flow collector needs to handle the aggregate sample/flow rate from all exporting routers. Sizing guidelines:

• Small ISP (5-20 routers, 10-50 Gbps transit): A single server with 4 CPU cores, 16 GB RAM, and SSD storage handles sFlow at 1:1000 sampling comfortably. Expect 5,000 to 50,000 samples per second.
• Mid-size ISP (20-100 routers, 50-500 Gbps transit): 8 to 16 CPU cores, 32 to 64 GB RAM. Sample rates of 50,000 to 500,000 per second. Consider dedicated NVMe storage for PCAP archival.
• Large ISP (100+ routers, 500+ Gbps transit): Distributed collector architecture with multiple ingest nodes and a central analysis cluster. At this scale, custom architecture is typically required.

Flowtriq handles flow ingestion, detection, and mitigation orchestration in a single platform. For ISP deployments, it accepts sFlow, NetFlow v9, and IPFIX from any number of routers, correlates traffic to customer prefixes, and triggers FlowSpec/RTBH automatically.

Step 2: Detection engine

The detection engine analyzes incoming flow data to identify DDoS attacks. Effective ISP-level detection requires a multi-method approach:

Threshold-based detection

Set per-customer and per-prefix thresholds for traffic volume (BPS), packet rate (PPS), and flow rate (FPS). When traffic to a customer prefix exceeds its threshold, the system raises an alert. Thresholds should be set per customer based on their normal traffic profile, not as a global value applied uniformly.

Example: a customer with a normal peak of 500 Mbps might have a BPS threshold at 2 Gbps (4x normal peak) and a PPS threshold at 500,000 PPS. A different customer peaking at 50 Mbps might have thresholds at 200 Mbps and 50,000 PPS.

Baseline deviation detection

More sophisticated than static thresholds, baseline detection learns each customer's traffic patterns over time (hourly, daily, weekly cycles) and triggers when current traffic deviates significantly from the expected pattern. This catches attacks that are large relative to the customer's normal traffic but may be below a static global threshold.

Protocol anomaly detection

Certain traffic patterns are inherently suspicious regardless of volume:

• UDP amplification signatures: Large volumes of UDP traffic from well-known amplification ports (DNS port 53, NTP port 123, SSDP port 1900, Memcached port 11211, CLDAP port 389) targeting a single customer IP.
• SYN floods: Extremely high SYN-to-SYN/ACK ratio indicating connection exhaustion attempts.
• Fragment floods: High rate of IP fragments, often used to bypass stateless packet filters.
• ICMP floods: Sustained high-rate ICMP traffic, typically echo requests or unreachable messages.
• Source IP entropy: Attack traffic often comes from many distributed sources, resulting in high source IP entropy combined with low destination IP entropy (many sources targeting one destination).

Detection speed targets

For ISP-integrated detection to be valuable, it must be significantly faster than the time it takes for an attack to impact customer service. Target detection times:

• Volumetric floods (UDP, ICMP, SYN): Detection within 5 to 15 seconds using sFlow with 1:1000 sampling.
• Amplification attacks (DNS, NTP, CLDAP): Detection within 5 to 10 seconds based on source port signatures.
• Carpet bombing (distributed across customer range): Detection within 15 to 30 seconds, requiring aggregate prefix-level analysis.

Step 3: Automated mitigation

Once the detection engine confirms an attack, the system must push mitigation rules to network infrastructure. Two primary mechanisms are available, and both can be used together:

BGP FlowSpec (RFC 5575)

FlowSpec is the preferred mitigation mechanism for ISPs because it provides surgical filtering without disrupting legitimate traffic. A FlowSpec rule specifies:

• Match criteria: Source IP/prefix, destination IP/prefix, IP protocol, source port, destination port, packet length, DSCP, fragment flags. Any combination of these fields can define a rule.
• Action: Drop (discard), rate-limit (traffic-rate), redirect to VRF (for scrubbing), or mark (set DSCP). The most common action for DDoS mitigation is drop or rate-limit.

The FlowSpec controller (detection system) advertises these rules via MP-BGP to edge routers. Routers receive the rules and install them as firewall filters in their forwarding plane. The entire cycle from detection to enforcement typically completes in under 30 seconds.

FlowSpec deployment considerations

• Validate FlowSpec support on all edge routers. Juniper Junos, Cisco IOS-XR, Nokia SR OS, and Arista EOS all support FlowSpec, but implementation depth varies. Test rule installation and forwarding-plane behavior before production deployment.
• Set FlowSpec rule limits. Routers have finite TCAM (ternary content-addressable memory) for ACL entries. A large-scale attack may require many FlowSpec rules. Configure your detection engine to aggregate rules where possible (use /24 source prefixes instead of individual /32s when the attack comes from a distributed botnet).
• Use route-reflectors for FlowSpec distribution. In networks with many edge routers, advertising FlowSpec rules via a route-reflector reduces the number of BGP sessions the controller must maintain.
• Implement safety limits. Prevent FlowSpec from accidentally blocking legitimate traffic by configuring maximum rule counts, maximum rate-limit values, and mandatory destination-prefix matching (never deploy a FlowSpec rule that matches all destination traffic).

RTBH (Remotely Triggered Black Hole)

RTBH is simpler than FlowSpec but less surgical. It works by advertising a /32 host route for the target IP with a specific BGP community that tells routers to null-route all traffic to that destination. This stops the attack but also drops legitimate traffic to the target IP.

RTBH is appropriate when:

• The attack is so large that filtering individual source IPs or protocols is impractical.
• FlowSpec is not supported on all edge routers.
• The customer accepts that their IP will be unreachable as a trade-off for protecting the rest of the network.
• The attack targets a single IP and the customer can fail over to an alternate IP.

Many ISPs deploy RTBH as a fallback when FlowSpec rules are insufficient or when FlowSpec is not available on specific router platforms in the network.

Upstream transit provider coordination

For attacks that exceed the ISP's own capacity, the mitigation system should be able to:

• Signal RTBH to upstream transit providers using well-known BGP communities (RFC 7999: blackhole community 65535:666). Most major transit providers support this.
• Trigger on-demand scrubbing with a cloud scrubbing partner by automating the BGP announcements that divert traffic through the scrubbing infrastructure.
• Coordinate FlowSpec upstream where supported. Some transit providers accept FlowSpec rules from downstream customers, enabling surgical filtering at the transit level.

Step 4: Customer notification

DDoS protection is a value-add service for ISPs. Customer-facing notification and visibility transforms a network operations concern into a revenue-generating feature.

Real-time alerting

When an attack is detected targeting a customer prefix, notify the customer within 60 seconds through their preferred channels:

• Email: Automated alert with attack type, peak volume, target IP, mitigation action taken.
• Webhook: JSON payload delivered to the customer's monitoring system (Slack, PagerDuty, custom integration).
• SMS/voice: For critical alerts only, to avoid alert fatigue.
• Customer portal: Real-time dashboard showing attack status, traffic graphs, and mitigation effectiveness.

Customer portal features

A well-designed customer portal differentiates your DDoS protection service from basic transit. Essential features include:

• Real-time traffic graphs: Per-prefix and per-IP traffic volume (BPS and PPS) with per-protocol breakdown. Customers should see what traffic is hitting their prefixes in near-real-time.
• Attack history: Timeline of detected attacks with details on each event: start time, duration, peak volume, protocols, source distribution, mitigation actions.
• Threshold management: Allow customers to adjust their own detection thresholds (within ISP-defined bounds) for their prefixes.
• Mitigation preferences: Customers can configure whether they want automatic mitigation (FlowSpec/RTBH) or manual approval before mitigation activates.
• PCAP access: Packet captures from attack traffic samples for forensic analysis.

Flowtriq's dashboard provides all of these capabilities out of the box, with multi-tenant support that allows ISPs to give each customer a scoped view of their own traffic and attack data.

Step 5: Capacity planning

Sizing your mitigation capacity

ISPs need to size their mitigation infrastructure based on three metrics:

1. Largest observed attack: Review your attack history for the past 12 months. Your mitigation capacity should handle at least 2x your largest observed attack without impacting other customers.
2. Total upstream transit capacity: Your FlowSpec/RTBH-based mitigation can filter up to 100% of your transit capacity because filtering happens at the router forwarding plane. The practical limit is TCAM capacity for FlowSpec rules, not bandwidth.
3. Customer growth projection: As you add customers, your aggregate attack surface grows. Plan for 20 to 30% annual growth in both traffic volume and attack frequency.

Escalation tiers

Build a tiered escalation model based on attack size relative to capacity:

Monetization: DDoS protection as a service

ISP-integrated DDoS protection is not just a cost center. It is a differentiator that reduces churn and generates revenue:

Pricing models

• Included with premium transit: Offer basic detection and automated FlowSpec mitigation as a standard feature of business-grade transit packages. This reduces churn by giving customers a reason to stay even when competing ISPs offer lower per-Mbps pricing.
• Tiered protection add-on: Offer detection-only as a free tier, automated mitigation as a paid tier ($50 to $200/month per customer depending on bandwidth), and premium protection with PCAP forensics and dedicated scrubbing as a higher tier ($200 to $1,000/month).
• Per-event pricing: Charge per mitigation event (typically $50 to $500 per event) for customers who prefer lower monthly costs. This works well for customers who experience infrequent attacks.

ROI for ISPs

The economics of ISP-integrated DDoS protection are compelling:

• Reduced churn: Customers under attack who receive automated mitigation and real-time visibility are far less likely to switch providers than customers whose service goes down during attacks with no communication.
• Revenue per customer: Even a modest $100/month DDoS protection add-on across 50 customers generates $60,000/year in additional revenue.
• Reduced NOC load: Automated detection and mitigation reduces manual incident response. Fewer 3 AM pager alerts for your NOC team.
• Network protection: A large attack targeting one customer can congest shared infrastructure, affecting all customers on the same transit links. Automated mitigation protects your entire customer base, not just the target.

Implementation checklist

1. Enable flow export on all edge and peering routers. Configure sFlow at 1:1000 to 1:2048 on edge interfaces.
2. Deploy a flow collector and detection engine. Flowtriq or similar platform that ingests sFlow/NetFlow/IPFIX and provides baseline-aware detection.
3. Configure BGP FlowSpec sessions between the detection engine and edge routers. Use route-reflectors if the network has more than 10 edge routers.
4. Configure RTBH communities on all edge routers and upstream transit sessions. Test with RFC 7999 blackhole community (65535:666).
5. Set per-customer detection thresholds based on contracted bandwidth and historical traffic patterns. Start with 3x to 5x normal peak to avoid false positives, then tighten over time.
6. Configure automated alerting to customer-facing channels (email, webhook) and internal NOC channels (Slack, PagerDuty).
7. Establish upstream scrubbing partnerships for attacks exceeding local capacity. Configure automated BGP diversion triggers.
8. Test the full pipeline using controlled traffic generators. Verify detection time, FlowSpec rule propagation, customer notification, and escalation paths.
9. Deploy customer portal with real-time traffic visibility, attack history, and threshold management.
10. Document and communicate SLAs to customers: detection time, mitigation time, notification time, and scrubbing capacity.

Flowtriq is purpose-built for ISP deployments. It ingests sFlow, NetFlow, and IPFIX from any router; provides per-customer baseline detection; pushes automated FlowSpec and RTBH rules; and includes a multi-tenant customer portal. At $9.99/node/month, a 10-router ISP deployment costs under $100/month for full-stack DDoS detection and mitigation orchestration. Start a 14-day free trial with no credit card required.

Frequently asked questions

Related articles