#  Peregrine: ML-based Malicious Traffic Detection for Terabit Networks

João Romeiras Amado  Francisco Pereira  David Pissarra
Salvatore Signorello  Miguel Correia  Fernando M. V. Ramos
INESC-ID, Instituto Superior Técnico, Universidade de Lisboa  Telefonica
Research

###### Abstract.

Malicious traffic detectors leveraging machine learning (ML), namely those
incorporating deep learning techniques, exhibit impressive detection
capabilities across multiple attacks. However, their effectiveness becomes
compromised when deployed in networks handling Terabit-speed traffic. In
practice, these systems require substantial traffic sampling to reconcile the
high data plane packet rates with the comparatively slower processing speeds
of ML detection. As sampling significantly reduces traffic observability, it
fundamentally undermines their detection capability.

We present Peregrine, an ML-based malicious traffic detector for Terabit
networks. The key idea is to run the detection process partially in the
network data plane. Specifically, we offload the detector’s ML feature
computation to a commodity switch. The Peregrine switch processes a diversity
of features per-packet, at Tbps line rates—three orders of magnitude higher
than the fastest detector—to feed the ML-based component in the control plane.
Our offloading approach presents a distinct advantage. While, in practice,
current systems sample raw traffic, in Peregrine sampling occurs after feature
computation. This essential trait enables computing features over all traffic,
significantly enhancing detection performance. The Peregrine detector is not
only effective for Terabit networks, but it is also energy- and cost-
efficient. Further, by shifting a compute-heavy component to the switch, it
saves precious CPU cycles and improves detection throughput.

††copyright: none

##  1\. Introduction

Network operators deploy Network Intrusion Detection Systems (NIDS) that
capture and analyze packet flows to identify malicious traffic. The ideal NIDS
should fulfil three requirements: (R1) Observe and analyze all network traffic
at high speed (ideally Tbps), and (R2) detect any attack (R3) without
generating false positives111A false positive occurs when regular traffic is
(wrongly) perceived as an attack.. Traditional signature or rule-based NIDS
offer a good performance/accuracy trade-off and are, therefore, widely
deployed. These systems use signature profiles (paxson1999bro, ;
roesch1999snort, ) to detect network attacks. As a result, they detect attacks
quickly with low false positives (R3). Regarding performance, modern NIDSs are
already capable of securing multi-Gbps networks. The state-of-the-art,
Pigasus, achieves 100Gbps on a single server (pigasus, ) (R1).

Figure 1. Detection performance (Area-Under-the-Curve) of a representative
malicious traffic detector (mirsky2018kitsune, ) on attacks from two datasets
(mirsky2018kitsune, ; sharafaldin2018toward, ), across traffic sampling rates.
Current detectors are ineffective under realistic sampling rates.

(a) State-of-the-art malicious traffic detector (b) Peregrine

Figure 2. State-of-the-art vs. Peregrine.

This category of NIDS presents two limitations. First, as they need to scan
packet payloads for attack signatures, they are ineffective when payloads are
encrypted, which is the norm today (cisco-whitepaper, ; nguyen2008survey, ;
barradas2021flowlens, ). Second, they are unable to detect zero-day attacks.
As they depend on a threat signature database, they are ineffective against
unknown attacks (thereby only partially fulfilling R2).

A different category of NIDS can complement these systems to mitigate these
issues. They work on the assumption that the traffic patterns of network
attacks deviate from those of regular traffic, an assumption that often holds
(phishingHo2019, ; FeatureSmithZhu2016, ; disinfoHounsel2020, ;
mirsky2018kitsune, ; whisperFu2021, ; buczak2016survey, ;
chaabouni2019network, ). These solutions aim to spot these deviations and, as
a result, can detect unknown attacks for which there is no defined signature
(R2). The most promising solutions of this class leverage machine learning
algorithms (buczak2016survey, ; chaabouni2019network, ) to learn the traffic
profiles of regular traffic, aiming to identify statistical variations. Recent
advances in ML, and Deep Learning in particular, have led to promising results
for this sort of detection in several domains (phishingHo2019, ;
FeatureSmithZhu2016, ; disinfoHounsel2020, ; mirsky2018kitsune, ;
whisperFu2021, ) (R3). They can thus augment traditional NIDS detection
(augmentCensorBrown2023, ) by discovering new attack instances missed by rule-
based methods, assisting in deploying new signatures.

Problem. These ML-based malicious traffic detection systems face a performance
challenge. The processing overhead of machine learning algorithms, including
running the model and computing the features that feed it, imposes a severe
performance tax. As a result, many run offline (NazcaInvernizzi2014, ;
WebWitnessNelms2015, ; invariantBartos2016, ; unlearningDu2019, ). Recent
solutions propose new mechanisms for online detection (mirsky2018kitsune, ;
whisperFu2021, ), but their throughputs are at least one order of magnitude
lower when compared to traditional rule-based NIDS (R1).

As a result, when deployed in a Terabit network (singh2015jupiter, ;
poutievski2022jupiter, ), these detectors demand significant traffic sampling
to align their processing capabilities (a few Gbps at best) to the data plane
packet rates (Tbps scales). Figure 1 illustrates its consequence. The
detection performance of a state-of-the-art malicious traffic detector
(mirsky2018kitsune, ) across different attacks, albeit excellent without
sampling, sharply declines with sampling, rendering the detector ineffective:
AUC222The Area Under the Receiver Operating Characteristic curve (AUC) is a
metric used to evaluate the performance of binary classification models,
valuable as it summarizes their overall performance and discrimination ability
considering different configuration/threshold values. values below 0.5
indicate a performance worse than a detector that classifies traffic randomly!
The required sampling reduces the detector’s visibility over network traffic,
breaking its detection capabilities. We emphasize that this result should
generalize to any server-based middlebox detector. As its processing
capabilities are fundamentally limited by the host/NIC architecture and its
network stacks (nanoPU_Ibanez2021, ), we anticipate any current and near-
future middlebox-based detector to face the same limitation.

Peregrine. To address this problem, in this paper, we present Peregrine, an
ML-based malicious traffic detector that aims to be effective in Terabit
networks. Figure 2 presents an overview of the system. In contrast with
current ML-based detectors, which run entirely in a middlebox server, ours is
a cross-platform approach that integrates a commodity network switch
(bosshart2013forwarding, ; intelTofinos, ). The key insight (and challenge) is
to offload feature computation to the switch data plane. This design presents
three key advantages. First, the features that feed the ML detector are
computed per packet, for all packets, scaling to Tbps speeds (R1). The ability
to compute multiple network features of different types over all network
traffic is the crucial ingredient for high detection performance
(mirsky2018kitsune, ). Second, as the ML inference component runs in the
middlebox server, we can leverage the best-of-breed ML-based detection
technology (R2, R3). Recent attempts to run ML in network switches severely
restrict the ML model (xiong2019switches, ; busse2019pforest, ) and are thus
insufficient for this task. As a server cannot keep up with the switch packet
processing rates, its execution is not per-packet—it is per-epoch. At the end
of each epoch, a features record is sent to the server with all computed
features to trigger ML-based detection—the downsampling required to reconcile
the traffic rates of the switch and the server. The critical observation here
is that this downsampling is performed after computing the features (that
summarize all traffic), while existing systems sample raw packets, hence have
only a partial view of the traffic. Third, offloading the feature computation
to a network switch is a cost- and energy-efficient solution compared to an
alternative scaling approach that uses multiple detection servers (as we show
in Section 5.7).

The main challenges entailed in developing Peregrine are rooted in the switch
data plane’s computational constraints and hardware intricacies (Section 2).
Its limited resources, including constrained memory (size and access),
simplified match-action mechanisms, and availability of only basic arithmetic
and logical operations, present significant obstacles to implementing the
complex computations required for malicious traffic detection. Determining the
placement of functionality within the switch’s data plane while maintaining
the correctness of the computations involved is another challenge, especially
given the complexity of the calculations typically involved.

We designed and implemented Peregrine targeting a commodity switch
(intelTofinos, ) (Section 3 and Section 4). We make the Peregrine prototype,
including its two versions of the data plane implementation (for Intel Tofino
1 and 2), available at (peregrine, ). The switch processes close to one
hundred features for different flow types, including number of packets, mean
packet size, standard deviation, and several features that cross-correlate
inbound and outbound traffic.

System | Zero-days | Tbps networks | Generic
---|---|---|---
Snort (roesch1999snort, ) | $\mathbb{X}$ | $\mathbb{X}$ | ✓
Bro (paxson1999bro, ) | $\mathbb{X}$ | $\mathbb{X}$ | ✓
Pigasus (pigasus, ) | $\mathbb{X}$ | $\mathbb{X}$ | ✓
Jaqen (liu2021jaqen, ) | $\mathbb{X}$ | ✓ | $\mathbb{X}$
Poseidon (zhang2020poseidon, ) | $\mathbb{X}$ | ✓ | $\mathbb{X}$
ACC-Turbo (alcoz2022aggregate, ) | $\mathbb{X}$ | ✓ | $\mathbb{X}$
Invariant (invariantBartos2016, ) | ✓ | $\mathbb{X}$ | $\mathbb{X}$
Kitsune (mirsky2018kitsune, ) | ✓ | $\mathbb{X}$ | ✓
Whisper (whisperFu2021, ) | ✓ | $\mathbb{X}$ | ✓
ENIDrift (wang2022enidrift, ) | ✓ | $\mathbb{X}$ | ✓
Peregrine | ✓ | ✓ | ✓
|  |  |
Table 1. Malicious traffic detection systems.

Our evaluation (Section 5) on two datasets incorporating 15 attacks
demonstrates the effectiveness of Peregrine as a malicious traffic detector
for Terabit networks. The detection performance was consistently high (AUC ¿
0.8) for the vast majority of attacks considered (13/15), both with and
without sampling. As a comparison point, our baseline (a state-of-the-art
detector (mirsky2018kitsune, )) was ineffective (AUC ¡ 0.5) for most attacks
(12/15). Peregrine is also orders of magnitude more cost- and energy-efficient
than a multi-server alternative that performs detection at Terabit traffic
rates. As feature computation represents more than 50% of the overall
processing time for most of the network attacks we evaluated, offloading FC to
the switch also results in more than doubling the detection throughput.

This work does not raise any ethical issues.

##  2\. Background and motivation

In this section, we present the state-of-the-art on malicious traffic
detection. We then motivate in-network feature computation as a new approach
to deploying high-performance detectors for Tbps networks. Finally, we discuss
some key challenges to materialising the Peregrine approach.

###  2.1. Malicious traffic detection

Signature or rule-based NIDSs (roesch1999snort, ; paxson1999bro, ; pigasus, )
are widely deployed in network infrastructures. Unfortunately, they are
usually ineffective against attacks involving encrypted payloads. As they
depend on a threat signature database, they are also unable to detect zero-day
attacks. Even slight variations of a well-known attack can be sufficient to
sidestep detection (buczak2016survey, ; chaabouni2019network, ). Alas,
attackers adapt. They routinely change their behaviours to evade existing
fixed rules. Indeed, the number, variety, and sophistication of network
attacks are in rising crescendo (antonakakis2017understanding, ;
hamza2019detecting, ; csikor2019tuple, ; alcoz2022aggregate, ;
atre2022surgeprotector, ).

Another class of NIDS builds traffic profiles of regular network patterns and
attempts to identify attacks as deviations from that behaviour. These systems
follow the hypothesis that the attacker’s behaviour differs from regular
behaviour. This property allows them to detect known and previously
unidentified attacks. In particular, anomaly-based systems based on learning
approaches, often using ML-based classification pipelines (buczak2016survey, ;
chaabouni2019network, ; mirsky2018kitsune, ; whisperFu2021, ), are able to
identify minor variations in traffic patterns. An additional advantage of
these systems is their ability to learn new attacks continuously without
requiring external updates. One limitation is their system performance, a
topic we will elaborate on in the next section.

A recent class of malicious traffic detectors (liu2021jaqen, ;
zhang2020poseidon, ; alcoz2022aggregate, ) can achieve good detection
performance and Tbps throughput. Like Peregrine, they leverage the in-network
computation possibilities of programmable network switches to scale detection
to very high throughputs. In contrast, they are limited to a specific attack
(DDoS), while we are interested in generic detectors that can detect attacks
of different types and variants. Table 1 presents a high-level summary of
these solutions and how Peregrine differentiates.

###  2.2. Motivation and opportunity

Our motivation to develop Peregrine is threefold. First are the recent
improvements in detection performance achieved by ML-based systems in several
domains (phishingHo2019, ; FeatureSmithZhu2016, ; disinfoHounsel2020, ),
including malicious traffic detection (mirsky2018kitsune, ; whisperFu2021, ;
augmentCensorBrown2023, ). These systems are particularly effective in
reducing the number of false positives (or false alarms), a problem often
considered a key barrier to deployment.

The second motivating factor is the poor system performance of state-of-the-
art detectors. Kitsune (mirsky2018kitsune, ), for instance, is very effective
by employing a network of autoencoders fed with 100+ features. It achieves
per-packet detection but is limited in throughput to less than 150Mbps
(¡4kPPS) (mirsky2018kitsune, ; whisperFu2021, ). The current state-of-the-art
concerning runtime performance, Whisper (whisperFu2021, ), employs frequency
domain and coding techniques using a simpler ML model (clustering). The
Whisper implementation using kernel-bypass mechanisms significantly improves
performance, achieving close to 15 Gbps (around 1MPPS). Still, this
performance is 10x slower than rule-based NIDS (pigasus, ).

As hinted before, these ML-based detectors demand significant traffic sampling
to align their processing capabilities to the data plane packet rates. As a
result, they become ineffective when deployed in a Terabit network
(singh2015jupiter, ; poutievski2022jupiter, ). Figure 1 illustrates this
problem. There, we present the detection performance (measured as the AUC) of
a state-of-the-art malicious traffic detector representative of middlebox-
based detectors (mirsky2018kitsune, ). We illustrate the results for four
attacks from two datasets (mirsky2018kitsune, ; sharafaldin2018toward, )
(detailed in Section 5.2) across different traffic sampling rates. The
detector excels without sampling, with AUC consistently ¿ 0.8. However, with
realistic sampling rates for a network that processes Terabit traffic, its
performance sharply declines, rendering the detector ineffective—we recall
that AUC values below 0.5 indicate performance worse than random chance. The
root cause of the problem, which generalizes to any middlebox-based detector,
is the necessary sampling to address the processing rates mismatch,
fundamentally reducing the detector’s visibility over network traffic.

Our third motivation is also the opportunity: the emergence of commodity
network switch ASICs with programmable data planes that process traffic at
Terabit speeds and enable in-network computing (intelTofinos, ). This hardware
has enabled advanced traffic measurement approaches (yu2013software, ;
liu2016one, ; Sivaraman2017, ; yang2018elastic, ; tang2019mv, ; gao2021stats,
), cross-platform designs (gupta2018sonata, ; synapse, ; flightplan, ;
gallium, ; lyra, ), and in-network, attack-specific protection solutions
(liu2021jaqen, ; zhang2020poseidon, ; alcoz2022aggregate, ), all of which
motivate and inspire Peregrine’s design. We give some background of a
programmable network switch next.

###  2.3. Target Switch Architecture

The targets of our design are programmable switching platforms that can
sustain network traffic at Terabit speeds. At the time of designing our
system, the Protocol Independent Switch Architecture (PISA) (PISA, ) is the
most representative of such a switch architecture. The PISA architecture is
mostly known because it is embodied in Intel’s Tofino chips (intelTofinos, )
that deliver up to 12.8 Tbps throughput. However, architectural blocks of PISA
are also commonplace in other commercially available sibling switch
architectures (e.g., Trident-4 series from Broadcom (TridentSwitch, )).

The PISA switch architecture consists of programmable parser and deparser
blocks, two logical pipelines (ingress and egress) of programmable Match-
Action Units (MAUs) organized in stages, a Traffic Manager, and some buffering
at the end of the logical pipelines. PISA’s stages contain memory (SRAM and
TCAM) to build lookup tables and ALUs to perform operations on packet fields
and metadata. The pipeline stages also hold additional local SRAM memory as
register arrays that allow the storage of information across multiple packets,
enabling stateful processing. These stages typically run at a fixed clock
cycle and permit only basic arithmetic and logical operations, to guarantee
deterministic packet processing latency per stage and to achieve Tpbs
throughput. Intel Tofino switches have 2 or 4 of such pipelines working in
parallel to increase the aggregate throughput.

###  2.4. Challenges

Developing a malicious traffic detection solution for networks that process
traffic at Terabit speeds entails several challenges.

Efficiency. One solution to scale a server-based malicious traffic detector to
Terabit networks is a distributed architecture where multiple servers work in
parallel to handle the high traffic volume, avoiding the need for sampling
that breaks detection performance. Each server would be responsible for a
subset of the network traffic, and load-balancing mechanisms could help
distribute traffic evenly among the servers. As a middlebox detector can
process packets at a few Gbps at best, this solution would require 100+
servers to handle Terabit traffic. Such a distributed approach is very costly,
both monetary and power consumption-wise. Our solution proposes partially
offloading this task to programmable switches—highly efficient packet
processors (cost and energy-wise)—with the potential to reduce costs
dramatically (see Section 5.7). However, this cross-platform design creates
its own challenges.

Division of functionality. The first is determining a good division of
functionality for offloading the components of a malicious traffic detector to
a network switch’s data plane. The question is how to effectively distribute
the various functions of a detector (packet processing, feature computation,
ML inference) between the middlebox server and the programmable network
switch. Recognizing the inherent limitations of the switch, particularly its
inability to accommodate ML inference, we strategically opted to offload only
the packet processing and feature computation modules.

Computational constraints of the switch data plane. The increased
sophistication of network attacks requires capturing a wide variety of rich
statistics to serve as input to the detection system (mirsky2018kitsune, ).
The challenge lies in maintaining a comprehensive set of counters and
computing intricate statistics within the computational constraints of a
programmable network switch’s data plane333We invite the reader to peek at
Table 2 to check the sort of statistics involved.. A switch pipeline has a
limited number of match-action stages, limited memory, limited access to
stateful memory (e.g., a single read/modify/write operation), and limited
arithmetic and logical operations, presenting significant obstacles to the
implementation of the complex statistical computations required for malicious
traffic detection. The solution is to develop approximate algorithms and
computations and explore the trade-offs between practicality and detection
performance.

Pipeline placement. Another related challenge is determining the placement of
the feature computation functionality within the switch’s data plane. First,
the feature computation module must fit the restrictive computation model of
the switch data plane ASIC. In addition, we need to preserve its semantics
(e.g., concerning dependencies) while considering the constraints imposed by
the switch’s architecture. This can be especially challenging, considering the
complexity of statistics calculations.

##  3\. System Design

In this section, we present the overall design of Peregrine and describe its
architectural elements in detail. We start with a discussion around its
rationale and design principles in Section 3.1. Then, we present a high level
overview of Peregrine and its main system components in Section 3.2. Finally,
we describe each of the data plane (Section 3.3) and control plane (Section
3.4) components of Peregrine in greater detail.

###  3.1. Design rationale and guiding principles

To understand the rationale of our design, we invite the reader to consider
the high-level architecture of an ML-based NIDS (Figure 2(a)). Its pipeline is
divided into three main components: packet parsing and processing, feature
computation, and ML inference. Our starting point is to decouple each of these
elements to help us reason about the division of functionality, the complexity
of each computation, and uncover potential bottlenecks.

Packet Processing (PP) is the sort of task at which a packet switch ASIC
excels (bosshart2013forwarding, ; intelTofinos, ), so offloading this
component to the switch is in most cases straightforward.

Feature Computation (FC) in ML-based detectors typically consists of the
extraction and computation of flow- and packet-level statistics of varying
levels of complexity, including packet length, header fields, and a variety of
flow-based statistics (e.g., mean packet size). We observe that these
computations can often be performed in a streaming fashion, per-packet—much
aligned with the computational model of a switch pipeline. The main challenge
is to fit them into the restricted computation environment offered by a
programmable switch.

ML-based Detection (MD), on the other hand, involves ML inference, for which
current VLIW-based switch architectures are particularly inefficient
(taurus_Swammy2022, ). Recent attempts to run ML in network switches either
severely restrict the ML model (xiong2019switches, ; busse2019pforest, ) or
require an entirely new switch architecture (taurus_Swammy2022, ). It is
unclear if future switches will include the per-packet ML primitives proposed
in (taurus_Swammy2022, ), as required by malicious traffic detectors.

Design principles. Inspired by design patterns followed for other problem
domains (gupta2018sonata, ; synapse, ; flightplan, ; gallium, ; lyra, ),
Peregrine follows a cross-platform approach including middlebox servers and
network switches to scale detection to Tbps speeds. This requires the
consideration of the different programmability/performance trade-offs of each
platform and it is achieved by identifying the right division of labor,
previously identified, across those platforms. Our cross-platform approach
allowed us to derive two design principles that are crucial for scaling
detection to Terabit speeds.

#1 Per-packet feature computation in the data plane of a network switch. The
stages of a PISA packet processing pipeline may perform several basic
arithmetic operations per packet and store packet counters in stateful memory.
These simpler computational and memory blocks (we name those feature atoms)
can be engineered to compute more complex quantities with each incoming
packet. Despite the limited amount of persistent memory available in stages,
storing and updating the right few counters early in a PISA pipeline
translates into the ability to extract statistical values for different flow
types through the remaining stages of the pipeline. These observations enable
computing a wide range of flow statistics and to derive a sufficient number of
features for ML inference, per-packet, as each incoming packet traverses the
pipeline.

#2 Features records for ML detection in a middlebox server. The ML inference
component is executed at the control plane level, and as such is unable to
sustain the per-packet Tbps processing rates of a PISA switch data plane. To
overcome this difference, downsampling is required, and ML inference is
performed on a per-epoch basis. This epoch configuration value can be changed
in the data plane, effectively defining the sampling granularity at which the
computed features are sent to the ML component, but the feature computation
operations are always executed per-packet in the data plane. We can describe
this as a form of enriched record sampling, since it enriches the feature
summaries (alias records) that serve as input to the inference model.

Figure 3. Downsampling for malicious traffic detection.

Why it should work. As explained before, network traffic needs to be (heavily)
sampled to meet the capabilities of existing server-based NIDS, as they are
limited to a few Gbps packet processing at best (mirsky2018kitsune, ;
whisperFu2021, ). Our intuition is that by computing in-network the ML
features over all network traffic, even with approximate computations, we can
improve detection performance. As our features consider all traffic, they are
richer than the traditional traffic samples. As the ML-based detector runs in
a server, we still need to downsample its input traffic to the rates it is
able to process. The key point is, however, that this sampling is performed
after the FC module has already computed the ML features considering all
traffic, not before. This idea is depicted in Figure 3.

###  3.2. System overview

A high-level Peregrine overview is presented in Figure 2(b).

The system data plane is composed of the following components:

Packet Processing: Parses each raw packet that arrives at the switch,
obtaining the data necessary for the subsequent feature computation step as a
packet header vector (PHV).

Feature Computation: From the PHV, it updates flow counters pertaining to each
of the tracked flow keys (i.e., feature atoms) and calculates the respective
traffic statistics.

At the control plane, the collected statistics (i.e., features records)
forwarded by the data plane through ad-hoc packets are processed by the ML-
based detection module running in the middlebox server.

The Peregrine high-level workflow comprises of the following steps:

  1. (1)

As packets traverse the network, the switch processing pipeline performs
packet processing and feature computation at line-rate.

  2. (2)

Every x packets (corresponding to a configurable epoch value), the data plane
proactively sends a features record to the middlebox server encapsulated into
a custom packet.

  3. (3)

The server retrieves the input vector for classification from the features
record and sends it through the ML detection module, outputting a
classification result.

###  3.3. Feature Computation in the Data Plane

Figure 4. Feature computation in the data plane: main operations per-packet
and per-epoch.

A high-level breakdown of Peregrine’s packet processing pipeline is presented
in Figure 4 (Appendix A presents a more detailed view). The initial stages of
the pipeline are used to update the feature atoms \- building blocks used in
later calculations, stored in stateful memory - by applying a certain decay
factor. In subsequent stages, the feature atoms are used as input to the
statistics computation part. The respective output of any stage is carried
across the pipeline using packet metadata. Feature computation is performed
per-packet, effectively monitoring all network traffic at line-rate. At the
end of some configured epoch time, a custom network packet carrying the
computed features is forwarded to a middlebox server.

Feature Atoms. To compute flow statistics incrementally (e.g., the standard
deviation of the packet size), Peregrine’s data plane updates and stores flow
counters called feature atoms. Namely, Peregrine defines three types of
feature atoms: number of packets (w), linear sum of the number of bytes (LS),
squared sum of the number of bytes (SS). Feature atoms are incremented per
packet.

Decay Factor. To give higher weight to recent observations, Peregrine’s data
plane exponentially decreases the weight of the older measurement values over
time. We achieve this by applying a decay function $\delta$:

(1) $\delta=2^{-\lambda t}$

where $\lambda>0$ is the decay factor, and $t$ is the time elapsed since the
last observation. This function is applied to each feature atom before
updating it for the current packet (e.g., $LS_{i+1}=x_{pkt}+\delta*LS_{i}$,
where $x_{pkt}$ represents the current packet size). The packet inter-arrival
times of the monitored flows are used to determine a specific decay factor.
The rationale is that identifying specific attack patterns depends not only on
the statistical, but also on the temporal traffic characteristics for the
observed flow keys (mirsky2018kitsune, ; arp2022and, ).

Statistics computation. Table 2 presents the statistics that are calculated by
Peregrine’s packet processing pipeline. There are two types of statistics: (1)
unidirectional, tracking the outbound traffic (i.e., flow direction i → j), or
(2) bidirectional, considering both outbound and inbound traffic (i.e., flow
directions i → j and j → i). The latter are restricted regarding associated
flow keys, as they pertain to network channels (e.g., a possible flow key for
bidirectional statistics is the [5-tuple]). Due to the restricted instruction
set of the target switching platform, Peregrine resorts to several
approximations to perform some of the arithmetic operations (e.g.,
multiplications and divisions) required to compute all per-flow statistics
listed in the table. We detail this in Section 4.

Table 2. Statistics calculated in the data plane.

Statistics | Notation | Calculation
---|---|---
Weight | $w$ | $w$
Mean | $\mu$ | $\frac{LS}{w}$
Std. Deviation | $\sigma_{S_{i}}$ | $\sqrt{\mid\frac{SS}{w}-(\frac{LS}{w})^{2}\mid}$
Magnitude* | $\mid\mid S_{i},S_{j}\mid\mid$ | $\sqrt{\mu^{2}_{S_{i}}+\mu^{2}_{S_{j}}}$
Radius* | $R_{S_{i},S_{j}}$ | $\sqrt{(\sigma^{2}_{S_{i}})^{2}+(\sigma^{2}_{S_{j}})^{2}}$
Approx. Covariance* | $Cov_{S_{i},S{j}}$ | $\frac{SR_{ij}}{w_{i}+w_{j}}$
Pearson Corr. Coeff.* | $PCC_{S_{i},S_{j}}$ | $\frac{Cov_{S_{i},S_{j}}}{\sigma_{S_{i}}\sigma_{S_{j}}}$

* Bidirectional statistics.
LS = linear sum of the packet sizes
SS = squared sum of the packet sizes
$SR_{ij}$ = sum of residual products ($Res_{i}$, $Res_{j}$) for streams $i$
and $j$

Configuration. Peregrine’s features rely on an initial configuration of the
data plane program which is offered at compile time. Peregrine’s data plane
can compute feature atoms and statistics for multiple flow keys (e.g., [MAC
src, IP src], [IP src], [IP src, IP dst], [5-tuple]) for generality, or, its
resource usage can be fine-tuned to monitor only a subset of those flow keys
and to reduce their associated switch’s stateful memory. Besides, Peregrine
allows an operator to specify a desired epoch value. An epoch value defines a
certain record sampling rate—a rate of 1:1024 means that a features record is
produced and sent to the middlebox server for analysis once every 1024
packets.

###  3.4. ML-based Detection

Peregrine’s detection stage is performed on a middlebox server where its ML-
based classification pipeline is executed. The server expects features records
carrying the flow statistics computed in the switch data plane. Whenever a
record arrives, the server first updates its locally stored features, and then
it feeds them as input to the ML model used for malicious traffic detection.

Peregrine uses Kitsune’s KitNET neural network (mirsky2018kitsune, ) as a
detector for its ML-based classification pipeline. KitNET implements an
artificial neural network trained to reconstruct an original input from a
learned distribution, through two layers of autoencoders. The number of inputs
per autoencoder can be tuned through an input parameter. A Feature Mapper
component maps sets of features into k smaller sub-instances, one for each
autoencoder in the first layer of KitNET. The difference between the feature
vector x passed as input to the network of autoencoders and its output
instance y is measured using the Root Mean Squared Error (RMSE) metric. Input
instances that differ significantly from the learned distribution will result
in high reconstruction errors.

It should also be noted, however, that by design the data-plane functionality
of Peregrine is not tied to any specific ML-based classification pipeline.
Rather, the features computed in the data plane can be used as input for
different learning-based detection systems.

##  4\. Implementation

Peregrine’s implementation consists of a few thousand LoC in P4 for the data
plane, and a few thousand LoC in C++ for the control plane software in the
middlebox server. The switch data plane runs a P4 program that implements
Peregrine’s packet processing and feature computation modules. A C++ module
runs on a general purpose server to process features records and feed them to
the active ML-based detection module. The ML-based detection module tested
with our prototype is written in Python and leverages KitNET
(mirsky2018kitsune, ). We make the P4 implementation openly available at
(peregrine, ).

As described in Section 2.3, PISA-like switch architectures enforce a severely
constrained programming environment to achieve Tbps networking speed and
guarantee per-stage deterministic packet processing latency in the order of a
few nanoseconds. To conform to the physical constraints of the target switch
platform, the implementation of the data plane operations for traffic feature
computation presented in Section 3.3 resort to approximations and other
intricate mechanisms we describe next.

Switch Platform. The data plane implementation of Peregrine targets the Tofino
Native Architecture (TNA) (tna, ), a realization of a PISA architecture for
the Intel Tofino switching chip. This architecture encompasses two generations
of switching ASICs, Tofino 1 (TNA) and Tofino 2 (T2NA). Their main difference
is that the latter roughly doubles the network performance and programmable
resources available on the switches. We implemented two versions of the
Peregrine prototype, one for each architecture.

Approximating Arithmetic. Peregrine’s feature atoms and statistics computation
require arithmetic operations that are not natively supported by the basic
ALUs present in the PISA’s pipeline stages (i.e., multiplication and division,
square and square root). Our implementation resorts to several approximation
techniques to realize these operations. The first technique approximates
multiplication and division through bit shift operations, rounding the second
operand (e.g., the divisor) to the nearest upper power-of-two, and then
performing the intended operation (e.g., division) through the logical bit-
shift operation (e.g., a right shift). The rounding action for each specific
input operand is selected through ternary match tables. The second technique
converts the second operand of the target operation (e.g., the division) to a
constant value and leverages Tofino math units, special hardware features of
TNA/T2NA accessible through P4 extern objects, which allow performing the
operation with one operand as a constant value. This technique is used to
apply constant decay values that essentially halve the stored measurements
before the feature atoms are updated. Finally, Peregrine performs
exponentiation and square root operations through the Tofino math units that
provide a low-precision approximation of those mathematical functions.

Figure 5. Handling multiple decay values.

Handling Multiple Decay Factors. Peregrine employs four distinct decay values
on feature atoms before updating them. To achieve this, it stores four
instances of each feature atom, one for each decay value, and compares the
inter-arrival time between packets of the same flow against four different
time intervals (100ms, 1s, 10s, 60s), corresponding to decay factors
$\lambda=(10,1,\frac{1}{10},\frac{1}{60})$ (recall Equation 1). When an inter-
arrival time exceeds a specific interval, Peregrine updates the previous time
value and applies the relative decay before updating the feature atoms.
However, as the switch allows only one register update per packet, it is
impractical to update the four instances of the feature atom with the four
decay values simultaneously. One potential solution would involve replicating
the same feature atom (its four instances) across four stages, yet this
significantly increases resource usage.

Our approach is to compare only one decay value per pipeline execution, and
thus update a single instance of the feature atom, alternating the selected
decay value for each packet (Figure 5). Although this method is not precise,
it effectively handles most scenarios. A specific corner case is when the
inter-arrival time significantly exceeds the considered interval. For example,
if the decay value is 1s and the inter-arrival time of a new packet is 3s, we
need to apply the decay value $\frac{1}{2^{3}}$ (Equation 1 again). Since the
switch cannot perform exponentiation operations, we implement the decay value
iteratively. This involves executing a right bit shift across multiple
packets, gradually reducing the inter-arrival time by the decay value with
each step until the decay process is complete (3 steps in the example). In
essence, we sacrifice exactness for efficiency, adjusting decay application
across packets to manage varying inter-arrival times and constraints within
the network switch architecture.

Figure 6. Tracking bidirectional traffic.

Tracking Bidirectional Traffic. Computing bidirectional statistics (Table 2)
requires correlating pairs of feature atoms for concurrent read/write
operations. Simply storing feature atoms for both flow directions (i → j and j
→ i) in the same register memory (pipeline stage) would render such concurrent
operations unfeasible. This limitation arises because the same register memory
can only be accessed (read/write) once per packet, while we require access to
two registers (one for each flow direction).

Instead, Peregrine duplicates the correlated feature atoms across two pipeline
stages (Figure 6). In the first stage, the feature atom for the corresponding
packet direction (i → j) is updated (write/read) for every packet. Since a
read access to feature atoms on the inverse direction j → i is strictly
required only when calculating bidirectional flow statistics—once per epoch—in
the subsequent stage Peregrine alternates between writing to the current
direction i → j regularly, and reading from the inverse direction j → i only
once per-epoch. Consequently, between epoch changes, the registers at the two
stages are updated exactly the same way. During epoch change, however, while a
regular write/read update is performed in the first stage (allowing reading
the counter from the current direction i → j), in the subsequent stage, a read
from the inverse direction j → i is performed, to retrieve the second value
necessary to compute the bidirectional statistics. The trade-off is that once
per epoch, the feature atom update from the second stage is skipped,
introducing a slight inconsistency between the replicated atoms. This
inconsistency can be resolved by periodically copying the values from the
first stage (which contains the ground truth counters).

Figure 7. AUC across sampling rates. Peregrine is consistently better than a
state-of-the-art detector, Kitsune, for Terabit networks’ sampling rates.
While Kitsune is ineffective in detecting most attacks (13/15), Peregrine is
very effective for the vast majority (14/15).

##  5\. Evaluation

This section aims to empirically evaluate if Peregrine improves system and
detection performance by offloading the feature computation module of a
malicious traffic detector to the network data plane. We evaluate Peregrine
against a state-of-the-art, representative middlebox-based detection system,
Kitsune (mirsky2018kitsune, ). We resort to real datasets with labelled attack
traces for the evaluation. The objectives of our experiments are to assess (1)
whether Peregrine improves detection performance over a middlebox-based
detector, (2) Peregrine’s runtime performance, (3) data plane resource usage,
and (4) efficiency.

###  5.1. Testbed

To evaluate Peregrine’s detection and runtime performance, we built a testbed
composed of a Wedge 100BF-32X Tofino programmable switch and two servers
equipped with a dual-socket Intel Xeon Gold 6226R @ 2.90GHz, 96GB of DRAM, and
Intel E810 100 Gbps NICs. While running the Peregrine data plane, the switch
receives traffic generated from one server, computes the statistics that will
feed the ML inference, and sends features records with configurable
periodicity to the second server, which runs the ML-based detection module.

When measuring detection performance (Section 5.4), we replay attack traces at
the original rate, for fidelity. For runtime performance (Section 5.5), we
rely on a DPDK packet generator (pktgen, ) to replay the evaluation traces at
full 100G link speed, as a stress test.

###  5.2. Datasets

In our evaluation, we leverage attack traces from two sources: (1) the Kitsune
(mirsky2018kitsune, ) evaluation dataset, and (2) the CIC-IDS 2017 and CIC-
IDS-2018 datasets (sharafaldin2018toward, ). These datasets enclose various
labelled attacks occurring within realistic network environments. They are
part of a collection of datasets commonly used to assess intrusion detection
system performance (cic-datasets, ).

We train the ML classifier model with benign traffic sourced from the same
dataset as the evaluated attack. Specifically, we use the initial 1 million
packets, comprised exclusively of benign traffic across all traces.
Subsequently, each trace’s remaining portion contains malicious traffic
associated with a specific attack, forming the basis for evaluating the
trained classifier module.

###  5.3. Evaluation Metrics

The ML classifier generates an RMSE (Root Mean Square Error) score for the
features records sent from the data plane. In this context, an RMSE represents
the error of the classification score of each features record from the value
predicted by the trained model. The results presented in the following
subsections are calculated for each record’s RMSE score.

To evaluate detection performance, the RMSE scores obtained as output from the
classifier are compared with a given cut-off threshold value, which determines
which packets are considered anomalies, and which represent benign traffic.
During inference, any packet with an RMSE score higher than the threshold is
labelled malicious. If the dataset also labelled it as malicious, we have a
true positive; otherwise, it is a false positive.

The metric we use for evaluation in the next subsection is the _Area Under the
receiver operating characteristic Curve (AUC)_. This metric evaluates the
trade-off between true positive rate (sensitivity) and false positive rate
(1-specificity) at various threshold settings for a binary classification
model and is therefore useful for assessing the overall model performance and
discrimination ability. We present results considering the F1-score metric in
Appendix B.

###  5.4. Detection Performance

This section compares Peregrine’s and Kitsune’s detection performance. The
results are shown in Figure 7. We evaluated each attack trace at various
sampling rates to consider the downsampling of packet processing from a Tbps
switch to a Gbps middlebox.

Recall (Figure 3) that the two approaches we are evaluating employ different
sampling methods, based on their respective designs. In a traditional NIDS,
sampling determines the rate at which input packets entering the switch are
sampled to accommodate the system’s processing limitations, typically capable
of handling only a few Gbps of packet processing. However, in Peregrine,
features are computed for all packets in the data plane. In this case,
sampling refers to the rate at which a features record is generated and sent
to the ML-based detection module—i.e., after feature computation.

While the overall detection performance varies between attacks, consistently
with other works (mirsky2018kitsune, ; whisperFu2021, ), Peregrine’s
performance is systematically better. While Kitsune’s performance is good for
most attacks without sampling, this middlebox-based detector is ineffective
(AUC ¡ 0.5) with sampling (for 12 out of 15 attacks), as demonstrated before
(Figure 1). By contrast, Peregrine retains its very good performance (AUC ¿
0.8) for most attacks (13 out of 15). Clearly, the ability to compute features
in the data plane is extremely powerful, enabling malicious traffic detection
in Terabit networks. Delving a bit into the details, we now divide the
analysis of these results into three groups.

Figure 8. Throughput vs sampling rate.

Attacks 1 to 4. Without sampling (1:1), the performance of the Kitsune
baseline for these attacks is slightly better than Peregrine without sampling.
The reason may be that Kitsune computes exact statistics instead of
approximations. With sampling, however, Kitsune’s detection performance falls
abruptly. Peregrine, on the other hand, has very good performance for every
sampling rate (AUC ¿ 0.8). Crucially, its good performance is unaffected by
sampling.

Attacks 5 to 12. Somewhat surprisingly at first, for these eight attacks the
performance of Peregrine is better than Kitsune for any sampling rate, even
without sampling! The approximations we use for feature computation may cause
the model to generalise better. We conjecture the approximations may be acting
as a regularizer (tibshirani1996regression, ; cortes2012l2, ; guo2018survey,
), preventing the model from overfitting. An in-depth study of this hypothesis
is the subject of our future work.

Attacks 13 to 15. The results for these attacks are different from all of the
above. For the OS Scan and SSDP Flood attacks, both detectors achieve
excellent performance. We believe this is due to the specificity of the attack
traces: in these two attacks, the malicious traffic clearly dominates over the
benign traffic during the entire duration of the attack. The Fuzzing attack,
on the other hand, could not be effectively detected by any system as the
computed statistics do not catch its signature.

Figure 9. Pipeline performance of Peregrine vs Kitsune.

###  5.5. Runtime Performance

Peregrine successfully compiles for the Tofino 2 T2NA (tna, ) architecture.
This guarantees that it runs at a line rate of 6.4 Tbps. Its augmented version
with recirculation also compiles for the Tofino 1 TNA. As explained in Section
4, as there are fewer stages on a Tofino 1, Peregrine recirculates packets to
a second pipeline to perform the computations that did not fit on the first
one, an action that can have an impact on performance (more details in
Appendix A).

Figure 10. Relative weight of Feature Computation in the malicious traffic
detection pipeline.

Finding the optimal sampling rate. As mentioned in Section 3.1, downsampling
to the ML Classifier is fundamental, as server packet processing performance
is several orders of magnitude lower than the network data plane. In the
previous section we studied how the sampling rate affected detection
performance. Now, we study how it affects throughput, to find the right
balance between the two metrics.

We use a modified version of KitNET as the ML Classifier, which performs the
classification on Peregrine’s feature records. We assess throughput by
replaying network traffic traces at various packet rates. For each rate, we
measure the number of features generated by the switch and compare that to the
number handled by the ML Classifier. Throughput is considered stable if the ML
Classifier processes at least $99.9\%$ of the features generated by the switch
(in other words, if the number of packet drops is less than $0.1\%$). We
employ a binary search to find the highest stable packet rate within a
predefined range. In each step, we test the rate at the midpoint between the
current minimum (floor) and maximum (ceiling) rates. The ceiling is lowered if
the rate proves unstable (less than $99.9\%$ processed features). Conversely,
if stable, the floor is raised. After 10 iterations, the final throughput
value is the highest stable rate observed.

Figure 8 shows the variation of throughput with the sampling rate. These
performance values correspond to the average of stable throughputs among all
datasets, with error bars indicating standard deviations. From these results
we take that a sampling rate of 1:32768 is enough to handle one 100G switch
port. To properly handle the 32 switch ports of our Tofino switch, we would
need to either (1) lower the sampling rate ($32\times$), (2) use a more
performant classifier, or a combination of both (1) and (2). Throughout our
experiments, KitNET was processing at most 2kPPS, matching experiments from
other works (whisperFu2021, ). Nevertheless, Peregrine was able to scale
KitNET’s implementation to support 100G traffic _while maintaining higher
detection performance_.

Pipeline performance across modules. Peregrine is composed of two main
components: Feature Computation (FC) and ML-based Detection (MD). The first
runs on the data plane, the second on a middlebox server, each with differing
throughput capacities. Figure 9 compares the performance of each component
with each other, and finally with Kitsune.

Both the Packet Processing (PP) and Feature Computation (FC) components run on
the data plane, and therefore are capable of processing traffic at 6.4Tbps. We
used the same modified version of kitNET as mentioned before, and observed it
was capable of processing at most around 2-3Mbps on average. Kitsune, on the
other hand, achieves only half the performance of our modified ML-based
Malicious traffic Detector (MD).

This shows that offloading the FC component to the data plane can also have an
improvement ($2\times$ in this case) on detection performance. As observed in
Figure 10, which showcases the percentage split between the FC and MD in terms
of total processing time for multiple attacks, the FC component processing is
in most cases heavier than MD. Although it varies with each attack, it is
commonly over 50%, justifying the doubling in performance improvement in
Figure 9. This experiment further validates results from previous related work
(bai2020fastfe, ).

| Tofino1 | Tofino 2
---|---|---
| Pipeline 0 | Pipeline 1
Stages | 100% | 91.7% | 95%
Meter ALU | 72.9% | 6.9% | 72.4%
Hash Dist Units | 43.1% | 0% | 26.3%
VLIW | 26.6% | 56.0% | 53.3%
SRAM | 37.2% | 6.4% | 26.9%
TCAM | 6.9% | 9.7% | 5.7%
Table 3. Peregrine’s TNA data plane resource usage.

###  5.6. Resource Usage

Peregrine ’s resource usage on both the TNA and T2NA is shown with percentage
values in Table 3, with the overall processing split between the two switch
pipelines for TNA, as referred in Section 4.

The main bottleneck of the prototype implementation for the TNA is related to
the number of stages required by Peregrine. As the feature computations
performed require a significant number of operations, often with several
distinct stateful memory accesses, these must necessarily be split across
several processing stages and be recirculated in order to fit into the switch
architecture restrictions.

Conversely, as can also be observed in Table 3, Peregrine’s implementation for
the Tofino 2 architecture is able to perform all feature computations in a
single pipeline, avoiding recirculation.

###  5.7. Cost Efficiency

Finally, we compare the cost efficiency of scaling ML-based malicious traffic
detectors using a distributed architecture of commodity servers (see Section
2.4) against Peregrine’s cross-platform approach. We perform a quantitative
analysis of both approaches’ monetary cost and power consumption and analyze
how they change with increasing traffic rates. Given the variation of switch
power consumption values reported in the literature (kim2020tea, ;
liu2021jaqen, ; jacob2023does, ), we consider the worst-case scenario for our
cross-platform approach.

We present the results in Figures 11 and 12. As server-based solutions require
more server instances to keep up with line rates, their cost and power
consumption increase linearly with traffic rates. By contrast, the Peregrine
approach of offloading part of the computation to the network switch, a
domain-specific, highly efficient packet processing accelerator, enables
scaling to Terabit scales with constant energy or monetary costs.

##  6\. Related Work

Figure 11. Cost of a server-based malicious traffic detector and Peregrine
with increasing line rates.

Malicious traffic detection. Most contemporary malicious traffic detection
systems harness ML techniques (buczak2016survey, ). While numerous systems are
tailored for Internet of Things (IoT) networks (hamza2019detecting, ;
chaabouni2019network, ; yang2021efficient, ), recent advancements target
networks with higher traffic speeds. Whisper (whisperFu2021, ), an ML-based
detector capable of sustaining speeds exceeding 10 Gbps, achieves this
performance through frequency domain analysis, feeding its clustering
algorithm. Although solutions like Jaqen (liu2021jaqen, ) and ACC-Turbo
(alcoz2022aggregate, ) target terabit networks, they specialize in detecting a
specific attack class (volumetric DDoS). To our knowledge, Peregrine is the
first system that showcases ML-based detection of generic attacks in terabit
networks.

In-network telemetry. The emergence of commodity programmable switches
(bosshart2013forwarding, ) enabled a new class of in-network telemetry
solutions. Several systems have proposed implementations of different types of
sketching algorithms and data structures for the network data plane, achieving
beneficial memory/accuracy trade-offs for network monitoring (yu2013software,
; liu2016one, ; Sivaraman2017, ; yang2018elastic, ; tang2019mv, ;
namkung2022sketchlib, ). Recent SDN-based telemetry systems rely on
specialized query languages (narayana2017language, ) and propose cross-
platform approaches (gupta2018sonata, ; sonchack2018turboflow, ) to distribute
query functionality across servers and programmable switches. Other works
(wang2020martini, ; yu2020mantis, ) explore the offload of control tasks, like
monitoring, entirely to the switch data plane, completely removing the control
plane from the decision-making loop.

ML Feature Extraction in the data plane: P4DDLe (doriguzzi2023introducing, ),
Musumeci et al. (musumeci2022machine, ), and FastFE (bai2020fastfe, ) extract
features from the data plane and feed them to ML-based classifiers running on
the control plane. However, they extract only simple features (bai2020fastfe,
) and/or are implemented for the bmv2 software switch
(doriguzzi2023introducing, ; musumeci2022machine, ). It remains unclear
whether any such system is effective in Tbps networks.

Line-Rate Traffic Statistics Sharma et al. (sharma2017evaluating, ), Stat4
(gao2021stats, ), and others(choi2007quantile, ; wang2023easyquantile, ;
ivkin2019qpipe, ) introduced a series of data plane primitives for
approximated calculations of basic mathematical operations and statistical
functions (e.g., average, variance, quantiles, and percentiles), instrumental
to monitoring tasks like anomaly detection. Peregrine implements many of these
primitives on the Tofino programmable switch. Others (e.g., quantiles) could
potentially be integrated to increase the set of traffic features we compute
in the data plane.

Figure 12. Expected power consumption of a server-based malicious traffic
detector and Peregrine with increasing line rates.

##  7\. Conclusion

Motivated by the growth in number, scale, and complexity of network attacks
and faced with the performance limitations of current detection systems, we
proposed Peregrine, a cross-platform, ML-based malicious traffic detector.

To scale detection to Terabit speeds, Peregrine decouples feature computation
from ML-based detection, offloading the former to the network data plane. Our
evaluation demonstrates that computing the ML features in the switch data
plane enables line-rate analysis of all network traffic—the key enabler for
effectively detecting malicious traffic in Terabit networks.

## Acknowledgements

This work was supported by the European Union (ACES project, 101093126) and by
national FCT funds (Myriarch project, 2022.09325.PTDC). João Romeiras Amado
was supported by the FCT scholarship 2020.05965.BD.

## References

  * (1) Canadian Institute for Cybersecurity datasets.  Retrieved 2023-02-15.  URL: https://www.unb.ca/cic/datasets/.
  * (2) High-capacity strataxgs® trident4 ethernet switch series.  Retrieved 2023-02-15.  URL: https://www.broadcom.com/products/ethernet-connectivity/switching/strataxgs/bcm56880-series.
  * (3) Albert Gran Alcoz, Martin Strohmeier, Vincent Lenders, and Laurent Vanbever.  Aggregate-based congestion control for pulse-wave DDoS defense.  In Proceedings of the ACM SIGCOMM 2022 Conference, pages 693–706, 2022.
  * (4) João Romeiras Amado.  Source code.  Retrieved 2024-02-06.  URL: https://github.com/netx-ulx/peregrine.
  * (5) Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halderman, Luca Invernizzi, Michalis Kallitsis, et al.  Understanding the Mirai botnet.  In 26th USENIX Security Symposium, pages 1093–1110, 2017.
  * (6) Daniel Arp, Erwin Quiring, Feargus Pendlebury, Alexander Warnecke, Fabio Pierazzi, Christian Wressnegger, Lorenzo Cavallaro, and Konrad Rieck.  Dos and don’ts of machine learning in computer security.  In Proc. of the USENIX Security Symposium, 2022.
  * (7) Nirav Atre, Hugo Sadok, Erica Chiang, Weina Wang, and Justine Sherry.  Surgeprotector: Mitigating temporal algorithmic complexity attacks using adversarial scheduling.  In Proceedings of the ACM SIGCOMM 2022 Conference, pages 723–738, 2022.
  * (8) Jiasong Bai, Menghao Zhang, Guanyu Li, Chang Liu, Mingwei Xu, and Hongxin Hu.  Fastfe: Accelerating ml-based traffic analysis with programmable switches.  In Proceedings of the Workshop on Secure Programmable Network Infrastructure, pages 1–7, 2020.
  * (9) Diogo Barradas, Nuno Santos, Luís Rodrigues, Salvatore Signorello, Fernando MV Ramos, and André Madeira.  Flowlens: Enabling efficient flow classification for ml-based network security applications.  In NDSS, 2021.
  * (10) Karel Bartos, Michal Sofka, and Vojtech Franc.  Optimized invariant representation of network traffic for detecting unseen malware variants.  In 25th USENIX Security Symposium, 2016.
  * (11) Pat Bosshart, Glen Gibb, Hun-Seok Kim, George Varghese, Nick McKeown, Martin Izzard, Fernando Mujica, and Mark Horowitz.  Forwarding metamorphosis: Fast programmable match-action processing in hardware for SDN.  In ACM SIGCOMM Computer Communication Review, volume 43, pages 99–110, 2013.
  * (12) Jacob Alexander Markson Brown, Xi Jiang, Van Tran, Arjun Nitin Bhagoji, Nguyen Phong Hoang, Nick Feamster, Prateek Mittal, and Vinod Yegneswaran.  Augmenting rule-based dns censorship detection at scale with machine learning.  arXiv preprint arXiv:2302.02031, 2023.
  * (13) Anna L Buczak and Erhan Guven.  A survey of data mining and machine learning methods for cyber security intrusion detection.  IEEE Communications Surveys & Tutorials, 18(2):1153–1176, 2016.
  * (14) Coralie Busse-Grawitz, Roland Meier, Alexander Dietmüller, Tobias Bühler, and Laurent Vanbever.  pforest: In-network inference with random forests.  arXiv preprint arXiv:1909.05680, 2019.
  * (15) Nadia Chaabouni, Mohamed Mosbah, Akka Zemmari, Cyrille Sauvignac, and Parvez Faruki.  Network intrusion detection for IoT security based on learning techniques.  IEEE Communications Surveys & Tutorials, 21(3):2671–2701, 2019.
  * (16) Baek-Young Choi, Sue Moon, Rene Cruz, Zhi-Li Zhang, and Christophe Diot.  Quantile sampling for practical delay monitoring in internet backbone networks.  Computer Networks, 51(10):2701–2716, 2007.
  * (17) Cisco.  isco Encrypted Traffic Analytics Whitepaper.  Retrieved 2024-02-01.  URL: https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.pdf.
  * (18) Corinna Cortes, Mehryar Mohri, and Afshin Rostamizadeh.  L2 regularization for learning kernels.  arXiv preprint arXiv:1205.2653, 2012.
  * (19) Levente Csikor, Dinil Mon Divakaran, Min Suk Kang, Attila Kőrösi, Balázs Sonkoly, Dávid Haja, Dimitrios P Pezaros, Stefan Schmid, and Gábor Rétvári.  Tuple space explosion: A denial-of-service attack against a software packet classifier.  In Proceedings of the 15th International Conference on Emerging Networking Experiments And Technologies, pages 292–304, 2019.
  * (20) Roberto Doriguzzi-Corin, Luis Augusto Dias Knob, Luca Mendozzi, Domenico Siracusa, and Marco Savi.  Introducing packet-level analysis in programmable data planes to advance network intrusion detection.  arXiv preprint arXiv:2307.05936, 2023.
  * (21) Min Du, Zhi Chen, Chang Liu, Rajvardhan Oak, and Dawn Song.  Lifelong anomaly detection through unlearning.  In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019.
  * (22) Chuanpu Fu, Qi Li, Meng Shen, and Ke Xu.  Realtime robust malicious traffic detection via frequency domain analysis.  In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pages 3431–3446, 2021.
  * (23) Jiaqi Gao, Ennan Zhai, Hongqiang Harry Liu, Rui Miao, Yu Zhou, Bingchuan Tian, Chen Sun, Dennis Cai, Ming Zhang, and Minlan Yu.  Lyra: A cross-platform language and compiler for data plane programming on heterogeneous ASICs.  In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, SIGCOMM ’20, 2020.
  * (24) Sam Gao, Mark Handley, and Stefano Vissicchio.  Stats 101 in p4: Towards in-switch anomaly detection.  In Proceedings of the Twentieth ACM Workshop on Hot Topics in Networks, pages 84–90, 2021.
  * (25) Yunhui Guo.  A survey on methods and theories of quantized neural networks.  arXiv preprint arXiv:1808.04752, 2018.
  * (26) Arpit Gupta, Rob Harrison, Marco Canini, Nick Feamster, Jennifer Rexford, and Walter Willinger.  Sonata: Query-driven streaming network telemetry.  In Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication, pages 357–371, 2018.
  * (27) Ayyoob Hamza, Hassan Habibi Gharakheili, Theophilus A Benson, and Vijay Sivaraman.  Detecting volumetric attacks on lot devices via sdn-based monitoring of mud activity.  In Proceedings of the 2019 ACM Symposium on SDN Research, pages 36–48, 2019.
  * (28) Grant Ho, Asaf Cidon, Lior Gavish, Marco Schweighauser, Vern Paxson, Stefan Savage, Geoffrey M. Voelker, and David Wagner.  Detecting and characterizing lateral phishing at scale.  In 28th USENIX Security Symposium, 2019.
  * (29) Austin Hounsel, Jordan Holland, Ben Kaiser, Kevin Borgolte, Nick Feamster, and Jonathan Mayer.  Identifying disinformation websites using infrastructure features.  In 10th USENIX Workshop on Free and Open Communications on the Internet, 2020.
  * (30) Stephen Ibanez, Alex Mallery, Serhat Arslan, Theo Jepsen, Muhammad Shahbaz, Changhoon Kim, and Nick McKeown.  The nanopu: A nanosecond network stack for datacenters.  In 15th USENIX Symposium on Operating Systems Design and Implementation, 2021.
  * (31) Intel.  P416 Intel® Tofino™ Native Architecture – Public Version.  Retrieved 2023-02-15.  URL: https://raw.githubusercontent.com/barefootnetworks/Open-Tofino/master/PUBLIC_Tofino-Native-Arch.pdf.
  * (32) Intel.  The Intel® Tofino™ series of P4-programmable Ethernet switch ASICs.  Retrieved 2022-10-20.  URL: https://www.intel.com/content/www/us/en/products/details/network-io/programmable-ethernet-switch/tofino-series.html.
  * (33) L. Invernizzi, S. Miskovic, Rubén Torres, Christopher Krügel, Sabyasachi Saha, Giovanni Vigna, Sung-Ju Lee, and M. Mellia.  Nazca: Detecting malware distribution in large-scale networks.  In NDSS 2014, 2014.
  * (34) Nikita Ivkin, Zhuolong Yu, Vladimir Braverman, and Xin Jin.  Qpipe: Quantiles sketch fully in the data plane.  In Proceedings of the 15th International Conference on Emerging Networking Experiments And Technologies, pages 285–291, 2019.
  * (35) Romain Jacob, Jackie Lim, and Laurent Vanbever.  Does rate adaptation at daily timescales make sense?  In Proceedings of the 2nd Workshop on Sustainable Computer Systems, pages 1–7, 2023.
  * (36) Keith Wiles.  Pktgen - Traffic Generator powered by DPDK.  Retrieved 2022-10-20.  URL: https://github.com/pktgen/Pktgen-DPDK.
  * (37) Changhoon Kim.  Programming the network data plane: What, how, and why?  Retrieved 2023-02-15.  URL: https://conferences.sigcomm.org/events/apnet2017/slides/chang.pdf.
  * (38) Daehyeok Kim, Zaoxing Liu, Yibo Zhu, Changhoon Kim, Jeongkeun Lee, Vyas Sekar, and Srinivasan Seshan.  Tea: Enabling state-intensive network functions on programmable switches.  In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 90–106, 2020.
  * (39) Zaoxing Liu, Antonis Manousis, Gregory Vorsanger, Vyas Sekar, and Vladimir Braverman.  One sketch to rule them all: Rethinking network flow monitoring with UnivMon.  In Proceedings of the 2016 ACM SIGCOMM Conference, pages 101–114, 2016.
  * (40) Zaoxing Liu, Hun Namkung, Georgios Nikolaidis, Jeongkeun Lee, Changhoon Kim, Xin Jin, Vladimir Braverman, Minlan Yu, and Vyas Sekar.  Jaqen: A high-performance switch-native approach for detecting and mitigating volumetric DDoS attacks with programmable switches.  In 30th USENIX Security Symposium, pages 3829–3846, 2021.
  * (41) Yisroel Mirsky, Tomer Doitshman, Yuval Elovici, and Asaf Shabtai.  Kitsune: an ensemble of autoencoders for online network intrusion detection.  In Network and Distributed Systems Security Symposium, 2018.
  * (42) Francesco Musumeci, Ali Can Fidanci, Francesco Paolucci, Filippo Cugini, and Massimo Tornatore.  Machine-learning-enabled ddos attacks detection in p4 programmable networks.  Journal of Network and Systems Management, 30:1–27, 2022.
  * (43) Hun Namkung, Zaoxing Liu, Daehyeok Kim, Vyas Sekar, and Peter Steenkiste.  $\\{$SketchLib$\\}$: Enabling efficient sketch-based monitoring on programmable switches.  In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 743–759, 2022.
  * (44) Srinivas Narayana, Anirudh Sivaraman, Vikram Nathan, Prateesh Goyal, Venkat Arun, Mohammad Alizadeh, Vimalkumar Jeyakumar, and Changhoon Kim.  Language-directed hardware design for network performance monitoring.  In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, pages 85–98, 2017.
  * (45) Terry Nelms, Roberto Perdisci, Manos Antonakakis, and Mustaque Ahamad.  WebWitness: Investigating, categorizing, and mitigating malware download paths.  In 24th USENIX Security Symposium, 2015.
  * (46) Thuy TT Nguyen and Grenville Armitage.  A survey of techniques for internet traffic classification using machine learning.  IEEE communications surveys & tutorials, 10(4):56–76, 2008.
  * (47) Vern Paxson.  Bro: a system for detecting network intruders in real-time.  Computer networks, 31(23-24):2435–2463, 1999.
  * (48) Francisco Pereira, Gonçalo Matos, Hugo Sadok, Daehyeok Kim, Ruben Martins, Justine Sherry, Fernando M. V. Ramos, and Luis Pedrosa.  Automatic generation of network function accelerators using component-based synthesis.  In Proceedings of the Symposium on SDN Research, SOSR ’22, 2022.
  * (49) Leon Poutievski, Omid Mashayekhi, Joon Ong, Arjun Singh, Mukarram Tariq, Rui Wang, Jianan Zhang, Virginia Beauregard, Patrick Conner, Steve Gribble, et al.  Jupiter evolving: transforming google’s datacenter network via optical circuit switches and software-defined networking.  In Proceedings of the ACM SIGCOMM 2022 Conference, pages 66–85, 2022.
  * (50) Martin Roesch et al.  Snort: Lightweight intrusion detection for networks.  In Proceedings of LISA’99: 13th Systems Administration Conference, volume 99, pages 229–238, 1999.
  * (51) Iman Sharafaldin, Arash Habibi Lashkari, and Ali A Ghorbani.  Toward generating a new intrusion detection dataset and intrusion traffic characterization.  ICISSp, 1:108–116, 2018.
  * (52) Naveen Kr Sharma, Antoine Kaufmann, Thomas Anderson, Arvind Krishnamurthy, Jacob Nelson, and Simon Peter.  Evaluating the power of flexible packet processing for network resource allocation.  In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), pages 67–82, 2017.
  * (53) Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, et al.  Jupiter rising: A decade of clos topologies and centralized control in google’s datacenter network.  ACM SIGCOMM computer communication review, 45(4):183–197, 2015.
  * (54) Vibhaalakshmi Sivaraman, Srinivas Narayana, Ori Rottenstreich, S. Muthukrishnan, and Jennifer Rexford.  Heavy-hitter detection entirely in the data plane.  In Proceedings of the Symposium on SDN Research, SOSR ’17, 2017.
  * (55) John Sonchack, Adam J Aviv, Eric Keller, and Jonathan M Smith.  Turboflow: Information rich flow record generation on commodity switches.  In Proceedings of the Thirteenth EuroSys Conference, pages 1–16, 2018.
  * (56) Nik Sultana, John Sonchack, Hans Giesen, Isaac Pedisich, Zhaoyang Han, Nishanth Shyamkumar, Shivani Burad, André DeHon, and Boon Thau Loo.  Flightplan: Dataplane disaggregation and placement for p4 programs.  In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21), 2021.
  * (57) Tushar Swamy, Alexander Rucker, Muhammad Shahbaz, Ishan Gaur, and Kunle Olukotun.  Taurus: A data plane architecture for per-packet ml.  In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’22, 2022.
  * (58) Lu Tang, Qun Huang, and Patrick PC Lee.  Mv-sketch: A fast and compact invertible sketch for heavy flow detection in network data streams.  In IEEE INFOCOM 2019-IEEE Conference on Computer Communications, pages 2026–2034, 2019.
  * (59) Robert Tibshirani.  Regression shrinkage and selection via the lasso.  Journal of the Royal Statistical Society Series B: Statistical Methodology, 58(1):267–288, 1996.
  * (60) Bo Wang, Rongqiang Chen, and Lu Tang.  Easyquantile: Efficient quantile tracking in the data plane.  2023\.
  * (61) Shuhe Wang, Chen Sun, Zili Meng, Minhu Wang, Jiamin Cao, Mingwei Xu, Jun Bi, Qun Huang, Masoud Moshref, Tong Yang, et al.  Martini: Bridging the gap between network measurement and control using switching asics.  In 2020 IEEE 28th International Conference on Network Protocols, pages 1–12, 2020.
  * (62) Xian Wang.  Enidrift: A fast and adaptive ensemble system for network intrusion detection under real-world drift.  In Proceedings of the 38th Annual Computer Security Applications Conference, pages 785–798, 2022.
  * (63) Zhaoqi Xiong and Noa Zilberman.  Do switches dream of machine learning? toward in-network classification.  In Proceedings of the 18th ACM workshop on hot topics in networks, pages 25–33, 2019.
  * (64) Kun Yang, Samory Kpotufe, and Nick Feamster.  An efficient one-class SVM for anomaly detection in the internet of things.  arXiv preprint arXiv:2104.11146, 2021.
  * (65) Tong Yang, Jie Jiang, Peng Liu, Qun Huang, Junzhi Gong, Yang Zhou, Rui Miao, Xiaoming Li, and Steve Uhlig.  Elastic sketch: Adaptive and fast network-wide measurements.  In Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication, pages 561–575, 2018.
  * (66) Liangcheng Yu, John Sonchack, and Vincent Liu.  Mantis: Reactive programmable switches.  In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 296–309, 2020.
  * (67) Minlan Yu, Lavanya Jose, and Rui Miao.  Software defined traffic measurement with OpenSketch.  In 13th USENIX Symposium on Networked Systems Design and Implementation, pages 29–42, 2013.
  * (68) Kaiyuan Zhang, Danyang Zhuo, and Arvind Krishnamurthy.  Gallium: Automated software middlebox offloading to programmable switches.  SIGCOMM ’20, 2020.
  * (69) Menghao Zhang, Guanyu Li, Shicheng Wang, Chang Liu, Ang Chen, Hongxin Hu, Guofei Gu, Qianqian Li, Mingwei Xu, and Jianping Wu.  Poseidon: Mitigating volumetric DDoS attacks with programmable switches.  In 27th Network and Distributed System Security Symposium, 2020.
  * (70) Zhipeng Zhao, Hugo Sadok, Nirav Atre, James C Hoe, Vyas Sekar, and Justine Sherry.  Achieving 100gbps intrusion prevention on a single server.  In 14th USENIX Symposium on Operating Systems Design and Implementation, pages 1083–1100, 2020.
  * (71) Ziyun Zhu and Tudor Dumitraş.  Featuresmith: Automatically engineering features for malware detection by mining the security literature.  In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016.

Figure 13. Data plane implementation of the feature computation module for the
Tofino 1 (TNA) architecture, with recirculation across two pipelines. Each
column inside a pipeline represents a stage. Several computations are
performed per-stage across all flow keys.

## APPENDIX

##  Appendix A Data plane Implementation

The Tofino 2 (T2NA) architecture features a higher number of stages per
pipeline compared to the previous generation of the Tofino switch architecture
(TNA). As such, Peregrine’s implementation for T2NA is able to compute the
entire set of features for all four flow keys on a single pipeline (as
described in Section 4). However, the number and complexity of the features
computed by Peregrine precludes its deployment on a single pipeline of a TNA-
based switch.

To overcome this issue and enable the use of Peregrine using the first
generation of Tofino chips, we leverage the packet recirculation primitive of
this switch architecture to forward only selected packets to another pipeline
in the switch. This primitive virtually extends the number of stages for the
additional processing required by Peregrine, as shown in Figure 13. Using two
pipelines on TNA introduces overhead, as the recirculation ports only support
a relatively small portion of the switch’s overall throughput. However, in
Peregrine, recirculation needs only be performed once per epoch to support the
computation of the more complex features and subsequent record generation.
Notably, the feature atoms are executed in the first pipeline, enabling their
updates for each packet traversing the switch—in other words, we observe and
maintain the state of every packet, which is fundamental to guarantee a high
detection rate. On T2NA, an operator’s configuration of the epoch value is not
restrained by the limitations on the overall switch throughput as
recirculation is not necessary, being instead only dependent on the throughput
handling capabilities of the active classifier running on the middlebox server
(Section 5.5).

As can be observed in the high-level illustration of the switch’s pipelines in
Figure 13, a number of auxiliary computations are performed in the data plane
to calculate the more complex features. These computations are strategically
split between both pipelines in order to optimize pipeline placement (as
referred to in Section 2.4). The values obtained from the auxiliary
computations performed in the first pipeline are carried onto the second
pipeline using internal bridge headers and subsequently used in the remaining
feature computation operations. The list of statistics finally computed in the
data plane of Peregrine is included in Table 2 (Section 3.3).

Computations in detail. The following lines offer a more detailed description
of the various computations illustrated in Figure 13. For each computation, we
indicate the total number of processing stages required inside square
brackets.

Hash Computation [2 stages]: Usually a single-stage process, Peregrine’s hash
computation requires an extra step performed in a second stage. Since, for a
given flow key, the 4 instances of each flow atom—corresponding to the 4 decay
constants—are stored in the same register, each occupying a quarter of its
available memory, we must add a constant value to the obtained hash,
representing the register index value that marks the initial position for the
active decay factor.

Pkt$++$ [1 stage]: Global packet counter, used to keep track of each epoch’s
state.

Residue ($Res_{i}$) [3 stages]: Peregrine tracks a residue value for each flow
direction, with both values stored in a single register position using a P4
struct. A hash-based check is performed to track the previous/current flow
direction and update the stored values in the correct struct positions
accordingly. This operation encompasses: (1) Residue value calculation
(subtraction of the packet length and mean); (2) Flow direction check; (3)
Stored residue values’ update.

Sum of residual products ($SR_{ij}$) [3 stages]: Calculated as 64-bit values,
the sums of residual products are obtained through a process encompassing
three pipeline stages. Due to architecture limitations that restrict register
actions on 64-bit values, the required calculations are performed using a
sequence of 32-bit manipulations: (1) Sum of the lower 32-bits; (2) Carry
value calculation; (3) Sum of the higher 32-bits.

Mean ($\mu_{i}$) [1 stage]: Calculated through a right-shift division between
the linear sum of the number of packet bytes and the number of packets (both
obtained as feature atoms).

Mean of Squared Sum ($\mu(SS)_{i}$) [1 stage]: Calculated through a right-
shift division between the squared sum of the number of packet bytes and the
number of packets (both obtained as feature atoms).

Squared Mean ($\mu^{2}_{i}$) [1 stage]: Obtained through a square calculation
(math unit approximation) of the mean for a given flow.

Variance ($\sigma^{2}_{i}$) [2 stages]: Obtained through (1) Subtraction of
the mean (squared sum) and the squared mean; (2) Square root calculation (math
unit approximation) of the previously obtained value.

Standard Deviation ($\sigma_{i}$) [1 stage]: Obtained through a square root
calculation (math unit approximation) of the variance.

Magnitude [2 stages]: Obtained through (1) Addition of the squared mean for
both flow directions; (2) Square root calculation (math unit approximation) of
the previously obtained value.

Radius [2 stages]: Obtained through (1) Addition of the squared variance for
both flow directions: (2) Square root calculation (math unit approximation) of
the previously obtained value.

Approximate Covariance (Approx. Cov.) [2 stages]: Obtained through (1)
Addition of the packet weight for both flow directions; (2) Right-shift
division for the sum of residual products and added weights.

Pearson Correlation Coefficient (PCC) [1 stage]: Calculated through a right-
shift division between the approximate covariance and the product of the
standard deviation for both flow directions.

##  Appendix B Detection Performance: F1-score

Figure 14. F1-score across sampling rates. Threshold set to FPR=0.1.

The metric presented in the following section is the F1-score, defined as the
harmonic mean between precision (proportion of instances identified as
positives which are actually positives) and recall (proportion of instances
correctly identified as true positives).

As described in Section 5.3, a number of techniques can be used to select a
threshold value for classification according to the needs of each operator
(e.g., choosing a threshold value based on a maximum percentage of a given
metric). Figures 14 and 15 present results (logarithmic scale) for two such
threshold values. One which guarantees a False Positive Rate (FPR) of 0.1, a
looser threshold that allows for more false positives to detect a greater
number of attacks; and one with FPR = 0.01, a more conservative threshold that
minimizes false positives. The rationale for choosing these two values was to
analyze the trade-off between maximizing attack detection and minimizing false
alarms.

On the first case, in Figure 14, as the threshold is set to a comparatively
lower value, the range of packets identified by the model as outliers—either
True Positives or False Positives—is higher. While the results are generally
high for both systems when the sampling is 1:1, Peregrine achieves a higher
F1-score than Kitsune on the remaining sampling rates, as expected.

In Figure 15, when the threshold is set to FPR=0.01, the difference between
the two systems becomes more noticeable. While Kitsune often exhibits a clear
decline in its results as the sampling rate increases (e.g., in the Mirai and
SSH Bruteforce attacks), Peregrine consistently maintains its detection
performance across sampling rates in most attacks. This latter property is in
fact observed on both threshold values, highlighting Peregrine’s much stronger
stability in terms of detection performance across different sampling rates.

Figure 15. F1-score across sampling rates. Threshold set to FPR=0.01.