OpenLI Tutorial 17: Integration with Vendor Mirroring
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 and thank you for joining me for the seventeenth chapter in the OpenLI training series. In this lesson, I’m going to show you how you can use OpenLI in combination with the existing mirroring capabilities on certain vendor hardware to produce valid ETSI intercept records.
This is a slightly niche topic that won’t apply to everyone, depending on who you buy your networking equipment from. If your network does fall into that niche, though, this is a handy feature that is very popular among our operator user base.
What I’m talking about in this lesson is a feature that is commonly advertised by networking hardware vendors as a quote lawful intercept feature unquote, whereby you can configure the device to mirror the traffic for a particular subscriber to another port on a router.
The idea here, of course, is that you can configure this type of mirror whenever an agency requires you to perform an intercept. The mirror will then siphon off just the traffic for the intercept target and you can then deliver that mirrored traffic back to the requesting agency.
Here’s how it works in practice. Imagine you have a router that is enabling three users to connect to the Internet. One of those users has been doing something shady and has attracted the attention of the authorities, who have tasked the network operator with performing an IP intercept on their communications traffic.
Fortunately, the router has support for vendor mirroring so the network operator can apply special configuration to the router to add a mirror instruction for the target user.
Now the router will emit a copy of the target user’s traffic to some client software that is listening on a host that is reachable via the designated mirror port on the router. The mirrored traffic is encapsulated in UDP datagrams so that they can be correctly routed to the client if it is multiple hops away.
The client software may be provided by the vendor when you purchase the mirroring feature, or it may be some third-party software that is designed to be compliant with the vendor’s particular mirroring format.
And then, in an ideal world, the mirror client would then implement the ETSI handovers and deliver the intercepted traffic to the requesting LEA using the expected record format.
The key thing I want to highlight here is that the mirrored traffic that exits your router in this situation is NOT ETSI-compliant on its own. The captured communications are wrapped in a simple shim header and are therefore not tagged with the meta-data required by the ETSI standards, such as the operator ID and interception location. There are also no associated IRIs generated by the mirroring system.
As a result, you cannot simply provide the mirrored traffic directly to the LEA and expect them to be satisfied with what you’ve delivered. You still need a proper mediation device, either from the vendor or a third party, to translate the mirrored packets into compliant records.
Having said that, having the ability to mirror just an intercept target’s traffic at the router level is very useful and it makes sense for an interception system to take advantage of it wherever possible.
With that in mind, we have given the OpenLI collectors the ability to parse and strip some of the vendor mirroring shim headers, so that they can then replace them with valid ETSI headers instead. This means that you can still make use of the mirroring capabilities on your hardware, but also be able to produce ETSI-compliant CC records. If you are also able to supply the collector with the corresponding AAA traffic for the mirrored user, then OpenLI will be able to generate IRIs for the interception as well.
The support for this feature is primarily driven by requests and funding from our users. Based on these requests, we’ve implemented support for the mirroring methods used by Juniper and Nokia devices. In theory, other vendors could be supported as well -- we would just need you to tell us which vendors you need us to support.
This diagram will demonstrate the interaction between vendor mirroring and OpenLI in a more visual manner. The OpenLI collector acts as the client that will receive the wrapped mirrored packets as UDP datagrams. The datagrams are stripped, mapped back to a known intercept, and then reconstructed into valid ETSI CCs. The CCs are then forwarded on to the OpenLI mediator as per usual, which will then use the handover interfaces to pass them on to the requesting LEA.
Of course, for an OpenLI collector to be able to do that, we need a mechanism that allows us to tell the collector which of the packets that it captures are from a vendor mirror, as opposed to being regular customer traffic.
We also have to be explicit about which vendor is being used, as the shim header that mirrored traffic is wrapped in is different for each vendor (naturally).
Right now, the way that you provide this information is to list the vendor mirror details in the YAML configuration file for the collector. Unfortunately, we do not have a REST API method for specifying these details just yet, but we are considering addressing that in the near future.
Here is an example of configuration that would allow an OpenLI collector to recognise mirrored traffic from a Juniper packet mirror.
The syntax itself is quite simple -- at the top level, add a YAML list with the name “jmirrors”. Each list item describes an IP and port pair that must match the destination IP and destination port for a mirror that you have configured on your Juniper device.
In this example, any UDP traffic captured by the OpenLI collector that has a destination IP of 10.55.86.220 and a destination port of 30742 will now be assumed to be mirrored traffic, and will be stripped and re-constructed accordingly.
The configuration for recognising mirrored traffic from a Nokia or Alcatel-Lucent mirror is very similar -- this time, the YAML list is named “alumirrors”, but everything else is the same as before.
If you make changes to the configuration file for a running OpenLI collector, you will need to restart the collector to apply the changes.
In the training lab, this means running the two commands that are shown on the slide.
In a real deployment, you can just use the systemd “reload” command to request the collector to re-read its config instead.
Alright, let’s try and work through another practical example. In this scenario, an intercept warrant has arrived for one of our wireless customers, with a requested LIID of “NZP_20211010”.
We’ve found the customer in our user database and see that they happen to have the username that is shown on the slide -- I’ll refer to them as user “2O” from now on. In this exercise, we are once again using real-world traffic that has been anonymised for privacy reasons, which is why the username is seemingly random.
Our network uses Juniper hardware, so we are going to mirror the target’s traffic into our OpenLI collector using a Juniper packet mirror. The mirror will be configured with a destination IP of 10.55.86.220 and a destination port of UDP 30742.
In a real deployment, the destination IP address would be the address of the collector on the capture interface and there would be a route that forwards the mirrored traffic from the Juniper router to the OpenLI collector via that address. In the lab, we’re simply replaying previously captured traffic directly onto the capture interface, so we don’t need to worry about the routing.
As we’ve already discussed, we start by making sure that our collector can recognise the traffic from our Juniper mirror. To do this, we add the appropriate jmirror configuration to our OpenLI collector configuration file and restart the collector.
Next, we would need to configure a single-subscriber mirror on the Juniper device to mirror the traffic into our OpenLI collector.
This is a theoretical step for the lab exercise, because we obviously don’t have a Juniper device in our container environment to configure. Instead, we’re going to replay mirrored traffic captured from another network directly into our collector to get the desired result.
However, I’m going to broadly explain the configuration process anyway so that it is clear what you would do in a real world situation.
In this case, we want to specify our mirroring criteria to be the user’s identity “2O” and we would set the destination IP for the mirror to be 10.55.80.220 and the destination port to be UDP 30742.
The last thing that you would need to configure is an LIID for the mirror. The Juniper configuration requires that this ID be a 32 bit integer, so we can’t use the LIID that was given to us by the LEA here. Instead, for this exercise, we’re going to use the number 500 as the ID.
Now we are ready to add our new IP intercept to OpenLI. For this task, we are going to use the exact same REST API as we did with our previous IP intercepts -- there is just one new JSON property that you need to know about.
Here’s our JSON object for the mirrored IP intercept, containing all of the properties that you should be familiar with from previous lessons.
In this case, we’ve set our LIID to the one that our agency requested, the target user name to “2O” and the access type has been set to “wireless”.
The new property we need to add is called “vendmirrorid”, and this needs to be set to the ID number that we set for the mirror when we configured it on our Juniper device. In our case, you will hopefully remember that we chose the number 500.
This tells OpenLI that any vendor mirrored traffic with an ID number of 500 should be treated as a CC for the LIID “NZP_20211010”.
Please note that “vendmirrorid” is the name of the property regardless of what type of vendor mirroring you are using -- for instance, Juniper or Nokia.
Now that we have a complete JSON object, we can use curl to add the IP intercept to our OpenLI provisioner, just like we have done several times already.
Afterwards, if you look at the collector logs, you’ll see a log message that explicitly states that a vendor mirrored IP intercept has been added, along with the details of the LIID, vendor mirror ID and the target identity.
You’ll also see the usual “intercept added” messages in the logs for the other components, but these will look much the same as they did previously so we don’t need to show them to you again.
Now we are ready to inject some mirrored traffic into our OpenLI collector. On the collector container, you’ll find a pcap trace file called jmirror.pcap. This pcap contains two traffic streams: one is the traffic that has been mirrored by a Juniper device with an intercept ID of 500. The other stream is the corresponding RADIUS traffic for the target’s IP session, which we will need to generate IRI records for this intercept.
The server for the RADIUS traffic was 172.24.66.17 port 18133, and you will need to make sure you add that server using the REST API before proceeding with the rest of this exercise. Hopefully, you should know how to do this by now.
Once you’ve added the RADIUS server, you can use the following tracereplay command on the collector to replay the mirrored traffic onto the collector’s capture interface.
Make sure you use the 10-time replay speed option to make things run a bit faster.
The resulting IRIs from this intercept should look fairly similar to what we saw previously with the RADIUS intercept.
One thing that is worth noting is the assigned IP address that was derived from the RADIUS messages -- remember the address so we can compare it against the addresses in the CCs when we look at HI3.
The other thing you should try to remember is the communication identity number -- once again, we will want to confirm that this matches the number seen in the HI3 records.
Here’s the PS Header from a CC record observed on the HI3 handover. This should be very familiar to you by now.
And thankfully we see that the communication identity numbers are consistent across both our IRI and CC records.
If you scroll further down into the CC record, you will also hopefully see that either the source or destination IP for every packet in the CC Payload matches the IP address that was assigned to our target user.
This means that even though the packets being processed by our collector had been wrapped in shim headers and tunnelling layers, the collector has still been able to correctly find the IP traffic for our target user within these packets and intercept it accordingly.
To sum up, we’ve learned that OpenLI is capable of receiving and translating certain vendor-specific intercept formats into ETSI-compliant records that will satisfy a strict LEA. The only downside is that you need to do a little extra configuration work to both tell OpenLI how to recognise the mirrored traffic and ensure that the mirror is routed directly into your OpenLI collector.
I’d like to reiterate here that OpenLI currently supports the mirroring formats used by Juniper and Nokia / Alcatel-Lucent, but we are always open to adding support for other vendors -- please reach out to us if you have any particular requests in this regard.
That’s all we have time for in this lesson, but join me again next time to learn about how you can use TLS to encrypt the messages that OpenLI components send to one another.