Overview
Picture the moment power comes back after a three-hour outage. The network itself doesn’t decide whether the region is online again. The AAA (Authentication, Authorization and Accounting) tier does. Tens of thousands of CPEs, ONTs and handsets wake up within seconds of each other, and every one of them sends an Access-Request or a Diameter authentication message to the same handful of servers.
Not one of those requests is hostile. The tier can still go down under them. That’s authentication noise: legitimate signaling that shows up in a volume or a pattern the AAA path was never sized for. The awkward part is that a malicious storm looks exactly the same until you read the reject codes. So signaling storm protection starts with telling the two apart, which makes it as much a telecom security problem as a capacity one.
What follows is a taxonomy of authentication storms, a four-layer filtering stack, the handful of signals that separate noise from attack, and a playbook your NOC can actually follow at three in the morning.
What Is a Signaling Storm in Authentication Infrastructure?
A signaling storm in authentication infrastructure is a sudden surge of RADIUS or Diameter requests that exceeds what the AAA tier can process. Storms can be self-inflicted (power restoration, firmware pushes), protocol-induced (retransmission loops), device-induced (IoT reconnect loops) or malicious (credential stuffing, floods), and every type needs layered filtering rather than one control. Authentication noise is the legitimate share: real subscribers, no attacker, still more than the tier was built for.
Most of what gets written about signaling storms is really about interconnect floods on S6a, S9 and the other roaming links. A Diameter routing agent (DRA) deals with those, following Diameter security guidance such as GSMA FS.19. Authentication storms happen somewhere else. They run along the access path, from a BNG, BRAS, PGW, SMF, ePDG or wireless LAN controller to the AAA server, and from there to whatever LDAP, HSS, UDM or OCS sits behind it. An interconnect firewall never sees a RADIUS retransmission storm from a misconfigured BNG, and a DRA tuned for S6a has no idea credential stuffing is arriving over the 3GPP TS 29.273 interfaces that carry Wi-Fi offload.
Noise or Attack? A Taxonomy of Authentication Storms
Four families, and they all announce themselves the same way, with a step change in request rate. The eight triggers we see most often are power restoration, firmware pushes, controller failover, DHCP lease-expiry waves, short NAS retry timers, proxy loops, IoT reconnect loops and credential stuffing.
| Storm type and triggers | Signature at the AAA tier | Noise or attack |
| Self-inflicted: power restoration, firmware push, failover, DHCP wave | Sharp step; known identities; mostly Access-Accept; footprint matches an event | Noise |
| Protocol-induced: short NAS timers, aggressive retries, proxy loops | Requests climb while unique identities stay flat; repeated Identifiers | Noise |
| Device-induced: IoT reconnect loops, bad CPE firmware, Wi-Fi roaming churn | Few devices at very high rate; same reject repeating for days | Noise |
| Malicious: credential stuffing, brute force, RADIUS or Diameter floods, rogue NAS | Rejects dominate; unknown identities; concentrated sources; no matching event | Attack |
Self-inflicted re-authentication storms
Power restoration is the textbook case. Hours of authentications get squeezed into seconds, then a second wave of accounting starts and DHCP renewals arrives that nobody planned for. A firmware push without any stagger does the same thing, except on a schedule you picked yourself.
Protocol-induced RADIUS retransmission storms
RADIUS runs over UDP, so the client decides when to retry, and nothing stops it deciding badly. A one-second timeout with unlimited retries turns every slow response into a fresh request. Add a proxy with no duplicate detection and the same request gets multiplied again. RFC 5080 addresses exactly this. During one migration we traced a storm that had been running quietly for months back to a BRAS retry timer still sitting at the vendor default. Nobody had touched it since the box was racked.
Device-induced storms
An IoT fleet with a reconnect loop baked into its firmware behaves like a slow, permanent attack. Same devices, same failure, every few seconds, for days. Bad CPE firmware does it after a push. Wi-Fi roaming churn does it in bursts, as handsets flap between access points on a crowded floor. The giveaway is a tiny population of identities generating most of the requests, each failing with the same Access-Reject reason every time.
Malicious storms: credential stuffing, RADIUS floods, rogue NAS
Credential stuffing replays leaked credentials across the subscriber base. Brute force takes the opposite approach and hammers a few identities. A RADIUS flood, the most basic RADIUS attack, just exhausts capacity. A rogue NAS injects requests from outside the trust boundary, which is precisely the gap a zero-trust AAA design closes. All of them show up as volume first. The hardest campaign to spot is one that hides inside a genuine power-restoration surge; the only giveaway is a reject rate that stays high long after the real traffic has settled. If you need budget for any of this, the security case for AAA modernization is the place to start.
How a Storm Cascades Into an Outage
It takes six steps, and two of them do most of the damage:
- Requests outpace the server; queue depth climbs.
- p99 latency passes the NAS timeout.
- Every NAS retransmits; each duplicate costs a backend lookup.
- LDAP, HSS, UDM or OCS lookups time out.
- The NAS fails over; the secondary inherits the load.
- Failed sessions reconnect; a third wave lands.
Steps 3 and 6 are the amplifiers. They turn a wave that should have lasted seconds into an outage measured in tens of minutes, and filtering at Layers 1 and 3 is aimed squarely at them. The identity store usually gives out first, because backend identity stores are sized for normal read rate, not storm rate.
The Four-Layer Signaling Storm Protection Stack
Signaling storm protection is a stack, not a box. Each layer stops something the layer below it can’t see, and the table shows which control, which standard and which kind of storm belongs at each level. You won’t get all four from one vendor.
Layer 1: NAS and client discipline
A NAS that behaves is protection you already paid for. RFC 5080 spells out the retransmission algorithm RADIUS borrowed from DHCPv6: a two-second initial timeout, random jitter, exponential backoff, and a hard cap on both retries and total duration. Failover should follow the RFC 3539 watchdog model rather than a raw timeout, so a client only walks away from a server that has really stopped answering. Staggered reboots and randomized interim-accounting intervals live here too. Check every NAS vendor in the estate, not just the one you bought most recently; the old boxes are the ones nobody has looked at.
Layer 2: Proxy, load balancer and Diameter routing agent
The proxy tier’s job is to keep floods off the server. On the Diameter side that’s a Diameter routing agent (DRA); on the RADIUS side it’s a proxy or a load balancer. Diameter overload control (DOIC, RFC 7683) lets an overloaded server tell its clients to cut traffic by a stated percentage for a stated period, and either the DRA or the client applies the reduction. RFC 7944 marks which messages get dropped first, and RFC 8581 covers overload at the agents themselves. RADIUS has no overload signal at all, so a RADIUS proxy does the work on its own: per-peer limits, dropping unknown clients, loop detection. RadSec (RFC 6614) moves RADIUS onto TLS, so a shared secret is no longer the only thing standing between a spoofed client and your server.
Layer 3: AAA server admission control
Five controls protect a RADIUS or Diameter server from floods:
- RADIUS rate limiting per NAS, subscriber and realm, plus per-account throttling of failed attempts (NIST SP 800-63B)
- A duplicate-detection cache keyed on source address, source port, Identifier and Request Authenticator
- Coalescing identical in-flight requests into one backend call
- Prioritizing re-authentication of existing sessions, and shedding accounting first
- Backpressure that signals overload early instead of timing out late
This is where signaling filtering and real-time fraud detection live in the Alepo AAA Server, a carrier-grade RADIUS, Diameter and TACACS+ platform built for operators. Filtering strips out duplicates and over-rate sources before they reach the backend. Fraud detection blocks suspicious attempts by pattern rather than volume, which matters because a slow campaign never trips a volume threshold.
Layer 4: Fast paths that remove load
The best request is the one that never reaches the backend at all. EAP-AKA and EAP-SIM fast re-authentication (RFC 4187, RFC 4186) reuse keying material from the last full exchange, so a reconnecting handset skips the HSS or UDM round trip. EAP-TLS session resumption (RFC 5216, RFC 9190) does the same for certificate-based clients. Short-TTL result caching lets the server answer a re-authentication storm from memory while the backend catches its breath. And when none of that is enough, degrade gracefully rather than heroically: keep existing sessions up, defer accounting, keep answering.
Telling Noise From Attack in Real Time
The first ten minutes decide whether you’re fixing a timer or calling the SOC.
| Signal | Legitimate surge | Attack | Check |
| Unique identities per second | Known subscribers | Unknown identities, or a few with many attempts | Unknown-user ratio |
| Reject-code mix | Accepts dominate | Rejects dominate; bad-credential reasons; repeated EAP failures | Access-Reject reasons, EAP traces |
| Per-NAS distribution | Matches the event footprint | Few NAS IPs; unexpected sources | NAS inventory |
| Timing | Follows a known event, then decays | No event; flat; persists | Change calendar |
| Retransmission ratio | Climbs after latency rises | Often low; scripts do not wait | High ratio, flat identities: a timer |
No single signal settles it. Taken together they rarely miss, even when someone has timed a credential-stuffing run to coincide with a real outage.
Where AI-assisted detection fits
Nobody runs five checks in ten minutes for every spike at carrier scale, and nobody should have to. The platform criteria are covered in AI anomaly detection for authentication traffic, so we won’t repeat them here. The short version: the Alepo AI Agent for AAA flags brute-force and credential-stuffing patterns and decodes reject codes and EAP failure traces for you, so the table above becomes a query rather than a war-room exercise.
Headroom vs. Filtering: Why You Need Both
Filtering lowers the storm multiple. It never gets it down to one. Even a perfectly filtered power-restoration surge still delivers one legitimate reconnect per device, and only headroom absorbs that remainder. Our guide to sizing AAA with transaction headroom for re-authentication storms has the arithmetic. Alepo sizes headroom against storm scenarios rather than average peak, and signaling filtering is what keeps that headroom from being spent on duplicates. It’s worth asking any AAA vendor the same thing in a PoC: what is your tested transaction rate under our largest fleet’s reboot profile, not under an average afternoon?
Storm Response Playbook
Assign owners before the next outage, not during it.
| Stage | What to do | Owner | Tooling |
| Detect | Alert on request-rate step, queue depth, p99 latency and retransmission ratio | NOC | AAA metrics, proxy counters |
| Triage | Five-signal check; classify within ten minutes | NOC, SOC on call | Reject-code reports, anomaly detection |
| Act | Noise: raise per-NAS limits, extend cache TTL. Attack: tighten per-identity throttles, block sources, enable fraud rules | AAA engineering, security | Admission policy, proxy ACLs, fraud rules |
| Recover | Confirm backend latency before lifting limits; fail back deliberately | AAA engineering | Backend health checks |
| Learn | Record trigger, multiple, time to classify; fix the root cause; add the scenario to stress tests | Architecture, security | Post-incident review, test harness |
Triage finishes before anyone touches a limit. Raising per-NAS limits during a flood hands the attacker more capacity, and that’s a mistake you only get to make once.
Measuring Protection: Metrics and Tests
Throughput and CPU tell you a storm is over. They don’t tell you one is starting. Watch these instead:
- Transactions per second, per NAS
- Queue depth and p99 latency
- Retransmission ratio (duplicates over unique requests)
- Reject rate by Access-Reject reason and EAP failure code
- Unique identities per second against requests per second
- Backend lookup latency
The retransmission ratio belongs on the main NOC screen. When it starts climbing before the request rate does, a timer changed somewhere, and you want to know which one before the next reboot window.
Then replay three profiles against staging with every release: a power-restoration surge sized to your largest fleet’s reboot window, a retransmission loop from a single misconfigured NAS, and a credential-stuffing script.
Get a storm-resilience review of your authentication path
Signaling storm protection is a design exercise, not a product switch. If you would like a second pair of eyes on where authentication noise would hit your NAS-to-AAA path first, Alepo’s AAA experts run resilience and security reviews for operators who would rather find out before the next outage.
Frequently Asked Questions
Q1. What is the difference between an authentication storm and a Diameter signaling storm?
Diameter signaling storms hit interconnect and roaming interfaces such as S6a and S9, where a Diameter routing agent handles them. Authentication storms hit the NAS-to-AAA access path instead, where an interconnect firewall never sees them.
Q2. Why does a power outage cause an authentication storm when power comes back?
Every device reconnects within the same reboot window, which compresses hours of authentications into seconds. A second wave of interim accounting and DHCP renewals follows close behind.
Q3. How do misconfigured NAS timers overload RADIUS?
A short timeout with aggressive retries turns every unanswered request into several, so load grows fastest at exactly the moment the server is slowest. RFC 5080 prescribes jittered backoff and capped retries to break that loop.
Q4. What is Diameter overload control (DOIC)?
DOIC is the RFC 7683 mechanism that lets an overloaded Diameter server tell its clients to cut traffic by a percentage for a validity period. Either a Diameter routing agent or the client applies the reduction.
Q5. Where should RADIUS rate limiting be applied?
At the proxy per peer, and at the server per NAS, subscriber and realm. Layered RADIUS rate limiting is a low-cost RADIUS security control because it needs policy changes, not new hardware.
Q6. Can IoT devices cause signaling storms?
Yes. A firmware reconnect loop produces a long-running storm of identical failures from a small group of devices. Device-side backoff, per-device limits and result caching keep it contained.
Q7. How much headroom should AAA have for storms?
A multiple of normal peak derived from your own storm scenarios, not from a generic rule of thumb. Our high-availability AAA guide covers the method.
