Telecom Protocols
The telecom sensor connects decoded signaling and media metadata with the process, host, container, and workload that handled the traffic. Protocol evidence appears in the relevant Telco workspace and can be opened in Live Feed or Investigate when an event record is available.
Requires: Telecom sensor flavor.
Supported evidence
| Area | Protocols | Evidence available |
|---|---|---|
| 5G and 4G RAN | NGAP, F1AP, E1AP, XnAP, S1AP, NRPPa, NAS 5G (NAS/NGAP), NAS EPS, SCTP | Message class, procedure, criticality, selected security or session metadata, association context, outcome, and decode status |
| Core control and user plane | PFCP, GTP-U, GTPv2-C, GTPv1-C, GTP Prime | Session, tunnel, control, PDP-context, charging-transfer, endpoint, lifecycle, and anomaly metadata; subscriber payload is not retained |
| 5G service-based interfaces | 5G SBI over HTTP/2 | NF role, service, method, path, response, latency, trace, and supported TLS plaintext evidence |
| O-RAN control and service models | E2AP, E2SM-RC, E2SM-KPM, E2SM-CCC | RIC procedure, request, function, action, supported container format, outcome, and decode status |
| Core and subscriber services | Diameter, RADIUS, SIP, IKEv2 | Peer, command, session, outcome, and anomaly metadata where observed |
| SIGTRAN and SS7 | SCTP, M3UA, SCCP, TCAP, MAP, CAP | Association state, routing context, message type, transaction, application context, and supported operation metadata |
| Media and gateway control | RTP, RTCP, H.248, MGCP | Stream or transaction metadata, endpoints, identifiers, state, and decode status; media payload is not displayed |
| Interworking and location | SGsAP, LCS-AP | Procedure, association, endpoint, and decode-status evidence |
| O-RAN fronthaul and management | eCPRI, O1, O2, NETCONF | Message or operation metadata and current management state where observed |
Some protocols produce individual event records, while others also provide summarized interface or session state. Live Feed and Investigate show recorded events. Open Telco > Network or Telco > Sessions for current reports. A summary count does not imply that a separate event is retained for every message.
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.
The Console reports the following protocol evidence when available:
| 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
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)
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
To review listener ownership, open Monitor > Runtime Explorer, select the Sensor, and choose Listening. This shows which executable 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
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
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 processes that bind SCTP port 2905 as SIGTRAN gateway candidates and reports M3UA association state. For supported transfer messages, Telovix also extracts bounded SCCP, TCAP, MAP, and CAP metadata. ISUP message decoding is not currently included.
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 > Sessions > Protocols. The page shows cross-protocol analytics for legacy signaling, SS7, media, interworking, and gateway-control protocols, including observed peers, sessions, message state, and anomalies.
Telecom security events
In the Console, go to Telco > Threats. 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 Monitor > Investigate and choose a protocol under Telecom Searches. The selected protocol opens a historical event search. Narrow results by sensor, network function role, process, or time range. Use Telco > Network and Telco > Sessions for current interface and session reports.
NF inventory
In the Console, go to Telco > Network > Network Functions. Use the role filter to select a legacy role such as DiameterNode. The filtered list shows Sensor assignment, confidence, 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 high-value attack surface. Review decoded SCCP, TCAP, MAP, and CAP metadata together with the SCTP peer and process that owns the M3UA gateway. ISUP remains transport-level evidence. Unexpected SCTP associations from unknown peers on port 2905 should be investigated promptly.
Further reading
- Telecom Overview
- RAN Signaling
- 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)