DDoS Protection & Protect Mode · victim×vector · solicited-aware · monitor→limit→block · v4 + v6

Security Brief · Inbound DDoS & Protect Mode

Block the flood. Keep the subscriber online.

A volumetric flood aimed at one subscriber shouldn't knock them offline — and neither should the mitigation. Crude "drop everything to this IP" DDoS filtering is itself an outage: it clips the subscriber's own game, video call, download and web traffic along with the attack. BNGSOFT does the opposite. It classifies every inbound packet to a (victim × attack-vector) pair, drops only the unsolicited excess with a graduated monitor → limit → block response, and a solicited gate spares anything the subscriber actually asked for — across IPv4-CGNAT, native IPv6, and public IPv4.

legit requests dropped

HTTP 200 through every flood

block

reached in seconds

monitor→limit→block, dropped the flood

attack vectors

refl / UDP / SYN / RST / ICMP / ICMPv6 / frag

v4 + v6

one unified engine

CGNAT-v4 · native v6 · public v4

A DDoS filter that also drops the customer's own traffic hasn't protected them — it has finished the attacker's job. Surgical beats sweeping.

The problem — collateral damage is the real outage

Most edge DDoS defences work at the granularity of an IP. When a subscriber (or the shared CGNAT public IP they sit behind) is flooded, the box either blackholes the whole address or rate-limits everything to it. The flood stops — and so does the subscriber's Netflix stream, their Zoom call, their Steam download, their online banking. To the customer, "we mitigated a DDoS on you" is indistinguishable from "we took you offline." On a shared CGNAT pool it is worse: one flooded target can strand every innocent subscriber on that public IP.

What operators actually need: stop the attacker's packets, keep the customer's packets. That requires the box to tell the two apart per packet, per subscriber, per vector — at line rate, in the data plane — not a coarse per-IP hammer.

How BNGSOFT tells the flood from the customer

Every download packet that resolves to a subscriber runs through an in-line XDP classifier. It answers three questions in order, entirely in the data plane:

Per-packet, in XDP: classify to (victim, vector) → spare anything the subscriber recently solicited → rate-limit only the unsolicited excess. A legit high-rate flow (game, QUIC, CDN, OS update) is on the green path and is never touched.

1 · Whose traffic is this?

The packet is resolved to the exact subscriber it's destined for (CGNAT reverse map, or the IPv6 / public-IPv4 customer route). That subscriber is the "victim" key — so counting and any drop are scoped to one subscriber, never the whole box or pool.

2 · What kind of attack?

The packet is classified into one of seven vectors — UDP reflection/amplification, UDP flood, TCP SYN, TCP SYN-ACK/RST reflection, out-of-state TCP, ICMP / ICMPv6, and IP-fragment flood — each with its own per-second threshold.

3 · Did they ask for it?

If the subscriber sent an outbound packet on this flow within the recent window (default 30s), the inbound is solicited and is passed untouched — no counting, no drop. Only unsolicited traffic can ever be mitigated.

Graduated, surgical enforcement — not a kill switch

A flagged (victim, vector) doesn't jump straight to a blackhole. It escalates through three stages driven by a control-plane sweep, and only the packets above the threshold are dropped — the subscriber's baseline of that same traffic type keeps flowing.

Observe-before-enforce is built in: run the whole engine in monitor mode to see exactly what would be flagged — per victim, per vector — before you ever enable a drop.

Live validation — production BNG, real subscriber

The engine was exercised in live enforce mode on a production BNG serving real subscribers. An inbound flood was directed at one subscriber's IPv6 host from an external source, across three vectors in turn. Throughout every flood, that same subscriber's own web browsing was measured from their device.

Vector (v6, inbound to subscriber)	Detector result	Subscriber's own v6 web, during flood
ICMPv6 flood	escalated to BLOCK · unsolicited flood dropped in XDP	HTTP 200 · ~0.66 s (normal)
TCP-SYN flood	detected · flagged · ~3,700 unsolicited SYN/s counted to the victim	HTTP 200 · ~0.68 s (normal)
UDP flood	counted per victim · unsolicited UDP tracked against threshold	HTTP 200 · ~0.58 s (normal)
Baseline (no flood)	—	HTTP 200 · ~0.81 s

The headline result: the attack traffic was detected and blocked per-victim while the subscriber's own IPv6 browsing returned HTTP 200 at normal latency through every single flood. Zero false-drop of solicited traffic — the mitigation was invisible to the customer.

# production BNG — live, during the ICMPv6 flood $ bngxdpctl ddos attacks DDoS Protection — Active Attacks (per victim + vector) Mode: enforce Total flagged: 1 victim ppp1 vector icmpv6 state block dropped 229 # the same subscriber's own browser, same moment > curl -6 https://ipv6.google.com HTTP 200 (0.66 s) ← untouched

Solicited-sparing — the "never touch what the sub asked for" guarantee

Coarse per-IP DDoS filter

Flood on subscriber → blackhole / rate-limit the IP.

The attacker's packets stop — and so do the subscriber's game, video call, download and web. The customer experiences the mitigation as an outage. On a shared CGNAT IP, everyone behind it is hit.

BNGSOFT solicited-aware mitigation

Flood on subscriber → drop only the unsolicited excess.

Any flow the subscriber sent outbound on within the window is spared — game, QUIC, CDN, OS update, web. The block is surgical to the attack vector. The customer never notices.

The "recent outbound" signal is read straight from the data plane per family: the CGNAT forward-session timestamp for IPv4-CGNAT subscribers, and a dedicated outbound-seen map for native IPv6 and public IPv4. If the subscriber touched it, it lives — before any counting happens, so a legitimate high-rate flow is never even measured against a threshold.

One engine for IPv4-CGNAT, native IPv6, and public IPv4

IPv4 · CGNAT

Behind the shared pool

Victim resolved via the CGNAT reverse map
Solicited = a live CGNAT upload session
Protects the pool's reputation too

Native IPv6

First-class, not an afterthought

Full v6 parse: real L4 ports & flags
ICMPv6 flood is its own always-on class
v6 TCP/UDP + fragment detection

Public IPv4

Routed / static subscribers

Same victim×vector model
Outbound-seen solicited sparing
No separate policy to maintain

Protect Mode is the umbrella: inbound subscriber DDoS (above), outbound-abuse detection (a compromised subscriber flooding out), and the box's own self-protection are one coordinated posture with a single enforce / observe switch and one live view.

Built for the data plane

Line-rate, in XDP

Classification and the drop decision happen in the eBPF/XDP fast path before the kernel network stack — a flood is dropped on the NIC-driver ring, not after it has already cost the box CPU. Per-CPU counters keep the hot path lock-free.

Operator-tunable

Every per-vector threshold, the solicited window, and the escalation are configurable and hot-reloadable. Observe mode lets you watch what would be flagged on your real traffic before enabling any drop.

Surgical by construction

Counting is keyed on (victim, vector), so a flood on one subscriber never rate-limits another, and a UDP flood never touches the victim's TCP. A thin-spread "carpet-bomb" across many victims is caught by a matching aggregate.

Accountable

Every flagged victim is visible live with its vector and stage; observe-mode candidates are logged before any enforcement. You can always answer "what did the box drop, for whom, and why."

Stop the attacker's packets. Keep the customer's.

BNGSOFT DDoS protection and Protect Mode give you surgical, per-victim, per-vector inbound flood mitigation that is solicited-aware — so the customer stays online while the flood is dropped in the data plane. IPv4-CGNAT, native IPv6, and public IPv4 in one engine, default-on and operator-tunable.

Ask for a walkthrough of the live enforcement results and how it fits your edge — sales@bngsoft.com.

How these results were produced (honest framing). The validation was run in live enforce mode on a production BNGSOFT BNG serving real subscribers, flooding one test subscriber's IPv6 host from an external internet source while measuring that subscriber's own IPv6 web from their device. The "229 packets dropped", the per-second SYN/UDP counts, and the "HTTP 200 throughout" figures are from that run. Because standard packet generators could not sustain the multi-thousand-pps rates the production thresholds are set to for valid IPv6, the relevant per-vector threshold was temporarily lowered for the demonstration and then restored — this exercises the identical detect→escalate→block→spare code path at a controlled rate; it does not change how the engine behaves. Absolute packet counts, latency, and escalation timing depend on hardware, NIC, traffic mix, and configured thresholds, and are indicative — validate per deployment. Per-vector thresholds and the solicited window are operator-tunable; the feature is default-on from release 3.7.73 and can be disabled in configuration. Names of internal daemons/components are omitted; this brief describes the BNGSOFT BNG data-plane behaviour.