ASN Observability details Aviz DPI metadata extraction without payload decryption

ASN Observability’s Aviz Service Node uses deep-packet-inspection metadata to recover application context from both encrypted and unencrypted traffic, without decrypting payloads, while also adding configurable telemetry controls in ONES 4.1. For enterprise IT and security teams, the update focuses on troubleshooting, security visibility, and structured compliance evidence from protocol signals.

Research Overview

The post describes challenges in encryption-first networks where monitoring tools confirm traffic activity but provide limited application-level behavior details. It presents Aviz Service Node as a metadata extraction approach that extends DPI into structured protocol metadata across HTTP, DNS, TLS, QUIC, DHCP, and SIP RTP.

It also outlines ONES 4.1 changes that adjust what telemetry is collected and how host and container health signals are surfaced inside the existing telemetry pipeline. The combination is presented as a way to reduce unnecessary data volume and correlate infrastructure health with network observability workflows.

Key Findings

Aviz Service Node extracts more than 100 metadata fields derived from protocol traffic while preserving encryption boundaries, with exports described as real-time protocol-specific metadata. The post links this approach to faster troubleshooting by isolating whether faults align to DNS, TLS negotiation, HTTP outcomes, or transport anomalies rather than relying on multi-system log correlation.

For security and compliance use cases, the post frames metadata as structured and queryable evidence that avoids exposing payload data. It also describes a shift in security analysis away from signature-only packet inspection toward behavioral analysis based on metadata such as TLS fingerprints and DNS patterns.

Technical Breakdown

On the architecture side, the post states that Aviz Service Node uses modular, event-driven DPI with independent protocol handlers and event callbacks. It describes protocol-aware export logic intended to support rapid onboarding of new protocols and scalability as application ecosystems change.

For metadata coverage, the post lists HTTP signals such as hostnames, URL paths, methods, user agent and inferred client platforms, response status codes and content types, plus server software and custom headers. For DNS, it cites domain names, record types, response codes such as NXDOMAIN, returned IP addresses, TTL values, and unusual query patterns.

For TLS, it describes handshake metadata including SNI and certificate details, TLS versions and cipher suites, JA3 and JA4 client fingerprints, and encryption posture indicators, with stated outcomes including identification of weak ciphers and deprecated TLS versions without payload decryption. For QUIC, it lists connection identifiers, version negotiation, transport parameters and flow control limits, QUIC-adapted client fingerprinting, and performance indicators such as ACK delays.

For voice and video, it describes SIP call IDs for signaling and media correlation along with codec types, sampling rates, channel counts, and RTP packet metrics such as loss, jitter, duplicates, and reordering. It adds DHCP IP assignment correlation elements including client MAC addresses, assigned IPs, lease durations and lifecycle events, and session correlation back to physical devices.

Operational Impact

The post compares traditional packet capture with Aviz DPI metadata observability by stating that encrypted payloads remain a black box in packet capture, while Aviz extracts 100+ metadata fields. It also describes troubleshooting differences, stating that metadata-based observability provides a single pane combining network and application context compared with correlating logs across multiple systems.

In the ONES 4.1 section, the post highlights “Telemetry Preferences” as a way to control which telemetry is collected instead of subscribing to every available telemetry path from devices. It describes ONES Monitoring as automatically tracking host-level health metrics such as CPU, memory, and disk, along with Docker container status, with data published into the existing telemetry pipeline.

The post states that telemetry preference categories include “Platform Default” for hardware and environmental basics, “Feature Protocol” enabled based on in-use features, and “QoS Telemetry” for traffic prioritization and queue behavior that can be enabled or disabled by device role and troubleshooting needs. It describes rule-engine integration for proactive alerting using CPU, memory, and disk utilization thresholds, and it states that turning on only relevant telemetry reduces load on devices and collectors while reducing noise in the collected dataset.

It also describes Telemetry Preferences as working across SONiC, Cumulus, Cisco NX-OS, Arista, and Compute platforms, aiming to provide consistent telemetry control in mixed-vendor environments.

The post’s overall through-line is that application-level observability can be built from protocol metadata extracted via DPI without payload decryption, paired with telemetry controls that narrow collection to what teams need while publishing infrastructure health signals into the same telemetry pipeline. Blog Signals brief is a fact-based summary of the vendor blog.