Deep packet inspection

A classic firewall decides on the packet header: source and destination address, port and protocol. Deep packet inspection reads further. It reassembles the packets of a flow and looks at what they carry, so it can tell which application or protocol is behind the traffic regardless of the port it uses. ITU-T standardized the requirements for DPI in operator networks in Recommendation Y.2770 (2012). The same technique runs today in enterprise gateways, cloud proxies and on devices.

A DPI engine combines three methods. Protocol dissectors parse known protocols and pull out fields: the name in a DNS query, the Host header of plain HTTP, the server name in a TLS handshake. Signatures match byte patterns typical of an application. For traffic that cannot be read, statistical and behavioral features of the flow (packet sizes, timing, handshake parameters) suggest what it is. nDPI, an open LGPLv3 library maintained by ntop, is a common building block: its maintainers list more than 450 detected Layer-7 protocols, and it extracts metadata from encrypted communications for encrypted traffic analysis.

Encryption keeps shrinking what DPI can see without decrypting. In TLS 1.3 (RFC 8446) all handshake messages after the ServerHello are encrypted, including the server certificate, which TLS 1.2 sent in the clear. The server name indication in the ClientHello stayed visible, and many classifiers rely on it. Encrypted Client Hello (ECH), published as RFC 9849 in March 2026, encrypts the ClientHello under the server's public key and protects the server name and the ALPN list. DNS over HTTPS (DoH, RFC 8484) moves name lookups into ordinary HTTPS traffic, so DNS-based detection also loses its input. Without decryption, a network DPI box increasingly sees an IP address, flow behavior and little else.

On a device the situation is different, because the operating system knows which app opened each connection before any byte is encrypted. On stock Android an app can inspect traffic only through VpnService, which creates a virtual network interface and hands the app every outgoing packet. The platform limits this: the user must approve the first VPN connection, unless a device owner or profile owner configures an always-on VPN; only one VPN can run at a time; and a system notification stays visible while it runs. A custom Android build can place inspection inside the system instead.

In practice DPI is a policy engine with a classifier in front of it, and most of the work goes into the policy, its updates and its behavior when classification fails. Requirements for any system that inspects or filters device traffic:

• Decide where inspection runs: in the network, in a cloud proxy, in an app on the device or inside the operating system. Each place sees different data and fails differently (see the table).
• Policy is versioned data per organization and device group: blocked protocols, applications, domains, URL keywords and patterns. Devices sync it from the backend and report which version they apply.
• Define the behavior before classification completes and for traffic the engine cannot identify. Fail-open lets unknown traffic pass; fail-closed breaks apps when a new protocol appears. Choose per policy, and say so in the admin panel.
• A blocked connection fails fast with a clear error, so apps do not hang on timeouts and users can tell a blocked site from a broken network.
• The detection library is a dependency with its own update cycle. Protocols change, so signatures and dissectors ship with system updates, and the build targets the device CPU, often ARM.
• Plan for less visibility. TLS 1.3, Encrypted Client Hello and DNS over HTTPS remove fields that older rules depend on. Decrypting TLS on a device means installing your own root certificate, which is a security and legal decision of its own, and apps that pin certificates will break.
• Logs of inspected traffic are personal data when they tie a person to sites and apps. Under the GDPR, Regulation (EU) 2016/679, the system needs a defined purpose, a retention period and access control for those logs.
• Measure CPU, memory and battery on the target hardware with real traffic before rollout.

ITU-T Y.2770 (2012) sets out requirements for DPI in next-generation networks; it is a reference for operator equipment, not a legal duty. The protocols that limit DPI are IETF standards: TLS 1.3 in RFC 8446, Encrypted Client Hello in RFC 9849 and DNS over HTTPS in RFC 8484. In the EU, traffic records linked to a user fall under the GDPR, so inspection of employees' devices needs a legal basis, information for the people concerned and a retention rule. Check the employment and telecommunications rules of each country where the devices are used.

In the Raw Control OS project, packet inspection ran inside the operating system. The first layer, built from 2020, was a link classifier: the system synced keywords, rules and addresses from the backend, rejected a connection when the address contained a keyword, matched a listed address or matched a regular expression, and returned the error EHOSTUNREACH so apps failed at once.

In April 2021 we compiled nDPI for ARM and integrated its API into the operating system. DNS detection followed in May and URL extraction in June. In August and September 2021 we added blocking of protocols and applications recognized by nDPI: an administrator selects them for a company or a group in the panel, the backend exposes the settings to the phones, and Android blocks the matching traffic.