RADIUS Lawful Interception
RBFS supports control of Lawful Interception (LI) through RADIUS, using either the Access-Accept or Change of Authorization (CoA) messages. To initiate or manage an LI session via RADIUS, all required LI attributes must be included in the RADIUS Access-Accept or CoA request.
These attributes are salt-encrypted using the algorithm defined in RFC 2868, originally specified for the Tunnel-Password attribute. As this encryption method is defined only for Access-Accept messages, RBFS uses a modified approach for CoA compatibility: the RADIUS Request Authenticator field is replaced with 16 zero bytes. This approach is widely adopted and compatible with multiple RADIUS server implementations.
| RFC and draft compliance for RADIUS-based LI is partial unless explicitly stated otherwise. |
VSA 26-50058-140 - RtBrick-LI-Action (salt encrypted integer)
| Value | Code | Description |
|---|---|---|
NOOP |
0 |
No action / Ignore LI request |
ON |
1 |
Start LI / Add LI request |
OFF |
2 |
Stop LI / Delete LI request |
VSA 26-50058-141 - RtBrick-LI-Identifier (salt encrypted integer) Device unique lawful interception identifier (LIID) within the range from 1 to 4194303.
VSA 26-50058-142 - RtBrick-LI-Direction (salt encrypted integer)
| Value | Code | Description |
|---|---|---|
INGRESS |
1 |
Ingress mirroring only (from subscriber) |
EGRESS |
2 |
Egress mirroring only (to subscriber) |
BOTH |
3 |
Bidirectional mirroring (from and to the subscriber) |
VSA 26-50058-143 - RtBrick-LI-MED-Instance (salt encrypted string) The routing instance through which the mediation device is reachable.
VSA 26-50058-144 - RtBrick-LI-MED-IP (salt encrypted IPv4 address) IPv4 address of the mediation device.
VSA 26-50058-145 - RtBrick-LI-MED-Port (salt encrypted integer) UDP port between 49152 and 65535 set in the mirrored traffic
To prevent exposure of LI activity based on the presence of specific attributes, RBFS supports the special LI action NOOP. This action can be used to insert fake or decoy LI requests that have no operational effect but obfuscate detection attempts based on attribute presence alone.
For additional confidentiality, failed LI activations triggered via RADIUS do not return an error or NAK in the RADIUS response. This prevents external systems from distinguishing between valid and NOOP-based requests based on response behavior.
LI requests received via RADIUS, whether real or NOOP, are handled uniformly and appear in the same internal BDS table as requests provisioned through the X1 interface or the HTTP (REST) API.