Compatibility with Other Lawful Intercept Interfaces - OpenLI-NZ/openli GitHub Wiki

Introduction

Most networking hardware vendors include lawful interception capabilities on their devices, which can be used to mirror a copy of the traffic for a particular network user to a pre-determined destination. The mirrored traffic may be encapsulated using a special protocol (which may also vary from vendor to vendor) prior to its transmission to the destination.

The resulting traffic stream will not be compliant with the ETSI TS 102 232 standards so it cannot be directly forwarded on to the LEA. Instead, you will still need a separate LI system that can ingest the mirrored traffic and perform the necessary encoding and mediation to fully satisfy your LI obligations.

On this page, we will describe which vendor mirroring methods are supported by the OpenLI collector and how you can configure OpenLI to be able to convert the mirrored traffic stream into an ETSI-compliant intercept.

Important note: OpenLI will not push any configuration or intercept requests to your networking hardware. The task of triggering the mirrored traffic stream on your device(s) is left entirely up to you. Alternatively, talk to the SearchLight team about their fully integrated LI Management Solution (LIMS) for OpenLI.

Supported Interfaces

At present, OpenLI is capable of ingesting mirrored traffic using one of the following interfaces:

ETSI TS 103 221-2, also known as X2 / X3
Nokia LI Mirroring
Juniper 'jmirror' encapsulation
Cisco intercept encapsulation (CCCID), sometimes referred to as PacketCable
Juniper FlowTapLite (requires OpenLI 1.1.16 or later)

Configuration

OpenLI has 3 different approaches for receiving and processing encapsulated traffic delivered via one of the aforementioned interfaces. Each approach has its own configuration settings.

Interception using X2/X3 Inputs

As you might expect, the X2/X3 input approach is used to intercept traffic delivered to an OpenLI collector using the X2 and X3 interfaces. For clarity, X2 and X3 are the names used to describe the streams of session management (X2) and communications contents (X3) that are emitted by a network device or function in response to an intercept request. Intercept requests are sent using the X1 protocol, which is not supported by OpenLI directly.

Please note: at the time of writing, OpenLI currently only supports the interception of voice traffic (i.e. SIP and RTP) over the X2 / X3 interfaces. Please contact the OpenLI team ([email protected]) if you require IP data interception using X2 / X3.

To enable X2/X3 ingestion on your OpenLI collector, you should add something similar to the configuration below to your collector config file:

x2x3inputs:
 - listenaddr: 10.0.1.100             # The IP address that the collector will listen on for X2/X3 connections
   listenport: 10000                  # The TCP port that the collector will listen on for X2/X3 connections
   certfile: /path/to/certificate.pem # The path to the file containing a TLS certificate that the collector should offer to clients

You may specify multiple "inputs" if required; simply add another item to the x2x3inputs sequence with the three required configuration parameters.

Note that TLS is mandatory for X2/X3 transport and therefore you must provide a valid TLS certificate to be able to use X2/X3 with OpenLI.

The listenaddr and listenport that you have set on your collector should then be used to define the destination when you tell your network device to begin interception (i.e. using the X1 protocol).

Each intercept that is created on a network device using X1 is assigned a unique identifier, called an XID. To tell OpenLI which XID(s) correspond to which intercept, you must include a sequence called xids in your intercept configuration.

For example, in JSON format using the REST API:

  "liid": "x2x3example",
  "authcc": "NZ",
  "delivcc": "NZ",
  "agencyid": "police",
  "mediator": 16002,
  "outputhandovers": 0,
  "starttime": 1753966800
  "endtime": 1754571600,
  "xids": [
    "29f28e1c-f230-486a-a860-f5a784ab9124"
  ],
  "siptargets": []
}

or as YAML written directly into a configuration file:

- liid: x2x3example
  authcountrycode: NZ
  deliverycountrycode: NZ
  agencyid: police
  mediator: 16002
  starttime: 1753966800
  endtime: 1754571600
  payloadencryption: none
  xids: 
  - 29f28e1c-f230-486a-a860-f5a784ab9124
  outputhandovers: all
  siptargets: []

Note that voice intercepts using X2 / X3 do not require siptargets to be specified, as we can guarantee that (assuming you set the intercept target identity correctly via X1) anything received on X2 / X3 with the provided XID must belong to the designated target for that intercept.

In summary, remember that you need 3 separate pieces of configuration for an X2 / X3 intercept to work with OpenLI:

a suitable destination defined in the x2x3inputs section of your collector configuration.
X1 to your network device that triggers the interception of traffic and sends it the destination on the OpenLI collector, tagged with a XID.
OpenLI intercept configuration that includes the XID from part 2 above so OpenLI knows that X2 / X3 messages with that XID belong to that intercept.

Interception using UDP Sinks

UDP Sinks are only available in OpenLI 1.1.16 or later; you will need to use Vendor Mirror IDs if you are running an earlier version of OpenLI.

The following interfaces can be ingested using a UDP Sink: Nokia, Jmirror, Cisco PacketCable, and FlowTapLite.

More to come...

Interception using Vendor Mirror IDs

The Vendor Mirror ID approach is the "old" way of telling OpenLI how to intercept encapsulated mirrored traffic. It is entirely superseded by the UDP Sink method, and we strongly recommend using that approach instead for new OpenLI deployments.

The following interfaces can be ingested using a Vendor Mirror ID: Nokia, Jmirror, and Cisco PacketCable.

When an intercept is configured on one of the aforementioned devices using their native LI capabilities, two key properties are required. The first property is an intercept ID number, which is roughly equivalent to an LIID but must be a number (i.e. not a string or a sequence of binary octets). The second property is the destination for the intercepted traffic that will be sent over encapsulated UDP (i.e. an IP address and a port number). Ideally, the destination would be a host that is running an OpenLI collector but that is not a strict requirement -- you could, for instance, use another machine as the destination and mirror the intercepted traffic from there to your OpenLI collector.

Most importantly, the mirrored traffic needs to end up as visible on one of the interfaces that your OpenLI collector is capturing traffic on, as defined in the inputs section of the collector configuration.

Then you must tell the OpenLI collector the IP address and port number of the original intercept destination. For Nokia mirroring, you would add the destination under the alumirrors section of your OpenLI collector configuration, as shown in the example below:

alumirrors:
  - ip: 10.0.200.1
    port: 7777

For Jmirror, the name of the configuration option changes from alumirrors to jmirrors. For Cisco PacketCable, the option name should be set to ciscomirrors. Note that you can have multiple mirror types in the same configuration file if necessary, as well as multiple IP/port pairs in a single section.

Once you add this configuration to your OpenLI collector, any UDP traffic received by the collector on an input interface that is destined for an IP/port pair defined as a mirror will be treated as though it was encapsulated mirror traffic from the corresponding vendor interface.

The last step is to include the intercept ID number that you used to create the intercept on your vendor equipment in the IP intercept configuration that you provide to OpenLI, so that OpenLI can associate any encapsulated mirrored traffic that is tagged with that particular intercept ID number with the correct ETSI intercept. This can be done by adding a vendmirrorid field to your IP intercept configuration, as below:

- liid: vendmirrorexample
  authcountrycode: NZ
  deliverycountrycode: NZ
  agencyid: police
  mediator: 16002
  starttime: 1753966800
  endtime: 1754571600
  payloadencryption: none
  user: bob
  accesstype: adsl
  vendmirrorid: 2500              # The intercept ID number from when you created the intercept on your vendor device

Only IP intercepts support the use of vendor mirror IDs.