Deep packet inspection for lawful interception is usually associated with the law enforcement side: the agency receives raw IP packets and analyses them in its monitoring facility. More and more network operators and agencies, however, are asking whether part of this work can be done at the provider, close to the traffic. In this model, the provider extracts and enriches metadata at the point of interception and hands it over together with the full copy of the communication.
Whether a provider may do any of this depends on national law: in Germany, analysis stays with the agency. Where it is allowed and done right, provider-side DPI speeds up investigations, can reduce data volumes where an order limits the scope, and gives agencies context they could not reconstruct themselves. Done wrong, it breaks evidence rules or exceeds the legal mandate. This article explains the architecture, what can be extracted, how enriched data is delivered, and where the boundaries are.
Key Takeaways
- Provider-side DPI complements the full copy of the communication. It never replaces it, unless the order and national rules explicitly allow a reduced scope.
- The provider has network context the agency lacks: line identity, NAT mappings, cell and location data, device identifiers and precise session timing. Subscriber details such as name and address need a separate request.
- Typical extracted metadata includes flow records, DNS, SNI, TLS fingerprints (JA4), application classification, VoIP signalling and activity types.
- Enriched data must be delivered in an agreed, documented format, for example as additional IRI records where the national specification allows it. Whether a provider may deliver any of it is jurisdiction-dependent: in Germany the provider hands over only the copy and the § 7 TKÜV event data, and analysis belongs to the agency.
- Where national law allows it, everything must be target-specific, reproducible, documented and strictly separated from commercial DPI. An acceptance concept documents it but cannot make it lawful.
Why Do Deep Packet Inspection on the Provider Side?
| Driver | Benefit for the agency | Benefit for the provider |
|---|---|---|
| Bandwidth growth (multi-Gigabit FTTH, 5G) | Metadata is available immediately, even if the full copy takes time to process | Less pressure on handover links where scope limits apply |
| Encrypted traffic | Pre-classified sessions and fingerprints | Reuse of existing DPI expertise |
| Network context | Line, NAT, cell and device data attached to each flow | Fewer follow-up requests for basic context, where national rules list the data for the copy (subscriber name and address always need a separate request) |
| Time-critical cases | Near real-time alerts on activity patterns | Clearly defined, automated process |
| Complex access models | Correct attribution behind CGNAT and in wholesale setups | Fewer disputes about incomplete intercepts |
Where the Law Draws the Line
Before designing anything, providers must understand their legal position:
- The full copy comes first. In most European jurisdictions the provider must deliver a complete, unaltered copy of the target’s telecommunications. Where national law allows enrichment, it is an addition; in Germany it is not allowed (see below). Filtering is allowed only where the order limits the scope.
- No analysis beyond the order. Provider-side DPI may only process traffic of the ordered target and only for the purpose of the interception. Bulk or untargeted analysis is not permitted.
- Separation from commercial DPI. The EU Open Internet Regulation (EU) 2015/2120 restricts DPI for traffic management, but allows measures needed to comply with Union or national law. LI processing must therefore run in a separate, access-controlled environment and must never feed commercial systems.
- Confidentiality. Staff and systems are bound by telecommunications secrecy, and the subscriber must not notice the measure.
- Germany is stricter. The obliged provider must enable the measure (§ 100a(4) StPO) and hand over a complete copy plus the event data listed in § 7 TKÜV, and nothing else at the handover point (§ 8(2) No. 2 TKÜV). Analysis of the content, including DPI classification, belongs to the agency. A BNetzA acceptance cannot create a legal basis for extra processing. Provider-side enrichment is only an option where national law expressly provides for it.
Reference Architecture
- Traffic access: BNG/BRAS for PPPoE and IPoE access, and PE or core routers for fixed-IP lines, copy the target’s traffic with their built-in LI function, using ETSI TS 103 221 (X1 tasking, X2/X3 delivery) where supported or the vendor’s LI interface. The ADMF handles the tasking, and the mediation layer converts the delivered streams into the ETSI handover format. Optical TAPs or virtual mirror ports are only a fallback where no native LI function is available.
- Target triggering: the LIMS/ADMF activates the target, and session events from RADIUS/Diameter, DHCP or the packet gateway tell the DPI node which IP addresses and prefixes currently belong to the target.
- Target-specific deep packet inspection node: the node processes only the X3 stream of the ordered target. Flows are reassembled, protocols identified and metadata extracted, using high-performance packet processing (for example DPDK or FPGA-based NICs) at 10/40/100 Gbit/s.
- Enrichment: each flow is tagged with the LIID, the target identifier, the NAT mapping (public IP and port block), cell ID or location, and the IMEI where available. Enrichment is limited to data the national rules list for the copy; subscriber details such as name and address still require a separate information request.
- Mediation and delivery: the full copy is delivered as CC via HI3, according to ETSI TS 102 232-3 or -4 for fixed access, or 3GPP TS 33.108/33.128 over TS 102 232-7 for mobile, and any enriched metadata permitted by national law is delivered via HI2.
- Audit and retention: DPI outputs are kept only as long as delivery requires, and every configuration and signature version is logged.
See X1/X2/X3 interfaces and how a mediation function works for the underlying interfaces.
What Can Be Extracted and Enriched?
| Metadata | Source | Value for the investigation |
|---|---|---|
| Flow records (5-tuple, start/end, bytes, packets) | Packet headers | Complete activity overview |
| DNS queries and responses | Unencrypted DNS | Services and domains used |
| TLS SNI, ALPN, JA4 / JA4S fingerprints (note the FoxIO licence terms for JA4S) | TLS / QUIC handshakes | Application and device identification |
| Application classification | DPI signatures and behaviour | Messenger, VoIP, streaming, VPN, Tor |
| Activity type | Packet size and timing patterns | Message vs call vs file transfer |
| VoIP signalling (SIP, RTP parameters) | Unencrypted VoIP | Third-party VoIP calls with participants and duration |
| HTTP host and user agent | Unencrypted HTTP | Services and client software |
| NAT mapping | CGNAT logs | Link between public IP and port and the target |
| Location and device | Cell ID, IMEI, access line | Where and with which device an activity happened |
Which of these an access provider may deliver depends on national law. In Germany, classification and service-level reconstruction of third-party services are done by the agency, not the access provider. The encryption rule applies here as well: the provider removes only the encryption it applied itself. End-to-end encrypted content remains encrypted, and the metadata above is extracted without decrypting it.
Handing Over Enriched Data
There is no single, universal ETSI record type for “DPI results”. Flow summaries are standardised in ETSI TS 102 232-3 (Packet Data Summary Reporting); application classification is not. In practice, three models are used:
- Additional IRI records: extracted events (for example a detected VoIP call or an application session) are sent via HI2, using standard fields where possible, and national extensions only where the national specification provides for them.
- Flow-level IRI: where flow-level IRI is required by the warrant, ETSI TS 102 232-3 already defines it (Packet Data Summary Reporting, IPIRIOnly). Proprietary analytics streams outside the national handover specification are not permitted in Germany and need an explicit legal basis elsewhere.
- Service-level records: in some jurisdictions, and only where explicitly required, the provider delivers events at service level, similar to the service-specific parts of ETSI TS 102 232 that messaging and multimedia providers use for their own services.
Whatever the model, the format must be documented, versioned and agreed with the receiving agencies and the regulator, and the agency must always be able to verify enriched data against the full copy.
Evidence Quality: Make Enrichment Reproducible
- Record the DPI engine and signature version used for every result.
- Use synchronised, high-precision timestamps so that metadata aligns with the CC and HI2 records.
- Provide confidence indicators for behavioural classifications.
- Keep a complete audit trail of target activation, configuration changes and deliveries.
- Test regularly with reference traffic to detect regressions after signature updates.
Implementation Checklist for Providers
- Legal assessment: what the national framework allows, and what the orders typically cover
- Where national law provides for enrichment: scope and delivery format agreed with the agencies and documented in the acceptance concept
- Target-specific activation only, driven by the LIMS/ADMF
- Hardware-accelerated DPI sized for peak subscriber rates
- Integration with AAA, DHCP, CGNAT logs, packet core and location data
- Strict separation from commercial DPI and traffic management
- Versioning, reference testing and audit logging
- Resilient delivery with buffering and monitoring
How ICS Helps with Provider-Side Deep Packet Inspection
ICS International Carrier Services builds on more than 20 years of team experience in telecommunications, lawful interception and compliance and on BNetzA-accepted LI implementations. We integrate network elements via their vendor LI interfaces or ETSI TS 103 221 X1/X2/X3 and operate mediation for providers today, so we know both the network and the receiving side.
- Architecture and legal-technical design of provider-side DPI (see DPI for Network Operators) that fits your national framework and your acceptance concept.
- Target-triggered DPI and enrichment pipelines integrated with RADIUS/Diameter, CGNAT logging and packet core events.
- Network element integration with BNG/BRAS and core routers via their vendor LI interfaces or ETSI TS 103 221 X1/X3, plus passive probes or cloud mirroring where no native LI function is available.
- Mediation and ETSI handover through our LI Mediation Platform and LIMS.
- Managed operations around the clock. See Managed LI Operations.
- Custom development of extractors, classifiers and delivery formats. See Integration & Custom Development.
Get in touch with ICS to discuss whether provider-side enrichment makes sense for your network.
Frequently Asked Questions
Is deep packet inspection allowed for lawful interception?
Only where national law expressly provides for it. In Germany the provider must hand over a complete copy plus the event data listed in § 7 TKÜV and nothing else at the handover point (§ 8(2) No. 2 TKÜV); analysis of the content, including DPI classification, belongs to the agency, and a BNetzA acceptance cannot create a legal basis for extra processing. Untargeted or commercial use of LI data is never allowed.
Does provider-side DPI replace the full copy of the communication?
No. In most jurisdictions the provider must deliver a complete, unaltered copy of the target’s communication. DPI-based metadata is delivered in addition to it, unless the order explicitly limits the scope.
Can an ISP decrypt a target’s HTTPS or messenger traffic?
No. The provider only removes encryption it applied itself in its own network. End-to-end or application-level encryption remains intact. DPI works on unencrypted headers, handshakes and traffic patterns.
How is DPI metadata delivered to law enforcement?
Where national law allows it, as additional IRI records via HI2, using standard records such as the Packet Data Summary Reporting of ETSI TS 102 232-3 where possible. Separate analytics streams outside the national handover specification are not permitted in Germany. The format must be documented and agreed with the agencies and the regulator.
What is the difference between provider-side and LEA-side DPI?
LEA-side DPI analyses the delivered traffic in the monitoring facility. Provider-side DPI runs at the point of interception, where, if national law allows it, it can add network context such as the line identifier, NAT mappings and location, and deliver results in near real time.
Related Articles
- How a Mediation Function Works: The Bridge Between Your Network and Law Enforcement
- Encrypted DNS (DoH/DoT) and Its Impact on Lawful Interception Capabilities
- Network Slicing in 5G SA: How It Complicates (and Can Simplify) LI Targeting
- AI-Assisted LI: What Automation Means for Operators and Law Enforcement Workflows
