DPIFuzz: A Differential Fuzzing Framework

to Detect DPI Elusion Strategies for QUIC

Gaganjeet Singh Reen Christian Rossow
CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security
Saarbrücken, Saarland, Germany Saarbrücken, Saarland, Germany
[Link]@[Link] rossow@[Link]

ABSTRACT 1 INTRODUCTION
QUIC is an emerging transport protocol that has the potential to Organisations across the globe inspect the encrypted traffic at the
replace TCP in the near future. As such, QUIC will become an periphery of their network. Deep Packet Inspection (DPI) tech-
important target for Deep Packet Inspection (DPI). Reliable DPI niques are at the core of such traffic analyses. DPI allows to re-
is essential, e.g., for corporate environments, to monitor traffic assemble and inspect application-layer communication content,
entering and leaving their networks. However, elusion strategies and consequently, detect various security-critical incidents such as
threaten the validity of DPI systems, as they allow attackers to malware [13], data leakage [38], phishing attacks [37], or remote
carefully design traffic to fool and thus evade on-path DPI systems. exploits [36]. With the rising popularity of protocols that are en-
While such elusion strategies for TCP are well documented, it is crypted by default, DPI systems are typically used in combination
unclear if attackers will be able to elude QUIC-based DPI systems. with man-in-the-middle proxies [27, 39] that assist in intercepting
In this paper, we systematically explore elusion methodologies for encrypted channels (such as TLS).
QUIC. To this end, we present DPIFuzz: a differential fuzzing frame- However, prior research has demonstrated elusion attacks against
work which can automatically detect strategies to elude stateful DPI DPI systems that fool their TCP and/or HTTP [17, 23, 33, 41, 42]
systems for QUIC. We use DPIFuzz to generate and mutate QUIC inspections. The core reason for such evasion are differences in how
streams in order to compare (and find differences in) the server-side the DPI system and the actual data recipient have implemented a
interpretations of five popular open-source QUIC implementations. protocol (such as TCP). Any slight difference may lead to the fact
We show that DPIFuzz successfully reveals DPI elusion strategies, that the actual recipient of the data and the DPI system reassembled
such as using packets with duplicate packet numbers or exploit- different payload data, although operating on the same sequence
ing the diverging handling of overlapping stream offsets by QUIC of raw packets. There are plenty of reasons why such differences
implementations. DPIFuzz additionally finds four security-critical may occur: (i) Protocol specifications (deliberately or not) leave
vulnerabilities in these QUIC implementations. some details out, either not to blow up the standard, to allow ven-
dors to handle certain situation as they see fit, or simply as these
CCS CONCEPTS details were forgotten. (ii) In order to reassemble the application-
layer content, the DPI systems needs to model the state machine
• Security and Privacy → Intrusion detection systems; Net- of stateful transport protocols (such as TCP). Having said this, DPI
work security; Software and application security. systems may choose to simplify this state machine to minimize the
overhead [41] and thus, to foster scalability. (iii) Similarly, DPI sys-
KEYWORDS tems might perform a lower number of checks or less sophisticated
DPI Elusion, QUIC, Protocol Fuzzing, Differential Fuzzing checks to validate packets as compared to an endpoint in order to
reduce the computational load.
ACM Reference Format:
Fortunately, there are just a few relevant protocols that have
Gaganjeet Singh Reen and Christian Rossow. 2020. DPIFuzz: A Differential to be studied to assess and mitigate these evasion attacks. As of
Fuzzing Framework to Detect DPI Elusion Strategies for QUIC. In Annual now, the vast majority of inspected Internet traffic is HTTPS/TLS-
Computer Security Applications Conference (ACSAC 2020), December 7–11, based [22, 25, 27, 39]. As such, it is not surprising that most works
2020, Austin, USA. ACM, New York, NY, USA, 13 pages. [Link] in the context of evasion attacks so far have focused on the specifics
1145/3427228.3427662 of TCP [17, 23, 33, 41, 42]. Yet, with the IETF working to standardise
the QUIC protocol, coupled with the performance and the secu-
rity benefits QUIC offers compared to TCP, it is only a matter of
time before it is adopted widely as the go-to transport protocol.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
Consequently, intercepting and analysing QUIC packets using DPI
for profit or commercial advantage and that copies bear this notice and the full citation systems coupled with inline proxies will be imperative to organi-
on the first page. Copyrights for components of this work owned by others than the sations to maintain the security of their networks. Unfortunately,
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission the known findings of TCP do not directly translate to QUIC, as
and/or a fee. Request permissions from permissions@[Link]. the two protocols have vastly different specifications. QUIC pro-
ACSAC 2020, December 7–11, 2020, Austin, USA vides security features, like authentication and encryption, that are
© 2020 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 978-1-4503-8858-0/20/12. . . $15.00
typically handled by a higher layer protocol (like TLS), from the
[Link] transport layer itself. QUIC also uses a large variety of packets and

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

UDP Header QUIC Header Long/Short Header

Frame Type Indicates Frame Type
(depending on Packet
(All frames contain this field)
type) Field 1
QUIC Packet 1 Frame 1
Field 2
Frame Specific Fields
Frame 2 (For example, the Stream Frame
UDP Packet QUIC Packet Payload contains Stream ID, Offset, Length
Payload QUIC Packet 2 (Version Negotiation, Stateless Reset, and Stream Data fields)
and
Retry packets do not contain frames) QUIC Frame

QUIC Packet
UDP Packet

Figure 1: QUIC Packet Structure Overview: QUIC Packets have confidentiality and integrity protection by default. Even parts
of QUIC headers are protected (using keys separate from the payload protection keys) [11].

frames , as well as multiple streams within a connection, for data • We additionally uncover and report on four security critical
exchange between end points as compared to TCP which simply vulnerabilities in the QUIC implementations, demonstrating
uses packets. Additionally, the wire image of QUIC is integrity pro- that DPIFuzz’s application is not just restricted to the setting
tected and reveals much lesser information to network monitors of finding evasion attacks.
as compared to the wire image of TCP which makes inspecting
the traffic more complex. In this paper, we address the problem
of DPI elusion attacks for QUIC-based communication. Instead of 2 BACKGROUND
manually searching for QUIC protocol details that can potentially 2.1 QUIC Protocol
be used for DPI elusion, we set out for a more methodological (and,
QUIC [12] is an encrypted-by-default Internet transport protocol
hopefully, more complete) way to discover such protocol details.
which was originally proposed by Google. QUIC is conceptually
We therefore develop a differential fuzzing framework (DPIFuzz)
similar to a combination of TCP, TLS, and HTTP/2 implemented
which can automatically uncover potential differences between
on UDP and was developed with the intended goal of eventually
implementations which could be used for eluding a DPI system. We
replacing TCP on the web. Since QUIC runs on top of UDP, it can
design a modular and stateful fuzzer that can generate and mutate
be distributed as a userspace library that can be easily upgraded.
sequences of QUIC packets. The fuzzer also tracks the responses
This is in stark contrast to other transport protocols like TCP/UDP
of the implementations to the generated sequences. We use the
which are implemented in operating system kernels and middlebox
fuzzer to test five popular open-souce QUIC implementations and
firmware because of which making significant changes to them is
consequently perform a differential analysis of the behaviour of
next to impossible [7].
these implementations to the fuzzed sequences of packets. In order
The QUIC IETF working group has been working since late 2016
to access the application level data reassembled by the implemen-
to standardise the protocol. For the purpose of this paper, we refer
tations, we create echo servers using these implementations. We
solely to draft 27 of the IETF specification [8] of the QUIC protocol.
also use Status Codes to track the status/state of implementations
The versions of the implementations considered in the paper are
after processing a given sequence of packets. Using DPIFuzz, we
also based on draft 27 of IETF QUIC.
uncover two distinct strategies which highlight ambiguities be-
QUIC defines several types of packets and frames. Figure 1 provides
tween QUIC implementations. Additionally, we also uncover four
an overview about the structure of QUIC packets. QUIC packets
security-critical vulnerabilities in the implementations and demon-
are carried in UDP datagrams. Multiple QUIC packets can be co-
strate how these could facilitate DPI elusion.
alesced into one UDP datagram. QUIC packets broadly contain a
Our findings are of direct importance for DPI users. Eliminating
header (long header or short header) and a payload. The payload of
any ambiguities or vulnerabilities that we identified is immensely
QUIC packets is expressed as a sequence of frames. Draft 27 of the
helpful to organisations that want to reliably monitor QUIC traffic
IETF QUIC Protocol defines 20 different types of frames [9] like the
on their network perimeter. At the very least, being aware of such
Stream Frame, which is used to carry the actual application level
shortcomings for QUIC will help DPI users identify the potential
payload over a stream or the Connection Close Frame, which is
flaws of their monitoring systems in an automated way.
used to indicate to an end point that a connection is being closed.
To summarize our contributions:
Detailed information about the different types of frames and pack-
• We develop DPIFuzz, a structure-aware and modular fuzzing ets can be found in the IETF draft for QUIC [9].
framework which allows (i) automated testing of QUIC im- A QUIC connection is a stateful interaction between a client and
plementations by generating and mutating communication server. Each QUIC connection starts with a handshake phase during
streams and (ii) a differential analysis of the behaviour of which client and server establish a shared secret using the cryp-
the implementations to these communication streams. tographic handshake protocol (QUIC-TLS [11]) and decide on an
• We apply DPIFuzz to five popular open-source QUIC imple- application protocol to use to facilitate the exchange of data. The
mentations. As a result, we are (to the best of our knowledge) successful completion of the handshake confirms that both end-
the first to report on potential DPI elusion methods for QUIC. points are willing to communicate and establishes the important

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

parameters for the connection. 3.2 Threat Model

The exchange of information primarily takes place by means of
streams. In a stream, the protected packets contain stream frames
which are responsible for carrying the data as payload. Multiple Enterprise Network DPI
streams can be used to send data in a connection. Streams in an System
QUIC connection can be bidirectional or uni-directional, depending
on the value of the second least significant bit of the stream ID. Packet Verdict
or
QUIC also uses flow control for each stream individually as well Decrypted QUIC Drop Connection
as for the connection as a whole. Several transport parameters are Packets
defined in the QUIC specification which allow flow control between
the client and the server.
Proxy
2.2 Types of Fuzzing
Fuzzing is the process of providing randomised inputs to programs
and observing their behaviour. It has gained immense popularity in
the software testing and the security industry owing to the fact that
it can detect bugs and security vulnerabilities in an automated way. Figure 2: DPIFuzz Threat Model: An in-line proxy inter-
Several tools [19, 20, 26, 29, 34] already exist to perform fuzzing on cepts QUIC communication and forwards decrypted QUIC
a variety of programs and systems and they have been extremely sequences to a separate DPI system for further inspection.
successful in discovering vulnerabilities [1, 5, 10, 29].
Fuzzing strategies can be broadly categorised into [2]: The threat model that we assume for the scope of this paper is
• Dumb vs. Smart Fuzzing: Dumb fuzzers are unaware about depicted in Figure 2. We envision a QUIC-aware monitoring system
the format of the input that the target expects while smart with two components that tackle the disjoint tasks of (i) decrypting
fuzzers are input format aware. the TLS-encrypted QUIC communication, and (ii) inspecting the
• Black-box vs. Coverage-guided fuzzing: Black-box fuzzers decrypted content. This setup is in line with industry-grade DPI
do not test which branches of the target were covered by systems that intercept TLS-encrypted communication [22, 27, 39],
fuzzing whereas coverage-guided fuzzers try to maximise and also corresponds to the recommended setup [21] of monitoring
the code coverage of the target. TLS-encrypted communication with open-source DPI systems like
• Generation- vs. Mutation-based fuzzing: Generation-based Snort/Suricata. In detail, these two components compromise of:
fuzzers create the input for a target from scratch for every • An inline proxy which establishes a QUIC connection with
execution of the fuzzer. In contrast, mutation-based fuzzers both the client and the server and forwards the traffic be-
alter existing data that is input to the fuzzer to modify and tween the two as well as to the DPI system for analysis.
thereby create new inputs. • A stateful, reassembly-based DPI system which reconstructs
Differential Fuzzing is a testing technique where the same fuzzed the streams and analyses the packets being sent for denylisted
input is provided to different yet similar implementations that content. If the organisation prefers intrusion prevention over
should behave identical given the same input. Differential fuzzing pure detection, the DPI system can optionally send a verdict
discovers potential implementation differences by comparing the to the proxy for each packet it receives, or alternatively, send
behaviors and/or responses of the systems under test. the proxy an asynchronous signal to drop a connection after
detecting denylisted content.
3 GOAL AND SCOPE Having the proxy and DPI system as separate components provides
(i) fault tolerance as it ensures that a fault in the analysis system
3.1 Goal does not affect the proxy and vice versa, (ii) flexibility to use the
Our goal is to automatically detect strategies to elude a stateful DPI system for intrusion prevention or detection depending on the
system. We aim to find sequences of QUIC packets/frames that con- use case and (iii) modularity which allows the DPI systems to be
tain payload that is denylisted (i.e., blocked using specific payload changed or upgraded while using the same proxy and vice versa.
keywords) by the DPI system, which however remains unnoticed The proxy itself does not attempt to reassemble or analyse the
by the DPI system. To this end, we aim to reveal sequences of QUIC application-level data. However, it will need to keep track of the
packets which are reassembled by the server and the DPI system— control data necessary to ensure smooth communication between
both of which use different QUIC implementations to reassemble the client and the server. The proxy might need to keep track of
the payload differently. Such sequences reveal a potential point of certain frames in the QUIC Payload like the New_Connection_Id
ambiguity in the two QUIC implementations that can be exploited frame which is used by endpoints when they want to change the
in elusion attacks. Once we discover such sequences, we analyse connection ID associated with a connection. It would need to parse
them to find the underlying reason for the disparate handling of the QUIC payload for this; however, in the event that the parsing
packets. Finally, we want to generalize the identified differences to fails, it will follow a soft fail strategy and forward the packets to
demonstrate that attackers can leverage them to elude a DPI system the DPI system and the endpoint as expected.
with any denylisted payload.

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

Deterministic DPIFuzz
RNG

Encoder
Packet JKL JKL and
XYZ JKL Response
Generator XYZ Mutator Encryptor XYZ Analyzer
............ XYZ ............ XYZ
............ ............
abcd a`b`c` ............
a`b`c`

Trace Files

------
------
Connection ------ -----
------ -----
Handler ------ -----------
-----------
-----------
------
QUICLY ------
QUANT
QUICHE
Differential
NEQO Analysis

MVFST
Result
QUIC File
Implementations

Figure 3: DPIFuzz overview. DPIFuzz is a differential fuzzing framework that executes multiple instances of the fuzzer against
different QUIC implementations, and then performs a differential analysis of the resulting trace files to find inconsistencies.

3.3 Elusion Strategies those performed by a server). These packets/frames are known
If we can cause the DPI system to reassemble different payload as evasion packets/frames [33, 41], and potentially result in the
than the destination server for the same sequence of packets, we following consequences:
can possibly elude the DPI system. We broadly group such elusion • The evasion packet/frame allows sending data to the server
strategies into the following three categories: without it being registered at the DPI system.
Insertion Packet/Frame: Some packets/frames might be ac- • The evasion packet/frame could lead to a difference in the
cepted by the DPI system and rejected by the server (because the state of the DPI and the server implementation such that it
edge cases could be handled differently or the checks at the DPI eventually manifests as an observable difference between the
might not be as sophisticated as those in the server implementa- behaviour of the DPI system and the server implementation.
tions). These packets/frames are known as insertion packets/frames Ambiguity: A DPI system implementation might also have dif-
[33, 41]. The consequence of an insertion packet/frame could be: ferent rules defined compared to a destination server implemen-
• The insertion packet/frame results in extra application layer tation in order to deal with ambiguous aspects of the protocol
payload being registered at the DPI system. specification. As stated by Wang et al. [41], most network protocol
• The insertion packet/frame causes an error/crash on the DPI specifications are inherently ambiguous because they are written
system, which results in the buffers being flushed, but not in a natural language like English. Often, some parts of the spec-
on the destination server. As a result, if a blocked keyword ifications are deliberately left unspecified, which in turn leads to
is split into parts such that some parts are sent before the vendor-specific implementations. This results in accepted pack-
insertion packet/frame and some parts are sent after, the ets/frames being reassembled differently or affecting the state of
server would be able to reassemble the data correctly while the protocol implementations in different ways.
the DPI system would never reassemble the entire blocked
keyword. 4 DPIFUZZ ARCHITECTURE
• The insertion packet/frame could affect the state of the DPI 4.1 Challenges Faced
system such that while the packet/frame itself does not lead
Designing efficient and effective fuzzers for secure and encrypted
to an observable difference, it causes the DPI system to con-
protocols is challenging. Using a “naive” fuzzer does not lead to
sequently reassemble different data or run into an error or a
valuable results because protocol implementations expect struc-
crash while the destination server does not.
tured packets with specific values for fields as input, in the absence
Evasion Packet/Frame: Some packets/frames might be accepted of which the input is simply discarded. Valid inputs are extremely
by the server and rejected by the DPI system (This can happen in important to guide an implementation into states that are deep
cases where the check performed by the DPI are different from in the state space of a protocol [32]. A fuzzer will only be able to

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

detect meaningful vulnerabilities if it considers the state space of Packet flow through the fuzzer: The fuzzing process starts
a protocol implementation and then injects unexpected inputs to with the Connection Handler module establishing a connection
test how such cases are handled. This is extremely important as the with the IUT. To ensure that the handshake between the client and
obvious errors/unexpected inputs are usually already handled by server completes successfully, we do not fuzz the initial and the
the developers using a variety of testing frameworks. handshake packets. Following a successful connection, the Packet
Thus, for protocol level fuzzing, a structure-aware fuzzer is es- Generator creates a sequence of QUIC packets that we wish to send
sential to obtain meaningful results. Then again, simply using a to the server. Since the Packet Generator creates QUIC packets
structured fuzzer might not be enough for stateful protocols like which are not yet encoded or encrypted, we can perform mutations
QUIC where the exchange of data only starts after a successful before the packet contents are encoded or encrypted.
handshake process. Once we have a sequence of packets generated from the Packet
Taking the above mentioned points into account, we design Generator, the sequence is passed through the mutator module. We
a modular, stateful, structure-aware, generation+mutation based ensure that we do not fuzz the packet header. This fact coupled with
fuzzer that can actively interact with the server-side implementa- fuzzing the packet payload before encoding or encryption ensures
tion under test (IUT). that the packets and most of the frames (some of the frames might
undergo structure altering mutations) remain structurally valid and
4.2 Fuzzer Design Overview allows us to observe the effects that fuzzing different frame field
Figure 3 shows the general structure of our fuzzing framework values can have on server implementations. Following this, each
DPIFuzz. We design a fuzzer that is split into the following modules: packet will either just be encoded (like the initial client packet)
or both encoded and encrypted (like the handshake and the data
• Connection Handler: This module establishes a connection packets). Finally, the fuzzer encapsulates the QUIC packet in a UDP
with the IUT by completing the TLS handshake. It uses the datagram and sends the datagram to the IUT. The IUT response is
high level QUIC API provided by QUIC-Tracker [28]. received at the Response Analyzer based on which a trace file is
• Packet Generator: This module generates a sequence of QUIC created.
packets without encoding or encrypting them. It supports
generating all types of QUIC frames and packets listed in the
4.3 Mutations
specification. The design of the Packet Generator module is
explored in detail in Section 4.4. We broadly define two types of mutations for our fuzzer:
• Mutator: This module mutates the QUIC packets generated Sequence-level mutations affect the sequence of packets, gen-
by the packet generator. The mutations are defined in Sec- erated by the Packet Generator (see next subsection), as a whole.
tion 4.3. We do not mutate the QUIC packet header. We envision three such mutations:
• Encoder and Encryptor: This module performs the neces- • Shuffle: The order of packets in a sequence is randomly
sary encoding and encrytion of the QUIC packets. It then shuffled.
encapsulates the QUIC packet in a UDP datagram and sends • Duplicate: Packets are randomly selected and then duplicated
the UDP datagram to the server. with varying degrees of duplication
• Response Analyzer: This module analyses the responses that • Drop: Randomly selected packets are dropped from the se-
the IUT sends on processing the fuzzed sequence of packets. quence of packets.
It creates a trace file that contains:
– The application level data sent by the IUT as a response to A sequence can undergo each of these three sub-mutations with
the packets it receives. This response will later be used to a probability 𝛼 1 , 𝛼 2 and 𝛼 3 , respectively. The values for these prob-
gauge if two QUIC implementations differ in their payload abilities are defined in Table 7 in the appendix.
reassembly. Packet-level mutations affect an individual packet payload in-
– Status Codes: These indicate the state of an IUT after stead of an entire sequence. Every packet in a sequence of packets
processing a sequence of packets. Our fuzzer infers the can undergo packet-level mutations with a probability 𝛾. We dis-
state of the IUT either from the responses that the IUT tinguish between payload mutations that are defined considering
sends or from the absence of a response. Status codes QUIC Packet payload simply as a collection of bytes, and frame
are (i) ServerTimeOut, which indicates that the IUT was mutations that are defined for the individual frames contained in
in an unresponsive state after processing a sequence of the QUIC packet payload, as outlined below. Once a packet has
packets1 , (ii) TLSHandshakeFail, which indicates that the been selected to undergo packet-level mutations, it could undergo
handshake could not be completed successfully with the either a payload-level mutation or a frame-level mutation with a
IUT, (iii) ServerDidNotRespond, which indicates that the probability 𝜔 and 1 − 𝜔, respectively. It is important to note that
IUT was unresponsive right from the initial packet and after performing the mutations on the packet payload, we update
(iv) ServerIsAlive, which indicates that the server was re- the payload length field in the long headers of packets (if present)
sponsive after processing the entire sequence of packets. to reflect the length of the mutated payload. This ensures that a
simple check of comparing the payload length field with actual
1 We test the responsiveness of the IUT , after processing the fuzzed sequence of payload length does not lead to the packet being discarded.
packets, by sending a response eliciting packer/frame like a Stream Frame to it and
also attempting to establish a new connection with the IUT by sending an initial • Payload mutations: These mutations do not take into con-
packet. sideration the structure of the payload or the frames that

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

make up the payload. They could lead to alterations in the • Basic Stream Reassembly Generator: This generator cre-
structures of the frames within the packets. The four types ates a sequence that contains a random number of pack-
of payload mutations are: ets with stream frames. Each stream established with the
– Repeat payload: A random substring of the entire packet server contains a random number of random-length and
payload is selected and injected at a random position in random-content QUIC packets that will be sent to the server,
the packet payload. The existing payload content is not and finally, is gracefully terminated. QUIC stream frames
overwritten. correctly encode the stream offets as if data was sent consec-
– Alter payload: In this, we iterate over the payload at a utively.
byte level. For each byte, a random decision is made about • Flow-Control-Aware Stream Reassembly Generator: In con-
whether to fuzz the byte or not. trast to the previous generator, the sequence generated by
– Add random payload: A payload with randomised content this generator also contains packets and frames which affect
and a random length lesser than the actual payload length the flow control parameters established for the streams as
is selected and inserted at a random position in the original well as the connection.
payload without overwriting the existing payload content. • Overlapping Offset Generator: This generator creates a se-
– Drop random payload: A random offset is selected and quence of packets and frames to specifically test how an
then a random number of bytes, of length ≤ payload length implementation deals with overlapping offsets in a stream.
− offset, starting at that offset is dropped. The sequence that this generator creates is simply shuffled
A selected packet will undergo one of the four mutations at but not passed through the mutators. This ensures that the
random. values of other fields in a frame are not fuzzed and offset field
• Frame mutations: The individual frames that a packet pay- is the only field affecting the results. Frames which contain
load contains are first extracted and then each frame is fuzzed overlapping offsets as well as different data for the same
with a probability 𝛽. offsets are created by randomly deciding on the total length
As an example, consider the STREAM DATA FRAME which for a stream and then fragmenting it in multiple different
carries the stream-level payload in QUIC. The different fields ways using randomised data and offsets.
in this frame are OFF bit, LEN bit, FIN bit, Stream ID, Offset,
Length and Stream Data. First, the maximum number of fields
that should be fuzzed in the frame is randomly determined. 4.5 Differential Analysis
Then, we randomly pick which fields to fuzz. All the other We now use the described fuzzing methodology to automatically
types of frames defined in the QUIC specification are fuzzed search for differences in protocol implementations. To this end, we
based on the same principle. leverage differential fuzzing, which feeds the same input to similar
yet different programs and compares their behavior. In our context,
these “similar” programs are semantically equivalent QUIC servers
based on different QUIC implementations. Technically, we thus im-
4.4 Packet Generators plement simple “echo” servers for the QUIC libraries under test (see
The previous subsection discussed how we can mutate existing Section 5.1 for more details), which reply with the application-level
sequences of QUIC packets. We will now discuss how to create payload they received from the client (i.e., from our fuzzer).
such streams and packets in the first place. Packet generators can To compare the program behaviors, for every execution (which
be of two types, which are different in whether or not the testers is bootstrapped with a particular generator and seed, more later)
have control over the sequence of packets being generated: against an IUT, the fuzzer records a trace file containing (i) the
Randomised: These generators randomly decide which types application-level data returned by the IUT and (ii) the correspond-
of frames/packets to create and randomly group frames into packet ing status code. The trace files do not necessarily distinguish be-
payload. They fill the frame and packet fields with random but type- tween all possible states of IUTs; however, they contain enough
accurate values. They attach frames as packet payload without information to highlight the relevant differences from the perspec-
considering whether the specification allows a particular packet tive of DPI elusion. More details can be readily included in the trace
to have specific frame types or if a client is even allowed to send files for a more detailed comparison of IUT states depending on the
frames of a specific type. use case. To speed up comparisons, DPIFuzz computes the hash for
Controlled: These generators create specific types of packet all generated trace files (i.e., the reassembled stream payloads and
sequences that we want to test the IUT with. This allows us to status codes, but not headers). DPIFuzz then compares the hashes
focus more on specific aspects of an implementation that we want of the trace files for all the executions of the fuzzer, with the same
to test. The total number of packets and frames, their field values seed and generator, for all the listed IUTs. If not all hashes of a
and their ordering can all still be randomised, but we can use the given seed are equal, DPIFuzz adds the seed value for the execution,
generator to control the type of packets and frames being created the name of the generator used and a hash map with the names of
as well as the grouping of frames into packet payload. The packets all the listed IUTs as keys and names of the IUTs their hash differs
still undergo mutations after this. from, as values to a result file. The differing hashes indicate that
In particular, we use three types of controlled generators. These the servers under test do not all respond in the same way to the
generators create sequences which allow us to specifically target same sequence of packets that were provided as input to them. That
the stream reassembly mechanism of the IUTs. is, either the data reassembled by the servers was different and/or

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

the values assigned by the fuzzer for status codes differed. Thus, then analyse the results with the assumption that a DPI system is
the sequence of packets are of interest to us as they can be used to based on one of the implementations under consideration in the
detect elusion strategies. result.
A slight complication arises from the fact that we cannot simply To model an inline proxy that forwards the packets to a DPI
replay one actual packet capture to all IUTs, as the underlying system for further inspection, our differential fuzzing module makes
cryptographic material differs. On the one hand, we want that the sure that the same sequence of packets are sent to all the IUTs. To
sequences sent to all IUTs essentially carry the same payload and ensure that in the event different data is returned by the two echo
follow the same order of packets and frames. On the other hand, servers, the difference is actually caused by an implementation
packets cannot be fully identical, as QUIC streams are end-to-end level difference and not a design difference in the echo servers, we
encrypted with diverging (and potentially ephemeral) key material. design and configure the echo servers in the same way. We use
To tackle this, the fuzzer first completes the handshake individually identical values for the QUIC transport parameters in the servers
with all the IUTs. All subsequent packets carry the appropriate as these parameters can affect stream data reassembly. The echo
connection IDs and are correctly encrypted so that all the servers servers send the data received on a stream back only if they are
see the same payload after decryption and decoding. This ensures able to reassemble the stream data completely, i.e., the reassembled
that we can replay “the same” sequence to multiple QUIC instances, data is contiguous and the stream has been closed. The servers
i.e., we can now recreate a sequence of randomly generated packets attempt to respond on the same streams for which they reassemble
in order to send identical sequencies to multiple implementations. the data. If a stream is unidirectional in nature, the write operation
Technically, we use a deterministic random number generator to for that stream will simply fail and the data is discarded (this does
randomize packet generations and to select mutations. This allows not affect our results because we ensure that our generators create
us to easily regenerate the same sequence of packets as long as we bi-directional communication streams).
know the seed value used to initialise the random number generator.
DPIFuzz thus selects and records a new cryptographically secure 5.2 Experiment Setup
seed value after each fuzzer execution. This seed initializes the To model a proper client server architecture while removing the
deterministic random number generator used in the fuzzer. effects of network latency and unintentional packet reordering,
Finally, we outline the inputs that DPIFuzz expects. DPIFuzz we run our echo servers on a locally hosted virtual machine using
requires an IUTList, which specifies the IUTs whose behaviour VirtualBox and run the client on our actual local machine. This
will be compared, a GeneratorList, which specifies the packet ensures that (i) the implementations being compared are fed the
generators that will be used in the fuzzer, the value Ns , which exact same logical sequence of packets and (ii) the reassembly
determines the number of times we execute the fuzzer with the differences that DPIFuzz uncovers are a consequence of design
each specified generator against each IUT with different seed values, differences in the implementations and not of any other reason.
and the value ParallelExecutions, which determines the number The experiments were run on a machine with a Quad-Core Intel
of fuzzer instances that can be executed in parallel. i5 processor with a 16GB RAM. The virtual machine used was
allocated 4 cores with 8GB of RAM. The operating system used
5 RESULTS for both the virtual machine and the local system is Ubuntu 18.04.
5.1 Experiment Methodology Running the tests locally also ensures that no servers in production
We implement our entire framework using Golang. For our experi- are harmed. Table 6 in the appendix contains the values used for
ments, we consider five actively developed, open source implemen- the transport parameters in the servers. Values of input parameters
tations2 of QUIC; namely, QUICHE [15] by Cloudflare, MVFST [16] for the Differential Fuzzing Module are:
by Facebook, QUANT [31] by NetApp, NEQO [30] by Mozilla and • IUTList is initialised with the IP address as well as the port
QUICLY [18] by Fastly. number for the 5 IUTs.
In order to access the data reassembled by the DPI system and the • GeneratorList is defined as "Basic Stream Reassembly, Flow-
server, we create echo servers using the QUIC implementations3 . Control-Aware Stream Reassembly, Overlapping Offset"
The echo servers allow us to easily validate whether or not there are • Ns is set to 200
ambiguities in how QUIC libraries handle certain packet streams. • ParallelExecutions is set to 5.
Having said this, they do not necessarily capture the full logic of • The probability values used for various mutations are listed
more complex QUIC applications—hence our findings represent in Table 7 in the appendix.
a lower bound of all potential QUIC implementation ambiguities.
From these five QUIC libraries, we create all potential pairs, i.e., 5.3 DPI Elusion Results
exhaust all possible combinations of systems being used for DPI In total, we use our framework to create 600 (|GeneratorList|*Ns )
inspection and data reception, respectively. We run DPIFuzz si- unique sequences, i.e., we run our fuzzer against each IUT, with
multaneously against servers of all five implementations, i.e., we each of the 3 (|GeneratorList|) specified generators, with 200(Ns )
compare the responses of all the servers against each other. We different seed values. It takes approximately 2.5 hours for all the
2 Versions of implementations as available on 29/05/2020 sequences to finish executing and for the comparison results to be
3 We do not create an echo server for the QUANT and the NEQO implementation due generated. If run without parallelization, the same process would
to the absence of a well defined API and documentation. Although we perform testing
on their fully fledged servers supporting QUIC protocol, we do not consider these take around 12.5 hours (considering the parallelization factor of
servers directly for our reassembly based results. 5). We summarise the differences uncovered by these sequences in

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

Seed Value Generator QUICHE Reassembled Data MVFST Reassembled Data QUICLY Reassembled Data

Basic Stream 2Z?b"?@N5?#48SZyBp????;yGJ-

4373445819122772715 yGJ+$0P7cdWYaBMetcem=+@- yGJ+$0P7cdWYaBMetcem=+@-
Reassembly +$0P7cdWYaBMetcem=+@Wf-
WfSja1xZwhYKFFA26AN&YI_ WfSja1xZwhYKFFA26AN&YI_
Sja1xZwhYKFFA26AN&YI_
7253654666463259418 Overlapping Offset (;k]Nx[CV@g@mc’jZP (;k]Nx[CV@g@mc1jZP (;k]>.gXhn%@mc1jZP
Table 1: Reassembly Differences

No. of
Stream Pay- over-
Packet QUICHE Reassembled QUICLY Reassembled MVFST Reassembled
Frame Stream load lap- Stream
No. Data Data Data
Pay- Offset Length ping Finbit
load offsets
1 ’jZP 14 4 0 True ______________’jZP ______________’jZP ______________’jZP
2 x[ 5 2 0 False _____x[_______’jZP _____x[_______’jZP _____x[_______’jZP
3 @mc1 11 3 1 False _____x[____@mc’jZP _____x[____@mc1jZP _____x[____@mc1jZP
4 ( 0 1 0 False (____x[____@mc’jZP (____x[____@mc1jZP (____x[____@mc1jZP
5 CV@g 7 4 0 False (____x[CV@g@mc’jZP (____x[CV@g@mc1jZP (____x[CV@g@mc1jZP
6 k]N 2 3 0 False (_k]Nx[CV@g@mc’jZP (_k]Nx[CV@g@mc1jZP (_k]Nx[CV@g@mc1jZP
7 >.g 4 3 3 False (_k]Nx[CV@g@mc’jZP (_k]>.gCV@g@mc1jZP (_k]Nx[CV@g@mc1jZP
8 Xhn% 7 4 4 False (_k]Nx[CV@g@mc’jZP (_k]>.gXhn%@mc1jZP (_k]Nx[CV@g@mc1jZP
9 ; 1 1 0 False (;k]Nx[CV@g@mc’jZP (;k]>.gXhn%@mc1jZP (;k]Nx[CV@g@mc1jZP
Table 2: Overlapping Offset Data Reassembly. Packets 3, 7 and 8 contain overlapping offsets and highlight the diverging be-
haviour of the implementations.

Table 8 in the appendix. We use the seed values in the result file become structurally invalid. While the destination server is
generated by DPIFuzz to regenerate sequences of packets for which configured to drop packets with a duplicate packet number,
the behaviour of the implementations differs. We then manually the DPI server attempts to process the packet. This results
inspect them to find the underlying reasons for the differences in in a "Frame Format Error" on the DPI server and the connec-
implementation behaviour. Analysing these sequences, we uncover tion is closed. Any data sent after this(stream 12 data) is not
6 logically different DPI elusion results which we summarise next. reassembled by the DPI server. When used with an inline
proxy, it will still be able to inspect the data in the individual
5.3.1 Reassembly Differences: packets and maybe reassemble stream 12 data independently,
In this category, we discuss the results which lead to different data but will not be able to combine it with contents reassembled
being reassembled (for the same sequence of input packets) by the from stream 16.
IUTs. Using the two exemplary results in Table 1, we highlight how This concrete evasion instance can be trivially generalized
attackers can exploit differences in reassembly strategies to elude a to fool the DPI in missing any blocked keyword(s). Let us
DPI system: assume that the text "BLOCKED" is denylisted by the DPI
system. We use two streams (IDs 0 and 4) to send this data
• Exploiting Packets with Duplicate Packet Numbers: from the client to the server. We create the frames such that
The first way to elude DPI systems uncovered by our fuzzer is stream 0 frames reassemble to "BLO" and stream 4 frames
based on the idea of inserting packets with duplicate packet reassemble to "CKED". After the packets containing stream
numbers that are ignored by some IUTs, in accordance with 0 frames, we insert a packet with a duplicate packet number,
the IETF specification of QUIC, but not by others. with a randomised payload (structurally invalid frames) , into
Consider the first entry in Table 1. The MVFST server or the sequence of packets. We then insert packets containing
the QUICLY server acts as the DPI system and the QUICHE the stream 4 frames and send this sequence of packets to the
server acts as the destination server. While the destination server. The DPI server reassembles the packets as "BLO" and
server reassembles data from two streams (stream ID 12 and therefore fails to detect the denylisted word. The destination
16 in our concrete sequence), the DPI server only reassem- server reassembles the packets as "BLOCKED" and is thus
bles the data from one stream (stream ID 16). After receiving able to elude the DPI.
packets containing stream frames of one stream (ID 16), the
servers receive a packet with a duplicate packet number. • Exploiting Stream Offset Overlaps: Another way to elude
This packet has undergone the "Repeat Payload" mutation at DPI systems discovered by our fuzzer is based on the idea
the fuzzer side because of which the frames in the payload

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

Packet Stream Frame QUICHE Reassembled Data QUICLY Reassembled Data

Stream Offset Stream Finbit
No. Payload (Destination Server) (DPI system)
1 OCKED 2 True __OCKED __OCKED
2 BLIN 0 False BLOCKED BLINKED
Table 3: DPI elusion using Overlapping Offsets (Case 1)

Packet Stream Frame MVFST Reassembled Data QUICLY Reassembled Data

Stream Offset Stream Finbit
No. Payload (Destination Server) (DPI system)
1 OCKED 2 True __OCKED __OCKED
2 INKED 2 False __OCKED __INKED
3 BL 0 False BLOCKED BLINKED
Table 4: DPI elusion using Overlapping Offsets (Case 2)

Seed Value Generator Implementation Error Description

5224880393376231849 Basic Stream Reassembly MVFST Null Pointer Dereference
6867396659762739268 Flow-Control-Aware Stream Reassembly QUANT Heap use after free
3544824671711368728 Flow-Control-Aware Stream Reassembly QUICLY Null Pointer Dereference
8969571667189322506 Basic Stream Reassembly NEQO Assertion Failed
Table 5: Summary of IUT Crashes

that implementations might handle receiving data at overlap- with the specification but does not consider all possible cases
ping offsets in different ways. We consider the second entry of overlapping offsets.
of Table 1 for this section. An analysis of the packets sent to We can generalize this fuzzing sequence to elude the DPI
three servers (QUICHE, QUICLY and MVFST), as shown in system in missing any blocked keyword(s). Let’s assume that
Table 2, reveals the reason for diverging data reassembly. the text "BLOCKED" is supposed to be denylisted by the DPI
Looking at Packets 3, 7 and 8, we can see that when the system. We demonstrate two DPI elusion cases:
QUICHE server receives a payload at an offset that it has – If QUICLY is used for DPI and QUICHE used for receiving
already received data for, it simply ignores the new data. The data, Table 3 depicts the packets we send and the data
QUICLY server on the other hand replaces the payload with reassembled by them which consequently allows eluding
the new payload. The analysis of the MVFST implementa- the DPI system.
tion is more involved than these cases. Packet 3 contains the – Similarly, if QUICLY is used for DPI and MVFST used for
first stream frame with data overlapping with the already receiving data, Table 4 depicts the packets we send and
reassembled data. Here, the MVFST server replaces the ex- the data reassembled by them which consequently allows
isting data with the new data that it receives. Packet 7 is the eluding the DPI system.
next packet that carries overlapping data. In this case, how-
ever, the MVFST implementation does not replace the data. 5.3.2 QUIC Implementation Bugs and Vulnerabilites:
Further analysis reveals that MVFST does not replace the In addition to strategies that lead to different data being reassem-
existing data if the starting offset of the payload in a stream bled by semantically equivalent QUIC implementation servers, our
frame already has existing data. Any unoccupied positions fuzzer revealed several security-critical vulnerabilities in the tested
that lie within the range of this new frame payload will be QUIC implementations. In this section, we discuss the results in
filled with characters from the new payload for those loca- which a sequence of packets lead to a crash on one implementation
tions. However, if the starting offset of the frame payload is but not on another.
not already occupied, the contents of this frame will replace We detect the errors by observing the status code values in the
all the existing characters that it overlaps with. trace generated for each execution of the fuzzer. These errors can
According to Draft 27 of IETF QUIC protocol, data at a given be trivially leveraged in order to evade a DPI system using the
offset must not change if it is sent multiple times and an end- buggy QUIC implementation. If a server crashes, the execution at
point MAY treat receipt of different data at the same offset the client will timeout at the client and the fuzzer will assign the
within a stream as a connection error [6]. The behaviour of value “ServerTimeOut” to the status code.
QUICHE seems to be consistent with the specification as it These sequences of packets could effectively be used to flush
does not change the data at an offset once received. QUICLY the buffers storing the reassembled data in the DPI system mid
seems to completely ignore the case of repeating offsets and way through data transfer, thereby allowing blocked content to
the MVFST implementation seems to be partially consistent go undetected. On top of this, and possibly more important, these

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

application crashes illustrate that our fuzzing framework can also These are potential points of divergence in the behaviours
be readily applied to finding security vulnerabilities in QUIC im- of the implementations.
plementations. In the following, supported by Table 5, we describe
the bugs that our fuzzer revealed in detail. Implications of DPIFuzz for DPI systems: Our main finding
• QUANT: The QUANT server runs into a heap use after free is that DPI systems that parse and reassemble QUIC packets in
error4 . Using address sanitizer [24] reveals that the imple- a different manner than the actual recipient are prone to elusion
mentation tries to access the state of a stream, i.e., check and differential fuzzing is an effective technique to uncover elusion
whether a stream is closed or not by calling "q_is_stream_closed strategies for such systems. As of writing this paper, we are not
()" after the memory allocated to the stream has already been aware of any actual DPI systems for QUIC. Designing performant
freed. DPI systems for QUIC will be a challenge owing to the fact that
• NEQO: The NEQO server runs into an Assertion failed error5 . QUIC uses TLS 1.3 for providing security. TLS 1.3 makes selective
A Connection is already in the "Closed" state and the NEQO MITM proxy interventions for DPI harder because of the encrypted
server calls close () function on this connection to try close Server Hello messages (which contain the server certificates used
it again. to verfiy server identity). Additionally, the ability of end points
• QUICLY: The QUICLY server runs into a Segmentation Fault6 . to change connection IDs as well as migrate connections would
The reason for the Segmentation Fault is a null pointer deref- make monitoring of connections more challenging for DPI systems.
erence [3]. When the server receives a stream frame from Having said this, given the expected rapid deployment of QUIC,
a client with a stream id not permitted by the QUIC specifi- DPI systems will have to be developed for QUIC based traffic in the
cation, the "QUICLY_get_ingress_max_streams ()" function near future. To test the validity and effectiveness of our approach,
tries to access the value stored in a NULL pointer causing we used open source QUIC implementations as a DPI system. Given
the server to run into a segmentation fault. that actual DPI systems are usually limited in functionality and
• MVFST: The MVFST server tries to dereference a null pointer. resources, our findings likely just represent the lower bound of elu-
This causes the server to run into a Segmentation Fault7 and sion sequences that DPIFuzz will be able to find for any upcoming
crash. When we send a stream frame to the server such that full-fledged QUIC DPI system.
the Offset field has a non-zero value but value of the OFF bit Limitations and Future Work: DPIFuzz uses a smart logic-
is set to 0 (which indicates that the Offset field is absent), the based fuzzer. However, as it is not coverage guided, it does not
FIN bit is set to true and the Payload field empty, the MVFST attempt to maximize the code coverage of the implementations
implementation is unable to handle such a packet and runs being tested and different sequences of fuzzed packets likely repeat-
into a Segmentation fault. edly end up testing the same code parts. Also, we currently do not
track how much of the implementation code we cover owing to
Coordinated Disclosure: We disclosed these security-critical
the variance in the languages used to code the implementations.
vulnerabilities to the developers of the implementations and pro-
Extending the functionality of the fuzzer to make it coverage con-
vided them with as much information as possible to assist them in
scious would definitely improve the efficiency and effectiveness of
fixing the root causes for these problems.
DPIFuzz.
Additionally, while analysing the results we encountered se-
6 DISCUSSION
quences which registered crashes according to their trace files.
Man-in-the-middle interception techniques are widely used in en- However, when replaying these sequences individually to the IUTs
terprise controlled [27, 39] networks. With the development of an for analysis, we noticed that not all crashes were reproducible. The
encrypted by default protocol like QUIC which has less informa- reason for this is that since DPIFuzz executes multiple fuzzer in-
tion visible to the network than TCP [4], interception techniques stances in parallel, if an IUT has multiple active connections and
will become even more important for monitoring purposes. These one of them causes it to crash, the remaining open connections
are the situations where a framework like DPIFuzz can be used to also register a crash. Also, once an IUT crashes, there is a certain
identify the potential limitations of the DPI system. Leveraging our amount of delay before it is automatically restarted. If our fuzzer
results, we can conclude that: sends a sequence to the IUT within this delay window, it registers
• Programmers implementing a protocol specification often a “TLSHandshakeFail” value for the status code even though the
fail to account for all the possible types of inputs that an handshake does not fail when the sequence is replayed to the IUT.
implementation might encounter [32]. This can be avoided by replaying the according candidates in a non-
• Programmers often fail to handle properly all the possible parallel version of DPIFuzz, at the cost of a temporal performance
state transitions that the state machine of an implementation slowdown.
might encounter.
• All protocol specifications have some degree of ambiguity
and have parts that are deliberately left unspecified and the 7 RELATED WORK
programmers are free to handle these cases as they see fit. Fuzzing: Most related fuzzing works so far have focused on dis-
covering software vulnerabilities, which is not our prime focus.
4 [Link]
5 [Link] Instead, we aim to discover ambiguities in network protocol im-
6 [Link] plementations. We are aware of just a few related works that have
7 [Link] designed fuzzers for secure network protocols, as described next.

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

In 2012, Tsankov et al. [32] designed a fuzzer for the IKE (Inter- TCP and consequently, the path explosion much worse.
net Key Exchange) protocol. They used fuzz operators to fuzz the These approaches by Wang et al. [41] and Bock et al. [23] detect elu-
payloads, messages and fields in the IKE protocol. The design of sion strategies in an automated way, but they do not demonstrate
their fuzzer differs significantly from ours, though, as their fuzzer applicability to the QUIC protocol. To the best of our knowledge,
is not a client in itself but instead sits between the client and the we are the first (i) to use the concept of Differential Fuzzing to auto-
server. Additionally, they do not use the Sequence level mutators mate detection of DPI elusion strategies, (ii) to explore DPI elusion
and do not allow embedding logic into their fuzzer. strategies for the QUIC protocol, and (iii) to design a modular and
A fuzzing-based differential black-box testing approach was used structure-aware fuzzer for QUIC.
by Walz and Sikora [14] in 2015 to test the handshake phase of TLS
implementations. The fact that they only fuzz the initial ClientHello 8 CONCLUSION
message which is not encrypted makes their approach significantly In this paper, we have presented a differential fuzzing framework
different and less detailed than our fuzzing methodology. which allows detecting DPI elusion strategies for the QUIC protocol,
A concurrent work by Pham et al. [40] uses a mutational approach when being inspected by an stateful DPI system, in an automated
coupled with server state feedback to create a coverage-guided, way. We test the framework against multiple open source implemen-
greybox fuzzer for protocol implementations. Instead of generating tations of the QUIC protocol and demonstrate techniques which
packets, they replay variations of previously captured packets and can allow DPI elusion, thereby proving the effectiveness of our
use the server response codes to identify the states exercised by a approach. DPIFuzz would enable organisations to test their QUIC
message sequence. They explore FTP and RTSP implementations traffic monitoring systems and uncover possible elusion strategies
using their work. However, they do not demonstrate the applicabil- that attackers might use. As a consequence, it will help improve
ity of their work to protocols like QUIC where previously captured the security of enterprise networks.
traffic cannot be directly used to establish a connection with, or
test, a server. Additionally, the server state machine-learning algo-
9 AVAILABILITY
rithm used relies on server response codes and does not work for
implementations that do not generate response codes. The code for our differential fuzzer is open source8 and can be freely
Deep Packet Inspection Elusion: All the way back in 1998, used and extended by (i) organisations to test the robustness of
Ptacek et al. [33] proposed the idea of insertion and evasion attacks their DPI implementations, and (ii) DPI users to identify potential
on Network Intrusion Detection Systems (NIDS) and highlighted shortcomings in their methodology.
several implementation level differences in TCP and IP Protocols.
In 2013, Khattak et al. [35] used the same approach to uncover
several vulnerabilities in GFW.
We do levearage similar principles of insertion and evasion packets REFERENCES
but, we (i) are the first to explore them for the QUIC protocol, and [1] 2015. A collection of vulnerabilities discovered by the AFL fuzzer (afl-fuzz). https:
(ii) find such packets in an automated way. //[Link]/mrash/afl-cve
A genetic algorithm based automated approach to detect packet [2] 2017. Fuzzing Basics. Retrieved May 11, 2020 from [Link]
us/security-risk-detection/concepts/fuzzing-basics
manipulation based evasion strategies was used by Bock et al. [23] [3] 2019. CWE VIEW: Weaknesses in the 2019 CWE Top 25 Most Dangerous Software
in 2019. They used genetic algorithms to generate packet manip- Errors. Retrieved May 19, 2020 from [Link]
ulation strategies based on basic packet manipulation primitives html
[4] 2019. Manageability of the QUIC Transport Protocol. Retrieved May 22, 2020 from
(drop, tamper headers, duplicate and fragment), and then apply [Link]
these strategies to user input. This is in contrast to our work where [5] 2020. Hongfuzz Found Bugs. Retrieved May 7, 2020 from [Link]
google/honggfuzz#trophies
our fuzzer actually generates input sequences (instead of strategies) [6] 2020. Overlapping Offsets. Retrieved June 06, 2020 from [Link]
and mutates those in a randomised manner. The primary aim of drafts/draft-ietf-quic-transport#section-2.2-4
their work was to automate "censorship evasion" which differs sig- [7] 2020. QUIC, a multiplexed stream transport over UDP. Retrieved May 11, 2020
from [Link]
nificantly from the purpose of our work of allowing DPI users to [8] 2020. QUIC: A UDP-Based Multiplexed and Secure Transport. Retrieved May 11,
test the robustness of ther DPI systems by uncovering DPI elusion 2020 from [Link]
strategies that attackers might leverage to get restricted or mali- [9] 2020. QUIC: Packets and Frames. Retrieved June 06, 2020 from [Link]
org/base-drafts/draft-ietf-quic-transport#name-packets-and-frames
cious content in and out of protected networks. [10] 2020. Syzkaller Found Bugs. Retrieved May 7, 2020 from [Link]
Another approach to detect automated DPI evasion strategies was google/syzkaller/blob/master/docs/linux/found_bugs.md
[11] 2020. Using TLS to Secure QUIC. Retrieved May 11, 2020 from [Link]
developed by Wang et al. [41] in 2020. They used Selective Symbolic [Link]/doc/draft-ietf-quic-tls/
Execution to explore TCP implementations and discover insertion [12] Alyssa Wilk et al. Adam Langley, Alistair Riddoch. 2017. The QUIC Transport
and evasion packets which could effectively "de-synchronise" the Protocol: Design and Internet-Scale Deployment. In SIGCOMM ’17: Proceedings
of the Conference of the ACM Special Interest Group on Data Communication.
state machines of the DPI middlebox and the implementation be- [Link]
ing tested. Their approach, however, is limited by path explosion [13] Nour-Eddine Lakhdari Mourad Debbabi Amine Boukhtouta, Serguei A. Mokhov
(even though they use just three symbolic packets) and they make and Joey Paquet. May 2016. Network malware classification comparison using
DPI and flow packet headers. In Journal of Computer Virology and Hacking
pruning decisions based on their domain knowledge to tackle path Techniques, vol. 12, no. 2. Springer, 69–100. [Link]
explosion. For a protocol like QUIC which has a large variety of 1007%2Fs11416-015-0247-x
frames and packets, the number of symbolic packets needed to
explore an implementation would be much more as compared to 8 [Link]

[Link]
 ACSAC 2020, December 7–11, 2020, Austin, USA Reen and Rossow

[14] Axel Sikora Andreas Walz. March-April 1, 2020. Exploiting Dissent: Towards APPENDIX
Fuzzing-based Differential Black-Box Testing of TLS Implementations. In IEEE
Transactions on Dependable and Secure Computing. IEEE. Table 6 contains the transport parameter values used in the servers.
[15] Cloudflare. 2018. Quiche: Savoury implementation of the QUIC transport protocol Table 7 contains the values for mutation probabilities defined in
and HTTP/3. [Link]
[16] Facebook. 2018. MVFST: A client and server implementation of IETF QUIC protocol
Section 4.3. Table 8 contains a summary of the differences uncovered
in C++ by Facebook. [Link] by our fuzzer between different pairs of implementations.
[17] Arash Molavi Kakhki Arian Akhavan Niaki David Choffnes Phillipa Gill Alan Mis-
love Fangfan Li, Abbas Razaghpanah. November 2017. lib•erate, (n): a library
for exposing (traffic-classification) rules and avoiding them efficiently. In IMC
’17: Proceedings of the 2017 Internet Measurement Conference. ACM, 128–141.
[Link]
Transport Parameter Value
[18] Fastly. 2017. Quicly: A QUIC implementation, written from the ground up to be initial_max_data 1048576
used within the H2O HTTP server. [Link] initial_max_stream_data_bidi_local 66560
[19] Google. 2015. honggfuzz: Security oriented software fuzzer. [Link]
google/honggfuzz initial_max_stream_data_bidi_remote 66560
[20] Google. 2015. syzkaller: An unsupervised coverage-guided kernel fuzzer. https: initial_max_stream_data_uni 66560
//[Link]/google/syzkaller
[21] Erik Hjelmvik. 2020. Sniffing Decrypted TLS Traffic with Security initial_max_streams_bidi 2048
Onion. [Link] initial_max_streams_uni 2048
Decrypted-TLS-Traffic-with-Security-Onion
[22] Jeff Jarmoc. 2012. SSL/TLS Interception Proxies and Transitive Trust. In Black
max_idle_timeout 60000
Hat Europe. blackhat. max_packet_size 1500
[23] et al. Kevin Bock, George Hughey. 2019. Geneva: Evolving Censorship Evasion ack_delay_exponent 3
Strategies. In CCS. ACM.
[24] Konstantin Serebryany. 2011. Address Sanitizer. Google. [Link] Table 6: Transport Parameter Values
google/sanitizers/wiki/AddressSanitizer
[25] Erling Ellingsen Collin Jackson Lin-Shung Huang, Alex Rice. [n.d.]. Analyzing
Forged SSL Certificates in the Wild. In IEEE Symposium on Security and Privacy.
[26] LLVM. 2015. libFuzzer: a library for coverage-guided fuzz testing. [Link]
docs/[Link]
[27] Mohammad Mannan Louis Waked and Amr Youssef. 2018. The Sorry State of Probability Parameter Value
TLS Security in Enterprise Interception Appliances. (2018). 𝛼 1, 𝛼 2 2
[28] Quentin De Coninck Maxime Piraux and Olivier Bonaventure. 2018. Observing 3
𝛽, 𝛾 1
the Evolution of QUIC Implementations. In EPIQ’18: Proceedings of the Workshop 2
on the Evolution, Performance, and Interoperability of QUIC. [Link] 𝜔 1
1145/3284850.3284852 3
[29] Michal Zalewski. 2019. american fuzzy lop. Google. [Link] 𝛼3 0
cx/afl/ Table 7: Probability Values
[30] Mozilla. 2019. Neqo: An Implementation of QUIC written in Rust. [Link]
com/mozilla/neqo
[31] NetApp. 2016. Quant: QUIC implementation for POSIX and IoT platforms. https:
//[Link]/NTAP/quant
[32] Mohammad Torabi Dashti Petar Tsankov and David Basin. 2012. SECFUZZ:
Fuzz-testing Security Protocols. In Proceedings of the 7th International Workshop
on Automation of Software Test (AST 2012). Zurich, Switzerland.
[33] Thomas Ptacek and Timothy Newsham. [n.d.]. Insertion, Evasion and Denial of
Service: Eluding Network Intrusion Detection. ([n. d.]).
[34] Ashish Kumar Lucian Cojocar Cristiano Giuffrida Herbert Bos Sanjay Rawat,
Vivek Jain. 2017. VUzzer: Application-aware Evolutionary Fuzzing. In NDSS
Symposium 2017.
[35] Philip D. Anderson Vern Paxson Sheharbano Khattak, Mobin Javed. 2013. Towards
Illuminating a Censorship Monitor’s Model to Facilitate Evasion. In 3rd USENIX
Workshop on Free and Open Communications on the Internet (FOCI ’13).
[36] D. Smallwood and A. Vance. 2011. Intrusion analysis with deep packet inspection:
increasing efficiency of packet based investigations. In International Conference
on Cloud and Service Computing. IEEE, 342–347.
[37] K. Xiong T. Chin and C. Hu. 2018. Phishlimiter: A phishing detection and
mitigation approach using software-defined networking. In IEEE Access, vol. 6.
Springer, 42516–42531.
[38] R. Tahboub and Y. Saleh. 2014. Data leakage/loss prevention systems (dlp). In
World Congress on Computer Applications and Information Systems (WCCAIS).
IEEE, 1–6.
[39] Roelof Du Toit. 2017. Responsibly Intercepting TLS and the Impact of TLS 1.3.
(2017).
[40] Abhik Roychoudhury Van-Thuan Pham, Marcel Böhme. 2020. AFLNET: A Grey-
box Fuzzer for Network Protocols. In IEEE International Conference on Software
Testing, Verification and Validation (ICST). IEEE.
[41] et al. Zhongjie Wang, Shitong Zhu. 2020. SYMTCP: Eluding Stateful Deep Packet
Inspection with Automated Discrepancy Discovery. In NDSS Symposium 2020.
[42] Zhiyun Qian Chengyu Song Srikanth V. Krishnamurthy Zhongjie Wang, Yue Cao.
November 2017. Your state is not mine: a closer look at evading stateful internet
censorship. In IMC ’17: Proceedings of the 2017 Internet Measurement Conference.
ACM, 114–127. [Link]

[Link]
 DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC ACSAC 2020, December 7–11, 2020, Austin, USA

Seed Value Generator IUT 1 IUT2 Difference Category

4373445819122772715 BSR QUICHE MVFST Duplicate Packet Number
4373445819122772715 BSR QUICHE Quicly Duplicate Packet Number
7253654666463259418 OO QUICHE MVFST Overlapping Offset Handling
7253654666463259418 OO MVFST QUICLY Overlapping Offset Handling
7253654666463259418 OO QUICHE QUICLY Overlapping Offset Handling
5224880393376231849 BSR MVFST QUICHE Null Poninter Dereference
5224880393376231849 BSR MVFST QUICLY Null Poninter Dereference
5224880393376231849 BSR MVFST NEQO Null Poninter Dereference
6867396659762739268 FCSR QUANT QUICHE Heap use after free
6867396659762739268 FCSR MVFST QUICHE Heap use after free
6867396659762739268 FCSR NEQO QUICHE Heap use after free
3544824671711368728 FCSR QUICLY QUICHE Null Poninter Dereference
3544824671711368728 FCSR QUANT QUICLY Null Poninter Dereference
3544824671711368728 FCSR MVFST QUICLY Null Poninter Dereference
3544824671711368728 FCSR NEQO QUICLY Null Poninter Dereference
4471396090777236879 FCSR QUANT QUICHE Heap use after free
4471396090777236879 BSR QUANT QUICLY Heap use after free
4471396090777236879 FCSR QUANT MVFST Heap use after free
4471396090777236879 BSR NEQO QUANT Heap use after free
8969571667189322506 BSR NEQO QUICHE Assertion Failed
8969571667189322506 BSR MVFST NEQO Assertion Failed
8969571667189322506 BSR QUANT NEQO Assertion Failed
8969571667189322506 BSR QUICLY NEQO Assertion Failed
6399819732713312401 BSR QUICHE QUICLY Duplicate Packet Number
6399819732713312401 BSR QUICHE MVFST Duplicate Packet Number
98269818471122413 FCSR QUICHE QUICLY Null Pointer Dereference
3738301969304892419 FCSR QUICHE NEQO Assertion Failed
3738301969304892419 FCSR QUANT NEQO Assertion Failed
3738301969304892419 FCSR MVFST NEQO Assertion Failed
8566626253336265389 OO MVFST QUICLY Overlapping Offset Handling
8566626253336265389 OO MVFST QUICHE Overlapping Offset Handling
8566626253336265389 OO QUICHE QUICLY Overlapping Offset Handling
423731078537465151 BSR QUICHE QUANT Heap use after free
423731078537465151 BSR MVFST QUANT Heap use after free
423731078537465151 BSR QUICLY QUANT Heap use after free
2730155016155308010 BSR QUICHE NEQO Assertion Failed
2730155016155308010 BSR QUANT NEQO Assertion Failed
2730155016155308010 BSR MVFST NEQO Assertion Failed
Table 8: Summary of differences uncovered by the fuzzer. BSR -> Basic Stream Reassembly, FCSR -> Flow-Control-Aware Stream
Reassembly, OO -> Overlapping Offset

[Link]