OpenLI Tutorial 02: The ETSI Standards for LI
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 everyone and welcome to the second installment in this series of training lectures about the OpenLI Lawful Intercept system.
In this chapter, we are going to look at the ETSI standards for LI in more detail. It’s not critical for you to understand the standards to use OpenLI, but it is useful background knowledge that will help you better understand your LI system once you get it up and running. Having said that, feel free to skip this chapter if you’re in a hurry.
Still here? Good -- I’ll start by talking a little about why these standards exist and the problems that they create for network operators who need to comply with them. Then we’ll go through the key requirements that must be met by any LI system for it to be compliant with the ETSI standards. Once we’re done, you will hopefully have a much better understanding of why lawful intercept systems are so complex (and expensive!) and maybe a better appreciation for what we have achieved with the OpenLI project so far.
To begin with, it’s worthwhile to reiterate exactly why these standards exist. The first reason, and a reason that underpins most formal standards, is that standards define the messaging protocols and formatting that must be used by conforming systems to communicate with each other.
Specifically in the LI case, this ensures that the output produced by the LI system running on an operator’s network can be parsed and processed by the receiving system at the LEA. Any difference or misunderstanding in the communication format between the two endpoints will mean that a collected intercept is effectively useless to the LEA. So first and foremost, the standards ensure that both data producers and data consumers are speaking the same language.
Because the data collected by an LI system may be used as evidence in a criminal trial, it is also important that the data is collected and labelled in a way that can withstand scrutiny from a legal defender. Here, the standards play a significant role too: they specify an encapsulation format for collected data that includes all of the information that would be necessary to identify the source of a communication, the time and place where it was intercepted, the case for which the interception was authorised, and whether any parts of the communication may have been missed or lost by the collection process.
Any failure to provide such information with the interception may allow a defence lawyer to either cast doubt on the integrity of the evidence or even have it ruled to be inadmissible in court by a judge. By making the collection of this additional meta-data part of the ETSI standard itself, the LEAs can be confident that any evidence collected by an ETSI-compliant LI system should be suitable for presentation in court (at least from a technical perspective).
Unfortunately, the need for rigorous and comprehensive standards also introduces some downsides. The complexity of the ETSI standards means that any implementation effort will require significant technical expertise and take months, if not years, to develop. Anyone that does succeed in implementing the standards is going to expect a return on their investment -- this inevitably leads to a high cost burden being placed on the users of these implementations, namely the operators and the LEAs. Buying a fully compliant LI solution from a commercial vendor is not cheap, but for most it is still a less expensive prospect than trying to develop a viable solution in-house.
The neat thing about OpenLI is that it disrupts the “high-cost to achieve compliance” dynamic that has been especially burdensome for smaller network operators. OpenLI was funded initially by a collaborative model where multiple ISPs pooled resources to fund an open-source implementation that could benefit the entire operator community. Now the software is publicly available, and anyone finding themselves in need of a low-cost alternative LI system has a viable option in OpenLI.
So what are the key requirements of an ETSI-compliant LI system? The first one is that all intercepted traffic and related meta-data must be streamed to the LEAs in real time. This is important because it allows the LEAs to react to criminal activities that are taking place right now, rather than only learning about them afterwards. The real time requirement is usually also part of the interception legislation in your country, and this is the main reason that you can instantly rule out tcpdump as a viable option for lawful intercept.
Agencies with relatively low security thresholds, such as police forces, will expect the intercept to be streamed to them over the public Internet using a TCP session within some sort of encrypted tunnel, such as an IPSec tunnel. High security interceptions, such as those conducted by intelligence agencies, may not be allowed to traverse the public Internet and may instead be streamed via a direct physical connection to your intercept infrastructure.
We’ve already covered how there are two separate handovers for delivering intercept records to the LEAs -- HI2 for the IRI meta data and HI3 for the Communications Contents. Each handover will have its own separate encrypted TCP session. The standards elaborate on how to implement these handovers in quite some detail -- there are keep-alives that must be sent regularly, options to potentially negotiate and buffering considerations to factor in.
As I mentioned earlier, the evidence collected by the intercept must be able to withstand extensive scrutiny, and must also be able to be catalogued and safely stored by the LEAs. Intercepts for different cases must be kept separate, even if those intercepts occur concurrently, and all intercepted communications must have a clear chain of evidence that shows where they were collected, by whom and for which investigation.
To that end, the ETSI standards define a custom record format that must be used to encapsulate each intercepted packet or meta-data record. The format includes all of the fields necessary to appropriately label each record to meet the requirements of LEAs who may wish to use the material in court. These include a unique lawful intercept identifier that is assigned by the LEA and is used to distinguish between different interception targets, a communications identifier which differentiates between multiple calls or sessions for the same target, and sequence numbers which are used to show that no collected data was lost by the interception or mediation processes.
These record formats are explicitly defined in the standards and cover many pages of ASN.1 notation, including the common header structures as well as the service-specific guidelines for each distinct type of intercept. Conventional IP, VOIP and Mobile IP all have slightly different requirements -- for instance, mobile IP has fields for recording the geographic location of the user which is not readily available for the other service types.
These next two requirements may seem obvious, but can be quite challenging from an implementation perspective -- firstly, all communications made by or directed to an intercept target must be captured and delivered to the LEA (wherever possible). No missing packets, no failing to recognise that the target has switched to another dynamic IP address, no records being lost due to overload of the mediation functions or a failure in your internal network linking the intercept functions to the mediation functions. You must employ adequate safeguards to ensure that a temporary disruption anywhere in the system can be borne without losing intercepted data.
Secondly, the LI system must be very precise in terms of which traffic is intercepted. Traffic belonging to users other than a current interception target must never be forwarded to the LEAs, and interception for a target must also cease immediately once the interception warrant expires. Erroneous interception of other users’ traffic would not only violate their privacy, but also damage the public perception of lawful intercept as a tool for law enforcement (even further).
The final key requirement that I’ll talk about today is that the interception target must not be able to detect that an intercept is taking place -- this is also for obvious reasons, as they will likely discontinue use of their phone or computer if they suspect that they are under surveillance. Most importantly this means that there must be no disruption to their Internet service when the interception begins, no matter how brief. There must also be no obvious changes to the routing or latency of their Internet traffic (such as routing their traffic through an offshore “intercept” box that adds 5 hops and 100ms to their latency), as this could be easily detected by a savvy target using tools like traceroute and ping.
Essentially, your LI system has to be a transparent part of your operational network that can be simply turned on and off, per target user as required by any warrants that you receive. It can’t be a dormant, offline system that you then put into the appropriate place when the LEAs come calling or something that lives off in the wilderness where no normal traffic would ever go.
Ok, so that concludes the main content for this chapter. By now, you should have a better understanding of why we have these complex standards for lawful intercept. I’ve also spoken a little bit about how that complexity can lead to LI systems being difficult to develop and therefore expensive for operators to deploy. Finally, we’ve gone over some of the key requirements for an LI system that are specified in the ETSI standards, just to emphasize how non-trivial it is to create a compliant system and to eventually help you understand some of the design choices that we’ve made with OpenLI.
Thanks again for listening -- next time we’re going to get a little more technical and talk about packet capture from the perspective of preparing to deploy an LI system. I’ll introduce a variety of packet capture methods that are available in Linux and discuss their pros and cons within the context of LI.
However, before I end this chapter I do have a little bit of bonus material for people who want to learn more about the ETSI standards for LI. Regular OpenLI users can probably just tune out now, but anyone interested in doing dev work on OpenLI in the future may want to stick around to become familiar with each of the various standards documents.
Right, if you are still here then let’s proceed into the standards documents themselves.
The ETSI standards for lawful intercept are defined in a series of documents, none of which are particularly thrilling reading, but it may pay to at least be aware of their existence in case you wish to look up some specific aspects of the standards later on.
The first document worth knowing about is ETSI TS 101 671, which describes the general architecture and communication model for a lawful interception system within the network operator’s domain. This is the document that describes the handovers (or communication channels) between the operator’s LI system and the LEA’s mediation function. It also defines the various identifier fields that are specific to lawful interception and are used to label intercepted traffic and meta-data records. For the most part, this document serves as an overview of how an LI system should work and leaves the technical specifics to the following documents...
… which form the ETSI TS 102 232 series. There are 7 documents in this series, 6 of which are dedicated to covering the interception process for a specific communications technology (as we will see shortly).
The first document in the series, however, describes the mediation aspect of the LI system, that is how to stream intercept records to the LEAs using an IP-based handover. This document includes the specification of the header that must be prepended to any intercepted packet or IRI meta-data record, as well as how to implement the handover and session layers of the delivery protocol stack. This standard includes the definitions of application-layer keep alives, session options and their negotiation methods and the acknowledgement of received data. The underlying transport protocol for the handovers is also specified as TCP, and there are some notes of specific TCP session configuration that should be applied for LI handovers.
Now we shall move into the service-specific standards documents, starting with number 3 -- which describes the interception process for conventional IP traffic. The document explicitly lays out the required formatting for the CCs and IRIs that must result from intercepting IP traffic for a target user. The text also describes how a target’s identity is defined in the context of an IP network, and how that identity can be mapped to an IP address (depending on the network type and the AAA system used by the operator). It also specifies how to generate IRI records in response to observed events within the AAA system, including very detailed instructions for RADIUS and DHCP networks.
Document 5 does much the same thing, except focusing on what the standards call IP multimedia traffic: in other words, VOIP and video-calling technologies that use SIP and RTP to conduct calls between users. Once again, the standard defines the formatting of the corresponding IRIs and CCs for a VOIP intercept, how to recognise calls belonging to an intercept target and how certain events observed in the SIP traffic stream should be used to trigger the generation of certain IRI records.
And finally we have document 7, which is the corresponding standard for intercepting mobile IP traffic for 2G, 3G and 4G services. We note that 5G is potentially a unique challenge that may require a separate standard again, but that’s a bit beyond the scope of this lesson. Once again, the document provides the required formatting of the IRI and CC records for this particular class of intercept, but for the most part this document will defer to a corresponding document published by the 3GPP, as they had already standardised interception in mobile environments before the ETSI standardisation process began. This, of course, means that there are even more documents for a potential implementer to read through and the 3GPP documents make the ETSI ones look like light reading.
Document 7 also includes instructions on how to derive the values of certain ETSI-specific header fields from their 3GPP equivalents, especially for situations where the original intercept collection has been performed by a 3GPP-compliant system and needs to be translated into the ETSI standard.
Astute listeners will notice that I have skipped some of the seven documents -- these cover portions of the standards that are currently not implemented within OpenLI (but may be in the future if there is sufficient demand). The first of these is document 2, which covers the interception of Email and would apply to networks that operate their own mail service. Document 4 describes the ETSI standards for interception within networks that solely provide layer 2 services without IP, such as those operated by wholesale fibre optic companies. Lastly, there is document 6 which defines how to intercept traffic from an older PSTN or ISDN network, which is likely only relevant for larger telcos that have been around since the pre-broadband days and have probably already solved most of their lawful intercept problems.
That concludes this quick tour of the ETSI standards documents for lawful interception. Hopefully you are still awake -- as mentioned earlier, our next lesson is going to teach you about the different technologies that are available for performing packet capture and how your choice of technology for your LI system will affect the ability of your system to cope with different traffic volumes. See you then!