Technical Report

Background and Justification:[Back to table of contents]

What is Lawful Interception?
Many network operators have a regulatory requirement to incorporate Lawful Interception (LI) capabilities into their networks, so that Law Enforcement Agencies (LEAs) can commission authorized electronic surveillance of specific network users. Operators that fail to comply with LI requirements can find themselves subject to prosecution, and the penalties are designed to strongly encourage compliance (for instance, in New Zealand non-compliance may result in a fine of up to $500,000 NZD plus a further $50,000 NZD per day for continued non-compliance).
What constitutes an acceptable intercept can vary across jurisdictions; some agencies will still accept pcap files of the target’s traffic that are delivered after an event, but it is now increasingly common for agencies to mandate intercepts in a format that can better withstand scrutiny in court. There are two sets of standards that have been defined for this purpose: CALEA (which is used in North America) and ETSI (which is used in Europe and the Asia Pacific).
Both standards are much more onerous for the operator than simply delivering pcap captures. The intercepted traffic must be delivered to the LEAs in realtime without any loss, over an encrypted channel. The intercept must be accompanied by a stream of ‘Intercept Related Information’ (IRI), which contains
metadata about the communication session itself. Individual IP sessions or VOIP calls for a target must have their own unique identifier, and each intercepted packet must be tagged with a sequence number to allow LEAs to detect missing or reordered segments. There are distinct ETSI standard encapsulations for
intercepted packets that are defined for different communication methods, for example IP, VOIP, mobile data, and email.

The Problem
Existing vendor solutions that implement the ETSI standards can cost upwards of $50,000 USD plus ongoing licensing costs. This price may be affordable for the larger operators in wealthy economies but smaller operators or operators based in developing countries will find the cost of the vendor solutions to be prohibitive. Another issue is that the vendor solutions are closed source and cannot be easily audited to ensure that there are no backdoors that would allow unauthorized entities to perform surveillance on the network. Accusations of covert backdoors in LI-capable commercial vendor equipment often attract
mainstream media attention , so this is a genuine concern for both operators and LEAs.
The problems that we have described affect companies that provide Internet services to paying customers, rather than directly affecting individuals of any particular gender. An operator that is forced to license a vendor solution for LI may need to increase the prices that they charge for their services to recoup the cost but this increase would most likely be applied to all customers, regardless of their gender. We feel, therefore, that the underlying problem that we are trying to address (unaffordable lawful interception solutions for small or disadvantaged network operators) is relatively gender-neutral.

Our Solution
The OpenLI project aims to provide smaller and less wealthy Internet Service Providers (ISPs) with a viable open source alternative that they can use to meet their lawful intercept regulatory requirements. OpenLI began as a collaboration between the WAND network research group at the University of Waikato and members of the New Zealand Network Operators Group, whereby the WAND group would apply its expertise in network packet capture to develop software that would allow the operators to comply with the ETSI LI standards and the operators would contribute money into a funding pool to cover the development costs (such as the salary of the researchers working on the software). To date, we have received funding contributions from 10 New Zealand ISPs, 1 ISP from Brazil and the New Zealand Internet Exchange. We also applied for and received a Community grant from InternetNZ to assist with ongoing development of the OpenLI system. Combined, this funding has covered the costs incurred over two years of development thus far. In 2019, the OpenLI project was a finalist in the New Zealand Hi-Tech Awards in the “Best Hi-Tech Solution for the Public Good” category.

Public releases of the OpenLI software have been available for 18 months and there have been multiple successful deployments of the OpenLI system by New Zealand operators which have been confirmed as suitably compliant by the NZ Police. The software itself remains free and open source, and can also therefore be independently verified as free of any covert or government-mandated backdoors.

An ongoing challenge now for the OpenLI project is to ensure that the project is sustainable: the project must continue to cover the costs associated with maintaining and supporting the software so that it can remain available for any operators that may need it.

Project Implementation:[Back to table of contents]

The project has three planned phases.

Phase 1 is Information Gathering and Building Relationships.

We have created a reference list of countries in the Asia Pacific region with as much as we can discover about the requirements for lawful intercept and the legal environment.  This was challenging because the information tends to be communicated directly from LEA to operator, instead of made publicly available.   We had to read and interpret legislation in some cases.

We have given a range of talks and NOG events and have started receiving and actively responding to international enquiries.  See more under project communications.  Due to CoVID-19 travel restrictions this has been in the form of video talks which has allowed attendance at a wide range of NOG events but limited the chances of meeting people in person.

We are working on developing a tutorial series to teach network operators about lawful interception, packet capture and the use of OpenLI. This is planned to be released as pre-recorded videos (with accompanying Docker images for hands-on exercises), but we also aim to run live interactive versions much like the APNIC / NSRC workshops (possibly with some assistance from those organizations).

Phase 2 is Implementation

There have been seven OpenLI releases since start of September 2020

Key features added:

•     Significant performance improvements, particularly through caching encoded packets.
•     Support for HI1 operations messages (required by many LEAs and requested by NZ operators).
•     Security enhancements, such as authentication for the REST API and running packaged binaries as a non-root user.
•     Allow use of RabbitMQ to buffer encoded records onto disk when collectors cannot reach mediators.
•     Allow packaged installs to co-exist alongside system loggers other than rsyslog.
•     BER encoding was added experimentally but removed based on operational feedback.
•     Many other bug fixes and performance improvements, mostly resulting from user reports.

We are evaluating the next major enhancements for OpenLI although many options will require support from a suitable network operator.

Phase 3 is Direct Engagement and Evaluation

We are engaging with operators as we receive enquiries.   Although numbers are small this appears to be increasing.

This part of the project has been severely restricted by COVID-19 pandemic which has limited travel and provided operators with other higher priorities.

Project Evaluation:[Back to table of contents]

At the moment we believe we have achieved most of our objectives.  It is however difficult with an open source project to definitively know how many users we do have and particularly how many people are using it in production rather than just looking out of interest. Both the number of package downloads and the variety of downloaders appear to be steadily increasing over time.

We have presented talks at five different events. Our talks have aimed to educate about LI concepts as well as promote OpenLI.

However the number of enquiries we receive, although small, appears to be increasing.   We have received more international enquiries since the start of this project than we did in the previous two years of OpenLI development.  This can only be because of the outreach activities undertaken as part of the project.

We have maintained a regular development and release cycle.  Projects that do not appear active may struggle to gain support.

NZ operators have been happy with level of maintenance and support so far, as evidenced by their willingness to sign up for ongoing support contracts.

Gender Equality and Inclusion:[Back to table of contents]

Gender issues play a very small part in this project.

The directly involved team is entirely male, however we are working in an environment with strong gender equality regulations and culture (the University).

We planned to involve female staff,   Harpreet Kauer – now moved to India could be a conduit for Indian network operators.   Abigail Koay to provide security advice for deployments.   COVID complication have limited the opportunity to involve them so far.

We are working with Safiya Noorzai as a commercialization officer of the University commercialization office to develop a business case to improve the business case for supporting OpenLI.

Project Communication Strategy:[Back to table of contents]

The project maintains a website at https://openli.nz and github pages including a wiki.  At the moment the github pages are generating a significant portion of the new enquiries.

The primary communications strategy has been by giving talks at NOG events.  Talks so far presented are:

* bdNOG — https://bdnog.org/bdnog12/index.php

* PacNOG — https://www.pacnog.org/pacnog27/agenda.html

* MMNOG — https://www.mmnog.net/4.php

* APRICOT — https://youtu.be/zb-g0XsRrLo?t=1728

Additionally we participated in a panel at APNIC 50 the Cooperation SIG — https://www.youtube.com/watch?v=_AF27w2RBXY

Recommendations and Use of Findings:[Back to table of contents]

So far the key lessons are:

Regular technical enquiries can use significant technical resource time.  We hope to address this through additional educational resources.

The project needs more specialist business input to ensure that we are on track to achieve financial sustainability while maintaining the open source nature of the project.  We are negotiating with the University commercialization office to get more input.  They have assigned an officer to work through the project with us.

Many law enforcement agencies have additional requirements on top of what is specified in the official standards, and these requirements are not typically public knowledge. In these cases, it may be that operators discover OpenLI but find that it is missing a key feature for their jurisdiction, only because we did not know that feature was required. We may need to find ways to engage with law enforcement outside of New Zealand more directly, so that we can better understand these requirements and implement support for them. This may require direct assistance from ISIF ASIA or APNIC to lend extra credibility to the project and encourage the agencies to engage with us as a viable vendor.

Bibliography:[Back to table of contents]