Don't chase the attacker's IP. Protect the victim — per subscriber, per attack type, at line rate.
Every DDoS filter that keys on the attacker's source IP has the same disease: on a real access network the busiest source IPs are Cloudflare, CloudFront, WhatsApp/Meta and every mobile-carrier CGNAT egress — so it blocks them and takes streaming, chat and whole peer ISPs offline for subscribers who were never attacked. BNGSOFT stopped keying on the source altogether. Our inbound DDoS engine asks a different question, in the data path, at line rate: which of my subscribers is being flooded, and by what kind of attack? — then drops only that attack flow to that subscriber. The attacker's IP is never on the ledger, so CDNs and carriers are spared by construction.
Victim + vector
not source IP
detect per (subscriber, attack type) — the source is never keyed, so aggregators can't be blocked
6 attack classes
one classifier
reflection · UDP · SYN · out-of-state TCP · ICMP · other-proto — each rate-limited per subscriber
In the BNG
eBPF/XDP line-rate
no scrubbing box, no tromboning — dropped in-kernel where the packet already is
Monitor→Limit→Block
graduated · self-healing
escalate only on a sustained flood, auto-heal the instant it stops — observe-first, default-off
The attacker's IP is not the attack. The victim and the vector are. Key on those, and the CDN false-positives don't get "reduced" — they become impossible.
The trap in source-IP DDoS filtering
Ask the wrong question and you get the wrong answer. A source-keyed auto-block asks “is this source IP sending a lot of packets?” — summed across every subscriber. On an access network the top talkers are never attackers, they're the internet your subscribers paid for:
Source-IP filter — structurally blind
The busiest source is a CDN, not an attacker. No amount of source-rate tuning fixes a wrong question.
BNGSOFT victim + vector New
Key on the victim and the vector. The flooded subscriber stays online; neighbours and every CDN are untouched.
Six attack classes, one line-rate classifier New
After a packet resolves to the subscriber it's headed for, one branch-light classifier files it under a vector and counts it against a per-victim, per-vector, per-second limit. Reflection is a hard drop (near-zero false positive); the volumetric classes are rate limits that drop only the excess, so legit traffic of the same type keeps flowing under the ceiling.
Attack vector
What BNGSOFT sees
Action
1 · UDP reflection / amplification
reply from a known amplifier port — DNS 53, NTP 123, SSDP 1900, memcached 11211, CLDAP 389, chargen 19, SNMP 161, and ~20 more
Drop — concentrated, near-0 FP
2 · Direct UDP flood
per-victim unsolicited UDP packet rate
Rate-limit the excess
3 · TCP SYN flood
per-victim SYN-without-handshake rate
Rate-limit the excess
4 · Out-of-state TCP (ACK/RST/FIN)
non-SYN TCP with no established session — spoofed / reflected
Observe → opt-in enforce
6 · ICMP flood / Smurf
per-victim ICMP rate
Rate-limit the excess
9 · Other IP protocol
GRE / ESP / SCTP and other non-TCP/UDP/ICMP floods, per victim
Rate-limit the excess
Multicast/IPTV is whitelisted, thresholds are per-vector. Out-of-state TCP ships observe-only on purpose — the one class where a briefly-idle legit flow could look "stateless" — and only becomes enforcing when you flip a per-vector switch, after the observe log shows it's clean.
Graduated response: monitor → limit → block New · v3
A flood isn't a light switch, so the response isn't either. For every (victim, vector) the engine now walks a graduated state machine — it watches, then trims, then fully blocks only a sustained attack — and heals itself the moment the flood stops. A brief spike never escalates; a real, committed flood climbs to a full block in seconds; and nothing stays blocked a heartbeat longer than the attack lasts. No human in the loop, no stale blocks to clean up.
Per (victim, vector): escalate on sustained over-threshold seconds, decay one step each quiet second, and auto-clear when idle. Reflection still hard-drops on sight — graduation is for the volumetric classes where legit traffic of the same type exists.
Monitor
Crossed the threshold once. Counted and flagged — the operator watches it build; nothing is dropped yet.
Limit
Sustained a couple of seconds. Cap only the excess above the per-vector rate — legit traffic of that type keeps flowing under the ceiling.
Block
Sustained ~8 seconds. Drop the whole vector to that victim — a committed flood gets zero room, the rest of the subscriber's traffic is untouched.
Auto-heal
Flood stops → decay block→limit→monitor, then the flag deletes itself. No stale blocks, no cleanup ticket, no operator babysitting.
Every stage is visible from one command — bngxdpctl ddos v2 status — so you can watch enforce decisions form in observe mode before a single packet is dropped:
Self-healing observability. The flag that marks a victim “under attack” used to latch forever; now it decays and auto-clears when the flood ends, so what you see is what's happening right now — not a graveyard of old spikes. The count is the truth, live.
How it rides in the data path Updated
The classifier lives in the same in-kernel eBPF/XDP program that already forwards, NATs and shapes every packet — so it runs where the packet already is. No appliance, no tromboning, no per-packet cost worth measuring.
1 · Resolve the victim
Detection runs after the BNG has resolved which subscriber the packet is for (post-NAT on CGNAT), so the counter is keyed on the real end subscriber — never a shared public IP.
2 · Classify the vector
One pass decides the vector from the L3/L4 header (amplifier port, TCP flags, protocol) — no second parse, no per-vector map cross-product.
3 · Per-victim rate
A per-CPU counter per (victim, vector) crosses its second-window threshold → the subscriber is flagged and only that vector's excess is dropped in-kernel, at line rate.
What this replaces: scrubbing centres and blackholes New
The two things operators reach for today both fail the subscriber in a different way. Scrubbing detours your traffic; blackholing finishes the attacker's job for them.
Same attack, three outcomes: scrubbing adds a detour and a bill; RTBH blackholes the victim; BNGSOFT drops only the attack flow where the packet already is.
Scrubbing centre / cloud scrub
RTBH / router ACL
BNGSOFT inbound DDoS
Where it runs
Separate appliance or far cloud PoP
Edge/core router
In the BNG you already run — eBPF/XDP
Granularity
Destination IP / prefix
Whole victim /32
Per subscriber × per attack vector
Effect on the victim
Cleaned if diverted in time
Fully offline (attacker wins)
Stays online — only the attack flow drops
CDN / carrier false-block
Possible on shared prefixes
N/A
Impossible — source is never keyed
Latency added
Tromboning to the scrubber
None
None — packet never leaves the path
Added cost
Appliance capex + per-Gbps, or monthly cloud opex
Router feature
Software feature of the BNG — no new box
Fair framing. Scrubbing centres and cloud DDoS services remain the right tool for very large edge-saturating volumetric attacks that must be absorbed before your uplink. BNGSOFT's inbound engine is complementary: it protects the individual subscriber inside the network — the per-victim, per-vector layer that scrubbing prefixes and blackholes can't express. Arbor Sightline/TMS, Radware DefensePro, Cloudflare Magic Transit and AWS Shield are trademarks of their respective owners, named for comparison only.
Cost: a software feature, not another appliance New
$0
added hardware — it's a feature of the BNG you already operate
0 ms
latency tax — no scrubber detour, no tromboning transit
≈2.5%
data-plane CPU at production load; detection is off the hot path
A dedicated scrubbing appliance is a capital purchase plus per-gigabit licensing; managed cloud scrubbing is a recurring per-Gbps subscription; both add a hop your traffic must detour through. BNGSOFT's inbound DDoS is a capability of the same eBPF/XDP data plane already forwarding your subscribers' traffic — no extra chassis to rack, power and refresh, no diversion bandwidth to pay for, and it scales for free as you add BNG capacity. For per-subscriber, in-network protection the marginal cost per protected subscriber is effectively zero.
What you get for your network
For the operator
Per-subscriber DDoS built into the BNG — protection for every line, not just a handful of protected prefixes.
Zero CDN/carrier false-blocks — the source is never on the ledger, so “Netflix is down / WhatsApp won't send” support storms during an unrelated attack simply stop.
Blast-radius of one — an attack on subscriber A never touches B, C or the CDNs everyone shares.
No new box, no scrubbing subscription — lower capex and opex, one less thing to rack, license and refresh.
Safe to turn on — observe-first, per-vector thresholds, opt-in enforce per class, default-off.
For the end user
Under attack on their line? Only the flood is dropped — their game, stream, call and downloads keep working. They are not blackholed off the internet the way an RTBH null-route would do.
Under attack on a neighbour? Zero impact — no shared-CDN outage, no collateral.
Every day? No added latency, ever — traffic never detours to a scrubber, so gaming and real-time apps stay crisp.
The invisible win: the best DDoS protection is the one the subscriber never notices, because their service simply never went down.
Observe before you enforce Updated
Nobody should drop subscriber traffic blind. The engine ships in observe mode: it runs the full per-victim, per-vector logic and records exactly what it would drop — which subscriber, which vector, what rate — while dropping nothing.
# observe mode: full detection, nothing dropped
DDoS v2 observe: victim subscriber #7455 vector=UDP-REFLECTION rate=82,657/s [would drop, observe only]
DDoS v2 observe: victim subscriber #7452 vector=TCP-SYN rate=25,544/s [would drop, observe only]# confirm no legit subscriber ever appears, then enable enforce per vector:bngxdpctl ddos v2 enforce# reflection + volumetric rate limits go livebngxdpctl ddos v2 threshold udp 2000# tune any vector's per-victim ceilingbngxdpctl ddos v2 oos-enforce on# opt-in the observe-only class when the log is clean
Proven, not just described.Lab-validated In controlled testing we aimed an amplifier-port reflection flood at a single subscriber: the engine attributed it to that victim (not the source), counted 82,657 packets/second, and in enforce mode dropped it in-kernel at line rate — the subscriber's real download kept flowing untouched. A separate SYN flood and a direct-UDP flood each flagged their own victim on the correct vector, and live legitimate traffic produced zero false positives. v3 graduated response, validated live: on a running BNG a sustained flood on one subscriber climbed monitor → limit → block within seconds — and the moment the flood stopped it decayed back down and cleared itself, no operator action, the live count tracking reality the whole time.
Where the intelligence sits
QoS / BNG edge
The victim is the subscriber's own IP; the “did they ask for this?” check uses the kernel's nf_conntrack state.
Detection runs after the reverse-NAT resolves the real subscriber, so the counter is keyed on the end user behind the shared public IP — never the pool address.
Reuses the session lookup the download path already performed — no extra cost.
“A source pushing 300,000 packets a second isn't an attacker if it's feeding ten thousand of your subscribers — it's a CDN. So stop looking at the source. Look at which subscriber is drowning, and in what. That's the only question worth answering in-line.”— BNGSOFT edge security
Where we stay honest. The victim + vector engine targets inbound floods aimed at your subscribers; edge-saturating attacks that must be absorbed upstream of your uplink remain a scrubbing-centre job, and outbound abuse is handled by the separate protect / scanner / quarantine path. Out-of-state TCP is observe-only by default and enforces only when you opt in per vector. All per-vector thresholds are tunable and the whole feature is default-off. The lab results above were measured in controlled testing on the BNGSOFT data plane; validate thresholds and behaviour against your own subscriber base and traffic mix before enabling enforce. Source-IP and subscriber examples are illustrative.
Stop choosing between “protected” and “my subscribers can reach the internet”
Inbound DDoS protection belongs in the BNG — but only if it protects the subscriber under attack instead of chasing the attacker's IP and blackholing the victim or the CDNs everyone shares. BNGSOFT keys on victim and vector, drops only the attack flow, keeps the subscriber online, and spares Netflix, WhatsApp, Cloudflare and your peers by construction — line-rate, in software, no scrubbing box.
