RJS Network Cloud Academy

Why Service Providers Don't Accept Customer BGP FlowSpec — And Why It's Not About Upselling DDoS Protection

After ~25 years in networking, I often hear: "ISPs block customer FlowSpec because they want to upsell DDoS protection."

That's only half the story.

The real reason FlowSpec rarely crosses the ISP–customer boundary is the collision of control, accountability, and shared infrastructure.

🎯 The Common Misconception

BGP FlowSpec (RFC 8955/8956) is one of the most powerful yet underutilized tools in DDoS mitigation. In theory, it allows a customer to signal filtering rules to their upstream provider during an attack — dynamically, without manual intervention.

But in practice, most service providers don't accept FlowSpec from customers.

The typical explanation? "They want to upsell managed DDoS scrubbing."

While there's truth to that, it misses the deeper technical and operational reasons why FlowSpec is fundamentally incompatible with the ISP–customer trust model.

"FlowSpec works best where control and accountability are aligned.
That's why it thrives inside an AS, but rarely across AS boundaries."

1️⃣ The Business Shift Is Real — But It's About Liability, Not Just Margin

Transit Became Cheap. DDoS Protection Didn't.

Over the last decade, IP transit pricing collapsed. What used to cost hundreds of dollars per Mbps now costs pennies. ISPs can't make meaningful margin on connectivity alone anymore.

But the deeper issue is ownership:

If the ISP scrubs → they own the outcome
If the customer injects FlowSpec → the ISP inherits the risk

One bad rule can blackhole legitimate traffic, and the ISP still gets blamed.

💡 Key Point: When you hand a customer the ability to inject drop rules into your network, you inherit liability for every mistake they make — without the visibility or control to validate their intent.

2️⃣ TCAM Is a Shared Fate Problem

FlowSpec Rules Consume Scarce Hardware Resources

Modern routers use TCAM (Ternary Content Addressable Memory) to perform line-rate packet filtering. TCAM is:

Expensive
Finite
Shared across all customers on the same router

Complex FlowSpec matches expand entries:

Multi-field matches (source port + destination port + protocol + packet length)
Fragment handling (differs by platform)
DSCP marking, TCP flags, ICMP types

There is no safe per-customer quota that works during a real attack.

⚠️ Technical Reality: A single customer under DDoS stress can inject hundreds of FlowSpec rules. If those rules exhaust TCAM, it impacts everyone on that router — not just the customer under attack.

Why ISPs Can't Just "Allocate TCAM Per Customer"

TCAM isn't like bandwidth — you can't partition it cleanly:

Rule expansion is unpredictable
Platform behavior varies (Juniper MX vs Cisco ASR vs Arista 7280)
During an actual volumetric attack, FlowSpec rules compete with ACLs, uRPF, and other control-plane protections

A "fair share" policy doesn't exist in TCAM world.

3️⃣ Validation Breaks Customer Expectations

RFC 8955 Protects the Network — But Creates Operational Ambiguity

FlowSpec includes validation to prevent abuse:

A FlowSpec rule targeting a destination must match a unicast BGP route in the RIB
If the destination prefix isn't in the routing table, the rule is marked Invalid

This sounds safe. But in asymmetric routing environments, it breaks:

📌 Example Scenario:

Customer owns 203.0.113.0/24
ISP receives this prefix via Peer A (best path)
Customer injects FlowSpec via Transit Link B
The ISP's router doesn't have a route to 203.0.113.0/24 via that session
Result: FlowSpec rule is silently marked Invalid

💡 The Problem: Rules aren't rejected — they're silently inactive. The customer thinks they mitigated. They didn't. This operational ambiguity is poison during an incident.

4️⃣ Source-Based Blocking Is Intentionally Constrained

You Don't Own Attacker Prefixes

FlowSpec is destination-anchored by design to prevent abuse:

You can't inject a rule saying "drop all traffic from 1.2.3.0/24" unless you own that prefix
If you could, a malicious actor could blackhole any prefix on the internet

That makes it safer — but it also means FlowSpec is not true push-back.

FlowSpec Is RTBH++, Not Attacker Suppression

Think of FlowSpec as:

Remotely Triggered Black Hole (RTBH) with granular match criteria
You can say "drop packets to MY prefix matching X"
You cannot say "block this attacker globally"

This limits its effectiveness against distributed attacks from thousands of sources.

5️⃣ Multi-Vendor Reality Hurts

What Works on One Platform May Fail on Another

ISPs run heterogeneous networks:

Juniper MX at peering points
Cisco ASR9k at aggregation
Arista 7280 at customer edge

FlowSpec behavior differs:

Some platforms support fragment filtering; others don't
TCAM layout varies (e.g., Broadcom Trident3 vs Jericho2)
Actions like "rate-limit" vs "redirect-to-VRF" aren't universally supported

⚠️ Real-World Impact: ISPs struggle to normalize FlowSpec internally. Letting customers inject rules multiplies that risk — now the ISP has to guarantee consistent behavior across platforms they don't fully control.

❌ So What Actually Kills Customer FlowSpec?

Not One Team — Every Team

Engineering fears blast radius:

One bad rule can affect hundreds of customers
TCAM exhaustion is silent until it's catastrophic

Operations fears silent failure and troubleshooting hell:

"Why isn't my FlowSpec rule working?" becomes the #1 ticket
Debugging asymmetric routing + validation state + multi-vendor TCAM behavior at 2 AM

Security fears abuse:

A compromised customer could inject rules targeting someone else
Even with validation, the attack surface is non-zero

Finance asks: Who pays when this goes wrong?

If the ISP's network drops traffic due to a customer-injected rule, who's liable?
SLAs don't cover "customer shot themselves in the foot"

🎯 The Core Issue: Shared Control Without Shared Responsibility Doesn't Scale

FlowSpec isn't broken. It's incredibly powerful inside a single administrative domain:

A large enterprise using FlowSpec between DC and branches
A cloud provider using it internally across regions
An ISP using it for internal DDoS response teams

But across AS boundaries, the trust model collapses:

The customer doesn't own the ISP's TCAM
The ISP doesn't control the customer's filtering logic
When something breaks, both sides blame each other

"It's not that FlowSpec is broken.
It's that shared control without shared responsibility doesn't scale."

🔮 What's the Alternative?

If Not Customer FlowSpec, Then What?

1. ISP-Managed Scrubbing Centers

BGP-triggered diversion to dedicated scrubbing infrastructure
ISP owns the filtering logic and liability
Customer pays for the service

2. Customer-Side FlowSpec (Within Their AS)

Customer runs FlowSpec internally (e.g., from firewall to edge routers)
ISP only sees the "clean" side

3. RTBH (Remotely Triggered Black Hole)

Simpler, less risky
Customer signals via BGP community: "drop all traffic to this /32"
ISP implements it at their edge

4. API-Based On-Demand Filtering

Customer calls ISP API during attack
ISP validates and applies rules in controlled manner
Combines automation with ISP oversight

✅ Final Takeaway

Customer FlowSpec across ISP boundaries fails not because ISPs are greedy, but because the operational model is fundamentally misaligned.

FlowSpec requires:

Trust in the customer's filtering logic
Shared fate in TCAM exhaustion risk
Multi-vendor consistency that doesn't exist
Clear liability when things break

None of these exist at the ISP–customer boundary.

"FlowSpec works best where control and accountability are aligned.
Inside your AS? Powerful.
Across AS boundaries? A liability nightmare."

The next time someone says "ISPs just want to upsell scrubbing" — remind them: the technical reasons are more fundamental than the business reasons. And until we solve TCAM scarcity, validation ambiguity, and multi-vendor normalization, customer FlowSpec will remain an idea that works in slides, but breaks in production.

BGP FlowSpec DDoS Mitigation ISP Strategy TCAM RFC 8955 Network Security Service Provider BGP Routing Security Traffic Filtering