Customer reported that the RADIUS initiated lawful intercept(LI, also known as secure subscriber policy) did not work. There has no mirrored traffic being seen on the Mediation device. They have followed the configuration example described in KB24745 [juniper.net].
RADIUS initiated lawful intercept(LI, also known as secure subscriber policy) did not work for customer.
Solution
Following KB24745 [juniper.net], customer has the correct [radius-flow-tap] configuration and the correct routing to the Mediation device.
services {
radius-flow-tap {
traceoptions {
file dfcd size 40m files 5;
}
source-ipv4-address 192.168.1.1;
routing-instance vrf-li;
RADIUS AVPs returned via Access-Accept message are:
Unisphere-LI-Action = 1
Unisphere-Med-Dev-Handle = 0x41111111
Unisphere-Med-Ip-Address = 203.134.14.242
Unisphere-Med-Port-Number = 7933
The RADIUS server customer used is called radiator(version: radiator-4.26-1.el7.noarch).
In the PFE shell, “show vbf service” and “show jnh if subscriber_interface_index detail” indicate that the LI policy is not attached to the subscriber interface.
The next step is to inspect the RADIUS access-accept packet.
The latest version of Wireshark(for example, Wireshark 4.4.1 for MAC) can decrypt the salt encrypted string by using the correct RADIUS shared-secret(Protocol Preferences -> RADIUS Protocol -> Shared Secret).
Look into the [26-59]Med-Dev-Handle AVP, it indicates the problem might be with the Med-Dev-Handle AVP.
RADIUS Protocol
Code: Access-Accept (2)
Packet identifier: 0xd3 (211)
Length: 858
Authenticator: xxxxxxxxxxxx
Attribute Value Pairs
<...>
AVP: t=Vendor-Specific(26) l=26 vnd=Juniper Networks/Unisphere(4874)
Type: 26
Length: 26
Vendor ID: Juniper Networks/Unisphere (4874)
VSA: t=Unisphere-Med-Dev-Handle(59) l=20 val=Decrypted: 30783431313131313131 <<<<<<<<<< Noted, the decrypted code is 0x4111111
Type: 59
Length: 20
Unisphere-Med-Dev-Handle: 30783431313131313131
Comparing with a known good AVP captured in lab, which displays the decrypted string as the correct 41111111.
Packet identifier: 0xa3 (163)
Authenticator: xxxxxxxxxxxxxxx
VSA: t=Unisphere-Med-Dev-Handle(59) l=20 val=Decrypted: 41111111
Unisphere-Med-Dev-Handle: 41111111
After removing the hex indicator 0x in Med-Dev-Handle, the LI finally works.
Unisphere-Med-Dev-Handle = 41111111
References
As an additional information, freeRADIUS 3.0.19 and onwards also fixed a bug with Juniper LI AVP when using CoA method. Please refer to this link for details.
https://lists.freeradius.org/pipermail/freeradius-users/2019-September/096395.html
With regard to how to enable subscriber LI via CoA, please refer KB85021 [juniper.net]:
https://kb.juniper.net/KB85021 [juniper.net]
With regard to the Med-Dev-Handle, please refer to below Juniper document:
https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-services/topics/concept/subscriber-management-subscriber-secure-policy-dtcp-header.html