Starting with nDPI 4.10, we have introduced a new feature called First Packet Classification (FPC). Goal of this technique is to address one problem of DPI that detects a protocol only when traffic has been dissected. This means that for TLS you need a few packets (usually between 5 and 10) for protocol dissection, as nDPI has to wait until TLS handshake packets are exchanged. This can be a problem in particular when DPI is used with inline traffic (e.g. on a IPS) as the decision about the application protocol cannot be taken at the first packet, hence some non-legitimate traffic (i.e. the first few flow packets until DPI is completed) can flow instead of being blocked.
The idea of FPC is to detect a protocol at the first packet so that we can reduce the workload on nDPI and address the above issue. As of today FPC is an ongoing development and we plan to extend it in the coming months. Currently it supports three modes:
-
NDPI_FPC_CONFIDENCE_DPI
A protocol is detected at the first packet using DPI. This can happen with protocols such as QUIC and SNMP where the first packet is enough fo deciding about a protocol. This typically happens only for UDP traffic as yo can imagine. -
NDPI_FPC_CONFIDENCE_IP
nDPI includes IP address lists about known services (e.g. the list of Facebook IP addresses published by Meta), so once an IP of a flow matches one of these addresses it is detected reliably. -
NDPI_FPC_CONFIDENCE_DNS
nDPI implements an LRU cache feeded by the DNS nDPI dissector. In essence when nDPI detects a DNS request for a host name for which the application protocol is known, this information is stored in the cache. Example, suppose nDPI detected a DNS request for host e12.whatsapp.net that has been resolved to IP address 15.197.206.217. As nDPI matches this host as WhatsApp as it has internally the list of WhatsApp domains, it stores in the cache 15.197.206.217 = WhatsApp. If in the near future nDPI sees traffic for host 15.197.206.217, it labels it as WhatsApp. This is a great hint for nDPI, in particular for TCP-based protocols such as TLS that as discussed earlier would require many more packets before the DPI detection would complete.
As said, this is just the beginning of FPC. In the near future we plan to extend it and add more aggressive caching. However thanks to this feature the nDPI performance has been already enhanced and detection time minimized. For all FPC details start here.
Stay tuned !