OpenLI Tutorial 13: Static 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 -- we are now going to begin the thirteenth chapter in the OpenLI training series. In this lesson, I’m going to introduce you to IP intercepts and show you how to configure an intercept for a target with a static IP address.
Over the past couple of lessons, we’ve learned about VoIP intercepts, which are used to surveil a target’s voice communications only.
However, there are many other methods by which one can communicate with others over the Internet. Posting on message boards, email and instant messaging applications are all obvious examples. Even the websites that a person visits may be relevant -- for instance, if they are viewing radical content or instructions for creating explosives.
Therefore it may be necessary for a law enforcement agency to collect all Internet-based communications for a person of interest, so that they can build a complete picture of what the person has been doing.
This would include any VoIP calls as well, by definition, so a separate VoIP intercept is often not required.
In this case, the agency would request what we call an “IP intercept”, whereby all IP-based communications for an intercept target must be collected and forwarded to the requesting agency.
The key information that is required to perform an IP intercept is the IP address (or addresses) that have been assigned by the network to the target. We can then intercept any and all traffic that is sent to or from that address, which will complete the requirements of an IP intercept.
But it is not always a straightforward task to determine which IP address is being used by a particular person at any given time.
The most obvious issue is that, in many production networks, IP addresses are assigned to customers dynamically. To complicate matters further, a customer’s address may also change dynamically even as they are using the network -- for instance, a mobile user may physically change location and move to a different access point, resulting in them potentially being assigned a different address. If an intercept target changes IP address, then the interception system needs to be able to detect this and modify its behavior accordingly.
There are also multiple mechanisms which network operators can use to assign IP addresses to their users, and each is suited for different network types and configurations. RADIUS, for instance, is common in fixed line networks where the subscriber set is clearly defined, whereas GTP is typically found in mobile networks. If an interception system does not understand the protocol that your network uses to assign IP addresses, then it will struggle to perform IP intercepts.
Another easily forgotten issue is that a target may be assigned, and even make use of, both an IPv4 and IPv6 address by the network. An interception system will need to account for multiple address assignments and be capable of capturing and recognising IPv6 traffic.
Finally, we also recognise that there may be multiple users that end up sharing a public IPv4 address through the use of CGNAT or some similar technology. Solving this problem is a bit beyond the scope of this tutorial, but I just wanted to include the concept here to emphasize how complex IP-based identity can be.
So the important thing to take away here is that OpenLI must (and does) support multiple methods to express identity for IP intercepts and different methods can require slightly different configuration options for interception to proceed.
In this lesson, we’re going to start with configuring an IP intercept using arguably the simplest approach for IP address assignment: static IPs. We’ll cover some other methods in future chapters.
I’m sure you are all familiar with static IP addressing -- in this scenario, network users are assigned a fixed IP address (or range of addresses) and that address never changes. The address may be configured explicitly on the customer’s edge device, or the network’s address assignment mechanism may be told to always assign a particular address to the customer.
From an interception perspective, how the address is assigned is not particularly important. The important thing is that the operator will already know the address that has been assigned to the target when an intercept order for that user is received.
This means that the operator can tell OpenLI directly which IP addresses to intercept traffic for, so OpenLI does not need to infer the target’s address from other protocol messages (such as RADIUS or DHCP).
With that in mind, let’s jump right into a practical scenario using the training lab.
In this scenario, we have received an IP intercept warrant from our mock agency. The intercept target happens to be the user “Shane Alcock”, who we have assigned the static IP address 10.1.18.217.
We also know that the target has bought a fiber optic connection from us, and that in our internal customer database they have been assigned a username of “salcock”.
Once again, we’re going to use the OpenLI REST API to add the requested intercept to our running OpenLI system.
This works exactly as it did when we were adding a VoIP intercept -- we make a POST request containing a JSON object that describes the intercept we want to add.
The important difference is that we send the request to a different URL. The new IP intercept is posted to “/ipintercept” instead of “/voipintercept”.
Let’s take a look at the JSON object that describes our IP intercept.
First off, you will see that there are a lot of properties that are common with the VoIP intercept that we configured a couple of lessons ago. These properties all have the same meaning here, as they did then.
Of course, you’ll notice that our LIID has changed because it must be unique for each intercept, but every other property has the same value as before as well.
The first new property for an IP intercept is the “user” property. This is a mandatory property that must be set to the username that the target has within your network.
In our case, the value for this property is the username “salcock”.
The next new property is the access type, where you must specify the type of connection that you supply to the intercept target. There is a range of possible values that you can supply here, which are listed in the OpenLI documentation.
For this example, our target has purchased a fiber optic connection from us so we must set this property to have the value “fiber”.
The last property that we need to include are the static IP addresses that have been assigned to the target. There could be multiple addresses, so OpenLI requires that this property be expressed as a JSON list.
Each item in the static IP list contains two properties. The first property is the iprange, where you can either specify a single address or a subnet (more on this in a moment).
In our case, our target only has the one IPv4 address -- 10.1.18.217 -- so that is what we include in our JSON object here.
The second parameter is the session ID. Because there is no session management protocol associated with a static IP address assignment, we do not have any information about the session available that OpenLI can use to derive a communication Identity Number.
Instead, the operator must provide a session ID number that will then be used as the CIN for any intercept records resulting from this intercept.
The choice of this number is entirely up to you -- it is a good idea to have a unique session ID for each static IP intercept that you add to OpenLI, just to keep things simple for the receiving agencies.
Larger IP address allocations can be expressed using the conventional technique of “network - slash - prefix length”. So for instance, if our target user had been assigned an entire IPv4 /28 for some reason, then we can tell OpenLI to intercept the whole range by setting the iprange property to “10.1.18.208/28”.
You can also configure IPv6 addresses and ranges using the iprange property, and you can include multiple static address ranges for a single intercept target by simply adding more entries to the staticips list.
As before, we can use curl to send the POST request for our static IP intercept to the provisioner.
Based on everything we’ve done up until now, this curl command should make perfect sense to you and not require any further explanation.
The OpenLI component logs should now each contain messages acknowledging the addition of your new static IP intercept.
The collector log will contain two messages: one stating that the collector now knows about a new IP intercept, and another mentioning the new IP range associated with that intercept.
The corresponding mediator log message is the same as what we saw earlier with the VoIP intercept.
The other REST API methods also work very much the same way for IP intercepts as they do for VoIP intercepts.
You can modify an IP intercept using the PUT method. Once again, the LIID field is mandatory in your JSON object, but any other unchanged fields may be left out. The only catch is that if you are modifying the static IP ranges for an intercept, you must include all ranges that want to persist as otherwise OpenLI will assume that any missing ranges are being removed.
DELETE and GET are exactly the same as they were for VoIP intercepts -- you just need to substitute “voipintercept” in the URL with “ipintercept”.
Our first IP intercept has now been configured and is ready to take place, so this seems like a good time to take a quick break.
In our next lesson, we will intercept some IP traffic and take a look at the resulting intercept records that are delivered over HI2 and HI3. I hope you’ll be able to join me again soon.