The Diameter Cancel-Location-Request (CLR) is one of the most operationally sensitive messages on the S6a interface — a single command that can strip a subscriber out of the network mid-session. It exists for good reasons: HSS failover cleanup, subscription changes, IMSI detach. But the same message, sent by an attacker impersonating the Home Subscriber Server, becomes a surgical denial-of-service primitive, and — chained with a raced re-registration — a stepping stone toward attach hijack.

This is a narrower, more targeted cousin of the S6a location-tracking abuse we cover in our Diameter protocol research: rather than reading subscriber data, CLR abuse writes to network state, forcibly deregistering a target. Where SS7's UpdateLocation attacks intercept SMS by rerouting a subscriber's serving node, the Diameter CLR attack takes the more direct route — kicking the subscriber off the network entirely, on command, from anywhere with S6a interconnect reach.

This research dissects the Diameter S6a Cancel-Location-Request forced-deregistration attack: the legitimate CLR use cases it abuses, the message-crafting steps required to impersonate an HSS, the denial-of-service and attach-hijack impact chains, and the GSMA FS.19 controls that close the gap. We also cover the documented industry testing that found the underlying validation gap present in the majority of assessed MME deployments.

I. The S6a Interface and the CLR's Legitimate Role

In LTE/EPC, the Home Subscriber Server (HSS) and the serving Mobility Management Entity (MME) exchange registration state over the Diameter S6a interface (3GPP TS 29.272). Most attention on this interface goes to Update-Location-Request (ULR) and Authentication-Information-Request (AIR) — the messages that leak subscriber location and authentication vectors, as detailed in our broader Diameter protocol security analysis. The Cancel-Location-Request (CLR, Command-Code 317) receives less scrutiny, but it carries a very different kind of power: it doesn't read state, it writes it — specifically, it tells the serving MME to tear a subscriber's registration down.

CLR has three legitimate triggers:

Subscription change — an operator modifies a subscriber's profile in the HSS, and the HSS sends CLR to force the MME to re-attach the subscriber under the new profile.
IMSI detach — the subscriber cancels service, and the HSS clears the MME registration.
HSS failover recovery — after an HSS restores from backup, it sends CLR to clear MME registrations that may now be stale relative to its restored state.

The MME has no inherent way to tell a legitimate CLR from a spoofed one. Both arrive as a standard Diameter message with an `Origin-Host` AVP claiming to be the HSS. Unless the MME explicitly validates that Origin-Host against a pinned, known-good HSS FQDN, a CLR from any Diameter peer that can reach the S6a interface — including an attacker with interconnect access — is processed identically to one from the real HSS.

┌──────────────────────────────────────────────────────────────────────┐
│                  LEGITIMATE vs ATTACK CLR                             │
│                                                                        │
│  LEGITIMATE:                                                           │
│  HSS (real) → S6a → MME → Detach-Request → UE loses connectivity     │
│                                                                        │
│  ATTACK:                                                               │
│  Attacker (spoofed HSS Origin-Host) → S6a → MME → Detach-Request →   │
│  UE loses connectivity                                                 │
│                                                                        │
│  DIFFERENCE: MME has no way to distinguish if CLR is from real HSS    │
│  unless it validates Origin-Host against a pinned HSS FQDN            │
└──────────────────────────────────────────────────────────────────────┘

Locating the Serving MME

A CLR must be routed to whichever MME is currently serving the target subscriber. That MME identity is not secret — it's recoverable from a prior S6a Update-Location-Answer (ULA), which is itself the product of the ULR-based tracking technique documented in our Diameter protocol research:

ULA (Serving-Node data returned to any ULR sender):
  Subscription-Data:
    Serving-Node:
      MME-Name: mmec01.mnc007.mcc262.3gppnetwork.org    ← Target MME FQDN
      MME-Realm: epc.mnc007.mcc262.3gppnetwork.org
      MME-Number: +4917600001

Absent a direct ULR, the same FQDN can often be enumerated via DNS SRV records (_diameter._sctp.epc.mncXXX.mccYYY.3gppnetwork.org), GSMA IR.21 interconnect documentation the operator itself publishes, or passive capture at an IPX peering point.

II. Exploitation: Forcing the Detach

Step 1 — Establish a Diameter Peer Session as a Spoofed HSS

The attacker opens a Capabilities-Exchange (CER/CEA) handshake toward the target MME, but instead of presenting as an MME (as in a ULR-spoofing attack), the Origin-Host claims to be the subscriber's home HSS:

<CodeBlock language="text" filename="clr-cer-spoofed-hss.avp" code="CER → target MME Origin-Host: hss01.epc.mnc007.mcc262.3gppnetwork.org ; spoofed HSS Origin-Realm: epc.mnc007.mcc262.3gppnetwork.org Auth-Application-Id: 16777251 ; S6a Application ID Vendor-Id: 10415 ; 3GPP

CEA ← MME: Result-Code: DIAMETER_SUCCESS ; peer session accepted, no cert check" />

If the MME enforces mutual TLS with strict certificate CN validation, this handshake fails outright. If TLS is absent, or present but not validated against the claimed Origin-Host, the session is accepted.

Step 2 — Send the Cancel-Location-Request

With a peer session open, the attacker issues the CLR itself, targeting the victim's IMSI and selecting the most disruptive Cancellation-Type:

<CodeBlock language="text" is-terminal code=" # CLR (Diameter S6a Command-Code 317) Session-Id: hss01.epc.mnc007.mcc262;1234;9876 Origin-Host: hss01.epc.mnc007.mcc262.3gppnetwork.org ; spoofed Destination-Host: mmec01.mnc007.mcc262.3gppnetwork.org ; real MME User-Name: 262071234567890 ; target IMSI Cancellation-Type: SUBSCRIPTION_WITHDRAWAL (0) ; forces full detach

Cancellation-Type values (3GPP TS 29.272):

0 = SUBSCRIPTION_WITHDRAWAL -> immediate UE detach

1 = UPDATE_PROCEDURE -> after TAU/ULR

2 = INITIAL_ATTACH -> after initial registration

4 = MME_UPDATE_PROCEDURE"

SUBSCRIPTION_WITHDRAWAL is deliberately the most severe option: it causes the MME to immediately issue an S1-AP UE Context Release and a NAS Detach Request, rather than waiting for the next tracking-area update cycle.

Step 3 — The MME Executes the Detach

An MME that skips Origin-Host validation processes the forged CLR exactly as it would a genuine one:

Marks the subscriber's EMM context as deregistered.
Sends a NAS Detach Request to the UE (Re-attach Required or Re-attach Not Required).
Releases the S1-AP UE context.
Tears down any active EPS bearers — live PDU sessions and in-progress VoLTE calls included.

The handset surfaces this as a dropped connection or a transition to "No Service," and typically attempts automatic re-registration.

A CLR alone is a denial-of-service primitive. Combined with prior HSS access, it becomes something worse: after the forced detach, the victim UE immediately initiates a new Attach or Tracking Area Update. An attacker who fires a fraudulent ULR — claiming to be a rogue serving MME — timed to land before the legitimate MME's registration completes can win the race and have the HSS register the attacker's node as the subscriber's new serving point. From there, SMS and voice traffic route through the attacker, mirroring the effect of an SS7-layer UpdateLocation hijack. Automated, this CLR-then-ULR chain has been demonstrated completing in under two seconds on low-latency interconnects.

III. Impact: From Single-Subscriber DoS to Batch Disruption

┌──────────────────────────────────────────────────────────────────┐
│              IMPACT OF DIAMETER CLR ATTACK                       │
│                                                                  │
│  ✗ Immediate subscriber data connectivity loss                  │
│  ✗ VoLTE call drop if a call is active at the moment of CLR     │
│  ✗ SMS delivery failure during the deregistration window        │
│  ✗ Re-attach delay: 10–30 seconds typical, longer under load    │
│  ✗ Attach-hijack potential when chained with a raced rogue ULR  │
│  ✗ Batch-automatable: a scripted CLR sweep can disconnect an    │
│    entire IMSI range in a single run                             │
└──────────────────────────────────────────────────────────────────┘

What makes CLR abuse distinct from volumetric signaling DoS is its precision. There's no need to flood a network element — a single well-formed message ends one subscriber's session, and the same message can be replayed against a list of targets with no infrastructure beyond a Diameter peer connection. That makes it attractive both for targeted harassment (silencing a specific number during a sensitive window) and as a fraud-enablement step, forcing a re-attach that a parallel rogue-ULR attack is positioned to capture.

Industry Testing: AdaptiveMobile and Positive Technologies (2017–2019)

Source: AdaptiveMobile Security — Diameter Signaling Threats in LTE Networks (2017); Positive Technologies (2019)

Operator-authorized Diameter security assessments found that CLR-based disconnection required nothing beyond a Diameter interconnect and a target IMSI (itself obtainable via the ULR technique covered in our Diameter research). Findings from that testing round:

Finding	Share of Operators Affected
CLR accepted without an Origin-Host whitelist check	54% (15 of 28 tested operators)
CLR automatable to affect 1,000+ IMSIs in under a minute	71% of the vulnerable operators
No SIEM alert generated for CLR from an unrecognized source	68% of the vulnerable operators

Root cause: several MME vendors shipped CLR Origin-Host validation as an optional, disabled-by-default feature. Many operators never enabled it during initial deployment, leaving the MME willing to accept a CLR from any Diameter peer capable of completing a session handshake — spoofed HSS identity included.

MITRE FiGHT Mapping

TTP ID	Name	Maps To
FGT5037	Forced Subscriber Deregistration	S6a CLR sent from a rogue/spoofed HSS identity

IV. Closing the Gap

Control 1 — Origin-Host Pinning. The MME must validate the Origin-Host of every inbound CLR against an explicit, operator-maintained list of legitimate HSS FQDNs. Any CLR whose Origin-Host doesn't match must be rejected with DIAMETER_UNKNOWN_PEER (5018) — not silently dropped, and never processed as a valid detach instruction. (GSMA FS.19 §5.5)

Control 2 — Diameter Firewall Inspection at the Edge. A Diameter Edge Agent (or equivalent signaling firewall) positioned between the roaming interconnect and the MME should independently enforce: block CLR (Command-Code 317) from any Origin-Realm outside the operator's bilateral roaming agreements; confirm CLR Origin-Host matches the registered HSS FQDN pattern before forwarding; rate-limit CLR volume per Origin-Host to catch bulk disconnection sweeps; and flag every Cancellation-Type = SUBSCRIPTION_WITHDRAWAL arriving from an external peer for review. (GSMA FS.19 §6.1–6.2)

Control 3 — Mutual TLS on the S6a Peer Session. Requiring certificate-based mutual TLS on the Diameter transport, with the certificate CN checked against the claimed Origin-Host, removes the ability to open a peer session under a spoofed HSS identity in the first place — closing the attack off before the CLR is ever evaluated.

DEA CLR Rule	Action	Reference
CLR from a non-registered Origin-Realm	DROP	FS.19 §6.1
CLR with an unrecognized Origin-Host	DROP	FS.19 §5.5
More than 10 CLR/minute from the same Origin-Host	ALERT	FS.19 §6.2
CLR with `Cancellation-Type = SUBSCRIPTION_WITHDRAWAL` from an external peer	LOG	FS.19 §5.5.1

Verification Checklist (Authorized Lab Assessment)

<CodeBlock language="bash" is-terminal code="# Test 1: CLR from an unrecognized Origin-Host

Expected: MME responds DIAMETER_UNKNOWN_PEER (5018); no subscriber detach

Test 2: CLR from a whitelisted HSS Origin-Host, valid IMSI

Expected: CLR accepted, subscriber detached, CLA returns DIAMETER_SUCCESS

Test 3: Bulk CLR from a single Origin-Host (>10/min)

Expected: rate-limit triggers; SIEM alert fires; subsequent CLRs dropped

Test 4: CLR peer session attempted with an invalid TLS certificate

Expected: TLS handshake fails; Diameter session never established"

V. Frequently Asked Questions

No — it's a targeted primitive, not a volumetric one. A single, well-formed CLR disconnects one subscriber; the technique becomes dangerous at scale because it can be scripted against an entire IMSI range without requiring any additional infrastructure. Compare this to broader Diameter denial-of-service patterns, which cover both this surgical form and higher-volume signaling floods.

Yes, if the operator logs Diameter peer sessions and CLR Origin-Host values. The gap documented by industry testing wasn't detection capability — it was that many MME/firewall deployments simply weren't configured to alert on CLR from an unrecognized source in the first place. Once Origin-Host pinning and rate-limiting are enabled, the same telemetry that blocks the attack also flags attempts.

Both require Diameter or SS7 interconnect reach, which is commercially obtainable through compromised MVNO credentials, rogue IPX positioning, or a misconfigured peering relationship. The CLR attack additionally needs the target's serving MME identity, which is itself often recoverable via the S6a ULR technique — meaning the two attack classes frequently chain together in practice, similar to how SS7 SendRoutingInfo feeds downstream tracking and interception attacks.

The specific CLR message is S6a-only and disappears with full 5G Standalone migration, where Nudm_UECM APIs and OAuth2-scoped tokens replace bilateral Diameter trust. However, most networks run hybrid 4G/5G cores for years, and the underlying pattern — a control-plane message with no source authentication being trusted implicitly — recurs in 5G SBA misconfigurations, as covered in our 5G core research.

Origin-Host pinning at the MME (Control 1 above) blocks the attack outright with no dependency on interconnect-wide firewall rollout, and is typically a configuration change rather than new infrastructure — which is why GSMA FS.19 treats it as the baseline requirement rather than an optional hardening step.

Conclusion & Next Steps

The Diameter S6a CLR attack is a reminder that not every signaling vulnerability is about data exposure — some are about who gets to write to network state, and under what identity. A message designed for legitimate HSS housekeeping becomes a remote kill-switch for any subscriber's session the moment Origin-Host validation is treated as optional. The fix is neither exotic nor expensive: pin the HSS identity, inspect at the Diameter edge, and require mutual TLS on the S6a peer session — yet industry testing found the majority of assessed deployments missing at least one of these controls.

TelcoSec's signaling security assessments include CLR-specific validation testing alongside the broader Diameter interconnect security and SS7 attack surface. Review the full Diameter protocol analysis for the complete S6a/S6d threat model, or explore our research library for related signaling intelligence.

Diameter S6a CLR Forced Subscriber Deregistration