Appearance
Legacy Protocols (Diameter / RADIUS / SIP)
The telecom sensor monitors legacy signaling protocols - Diameter, RADIUS, SIP, and M3UA - using AF_PACKET capture and eBPF process instrumentation to surface process ownership, peer anomalies, and protocol-level indicators.
Requires: Telecom sensor flavor.
How the sensor captures legacy protocol traffic
All legacy protocol capture uses the same AF_PACKET path as GTP-U and PFCP. The sensor reads from the configured monitoring interface. Auto-detection checks telecom socket bindings first, then falls back through default route, first physical interface, and eth0. The monitoring interface can be set explicitly in Console Settings when the auto-detection selects the wrong interface.
Heartbeat fields relevant to legacy protocols:
| Field | Type | Contents |
|---|---|---|
diameter_inventory | Optional | Diameter peer state |
sip_report | Optional | SIP session metrics |
m3ua_report | Optional | M3UA/SS7 transport state |
ikev2_report | Optional | IKEv2 tunnel inventory |
Diameter
Standards: RFC 6733, 3GPP TS 29.230
Transport: TCP or SCTP port 3868 (plaintext), TLS on SCTP port 5658
Sensor module: telecom/protocol/diameter.rs
Roles classified from this port: DiameterNode, CHF, HSS, PCRF
Diameter is the AAA and accounting protocol used in 4G EPC and in 5G Core functions that retain a Diameter interface (CHF for charging, HSS for subscriber data in interworking scenarios, PCRF for policy).
Commands monitored
| Command | Abbreviation | Purpose |
|---|---|---|
| Capabilities-Exchange-Request/Answer | CER/CEA | Peer discovery; Realm and Host identity exchange |
| Authentication-Request | Auth-Request | AAA authentication toward AUSF or HSS |
| Accounting-Request/Answer | ACR/ACA | Charging data delivery to CHF |
Anomalies detected
| Anomaly | Meaning |
|---|---|
| CER failure | Diameter peer cannot establish capabilities; connectivity or configuration issue |
| Auth success rate drop | Credential database issue or potential credential poisoning |
| Accounting data loss | ACR not matched by ACA; potential billing evasion attempt |
Role classification
A process binding to port 3868 or 5658 receives a DiameterNode classification by default. If the process name or path also matches a known CHF, HSS, or PCRF pattern, the more specific role takes precedence. Confidence scoring applies: a process with only port binding evidence receives a medium confidence score; additional name or path evidence raises it to high.
TLS coverage
Port 5658 (Diameter over TLS) is tracked by the TLS inventory module. If the sensor can hook the TLS library used by the Diameter process, the coverage classification becomes OpenSslTls (payload visible). If the port is active but no library hook fires, coverage is OpaqueTls (connection visible, payload not accessible).
RADIUS
Standards: RFC 2865 (authentication), RFC 2866 (accounting)
Transport: UDP port 1812 (authentication), UDP port 1813 (accounting)
Sensor module: telecom/protocol/radius.rs
Roles classified from these ports: RadiusServer, AUSF, UDM
RADIUS is used for authentication and accounting in 4G deployments, enterprise Wi-Fi calling, and in 5G interworking scenarios where AUSF or UDM present a RADIUS interface to external AAA servers.
Packets monitored
| Packet type | Direction | Purpose |
|---|---|---|
| Access-Request | Client to server | Authentication request |
| Access-Accept | Server to client | Authentication success |
| Accounting-Request | Client to server | Session accounting data |
| Accounting-Response | Server to client | Acknowledgment |
Anomalies detected
| Anomaly | Meaning |
|---|---|
| Access-Reject rate spike | Burst of authentication failures; brute-force attempt or account lockout storm |
| Accounting data loss | Accounting-Request without corresponding Accounting-Response; billing evasion attempt |
| Shared secret errors | Authentication message authentication code mismatch; tampering or misconfiguration |
Process attribution
UDP listener ownership is reported from the heartbeat snapshot. In the Console, go to Sensors > [sensor] > Network > UDP Listeners. This shows which binary owns ports 1812 and 1813.
A RADIUS server should show a stable, unchanging owner process on these ports. Any change in the binary owning the RADIUS listener, or a new process opening these ports outside the learned baseline, fires a network_listen event at warning severity.
SIP (Session Initiation Protocol)
Standard: RFC 3261
Transport: UDP or TCP port 5060 (plaintext), TLS port 5061
Sensor module: telecom/protocol/sip.rs
Role classified from this port: ImsNode
SIP is the session setup protocol for IMS (IP Multimedia Subsystem) environments. SIP nodes handle call setup, registration, and presence for voice and multimedia services.
Methods monitored
| Method | Purpose |
|---|---|
| INVITE | Session setup |
| ACK | INVITE confirmation |
| BYE | Session teardown |
| CANCEL | Cancel pending INVITE |
| REGISTER | UE registration with registrar |
| OPTIONS | Capability discovery |
Anomalies detected
| Anomaly | Meaning |
|---|---|
| Invitation rejection rate increase | Call setup failures; proxy misconfiguration or media path issue |
| Concurrent session count anomaly | Session count spikes outside baseline; resource exhaustion or INVITE flood |
SIP and the ImsNode role
Any process binding to port 5060 or 5061 receives the ImsNode classification. IMS environments typically run multiple SIP functions on the same node (P-CSCF, S-CSCF, I-CSCF). The sensor does not distinguish between CSCF types; all are classified as ImsNode. If the IMS stack runs as separate processes, each process is classified independently based on its socket bindings.
TLS coverage for SIP-TLS
Port 5061 (SIP-TLS) is tracked by the TLS inventory. SIPS traffic over TLS with an OpenSSL or GnuTLS library link is covered by the uprobe mechanism. Coverage classification follows the same rules as SBI and Diameter: OpenSslTls when the library hook fires, OpaqueTls when the port is active but no hook.
M3UA (MTP3 User Adaptation)
Standard: RFC 4666
Transport: SCTP port 2905
Heartbeat field: m3ua_report
Role classified from this port: SigtranGateway
M3UA is the SIGTRAN transport adaptation layer that carries SS7 MTP3 messages over SCTP/IP. It is used in SIGTRAN gateways that bridge legacy SS7 signaling networks to IP-based core infrastructure.
The sensor classifies any process binding to SCTP port 2905 as SigtranGateway and reports M3UA association state in the m3ua_report heartbeat field. Detailed M3UA message decoding (ISUP, MAP, TCAP) is not confirmed in the source code. The sensor provides process attribution, SCTP association health for the M3UA transport, and runtime behavioral monitoring of the gateway process.
For M3UA nodes, the primary security value comes from:
- Verifying that the correct binary owns port 2905
- Monitoring for unexpected new SCTP associations from unrecognized peers
- Detecting privilege escalation or binary integrity changes on the gateway process
TelecomProcess: generic binary classification
When the sensor detects a process whose name, path, or port bindings indicate telecom-related behavior but does not match a specific NF role, it assigns the TelecomProcess classification. This fallback role applies to:
- Processes with binary names or paths suggesting telecom vendor software but without a specific port match
- Processes on nodes where a primary NF role is already assigned and additional processes show telecom-adjacent behavior
TelecomProcess nodes receive the same behavioral baseline, integrity monitoring, and anomaly scoring as named roles. They do not receive role-specific KPI tracking or SLO monitoring. Upgrading a TelecomProcess to a specific role requires either an explicit role declaration set in the Console enrollment wizard or stronger port binding evidence.
Console views for legacy protocols
Protocol analytics
In the Console, go to Telco > Protocol Analytics. The page shows a cross-protocol analytics view that includes Diameter, RADIUS, and SIP alongside 5G signaling protocols, covering peer counts, anomaly counts, and session state per protocol family.
Telecom security events
In the Console, go to Telco > Security. The list shows security findings across all telecom NF roles, including ImsNode, DiameterNode, RadiusServer, and SigtranGateway. Use the NF role filter to scope results to a specific role such as DiameterNode.
Filtering runtime events by legacy role
In the Console, go to Activity > Runtime Events. Use the NF Role filter to select the desired legacy role (for example, RadiusServer or ImsNode) and the time range selector to set the window. This shows process, network, and file events for nodes carrying that role classification.
NF inventory
In the Console, go to Telco > NF Inventory. Use the role filter to select a legacy role such as DiameterNode. The filtered list shows sensor assignment, confidence score, detection evidence, and current anomaly risk for each classified node.
SLO targets for legacy roles
Legacy roles do not carry the same explicit 3GPP TS 22.261 SLO targets as 5G Core functions. The sensor applies a default 99.0% (2-nines) availability baseline for all roles not covered by the 5G Core or RAN SLO tiers.
| Role | SLO tier applied |
|---|---|
| HSS, PCRF | 2-nines (99.0%) default |
| ImsNode | 2-nines (99.0%) default |
| DiameterNode | 2-nines (99.0%) default |
| RadiusServer | 2-nines (99.0%) default |
| SigtranGateway | 2-nines (99.0%) default |
| TelecomProcess | 2-nines (99.0%) default |
Operational guidance
Diameter TLS: Production Diameter deployments should use TLS on port 5658 rather than plaintext on 3868. If the sensor reports Diameter connections in Plaintext TLS coverage mode, this is a security finding worth resolving. The sensor does not generate a compliance alert for plaintext Diameter by default (only for plaintext SBI), but the tls_inventory field will reflect the coverage gap.
RADIUS shared secrets: RADIUS authentication integrity depends entirely on the shared secret. The sensor detects shared secret errors (HMAC mismatches in Access-Request processing) as a specific anomaly. A cluster of these errors on a production RADIUS server is a high-priority finding and warrants immediate investigation.
IMS INVITE floods: The concurrent session count anomaly on SIP nodes fires when the number of simultaneous INVITE transactions exceeds the baseline. During a call setup storm (e.g., mass re-registration after an IMS core restart), this may fire legitimately. Use a time-bounded suppression rule on ImsNode sensors during planned maintenance windows that involve IMS core restarts.
M3UA and SS7 exposure: SIGTRAN gateways that bridge to legacy SS7 networks are a well-documented attack surface (SS7 vulnerabilities). While the sensor does not decode SS7 messages (MAP, ISUP, TCAP), it monitors the SCTP transport and the process owning the M3UA gateway. Unexpected new SCTP associations from unknown peers on port 2905 should be treated as high-priority events on any production gateway.
Further reading
- Telecom Overview
- RAN Signaling (NGAP / F1AP / E2AP)
- TLS Uprobe Coverage
- SLO and Resource Monitoring
- Network View
- RFC 6733 - Diameter Base Protocol
- RFC 2865 - Remote Authentication Dial In User Service (RADIUS)
- RFC 3261 - SIP: Session Initiation Protocol
- RFC 4666 - Signaling System No. 7 (SS7) Message Transfer Part 3 User Adaptation Layer (M3UA)