ChamaleoNet: Passive Probe for Traffic Visibility

• ChamaleoNet is a passive probe that targets erroneous network packets, capturing misconfigured, malformed, and unsolicited flows.
• It leverages an SDN architecture with P4-enabled switches and a centralized Flow-State Detection NF to filter and classify only the initial packets of suspicious flows.
• Lab and campus tests show 96% hardware filtering efficiency and scalable performance while ensuring privacy via data minimization and anonymization.

Searching arXiv for the specified papers to ground the article and verify metadata. ChamaleoNet is a programmable passive probe for traffic visibility that transforms a production network into a transparent monitor for unsolicited and erroneous packets, including unanswered traffic, malformed packets, ICMP “destination unreachable” messages, and requests directed to hosts that may be offline or active, hosting a server or a client, protected by a firewall, or assigned to unused addresses. It is programmed to ignore well-formed traffic and to collect only erroneous packets, including those generated by misconfigured or infected internal hosts and those sent by external actors scanning for services. The system leverages the SDN paradigm, is designed to lower pressure on the collection system while respecting privacy regulations by design, and can integrate with active deceptive systems such as honeypots (Wang et al., 17 Aug 2025).

1. Conceptual scope and monitoring objective

ChamaleoNet targets what the source describes as the network’s “dark corners” of erroneous traffic: unanswered TCP SYNs, half-open traffic, malformed packets, ICMP errors, and requests toward offline or firewalled hosts. The motivating premise is that such traffic carries early clues of misconfigured internal systems, temporary failures such as servers down or routing blackholes, and external scanners or early-stage attackers. Its monitoring goal is therefore sharply delimited: ignore the bulk of benign, well-formed flows; log all initial packets of “suspicious” flows that go unanswered or produce errors; and allow optional active engagement in honeypot style (Wang et al., 17 Aug 2025).

This positioning differentiates ChamaleoNet from three monitoring families explicitly named in the source. NetFlow and IPFIX summarize well-formed flows; classic telescopes focus only on darknets; and IDPSes trigger only on known malicious patterns. ChamaleoNet is presented instead as a passive probe for unsolicited and erroneous packets that would normally be ignored by those mechanisms. This suggests that it is intended as a complement to existing operational telemetry rather than a replacement for flow-based monitoring, darknet observation, or signature-driven detection.

A common misconception is that visibility on unsolicited traffic requires dedicated unused address space. ChamaleoNet is defined against that assumption: it observes traffic directed to hosts whether they are offline or active, whether they host a server or a client, whether they are protected by a firewall, and whether the address is unused. That broader scope is central to its claim of turning “any live network” into a focused monitor.

2. SDN architecture and control structure

At the architectural core, ChamaleoNet uses an SDN-capable switch programmable in P4 and a centralized SDN controller running a lightweight user-space network function named the Flow-State Detection NF, or FSD-NF. The deployment is out-of-path, via SPAN or mirrored traffic. Within the switch, the data plane contains a Service-Level Filter implemented as a static whitelist of known benign $\{dstIP, dstPort\}$ pairs, a Flow-Level Filter implemented through dynamic 5-tuple rules installed or removed by the controller, and a mirror path that forwards only “missed” packets to the controller. The controller side combines the FSD-NF and a control-plane thread (Wang et al., 17 Aug 2025).

The FSD-NF classifies “suspicious” packets, buffers the first packet of each new 5-tuple flow, waits for a DeTection timeout $DT$ or for a response, marks the flow benign when a response is seen, installs a drop rule in the switch for such benign flows, and forwards buffered packets to collectors when the timeout expires without reply. It also tracks host liveness through bitmaps that distinguish incoming traffic from flow-rule hits.

The significance of this division of labor is operational. Well-formed flows are retained in hardware and dropped at the switch, while only the first packet of each new flow and genuine errors are punted to the controller. The source attributes to this design the major reduction in controller pressure and presents the switch as the scalability boundary and the controller as the locus for stateful classification.

3. Packet classification and filtering semantics

ChamaleoNet formalizes erroneous traffic through the set

$$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$

where $p$ is the first packet of any 5-tuple flow that either receives no reply within the DeTection timeout $DT$ or is itself an error, such as an ICMP unreachable or a packet with a malformed header. The source also defines $F_{orig}$ as the rate of all mirrored packets and $F_{filtered}$ as the rate seen by the controller, with a reported reduction ratio of approximately $0.96$ (Wang et al., 17 Aug 2025).

Filtering is split between two rule families. The static per-service whitelist performs exact matches on $\{dstIP, dstPort\}$ for popular CDNs, SaaS, and campus servers and immediately drops those packets. The dynamic per-flow filter installs exact-match 5-tuple entries in both directions when a reply is seen and removes them on flow idle. These rules are expressible in OpenFlow-style tables named “StaticWhitelist,” with match(dstIP, dstPort) → action=DROP, and “DynamicFilter,” with match(srcIP, srcPort, dstIP, dstPort, proto) → action=DROP.

The classification pipeline is deliberately asymmetric. New flows are sampled only at their first packet; replies suppress further controller involvement; non-responses promote the buffered packet into the erroneous set and forward it to collectors. This suggests a design optimized for surfacing failed communication attempts, reconnaissance, and misconfiguration artifacts while suppressing steady-state application traffic.

4. Scalability, performance, privacy, and implementation

In lab replay and in vivo campus tests, ChamaleoNet is reported to achieve hardware-side filtering of benign traffic at approximately $96\%$, with a range of $DT$0–$DT$1 under various loads. Replay tests sustained $DT$2 Gbps and $DT$3 Mpps forwarding to the controller with ten parallel tcpreplay instances. Under synthetic DDoS, the peak FSD-NF insertion rate is reported as approximately $DT$4 k new flows per second before packet loss. Controller per-packet processing latency is reported such that $DT$5 of packets are handled within $DT$6 ms with optimized $DT$7-check parameters. Rule install and delete batching with $DT$8 entries speeds up gRPC calls by about $DT$9, and the rule-idle TTL is approximately $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$0 s. The memory footprint is described as a ring buffer of about $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$1 k descriptors and a hash table of about $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$2 k entries, both tunable for campus scale (Wang et al., 17 Aug 2025).

Privacy is treated as a first-class constraint under a “data minimization” and “honest but curious” model. Payload above L4 is stripped, and only IP headers together with UDP, TCP, or ICMP headers are collected. Internal IP addresses are anonymized on-switch in P4 using

$$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$3

Sensitive flows destined to active services never leave the switch, application-layer data are excluded, and disabling anonymization is possible only for explicitly designated honeypot hosts. The source frames these choices as measures that minimize GDPR and CCPA risks.

The implementation details align with that design emphasis. The switch program consists of about $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$4 lines of P4_16 targeting Intel Tofino under TNA. The controller and NF comprise approximately $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$5 k lines in C/C++, using either libpcap or DPDK for the FSD-NF, together with Python for control-plane logic. Rule installation and deletion use gRPC via the Barefoot Runtime Interface, or BFRt. The open-source release is hosted at https://github.com/zhihao1998/ChamaleoNet, with deployment guide, P4 code, and container images for the NF.

5. Honeypot integration and empirical findings

ChamaleoNet supports optional active deception beyond passive logging. For selected target IPs, when the $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$6 timeout expires the FSD-NF can forward the buffered packet to a responder, such as a TCP three-way handshake completer or a first-payload capturer. For honeypot hosts, $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$7 can be reduced, with $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$8 ms given as an example, to avoid arousing sender suspicion. The responder logs any application-level handshake and then tears down the interaction; nDPI or Zeek can classify the resulting protocol (Wang et al., 17 Aug 2025).

A five-month deployment on a $$E = \{\,p \mid p \text{ is unsolicited or erroneous}\,\},$$9 Gbps campus link with $p$0 k internal addresses and a /23 darknet baseline is reported to reveal substantially more “external radiation” than the telescope baseline: approximately $p$1 more unique source IPs, $p$2 more ASNs, and $p$3 more probed ports per internal host. The reported case studies include IP 5.96.X.X, generating 3 k UDP/123 packets/hour interpreted as NTP-amplification attack attempts; IP 188.92.X.X, associated with ~Satori C-style botnet scanning ports 37215, 52869…; IP 193.X.X.X, producing 1 k ICMP Time Exceeded/hour and indicating an external routing blackhole; IP 94.143.X.X, sending constant UDP→53137 and indicating a misconfigured service; and 38 senders conducting synchronized ICMP Echo scans to about 20 campus clients.

Internal misbehaviors are likewise prominent in the reported observations. ChamaleoNet recorded about 40 k erroneous packets/hour originating from inside the monitored network, including horizontal scanners sending thousands of TCP SYNs to random ports on a few external clouds, vertical scanners repeatedly probing two or three ports and thereby hinting at botnet infections, and DNS anomalies in which campus resolvers issued queries to authoritative servers in Iran and China that never replied, described as likely backscatter from infected clients. Temporal heatmaps and CCDFs of unique senders per host highlighted both “always-dark” addresses and hot servers under intense scanning. The source summarizes these outcomes as evidence that simple analytics can unveil internal misconfigured and infected hosts, identify temporary failures, and enhance visibility on external radiation produced by attackers looking for vulnerable services.

6. Relation to adjacent systems and nomenclature

ChamaleoNet is explicitly situated against three adjacent monitoring models. It is not presented as a flow summarizer such as NetFlow or IPFIX, not as a classic telescope restricted to dark address space, and not as an IDPS limited to known malicious patterns. Its defining property is narrower and more stateful: collect precisely the initial packets of suspicious flows that go unanswered or produce errors, while ignoring well-formed traffic. This suggests a specific observability niche centered on misconfiguration, failure, and reconnaissance rather than comprehensive packet capture or application telemetry (Wang et al., 17 Aug 2025).

A separate nomenclature issue appears in the literature. The record for “Chameleon: A Reconstruction package for a KM3NeT detector” describes a SeaTray-integrated reconstruction framework and identifies it in the provided material as “Chameleon (a.k.a. ChamaleoNet).” That system consists of a PatternRecognition chain and a Fitter chain, uses Minuit2 minimization, and targets detector event reconstruction rather than network monitoring. Its reported metrics include a median angular error of 0.12° after requiring ≥10 OMs in the final track and a fake fraction below 1% across the full energy range with the same cut (Lenis et al., 2012).

The two usages are therefore technically unrelated despite the lexical proximity. In current networking literature, ChamaleoNet denotes the SDN-based passive probe for erroneous traffic visibility; in the KM3NeT context, the near-homonymous Chameleon denotes a reconstruction package for muon-track fitting. Distinguishing these usages is important for bibliographic precision and for avoiding cross-domain ambiguity.