OpenLI Tutorial 16: Running a RADIUS IP Intercept
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.
Hi everyone and welcome to the sixteenth chapter of the OpenLI training series. In this lesson, we are going to perform the RADIUS IP intercept that we configured in the previous chapter and spend a bit of time learning how to interpret the IRIs and CCs that are produced by OpenLI for that intercept.
Just to quickly remind ourselves, you should now have a RADIUS IP intercept configured in your instance of the OpenLI training lab, aimed at the target user ‘b4’.
Now that we’ve added the configuration, our OpenLI collector will be monitoring any captured RADIUS traffic for information about sessions belonging to our target user. In particular, the collector will make note of any IP addresses assigned to the user by RADIUS and intercept any traffic for those addresses. Each RADIUS message involving the target will also be used to generate IRI records for the ongoing intercept.
Once again, the collector instance in the training lab comes with a pcap file which you can use for the purposes of this exercise. This trace will allow you to replay some anonymised RADIUS messages and IP traffic that belong to our target user onto the capture interface.
This time around, I’d recommend using the -X flag when running tracereplay to speed up the replay a bit. The original real-world RADIUS session that we derived the pcap from does span a number of minutes so it can be a bit tedious to replay the packets with their original timing.
Hopefully, you still have some tracepktdump instances running on the agency container for each of the mediator handovers! If not, start them back up before running tracereplay -- you’ll need one tracepktdump running for each handover.
Once you’ve replayed the pcap, you should hopefully see some new output on the tracepktdump instances for both the HI2 and HI3 handovers on the agency container.
We’re going to look at this output in more detail now, starting with the HI2 output.
I’d like to begin by looking at the FIRST IRI record that was printed after you started the replay of the pcap. If there is an HI1-Operation record with an LIID of “RADIUS003” in your output, you want to be looking at the IRI immediately after that.
This is what the PS Header portion of the first IRI record for RADIUS003 should look like. Your timestamp will obviously be different, but all of the other header fields should match what you see on this slide.
Most notably, you’ll see that the lawful Interception Identifier matches the LIID that you provided for this intercept at configuration time.
Here we see that our IRI has been assigned a Communication Identity Number of 383980. This was derived from the Accounting Session Id in the RADIUS message that triggered this IRI.
This number is going to appear as the CIN for all IRIs and CCs relating to this particular RADIUS session.
But overall, there isn’t anything particularly noteworthy in the PS Header that we haven’t seen already in the previous intercept exercises.
However, now we’re going to move onto the IRI payload and this is where the extra session detail that we get from RADIUS becomes more apparent.
Here’s the IRI payload that we’re going to be discussing -- hopefully this matches what you are seeing on your HI2 tracepktdump instance.
The first thing I want to point out is the new IRI type of IRI-Report. This IRI type is used when no IP session for the user actually exists, but an IRI still should be generated. In this case, the IRI was generated because the user is attempting to connect to the network, but has not yet been authorized.
And we can confirm that by looking at the accessEventType, which has been set to “accessAttempt”. Generally speaking, each RADIUS message type can be mapped to a particular ETSI access event type so you can usually follow the underlying RADIUS flow from the IRI messages.
Immediately below that, we can see that our target username has managed to be correctly included in the IRI record.
And the access type that we specified in our intercept config has also been translated into a suitable ETSI compliant type as well. ETSI uses the term “xDSL” to cover various types of digital subscriber line technologies, such as ADSL and VDSL.
Information about the network access server that is running the session will be placed in these POP attributes. Because the contents of our RADIUS messages for this exercise have been encrypted, these values are somewhat garbled but when you deploy OpenLI on your own network, you should be able to see some more familiar looking information in these fields.
Now let’s carry on to the next IRI record printed by your HI2 tracepktdump instance. This IRI should have the value of 1 as the sequence number in the PS Header.
Now scan ahead to the IRI payload portion of this record -- there’s nothing particularly new or interesting in the PS header this time around.
This time, we see that the IRI type is set to IRI-Begin -- this tells us that the user has now established an IP session.
Specifically, their access attempt that we saw in the previous IRI has now been responded to by the NAS with an access accept RADIUS message.
And even more importantly, our target user has now been assigned an IP address: 80.180.114.112. We can expect to see any following traffic to or from this address to be intercepted and delivered on HI3.
Lastly, the exact time that the session was accepted is also included in the IRI. The format of the timestamp is 2 year digits, followed by 2 month digits, 2 day digits, 2 hour digits, and so on. Your value will be different to what is shown on this slide, and the time is based on the UTC timezone, but hopefully you should be able to interpret it as a time that makes sense relative to the time when you replayed the RADIUS pcap.
Continue scrolling down through the IRI records.
Next should be an IRI with a sequence number of 2. You’ll see that it is a Continue IRI, which occurs when a session for the target exists and the message that triggered this IRI is not going to end that session. The access event type itself is an interimUpdate, which indicates that the IRI was triggered by the observation of a RADIUS Accounting request. In this case, this will likely be the Accounting Start message for this session.
The remainder of the IRI payload for this record contains a union of the fields that we saw in the previous two IRIs, such as the assigned IP address, NAS information and the session start time. This means that you don’t have to see the initial IRIs to get access to that information.
Looking at IRI number 3, we see that it is another interim update like the one before. But if you look closely between the startTime and POP identifier fields, you’ll notice that there are two new fields present: octetsReceived and octetsTransmitted.
These values are derived directly from the usage values that can be found in the RADIUS requests that are periodically sent by the client to the RADIUS server for accounting purposes. Effectively, every interim update that occurs in the RADIUS for a target’s session will produce a corresponding IRI with the target’s usage numbers in it.
Keep scrolling down to the IRI with the sequence number of 4.
This time you’ll see that we have an IRI End record, as this is the point where the RADIUS session has concluded. This will be due to the OpenLI collector observing an Accounting Stop record for the target’s RADIUS session, and is reinforced by the Access Event Type being set to Access End.
If you look closely at the IRI payload for this record, you’ll see that we’ve introduced two new fields.
One is the end time for the session, the meaning of which should be fairly obvious.
The second field is the endReason, which is derived from the Terminate Cause attribute in the RADIUS message (if present). In the pcap used for this exercise, the value of the Terminate Cause attribute has been encrypted which is why the end Reason is undefined here. Usually this would be because the target logged off or the connection was lost or timed out.
If you continue to scroll after that, you’ll see the RADIUS session re-establish itself shortly afterwards.
You’ll notice that the IRIs for the new session have a different CIN, which is expected because this is a separate session.
The session itself lasts longer than the first, so there are multiple interim updates containing octet counters.
You’ll also probably notice that there is no IRI end for the second session. This is because the pcap capture that contained this session was halted before the session itself ended.
Ok, now let’s turn our attention to the records that were sent on the HI3 handover.
There isn’t anything too much for me to say about the PS Header and CC payload sections of the CC records -- these are much the same as they were when we did the static IP intercept.
What you can see if you look carefully as you scroll through the CCs, is the impact of the session re-establishment that we saw in the IRI records. The CIN should change to match the CIN that was assigned to each RADIUS session, and you’ll also see the sequence numbering reset back to zero when the CIN changes over.
Within the intercepted payload itself, there are a couple of things that I want to highlight for you. The first is that we can confirm that each intercepted packet is either sent by, or sent to, the IP address that had been assigned to the target. So we know that the collector is doing a good job of limiting interception to just the intended target.
The other thing to notice is that our collector is also able to infer direction correctly. Any intercepted packets that have the target’s assigned IP as their destination address will have their payload Direction set to “totarget”. When the assigned IP is the source address, the payload Direction changes to “fromtarget”.
And that is all for this lesson. Hopefully you now have a better feel for how OpenLI is able to interact with session management protocols like RADIUS to generate an informative and comprehensive set of intercept records for a target user.
Next time, we’re going to look at how you can combine OpenLI with certain vendor-specific traffic mirroring capabilities, like Juniper Jmirror, to perform IP intercepts.
I’ll see you again then.