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.
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.
Points clés à retenir
- 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 context the agency lacks: subscriber and line identity, NAT mappings, cell and location data, device identifiers and precise session timing.
- 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, or as a clearly labelled analytics stream.
- Everything must be target-specific, reproducible, documented in the acceptance concept and strictly separated from commercial DPI.
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 | Subscriber, NAT, cell and device data attached to each flow | Fewer follow-up requests for basic context, where the order allows |
| 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, including Germany, the provider must deliver a copie intégrale et non modifiée of the target’s telecommunications. Enrichment is an addition, and 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.
- Distinction par rapport aux DPI commerciaux. 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.
- Confidentialité. Le personnel et les systèmes sont soumis au secret des télécommunications, et l'abonné ne doit pas se rendre compte de cette mesure.
- Acceptance. In Germany, anything the provider delivers must be part of the technical concept accepted by the BNetzA. National specifications such as the TR TKÜV define what may be delivered and how.
Reference Architecture
- Traffic access via X3: carrier-grade BNG/BRAS for PPPoE and IPoE access, and PE or core routers for fixed-IP lines, deliver the target’s traffic natively via X3 (ETSI TS 103 221-2). ICS integrates the LI functions of Huawei, Cisco, Juniper and other leading vendors. Optical TAPs or virtual mirror ports are only a fallback where X3 is not available.
- Déclenchement de la cible: 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.
- Enrichissement: each flow is tagged with the LIID, subscriber and line identifiers, the NAT mapping (public IP and port block), cell ID or location, and the IMEI where available.
- Médiation et exécution: the full copy is delivered as CC via HI3, for example according to ETSI TS 102 232-3 or -7, and the enriched metadata is delivered via HI2 or an agreed analytics channel.
- 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 et le fonctionnement d'une fonction de médiation for the underlying interfaces.
What Can Be Extracted and Enriched?
| Métadonnées | Source | Value for the investigation |
|---|---|---|
| Flow records (5-tuple, start/end, bytes, packets) | En-têtes de paquets | Aperçu complet des activités |
| Requêtes et réponses DNS | DNS non chiffré | Services and domains used |
| TLS SNI, ALPN, JA4 / JA4S fingerprints (note the FoxIO licence terms for JA4S) | TLS / QUIC handshakes | Identification des applications et des appareils |
| Classification des applications | DPI signatures and behaviour | Messagerie instantanée, VoIP, streaming, VPN, Tor |
| Type d'activité | Packet size and timing patterns | Message vs call vs file transfer |
| VoIP signalling (SIP, RTP parameters) | VoIP non chiffrée | Third-party VoIP calls with participants and duration |
| Hôte HTTP et agent utilisateur | HTTP non chiffré | Services et logiciels clients |
| Mappage NAT | Fichiers journaux CGNAT | Link between public IP and port and the target |
| Location and device | Identifiant de la cellule, IMEI, ligne d'accès | Où et sur quel appareil une activité a eu lieu |
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”. In practice, three models are used:
- Enregistrements IRI supplémentaires: extracted events (for example a detected VoIP call or an application session) are sent via HI2, using standard fields where possible and national or agreed extensions where necessary.
- A separate analytics stream: structured records (for example IPFIX-like flow records or JSON) are delivered over a secured channel, clearly labelled and correlated with the LIID and the CC.
- Enregistrements relatifs aux niveaux de service: 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
- Enregistrez le Moteur DPI et version de la signature used for every result.
- Utilisation synchronised, high-precision timestamps so that metadata aligns with the CC and HI2 records.
- Fournir indicateurs de confiance for behavioural classifications.
- Conservez un piste d'audit complète of target activation, configuration changes and deliveries.
- Test regularly with trafic de référence to detect regressions after signature updates.
Implementation Checklist for Providers
- Legal assessment: what the national framework allows, and what the orders typically cover
- Enrichment scope and delivery format agreed with the agencies and included 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 a plus de 20 ans d'expérience dans les télécommunications, l'interception légale et la conformité et contient plusieurs agréments de la BNetzA. We integrate network elements via X1/X2/X3 and operate mediation for providers today, so we know both the network and the receiving side.
- Architecture et conception technico-juridique of provider-side DPI (see DPI pour les opérateurs de réseau) 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.
- Intégration X3 with BNG/BRAS and core routers from Huawei, Cisco, Juniper and other leading vendors, plus passive probes or cloud mirroring where X3 is not available.
- Médiation et transfert à l'ETSI through our Plate-forme de médiation LI et LIMS.
- Opérations gérées around the clock. See Gestion des opérations LI.
- Développement sur mesure of extractors, classifiers and delivery formats. See Intégration et développement sur mesure.
Get in touch with ICS to discuss whether provider-side enrichment makes sense for your network.
Questions fréquemment posées
Is deep packet inspection allowed for lawful interception?
Yes, when it is limited to the traffic of the ordered target, serves the purpose of the interception order and is covered by the national technical specifications and the provider’s accepted concept. Untargeted or commercial use of LI data is not 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?
Typically as additional IRI records via HI2, or as a separate, secured analytics stream correlated with the LIID. 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 it can add network context such as subscriber identity, NAT mappings and location, and deliver results in near real time.
Articles connexes
- Comment fonctionne une fonction de médiation : Le pont entre votre réseau et les forces de l'ordre
- DNS crypté (DoH/DoT) et son impact sur les capacités d'interception légale
- Le « network slicing » dans la 5G en mode autonome : en quoi cela complique (et peut simplifier) le ciblage LI
- Enquête criminelle assistée par l'IA : ce que l'automatisation implique pour les opérateurs et les processus opérationnels des forces de l'ordre
