OpenLI Tutorial 14: Running a Static 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.
Welcome back -- it is time for us to begin the fourteenth chapter of the OpenLI training series. This time around we’re going to complete the exercise that we began in the previous lesson, where we configured an IP intercept for a user who has been assigned a static IP address.
The bulk of this lesson will be looking at the intercept records produced by this intercept, and learning more about the key information that is contained within those records.
Now that we’ve created a static IP intercept for the address 10.1.18.217, our OpenLI collector will now directly intercept all traffic to and from that IP address.
So now all we need to do is actually make some traffic for that address appear on our collector’s capture interface.
On your collector container, I’ve placed a pcap trace file for exactly this purpose called “staticip.pcap”. The traffic in this pcap was captured from a host that had the 10.1.18.217 address assigned to it, so it should be intercepted by OpenLI.
Once again, you can use tracereplay to replay the packets from the pcap file onto the capture network just as we did earlier with the trace for the VoIP call.
Once the tracereplay has completed, you’ll be able to inspect the tracepktdump output for HI3 on your openli-agency container.
In this lesson, we’re going to just focus on the most recent displayed packet on your terminal output, but feel free to scroll further back later on and check out any earlier packets as well.
Here we have the PS Header section of the last intercepted record on HI3 for our static IP intercept. This structure and its fields should look very familiar to you, as it is the same header format that we saw for the VoIP intercept.
I just want to point out a couple of differences here, though they should be fairly obvious.
The first is that the lawful interception identifier contains the LIID that we assigned to our static IP intercept this time around, which is what you would expect.
The other change is the communication Identity number, which is now set to 101 -- which matches the session ID that we specified for our static IP in our intercept configuration.
So here you can see the direct impact of choosing a session ID when you add a static IP range to an intercept.
OK, let’s move on now to the CC payload portion of the HI3 record.
There’s even less information here than there was in the corresponding portion of the VoIP CC -- the only field that is relevant is the payload direction, which again indicates whether the target was the sender or the receiver of this packet.
Finally, let’s take a quick look at the captured IP payload itself.
The last captured packet is a TCP ACK with no payload, and tracepktdump is able to decode the TCP/IP headers for us to interpret.
The most important thing to note here is that the static IP for our target is the destination IP address of this packet.
This means two things: 1) OpenLI was correct to intercept this packet and 2) the payload direction is correct, because the target IP is the destination address.
If you scroll back up through the other intercepted CCs, you should see that 10.1.18.217 appears as either the source or destination IP address in all of them. If you are feeling particularly keen, you could also confirm that the direction is set to toTarget whenever the target IP is the destination address and the direction is fromTarget whenever the target IP is the source address.
Let’s now move on to the IRIs that have appeared on HI2.
With a static IP intercept, you don’t actually get many IRIs being transmitted over HI2 because there are few changes to the target’s IP session state that we can report back to the agency.
The session itself never ends and there are no periodic updates or keep alives that can be intercepted and used to generate a valid IRI.
However, the ETSI standards do specify IRIs that should be produced whenever an intercept is started or halted for a target with an IP session already active, and OpenLI will emit these IRIs as needed.
You should see one such message on your HI2 output after you configured the static IP intercept, so I’ll explain that a bit now.
However, I am going to skip over the PS Header portion of the IRI, as that is no different from what we’ve seen already, and go straight to the IRI payload.
There’s a fair bit of useful information in the IRI payload, which I will now highlight for you.
I’ll begin with the IRI type and the access event type. Together, these two fields can tell you the current status of the target’s IP session at the time this IRI was generated.
“IRI Begin” is used to mark the point where the interception of IP traffic for an intercept target has begun.
The access event type then tells us what caused the interception to begin for that particular IP session. In this case, there was already a static IP session established for our target user when the intercept was configured, which corresponds to an event type of “start of interception with session active”. We’ll see other access event types in future lessons, but this is the only viable event type for the start of a static IP interception.
The username that we specified when we added the intercept is included in the IRI here, so there is always some form of identity attached to the IRI payload.
Similarly, the access type that we specified earlier for this intercept is also encoded into the IRI.
Below that, we see that the IRI also includes the static IP address we specified for the target.
As well as an indication that the address was assigned statically.
And the subnet mask for the allocated address -- if we had specified an address range, then this subnet mask would be adjusted accordingly.
If you were then to go ahead and withdraw the static IP intercept using the DELETE REST API method, you would then see another IRI appear on HI2.
The IRI would be very similar, except the IRI type would change to IRI-End to indicate that interception has ended. The access event type would be set to “end of interception with session active” to show that the IP session was still active when the intercept was concluded.
And that brings us to the end of another lesson.
Now that you are familiar with IP intercepts for static address assignment, our next chapter will introduce you to interception for targets with dynamically assigned IP addresses, using RADIUS as an example.
Take care and bye for now.