OpenLI Tutorial 15: RADIUS IP Intercepts
You may either watch the tutorial lesson on YouTube by clicking on the image above, or you can download the slides and read them alongside the transcript provided below.
Hello again and welcome to the fifteenth chapter in the OpenLI training series. In this lesson, I’m going to show you how to configure an IP intercept that will derive the target’s IP address from intercepted RADIUS messages.
Most network operators should have at least a passing familiarity with RADIUS. RADIUS is a AAA protocol that is used for managing access and tracking usage in networks that have a large number of users, particularly for fixed-line or wireless ISP networks.
RADIUS is not the only option for serving this purpose, but it is one of the most commonly deployed. If you don’t use RADIUS in your network, then you can probably skip these next two lessons.
Specifically from a lawful interception perspective, the RADIUS protocol messages provide us with some key information. Firstly, we can see which IP addresses are being assigned to our intercept targets and we can also see when a user ends their session or changes their IP address. This allows us to have accurate and timely knowledge of which IP addresses we should be intercepting traffic for.
Secondly, any session state changes for an intercept target that are communicated using the RADIUS protocol will form the basis of our IRI messages for the corresponding intercept. So unlike a static IP intercept where we had little context to use for IRI generation, a RADIUS-based intercept can produce regular IRIs to satisfy the LEAs.
In OpenLI, RADIUS traffic is handled in much the same way that we handled SIP traffic for VoIP intercepts. Firstly, this means that all relevant RADIUS traffic must be mirrored into the collector -- note that this includes both the Authentication and Accounting messages. The collector also needs to be able to recognise RADIUS traffic, so you will need to pre-configure the RADIUS server and ports just as we did with the SIP server identity.
Also just like with SIP, OpenLI siphons off the RADIUS messages into a separate thread to be processed. This thread uses all RADIUS messages to maintain the IP session status for all observed users. This includes users who are not currently specified as intercept targets, as if they do become a target at a later point, we want to already know what IP addresses they may have so we can begin interception right away.
This thread also informs each of the collector’s capture threads which IP addresses are assigned to the current active intercept targets, and this will trigger all packets to or from those addresses to be intercepted.
Finally, any RADIUS message involving a target user will also be further processed to generate a corresponding IRI record.
How is a user’s identity expressed in the RADIUS protocol? In our experiences so far, we’ve come across two different methods, and there may be more that we don’t yet know about.
The first, and most common, way is to include a User-Name attribute in a RADIUS message, and this typically corresponds to the user’s unique identifier within the network. The User-Name attribute will appear during the initial access request.
An alternative approach that we have seen in some networks is to use the Calling-Station-Id attribute as a unique identifier to avoid having to send customer usernames and hashed passwords across the network. In these cases, the User-Name attribute will be hard-configured on the CPEs to have the same default value for all network users and won’t be suitable for target identification.
It is the responsibility of the operator to convert the target identity expressed on the warrant from the LEA into a suitable RADIUS identity. It is unlikely, for instance, that an LEA will issue a warrant with the customer’s Calling-Station-Id on it.
All RADIUS messages that are relevant to LI will include an Accounting Session ID attribute. The Session Id value is assigned when the user attempts to access the network and will remain consistent for as long as their RADIUS session is active. If a user’s RADIUS session ends for some reason, like if the user disconnects their home router, then a new Session Id will be used when they rejoin the network.
The session ID directly correlates to the Communication Identification Number that the ETSI standards require OpenLI to include in every intercept record. Therefore, OpenLI uses the Session Id attribute to derive the Communication Identification Number for any intercepted traffic. As long as the RADIUS Session Id value remains the same, we consider that the session is continuing and therefore encode a consistent CIN in the resulting ETSI records. If the Session ID changes, then the CIN will need to change accordingly.
Let’s now try to work through a practical exercise using the training lab. For the purposes of this exercise, we’re going to be using RADIUS messages where most attribute values (including usernames and passwords) have been encrypted -- this will mean we end up with some slightly awkward user identities, but this is necessary to protect the privacy of the users on the network that supplied the RADIUS traffic for this scenario.
Here is the key information for the exercise: we are operating a RADIUS server at the IP address 203.122.255.140. Our RADIUS server listens for client requests on two ports -- access on UDP port 1645 and accounting on UDP port 1646. In our RADIUS deployment, users login to our network by providing valid User-Name and Password attributes.
Now we have received an IP intercept warrant from our usual LEA where the target is one of our network users. We’ve looked up the user in our internal database and discovered that they are an ADSL customer with the username that you see on the slide (b4CPidYn7u8Vesbo). For the sake of brevity, I’ll refer to them as user b4 from now on.
The first step is to tell our collectors how to recognise RADIUS traffic. We do this by sending the IP address and port number for each RADIUS service to the provisioner using the REST API, in much the same way as we did for SIP servers before configuring a VoIP intercept. Normally, this would be something you would configure when you first deploy OpenLI, but this is a training exercise so we’re going to do it now.
The API request to add a RADIUS service is also very similar to what you used when you configured your SIP server earlier; this time, you post the server details to the “/radiusserver” URL.
The JSON objects for RADIUS servers look exactly like the SIP server objects, containing the “ipaddress” and “port” properties. The only difference this time is that our RADIUS server listens on two ports so we’ll need to make two separate API requests to ensure that OpenLI knows about both services.
Once again we can use curl to send the POST requests for the RADIUS server properties to the provisioner. I’ve just shown one curl command on the slide, but remember that you’ll need to also run a second command to add the service listening on port 1646.
If you’ve run those curl commands successfully, you should be able to see the following messages in the logs for the collector which indicate that the collector will now be treating traffic for those IP-port pairs as RADIUS traffic.
Should you decide you want to disable a RADIUS service in OpenLI, then the process is effectively the same as what I showed you for disabling a SIP server. You send a DELETE request to the URL “/radiusserver/IP-port”.
As in the SIP instance, you need to make sure you use a hyphen to separate the IP address and the port number of the RADIUS server you want to remove. Don’t forget to send a second DELETE request to remove the entry for the Accounting service, if required.
Now we can use the REST API to tell OpenLI to commence the interception for our target user. To do this, we use the exact same API URL that we used when we added our static IP intercept a couple of lessons back, “/ipintercept”. The only difference here is that our JSON object is going to contain a slightly different set of properties.
The general intercept properties that we’ve seen twice before now remain the same, although we need to specify a new LIID for this intercept, of course.
One new property that we introduce here is “user”, which we set to contain our target’s identity in RADIUS.
Remember that our target is an ADSL customer, so we need to set the accesstype property appropriately.
The last thing we need to do is tell OpenLI which RADIUS attributes to search to find the target’s identity. This is the role of the “radiusident” property.
If you set this property to have the value “user”, then OpenLI will only look at User-Name attributes to find your target identity. If you set it to “csid”, then OpenLI will examine the Calling-Station-Id property instead.
If you don’t include this property, then OpenLI will check both attributes for your target’s identity. Of course, this is going to have a slight performance impact so it’s always a good idea to be specific whenever you can.
In our case, we know that our user identities appear in the “User-Name” RADIUS attribute, so we can set the “radiusident” property in our JSON object to be “user”.
And with that, we have everything we need to request OpenLI to add our RADIUS intercept to the provisioner. The slide again shows you how you would use curl to send this request.
Once you send the request, you should be able to see evidence of the intercept being pushed to the collector in the collector logs.
The message will include the target identity, LIID and the start and end times for the specified intercept.
The mediator logs should also have an entry showing that it is aware of the intercept and knows which agency it should forward any related intercept records onto.
Just like any other type of intercept, the OpenLI REST API supports the use of PUT, DELETE and GET requests to modify, remove and fetch RADIUS IP intercepts.
The syntax and application of these methods is exactly the same as for the previous intercept types so I’m not going to reiterate that here. If you’ve forgotten the syntax, then jump back to lesson 13 for a refresher.
One last thing before we continue on -- because there is an addressing overlap between the traffic for the static IP and RADIUS IP intercept exercises, I’m going to suggest that you disable the static IP intercept that we performed in the previous lesson. This will make it easier for you to verify the output of the RADIUS IP intercept later.
The curl command that I had to run on my lab environment is shown on the slide -- obviously, you may need to adjust the URL to account for any differences in your particular setup.
Our RADIUS intercept is all configured and ready to go, so now all that remains is to inject some matching traffic into our collector and see the result.
This will be the focus of our next lesson, where we will also take a deep dive into the IRI records in particular and see how RADIUS state changes can be observed in the resulting IRIs.
Goodbye for now.