S YM TCP: Eluding Stateful Deep Packet Inspection

with Automated Discrepancy Discovery

Zhongjie Wang∗ , Shitong Zhu∗ , Yue Cao∗ , Zhiyun Qian∗ , Chengyu Song∗ ,
Srikanth V. Krishnamurthy∗ , Kevin S. Chan† , and Tracy D. Braun†
∗ Department of Computer Science and Engineering, University of California, Riverside,
{zwang048, szhu014, ycao009}@ucr.edu, {zhiyunq, csong, krish}@cs.ucr.edu
† U.S. Army Research Lab, {kevin.s.chan.civ, tracy.d.braun.civ}@mail.mil

Abstract—A key characteristic of commonly deployed deep stateful protocols like TCP, DPI needs to engineer the cor-
packet inspection (DPI) systems is that they implement a simpli- responding state machine of the protocol. This introduces a
fied state machine of the network stack that often differs from that fundamental limitation of DPI, which is a susceptibility to
of endhosts. The discrepancies between the two state machines protocol ambiguities. In brief, most network protocol specifi-
have been exploited to bypass such DPI based middleboxes. cations (e.g., RFCs for TCP [36]) are written in a natural lan-
However, most prior approaches to do so rely on manually
crafted adversarial packets, which not only are labor-intensive but
guage (English), which makes them inherently ambiguous. To
may not work well across a plurality of DPI-based middleboxes. make things worse, some parts of the specifications are delib-
Our goal in this work is to develop an automated way to craft erately left unspecified, which in turn leads to vendor-specific
candidate adversarial packets, targeting TCP implementations in implementations. Consequently, different network stack imple-
particular. Our approach to achieving this goal hinges on the key mentations (e.g., Windows and Linux) typically have inherent
insight that while the TCP state machines of DPI implementations discrepancies in their state machines [42], [13], [38]. In fact,
are obscure, those of the endhosts are well established. Thus, in even different versions of the same network stack implemen-
our system S YM TCP, using symbolic execution, we systematically tation, can have discrepancies. To ensure low overheads and
explore the TCP implementation of an endhost, identifying compatibility with most implementations, DPI middleboxes
candidate packets that can reach critical points in the code (e.g., usually implement their own simplified state machines, which
which causes the packets to be accepted or dropped/ignored);
such automatically identified packets are then fed through the
are bound to differ from the ones on endhosts.
DPI middlebox to determine if a discrepancy is induced and As pointed out by previous works [37], [48], [29], such
the middlebox can be eluded. We find that our approach is discrepancies lead to certain network packets being accept-
extremely effective. It can generate tens of thousands of candidate ed/dropped by either a “DPI middlebox” or the endhost.
adversarial packets in less than an hour. When evaluating against
Exploiting this property, one can use insertion packets (i.e., a
multiple state-of-the-art DPI systems such as Zeek and Snort, as
well as a state-level censorship system, viz. the Great Firewall of packet which is accepted and acted upon by the DPI middlebox
China, we identify not only previously known evasion strategies, to change its state, whereas the remote host drops/ignores it)
but also novel ones that were never previously reported (e.g., and evasion packets (i.e., a packet which is ignored by the DPI
involving the urgent pointer). The system can be extended middlebox but the remote host accepts and acts on it) [37] to
easily towards other combinations of operating systems and DPI mislead the DPI’s protocol state machine. Specifically, such
middleboxes, and serves as a valuable tool for testing future DPIs’ packets cause the DPI to enter a different state than the one
robustness against evasion attempts. on the endhost. Consequently, the DPI can no longer faithfully
assemble the same application layer content as the endhost,
I. I NTRODUCTION failing to catch any malicious or sensitive payload.

Deep packet inspection (DPI) has become a technology To date, research on insertion and evasion packets are
commonly deployed in modern network security infrastruc- based on manually crafting such packets targeting specific
tures. By assembling and checking application layer content, DPI middleboxes [37], [48], [29]. Unfortunately, it is a labor-
DPI enables powerful functionalities that are not present in intensive task to analyze each and every middlebox implemen-
traditional firewalls. These include malware detection [10], tation and come up with the corresponding strategies for such
remote exploit prevention [41], phishing attack detection [16], adversarial packet generation. One can potentially automate the
data leakage prevention [46], government network surveil- process by searching through all possible sequences of packets
lance [7], [6], targeted advertising [28], [3], and traffic dif- to identify insertion and evasion packets. Unfortunately, the
ferentiation for tiered services [51], [32], [20]. search space is exponentially large, i.e., there are 2160 possi-
bilities to cover a 20-byte TCP header of even a single packet,
Unfortunately, to assemble application layer content from let alone testing a sequence of packets.
“Can we develop automated ways to construct packets that
can successfully de-synchronize the state of a DPI middlebox
Network and Distributed Systems Security (NDSS) Symposium 2020 from that of a (end) server?” This question is at the crux of the
23-26 February 2020, San Diego, CA, USA
ISBN 1-891562-61-4 work we target in this paper, answering which not only can
https://dx.doi.org/10.14722/ndss.2020.24083 help test future generations of DPIs but also help stay on top
www.ndss-symposium.org of the arms race against future censorship technologies. Our
focus here is on TCP, since it is the cornerstone upon which However, DPI suffers from the inherent vulnerability of
most popular application-layer protocols are built. We develop evasion because of discrepancies between its TCP implemen-
an approach that is driven by the insight that even though tation and that of the endhost (e.g., a server) arising because of
the TCP state machines of DPI middleboxes are obscure, the protocol ambiguities [37], [23]. An example is that Snort [43]
implementations of TCP on the endhosts are well established accepts a TCP RST packet as long as its sequence number is
(e.g., a very large fraction of the servers run Linux operating within the receive window (which is too lenient), while the
systems). Given this, we explore the TCP state machine of latest Linux implementation will make sure that the sequence
endhosts (using symbolic execution) and generate groups of number of the RST packet matches the next expected number
candidate packets based on what critical points and states they (rcv_next) exactly. This allows an attacker to send an
can reach, i.e., states where packets are either accepted or insertion RST packet with an intentionally marked “bad” in-
dropped/ignored due to various reasons. Next, we perform window sequence number, which terminates the connection on
differential testing by feeding such packets through the DPI Snort, whereas the remote host will actually drop/ignore such
middlebox and observe whether they induce any discrepancies, a packet. Such discrepancies open up a gap for attackers to
i.e., whether the DPI middlebox can still perform its intended elude the DPI by sending carefully crafted packets.
function of identifying connections that contain malicious/sen-
sitive payloads. Besides discrepancies due to protocol implementations,
lack of knowledge of the network topology could also intro-
The major contributions of the work are the following: duce additional ambiguities. For example, it is hard for a DPI
to infer whether a packet will reach the destination. Thus, the
• We formulate the problem of automatically identifying in- attacker can send a packet with a smaller TTL to cause it not to
sertion and evasion packets by focusing on exploring the reach the remote host, however, such a packet has an influence
TCP state machine on endhosts, and conducting differential on the DPI.
testing against blackbox DPIs.
• We develop S YM TCP, a complete end-to-end approach Previous research works [48], [29] have exploited the net-
to automatically discover discrepancies between any TCP work ambiguities and protocol implementation discrepancies
implementation (currently Linux) and a blackbox DPI. We to design evasion strategies against real-world DPI systems,
have released the source code of S YM TCP and datasets at such as the national censorship systems in China and Iran,
https://github.com/seclab-ucr/sym-tcp. and ISPs’ traffic differentiation systems for tiered services.
Those evasion strategies are shown to have high success rates
• We evaluate our approach against three DPI middleboxes, in rendering the DPI ineffective. However, most of the common
Zeek, Snort, and Great Firewall of China (GFW), and discrepancies can be patched by the DPI devices, leading to
automatically find numerous evasion opportunities (several an arms race. In contrast, our system presents a major step
are never reported in the literature). The system can extend towards automating the evasion strategies, which not only can
to other DPIs easily and serves as a useful testing tool serve as a valuable testing tool against future generations of
against future implementations of DPIs. DPIs but also keep pace in the escalating arms race in the
context of DPI evasion.
II. BACKGROUND
In this section, we first provide a brief background on why B. Symbolic Execution vs. Concolic Execution vs. Selective
eluding attacks are possible against DPI. Subsequently, we pro- Symbolic Execution
vide some background on symbolic execution and associated
techniques since these are integral to building S YM TCP. Symbolic execution [26] is a powerful and precise soft-
ware analysis/testing technique that is widely employed for its
ability to break through complex and tight branch conditions
A. Eluding Attacks against Deep Packet Inspection
and reach deeper along execution paths, which is a distinct
DPI is specially designed to examine content related advantage compared to other less precise techniques such
to higher-layers, such as the application layer (e.g., HTTP, as fuzzing. In symbolic execution, instead of using concrete
IMAP). To examine application-layer payloads, DPI first re- values, variables are assigned symbolic values to explore the
constructs data streams from network packets (TCP packets) execution space of a target program. The symbolic execution
captured from an interface. Then it automatically assigns an engine simulates the program execution by interpreting each
appropriate protocol parser to parse the raw data stream [19]. instruction (either at an intermediate representation level like
Finally, it performs “pattern matching” on the parsed output. LLVM-IR [11] or VEX [40], or at the binary level [49]),
To illustrate as an example, consider the common case of and maintain symbolic expressions for each program vari-
keyword-based filtering of HTTP requests (e.g., deployed on able. En route, the engine collects path constraints in the
censorship firewalls). When the DPI module (referred to as form of symbolic expressions. Whenever a branch with a
simply DPI for ease of exposition) detects a specific keyword symbolic predicate is encountered, the engine checks whether
in the HTTP URI, it may take follow-up actions (e.g., blocking the corresponding true/false path is satisfiable (with the help
the connection or silently recording the behavior). Sometimes of an SMT solver); if so, it forks the execution path into
the pattern matching signatures can be more complex, wherein two and adds a new path constraint according to the branch
the DPI examines a combination of fields from multiple condition (true or false). The disadvantage of symbolic
layers and data from both directions (to and from a server) execution, however, is in its efficiency or scalability. Both
in a sequence [44]. For example, one endhost first sends a simulated execution and constraint solving can be extremely
“HELLO” message to port 443, and then the other party slow even with optimizations such as caching and incremental
responds with an “OLLEH” message. solving [11]. Moreover, the total number of feasible execution

2
 III. T HREAT M ODEL AND P ROBLEM D EFINITION
In this section, we first describe our threat model. Subse-
quently, we formalize the problem that we set out to solve
Server
User
DPI device
when we design S YM TCP.

Fig. 1. Threat Model

A. Threat Model
The threat model that we consider is depicted as in Fig-
paths in a common size modern software can be huge, leading ure 1. We assume that a DPI engine is located in between
to the notorious path explosion problem. the client and the server, and is capable of reading all the
Concolic execution [12] is a practical testing technique packets exchanged between the client and the server. We only
that enhances symbolic execution with concrete execution. focus on the TCP protocol in this work since it is arguably the
The basic idea is to bind a concrete value to each symbolic most popular transport layer protocol. By eluding DPI from
expression, and so, it can switch modes between symbolic the TCP-layer, we can disrupt TCP packet reassembly of the
execution and concrete execution at any time. When a branch DPI, and therefore can allow upper-layer protocols to elude
with symbolic predicate is encountered, the concolic execution DPI (e.g., HTTP, HTTPS).
engine first uses the concrete value to decide which path to go; We assume that the DPI engine has its own TCP implemen-
subsequently, it also tries to generate a new concrete value for tation that can reassemble and cast the captured IP packets into
the opposite branch. When a particular part of the code or a TCP data streams. It then performs checks on the reassembled
function may cause path explosion or if the constraint solver data streams for whatever is needed based on the function of
is unable to or inefficient in solving, it can switch to concrete the middlebox (e.g., censorship, network intrusion detection,
execution which prevents forking and constraint solving, and etc.), and its behavior is deterministic. We also assume that
switch back at a later time. However, this may cause a loss in the inspections will lead to observable effects, e.g., blocking
terms of both completeness and soundness as a trade-off [4]. or resetting of a connection, if an alarm is triggered; otherwise
Most of the state-of-the-art symbolic execution engines like we cannot tell whether an eluding attack is successful or not.
Angr [40] and S2E [17] support concolic execution.
The goal of a host (e.g., client) is to elude inspection
Selective symbolic execution [17] further extends the of the DPI engine, by sending carefully crafted packets that
idea of concolic execution and makes it more flexible and exploit discrepancies between the TCP implementation of a
practical for testing large and complex software (like an DPI and that of the host on the other end (e.g., server),
operating system kernel). In particular, a selective symbolic prior to sending the sensitive content. For ease of discussion,
execution engine allows the testing of only a sub-system of a throughout the rest of the paper, we consider the client to be
program (e.g., the TCP implementation). This is achieved by the one attempting to elude the inspection unless otherwise
transitioning between the concrete mode (where most symbolic explicitly stated. We consider the DPI’s TCP implementation
variables already have concrete values) and the symbolic mode to be a blackbox, and thus, the client can send only probe
as follows: packets. The responses (or lack thereof) to the probe packets
allows the client to infer the state of DPI’s TCP state machine.
• Transition from concrete to symbolic: the engine symbolizes We assume that the server uses a publicly available TCP stack
the inputs of the scope (data coming into the scope), such implementation (e.g., Linux), and thus, the client can perform
as function parameters, to offer the possibility of exploring analysis as a whitebox. These assumptions also imply that the
all execution paths within the scope at the cost of under- server is not colluding with the client by using a specialized or
constraining, i.e., losing additional constraints imposed over custom TCP stack as otherwise arbitrary covert channels can
the inputs from external components. be established [33].
• Transition from symbolic to concrete: the engine concretizes
symbolic variables, which can cause over-constraining as we
are arbitrarily choosing one of the possible values to assign B. Problem Definition
to any symbolic variable and this can harm completeness. Conceptually, an evasion packet is a TCP packet that is
accepted by the server but dropped/ignored by the DPI engine.
S2E [17] is a representative system that combines selective Similarly, an insertion packet is a TCP packet that is dropped
symbolic execution with whole-system emulation to test the by the server but accepted by the DPI engine. However, such
Linux kernel. Its performance of symbolic execution is con- a definition is imprecise. In this section, we aim to provide a
trolled by selectively running part of the code of interest more precise definition of the concepts we use in this work,
(e.g., specific functions) in symbolic mode while keeping most as well as the problem that S YM TCP solves. First, we define
other parts and the external system running in the concrete what are accept and drop attributes associated with a packet.
mode. S2E provides different levels of execution consistencies
that allow trade-offs between performance, completeness, and TCP State Machine. Conceptually, each TCP implemen-
soundness of analyses. tation can be modeled as a deterministic Mealy machine,
In our solution, to address the complexity of real-world M = (Q, q0 , Σ, Λ, T, G) where
TCP implementations, we employ the selective symbolic ex- • Q is the set of states,
ecution feature in S2E to effectively explore the TCP imple-
mentation in the Linux kernel. • q0 ∈ Q is the initial state,

3
 • Σ is the input alphabet, i.e., a TCP packet, Let Ms be the TCP state machine of the server and Md be
the TCP state machine of the DPI engine. For simplicity, we
• Λ is the output alphabet, i.e., the TCP data payload, assume Ms and Md have the same input and output alphabet.
• T : Q × Σ → Q is the state transition function, and Although the set of states of Ms and Md are different, we as-
sume that their initial states (q0 ) are the same, i.e., the LISTEN
• G : Q × Σ → Λ is the output function. state. Given a state q of a TCP state machine M and a sequence
Compared with a traditional deterministic finite state machine, of packets P1...n ∈ Σ∗ , we denote TM (q, P1...n ) as the state
the output of the Mealy machine is determined by both its transition from q after handling P1...n , and GM (q, P1...n ) as
current state and the current inputs. Note that in this work, the generated TCP data stream to the application layer.
we define the output of a TCP state machine M as the Because the goal of the DPI’s TCP layer is to extract
output to the buffer that stores data which will be used by the the data stream from the monitored TCP session between the
application layer (i.e., payload), instead of the response packet. client and the server, we define the concept of “synchronized”
The reasons are that (1) DPI’s detection of sensitive keywords for the ease of discussion.
is strictly on the application layer payload, and (2) the TCP
layer of the DPI engine will not generate any TCP level output Definition 3: Synchronized. Given a sequence of packets
like ACK packets. This model allows us to unify the definition P1...n ∈ Σ∗ , we say that the DPI engine’s TCP state machine
of state machines for both the DPI and an endhost. We also Md is synchronized with the server’s state machine Ms if and
simplify the output behavior as follows: as long as the data only if the generated (application) data streams from the initial
payload will be output to the application layer, even in a LISTEN state are the same for both i.e.,
delayed manner, we consider that the packet generates a non- GMs (q0 , P1...n ) = GMd (q0 , P1...n ) (3)
empty output.
At a high-level, what insertion and evasion packets aim to
Definition 1: Drop. Given a TCP state machine M , a packet achieve is to “de-synchronize” the TCP state machine of the
P ∈ Σ is dropped if it neither causes a state change nor server (Ms ) from that of the DPI engine (Md ),1 so that the
generates any output. Here the state can be either the high- payload with sensitive information will not be output to the
level TCP states (e.g., LISTEN, ESTABLISHED), or low- application layer filters for inspection. However, because the
level/implementation-level states (e.g., the number of challenge DPI engine is a black box in our threat model, whether the two
ACKs that have been sent [13]). state machines have been de-synchronized can only be inferred
T (q, P ) = q ∧ G(q, P ) = ε (1) from the behavior of application layer filters (e.g., the decision
to block or reset a connection after sending a probe packet). To
Correspondingly, we define drop paths as the program paths of model such behaviors, we define an abstracted filter function.
a TCP implementation that free an incoming TCP packet with-
out changing the current state of a TCP session or producing Definition 4: Bad Keywords and Alarm. For simplicity, we
any output. To identify drop paths in practice, we also define use bad keywords to represent any content that can trigger an
drop points as the program points or statements where any path alarm, and we assume that the entire content fits into a single
that traverses it would become a drop path. In the Linux kernel TCP packet for the ease of discussion (but we can also support
we analyzed, we manually labeled 38 unique drop points in keywords which are split into multiple packets). Given a packet
total (more details in §VIII). Note that a single drop point may P containing a bad keyword, a filter function F : Λ → {0, 1}
correspond to many different packet instances. For example, a performs arbitrary checks over its data payload.
packet with “bad checksum” can have arbitrary SEQ or ACK
numbers, as well as arbitrary TCP headers. 
1 if G(q,P) contains any bad keyword
F (G(q, P )) =
Definition 2: Accept. Given a TCP state machine M , a packet 0 otherwise
P ∈ Σ is accepted if it causes a state change (including both a (4)
high-level, TCP state change and a low-level, implementation- The function applies to both DPIs and servers.
specific state change) or the output is not empty:
Definition 5: Evasion Packet. Given a sequence of packets
T (q, P ) 6= q ∨ G(q, P ) 6= ε (2) P1...n ∈ Σ∗ , we say that the last packet Pn is an evasion
packet if the following three requirements are satisfied. 1 The
Correspondingly, we define accept paths as the program paths server will accept every packet P1...n (Definition 2). 2 When
of a TCP implementation that change the current state of a handling P1...n−1 , the state machine of the server and the DPI
TCP session or append the payload of a TCP packet to the engine are synchronized (Definition 3). 3 Once Pn is sent,
receive buffer. Technically, all paths that are not drop paths the two state machines would be “de-synchronized” as the DPI
are considered accept paths; equivalently, any path that does engine will drop Pn (Definition 1) and thus fail to output the
not traverse any drop point is considered an accept path, and payload of Pn or its follow-up packets (as Pn itself may not
can be therefore be identified automatically. be a data packet). Let Pn+r be the data packet that contains
Next, we note that any evasion or insertion packet needs to the bad keywords (r = 0, 1, ...), we have:
be sent along with other packets in a sequence (e.g., the TCP GMs (TMs (q0 , P1...n+r−1 ), Pn+r ) 6= ε ∧
handshake, a data packet that contains sensitive keyword), in
GMd (TMd (q0 , P1...n+r−1 ), Pn+r ) = ε
order to discover discrepancies. For ease of exposition, we
first define two shortcut functions for handling a sequence of 1 It is also possible that a packet can be accepted differently, exerting
packets. different effects on the server and DPI; we do find such cases in practice.

4
Fig. 2. Overview of S YM TCP’s Workflow

Unfortunately, as mentioned above, we can only indirectly point (as defined in §III-B) at different TCP states and collect
infer whether the GMd output is empty by means of the the corresponding path constraints. Each path corresponds to
filtering function F . Given this, we use Pn+r as the probe a packet sequence P1...n and the collected path constraints
packet with bad keywords in the payload, and change the are later used to generate concrete test packets for differential
requirement 3 to: testing, i.e., serving as candidate insertion/evasion packets.
F (GMs (TMs (q0 , P1...n+r−1 ), Pn+r )) = 1 ∧ Figure 3 illustrates some example packets that reach drop
F (GMd (TMd (q0 , P1...n+r−1 ), Pn+r )) = 0 (5) points (Definition 1: the packets do not have any effect and are
simply discarded and optionally ACKed) and some example
Note that our definition of evasion is purely based on the packets that reach accept points (Definition 2: advancing the
outputs to the application layer and thus, is more strict. TCP state machine or causing data to be accepted). Note that
Specifically, P1...n−1 may already have triggered discrepan- our analysis will always start from the TCP LISTEN state
cies between Ms and Md (they are accepted and processed and end with the TCP ESTABLISHED state as it represents
differently on the DPI and server); however, without triggering the complete window of opportunity to inject insertion/evasion
observable behavioral changes at the application layer, we packets. For instance, it has been reported in [48] that if a
cannot ascertain that such packet(s) are evasion packet(s). Note client sends a SYN-ACK to a server in the LISTEN state,
that the requirement 2 and 3 together explicitly exclude the the server will drop the packet (and send a RST) whereas
cases that P1...n−1 already ends with an evasion or insertion the Great Firewall of China (GFW) will be confused into
packet. thinking that the client is the server. Such a SYN-ACK packet
is effectively an insertion packet that allows the client to
Definition 6: Insertion Packet. Given a sequence of packets then move on with the normal three-way handshake and start
P1...n ∈ Σ∗ , we say that the last packet Pn is an insertion sending data unchecked (Definition 6). Another example is
packet if the following three requirements are satisfied. 1 a SYN packet containing a data payload, which is allowed
The server will accept every packet P1...n−1 but will drop Pn by the TCP standard (the payload will be buffered until
(Definition 1). 2 When handling P1...n−1 , the state machine of the completion of the three-way handshake), but a DPI may
the server and the DPI engine are synchronized (Definition 3). incorrectly ignore it [37], making this packet an evasion packet
3 Pn will “de-synchronize” the two state machines as the (Definition 5). We do not wish to advance the server’s state
DPI will accept Pn (Definition 2), which has to be inferred beyond ESTABLISHED (e.g., TIME_WAIT) because we can
through some follow-up probe packets Pn+1...n+r where the then no longer deliver data.
last packet Pn+r contains bad keywords (r = 1, 2, ...) (same
as Equation 5). Pn+1...n+r−1 are needed for the purpose of Offline phase: In brief, the offline concolic execution
reaching the ESTABLISHED state. engine first boots a running Linux kernel with a TCP socket in
Goal. Given the above definitions, the goal of S YM TCP is the LISTEN state. Then we feed it with multiple symbolized
to automatically find packet sequences P1...n where the last packets to explore the server’s TCP state machine as exhaus-
packet Pn is an evasion/insertion packet. tively as possible. The primary output of this phase is the
sequence of candidate insertion/evasion packets in the form of
symbolic formulas and symbolic constraints that describe what
IV. W ORKFLOW OF S YM TCP possible values the TCP header fields should take (including
An overview of S YM TCP’s workflow is depicted in Fig- the constraints that describe the inter-relationships between
ure 2. The workflow is divided into an offline selective concolic packets). Note that each packet sequence will contain at most
execution phase and an online testing phase. The inputs of the one packet that reaches a drop point. This is because each
offline phase include a set of initial seed TCP packets (e.g., such a “drop packet” by itself does not impact the TCP state
initial SYN) that can drive the concolic execution engine, and machine whatsoever; thus, a sequence with two (successive)
a manually curated list of accept and drop points of a Linux “drop packets” is equivalent to two sequences each with a
TCP implementation (as defined earlier). single “drop packet” (i.e., splitting the original sequence).
The shorter sequences are discovered first with the symbolic
During the offline phase, by running concolic execution execution engine—we use a strategy similar to breadth-first
on the server’s TCP implementation, we attempt to gather all search to discover sequences of packets and limit the total
execution paths (if possible) that reach an accept or a drop number of symbolic packets to be practical (more details

5
 SYN packet w/ bad checksum
SYN packet w/ unsolicited MD5 option Packet #1 e.g. SYN packet
LISTEN SYN/FIN packet
SYN/RST packet
... Server Drop Server Accept
SYN packet w/o data
SYN packet w/ data
... SYN packet DPI Drop DPI Accept DPI Drop DPI Accept
ACK packet w/ bad ACK number
ACK packet w/ bad SEQ number
SYN_RECV
ACK packet w/ bad timestamp
ACK/RST packet
ACK packet w/ exact SEQ and ACK ... Packet #2 e.g. ACK packet
ACK packet w/ SEQ-in-window data
... Data packet w/ bad SEQ number
Data packet w/ bad ACK number Server Drop Server Accept
Data packet w/ bad timestamp
ESTABLISHED
RST packet w/ bad SEQ number
RST packet w/ unsolicited MD5 option DPI Drop DPI Accept DPI Drop DPI Accept
Data packet w/ exact SEQ and ACK ...
Data packet w/ in-window SEQ and ACK
Data packet w/ FIN flag
Partial in-window data packet
...
Packet #3 e.g. data packet
Legend
ESTABLISHED/ Accept packet
Data Recved
Drop packet Server Drop Server Accept

Examples: { Pic(SYN/bad checksum) } DPI Drop DPI Accept DPI Drop DPI Accept
                  { Pec(SYN/data), Pic(ACK/bad ACK number) }
                  { Pec(SYN/no data), Pec(ACK/SEQ-in-window data), Pic(Data/unsolicited MD5 option) }

Insertion Packet Evasion Packet

Fig. 3. Candidate packet generation with symbolic execution. Pic denotes
candidate insertion packet, Pec denotes candidate evasion packet
Fig. 4. Evaluation of insertion/evasion packet candidates

in §V); thus, the longer sequence containing multiple drop

a drop point, we will treat it as a candidate insertion packet
packets is unnecessary and redundant. In contrast, different
and probe the DPI to see whether it causes the DPI to later
paths reaching the same accept/drop point are not redundant
ignore the data packet with a known bad payload (Definition
and can represent distinct events. For instance, as shown
6). For example, a SYN packet with bad checksum will be
in Figure 3, if the current TCP state is SYN_RECV, one can
considered a candidate insertion packet (while the server is in
send two types of ACK packets to advance the TCP state to
the LISTEN state). If the current packet is one that reaches an
ESTABLISHED (both lead to the same accept point): (1) an
accept point such as a SYN packet with data (as in the example
ACK packet with a 0-byte of payload (where the SEQ and
mentioned earlier), we will feed it to the DPI and observe
ACK number match exactly what are expected), or (2) an ACK
whether it qualifies as an evasion packet (Definition 5). If the
packet with an in-window payload (as long as the END SEQ
DPI accepts the packet just as the server (which is the common
is greater than the expected SEQ number). They correspond
case as a DPI typically is lenient in accepting packets [37]), we
to two different accept paths that represent two distinct ways
will move on to the next packet and repeat the process. Note
of moving the TCP state forward. Discovering these different
that for different sequences of packets that share the common
paths is critical as not all paths are handled equivalently by
prefix packets, we only need to evaluate the common packets
the DPI (thus leading to possible evasion opportunities).
once (as candidate insertion or evasion packets).
An additional output of the offline symbolic execution
engine (as shown in Figure 2) is that for each sequence of V. T HE O FFLINE P HASE : P RACTICAL C ONCOLIC
candidate packets, there is a corresponding TCP connection E XECUTION ON THE TCP IMPLEMENTATION
state that the server will end up in after the sequence of
packets is consumed. Recording this information facilitates Our solution is built on top of the popular concolic execu-
the generation of follow-up probe packets. For example, if tion engine S2E [17] that is capable of analyzing OS kernels.
the sequence of candidate packets is a single TCP SYN with The challenge is that a full-size TCP implementation has a
a bad checksum, then we know that the server will stay in rather complicated finite state machine (especially with the
the LISTEN state; therefore a proper three-way handshake is low-level states). Thus, applying concolic execution on the
needed before we can send a data packet to check if the DPI same is extremely challenging. We describe how we tackle the
was confused by the initial candidate insertion packet. more detailed challenges in this section. Specifically, in §V-A,
we describe how we employ selective concolic execution to
Online phase: During the online phase, we attempt to bound the symbolic execution space. In §V-B, we describe
concretize these candidate insertion/evasion packets by adding how we symbolize the input, i.e., the fields in the TCP header
additional constraints (more details to follow in §VI). One such and options. In §V-C, we discuss how we abstract checksum
constraint is the server’s initial sequence number (which is functions in TCP. Finally, in §V-D, we discuss how to deal with
randomly generated every time we probe the server). Once the server-side inputs (specifically, the sequence number used by
constraint solver generates the sequence of concrete candidate the server) that are not known a priori.
insertion/evasion packets, they are fed to the DPI prober
(together with the follow-up packets). A. Selective Concolic Execution Favoring Completeness
We illustrate the process in Figure 4. For each sequence Because it is heavyweight, we want to run symbolic execu-
of packets, we start from the first packet and perform probes tion only on the TCP code base; for the rest of the system, we
according to the current packet. If the current packet reaches seek to use concrete execution to reduce complexity. To realize

6
this vision, we need to define the boundary between where destination port numbers. The symbolized fields include the
symbolic execution and concrete execution are applied. One sequence number, acknowledgment number, data offset, flags,
way to achieve this is to perform a fine-grained, function-level window size, checksum, and urgent pointer. In addition, we
analysis to identify those functions that are related to the TCP want to symbolize TCP options, which refers to the last part
logic, but this will require a prohibitively expensive manual of the TCP header and has an associated variable length.
effort. To solve this problem, we use a more conservative,
coarse-grained boundary, which is the entire net/ipv4 compila- Symbolizing the TCP options field is intrinsically hard
tion unit (object file) in Linux. When we are inside the address because it consists of a list of nested TLV (Type-Value-
space of the net/ipv4 compilation unit, we run the code with Length) structures. Currently there are 35 existing TCP option
symbolic execution and enable forking. When we are outside related numbers assigned by IANA [24], including those that
this address space, we run the code concretely with forking are standard and others that are obsolete, and the number
disabled, but still keep the original constraints (as is supported is growing. Some options have associated fixed lengths, and
by S2E). The benefit of this is that we do not lose the symbolic some are of variable length (e.g., SACK). Some options have
expressions when switching back from the concrete mode to associated subtypes (e.g., MPTCP). Although the maximum
the symbolic mode. S2E also maintains a concrete value for length of the TCP option field is 40 bytes, the number of
each symbolic variable and these will be used during concrete combinations of all top-level option types is still huge. The
execution. The concrete values are generated by constraint problem worsens if we also include illegal cases (e.g., an
solving at the first time they are accessed in the concrete option appears multiple times) or also want to consider the
execution. We emphasize that this is different from applying ordering of the options.
pure concrete execution from the beginning; switching from Linux only implements 10 TCP options using a parsing
the symbolic to the concrete mode still retains the symbolic loop, which can still easily cause the path explosion problem.
variables and propagates them during concrete execution. Theoretically there are at least 210 = 1024 execution paths
By default, even when running in the concrete mode, S2E even if we just execute the loop once. In practice, when
collects path constraints as the concrete branches are taken it is compiled into a binary form, additional branches are
(standard in concolic execution [4]). The reason for doing so introduced; hence, the number of possible paths is much larger.
is that during concrete execution, only one branch is taken, The problem is exacerbated exponentially given the already
and the result is bound to that branch. However, this will large number of paths that exist in the TCP logic. Because of
result in the previously discussed “over-constraining” problem these reasons, we need to bound the search space by limiting
(in §II), i.e., forcing certain branches to be taken (because the number of possible combinations of TCP options.
of the concretization when switching to concrete execution). While we attempted to bound the loop execution times and
More importantly, our focus is on the TCP code base only, and the number of occurrences of each TCP option, we found that
the executions outside of our scope are irrelevant (regardless of the number of paths was still prohibitively large even if we
which paths were taken). We therefore discard any constraints executed the loop just once and allowed each option to occur
collected during the concrete execution mode. For example, at most once. Hence, as a practical means to mitigate this
the netfilter module outside the TCP code base will read problem, in addition to bounding the execution times, we also
the symbolic TCP header fields and introduce constraints. feed a specific combination of TCP options as a seed (from
However, the execution results of netfilter do not affect the traffic observed on the Internet) to our concolic execution
main TCP logic at all, and therefore we can safely ignore those engine; the execution explores our seed value first and then
constraints. Specifically, the netfilter ConnTrack module tracks other values.
the TCP connections passively and maintains connection states
separately from the main TCP logic. Therefore, its execution
is insignificant — even if we ignore its constraints and force C. Abstracting the Checksum Function
a different execution path, it would have no consequence on The TCP checksum is calculated based on a pseudo-header
the main TCP states we are interested in exploring. that includes the IP addresses, the entire TCP header and the
payload. As mentioned earlier, we do not want to symbolize
B. Symbolizing the TCP Header and Options the IP header or the payload since this is likely to harm the
symbolic execution performance. Thus, instead, we abstract
0 8 16 24 32
the checksum validation function as follows:
Source Port Destination Port

Sequence Number 
true if header.checksum == 1
Acknowledgment Number 20 bytes f (pkt) =
Data C E U A P R S F
f alse if header.checksum == 0
Reserved W C R C S S Y I Window Size
Offset R E G K H T N N

Checksum Urgent Pointer where f denotes the checksum validation function and pkt
Options (if any) n bytes
is the network packet under consideration. If the checksum
field in the TCP header is equal to 1, then it is considered to
Fig. 5. Symbolized TCP header and options. be a valid checksum; if it is equal to 0, then it is an invalid
checksum. The constraint solver thus generates a checksum of
Since we limit our scope to TCP-level insertion and evasion 1 for a valid checksum case, and 0 for an invalid checksum
packets, we only symbolize the TCP header of a packet (not case. When we probe the DPI (discussed later), we fill the
the IP header or the application payload) (see Figure 5). checksum field with either the proper valid or an invalid check-
We symbolize all TCP header fields except the source and sum, correspondingly. By abstracting the checksum function,

7
we avoid solving complex constraints on the TCP header fields There are two additional constraints. The first is the server’s
and thus improve performance. initial sequence number (ISN) as mentioned in §V-D. The
second includes additional constraints on TCP flags, SEQ and
D. Symbolizing the Server’s Initial Sequence Number ACK numbers. These are especially necessary for candidate
insertion packets when a packet hits a drop point early (and
During TCP’s 3-way handshake, the server’s initial se- practically most fields are unconstrained). For example, if a
quence number (ISN) is a random number generated and packet is dropped because of an unsolicited MD5 TCP option,
sent in the SYN/ACK packet to the client. When the client then it has no constraint on TCP flags, SEQ or ACK number.
receives the SYN/ACK packet, it needs to echo the server’s Since the hope is that the error is ignored by the DPI (not
ISN by sending an ACK packet with an acknowledgment checking the MD5 TCP option), these other fields will have a
number that is equal to the server’s ISN plus 1. Because the direct effect on how the DPI processes the packet. Our solution
server’s ISN is randomly generated for each TCP connection, in such cases is to generate these constraints to make the
we need to symbolize the server’s ISN in the offline symbolic packet as legitimate as possible (i.e., with the correct SEQ
execution phase and collect the path constraint that expresses and ACK number). For TCP flags, we just enumerate the
the relationship between the server’s ISN and the client’s most common ones, which are more likely to be accepted
acknowledgment number. Then in the online probing phase by the DPI (SYN, SYN/ACK, ACK, RST, RST/ACK, FIN,
(§VI), we constrain the server’s ISN using the concrete value FIN/ACK). For example, we may generate a RST packet with
obtained from the SYN/ACK packet, and generate concrete an unsolicited MD5 option (with the additional constraint of
values for the client’s packets on the fly. the SEQ number to match the next expected one). The server
of course will reject the packet but the DPI will accept it and
E. Multi-round Symbolic Execution terminate the connection incorrectly, allowing subsequent data
to pass through unchecked. For candidate evasion packets, we
As mentioned earlier in §IV, we start our symbolic execu- do the opposite by generating random values of various fields
tion from the LISTEN state. We symbolize multiple packets and hope that it will be ignored by the DPI. Note that since
in order to explore the state machine in more depth (up to the an evasion packet is to be accepted by the server, most of the
ESTABLISHED state). Specifically, we choose to symbolize fields are already constrained and so we do not have much
3 packets in total for several reasons. First, 3 packets should room to select the values of different fields.
offer a reasonable coverage of the TCP state machine because
only 2 packets are needed to advance the TCP state from B. Constructing follow-up probe packets
LISTEN to ESTABLISHED (the SYN and ACK in a three-
way handshake); the third packet can further explore other As mentioned in §III-B, after sending a candidate evasion
minor states in ESTABLISHED. Second, we prefer shorter or insertion packet, we may still need to craft additional follow-
sequences of insertion and evasion packets as longer sequences up packets that contain bad keywords targeted by the DPI, in
can be unreliable in practice (e.g., due to packet losses). order to infer if there is any state discrepancy between the DPI
and server (otherwise there is no observable feedback).
To explore different sequences of packets, we develop a
custom path searcher/scheduler to guide S2E to explore packet To construct follow-up packets, we need to know the
sequences of 1 and 2 first (up to certain threshold), and then current state of the TCP connection. If the current TCP state
allow the third packet to arrive. is not in the ESTABLISHED state, we need to send packets
that cause it to transition into it. If the current TCP state is
As discussed later in §VIII, even though there are not many already the ESTABLISHED state, then we can directly send
accept and drop points in TCP, the number of possible accept the data packet with the correct sequence and acknowledgment
and drop paths is exponential and impossible to exhaust in our number. Due to this reason, we log the current TCP state after
experiments, which motivated our search strategy to balance processing each packet during symbolic execution. Based on
the exploration of sequences of different lengths. this, we use a simplified version of the TCP state machine to
generate the follow-up packets for transitioning the connection
VI. G ENERATING ONLINE EVASION ATTACKS from the specific TCP state to the ESTABLISHED state if need
be. Subsequently, we send a data packet with the sensitive
By means of the offline concolic execution phase described payload, and observe if it triggers any alarm on the DPI.
in §V, S YM TCP obtains path constraints that can be used to
generate insertion/evasion packet candidates. In this section,
we describe S YM TCP’s differential testing phase to probe the VII. I MPLEMENTATION
DPI to identify behavioral discrepancies between the DPI’s Our system is built upon S2E 2.0 [17], which uses KLEE
TCP implementation and that of the server. as its symbolic execution engine. We implement S YM TCP as
a set of S2E plugins written with around 2.5K lines of C++,
A. Constructing insertion/evasion packet candidates and the probing and peripheral scripts were written with around
6.5K lines of Python.
Armed with the constraints relating to each execution path
collected during the symbolic execution, as described in §V, A. Selective Concolic Execution
together with some additional constraints, we can then feed
these to a constraint solver to generate concrete values of We start the selective concolic execution whenever
TCP header fields. Using those values, S YM TCP constructs tcp_v4_rcv() is entered, where the TCP header fields are
a sequence of packets, P1...n (n ≤ 3), to probe the DPI. symbolized. When the current program counter is outside the

8
 TABLE I. A SUMMARY OF LABELED DROP POINTS
TCP scope, i.e., it leaves the tcp_v4_rcv function or it
wades into some other territory (e.g., netfilter), we disable Reason Count
TCP checksum error 5
forking to let S2E run in a way similar to concrete execution, TCP header length too small 1
except that it still maintains and propagates symbolic variables. TCP header length too large 4
In this way, we can switch from symbolic execution to concrete MD5 option error 2
TCP flags invalid 7
execution and later switch back to symbolic execution again. In SEQ number invalid 10
addition, we modify KLEE to prevent it from adding branch ACK number invalid 3
Challenge ACK 6
conditions to the path constraints when forking is disabled; Receive window closed 2
thus, it does not over-constrain the symbolic variables. Empty data packet 1
Data overlap in OFO queue 1
S2E only instruments basic blocks and instructions but PAWS check failed 2
Embryonic reset 1
not the edges connecting basic blocks. However, in Linux TCP DEFER ACCEPT drop bare ACK 1
TCP implementations, often it is the edge that determines the TCP Fastopen check request failed 1
reason for acceptance or rejection; for example, an if and Total number 47
goto statement can enter the same exact basic block, but
representing different reasons (acceptance or rejection). Thus, TABLE II. P ERFORMANCE OF OFFLINE SYMBOLIC EXECUTION
we also instrument the edges and implement an event. Finally,
we bound the number of loops that can be traversed and the # of 20-byte TCP pkts 40-byte TCP pkts 60-byte TCP pkts
number of occurrences of TCP options, by limiting the number pkts Time Covered Time Covered Time Covered
to cover drop points to cover drop points to cover drop points
of executions of related edges of interest — we allow at most 1 5s 8 5s 9 10s 8
5 TCP options in a packet, and each TCP option only occurs 2 20s 16 20m 19 18m 18
once, except the NOP option. We do not encounter any other 3 50s 31 1h2m 39 40m 38

loops where the number of iterations is symbolic. Time cost could vary due to randomness in path selection of symbolic execution.

We only consider drop points in the TCP LISTEN,

B. Online Constraint Solving SYN_RECV, and ESTABLISHED states. Because we assume
We use the state-of-the-art Z3 [50] theorem prover as the server doesn’t initiate a connection, we know that it will
our online constraint solver to generate concrete values of not go into the SYN_SENT state. In other TCP states such
TCP header fields. As mentioned previously, if we receive as TCP_CLOSE, the server will not accept any further data
a SYN/ACK packet from the server, we then add its initial packets. We also excluded some cases that are not practical
sequence number to the constraint and consult Z3 again to gen- for insertion packets: 1) a packet dropped due to memory
erate new concrete values for the following probing packets. allocation failures because it is rare to encounter memory
This is because the following packets will need to acknowledge pressure on the server; 2) a packet dropped due to listen queue
that number. Note that when we consult the constraint solver overflow, which is not a common case; 3) a packet dropped
multiple times (to generate subsequent packets), we need to due to SELinux check failed; 4) a packet dropped due to Xfrm
carry over the concrete values generated for the previous check failed; 5) a packet dropped due to socket filter; 6) a
packets in order to maintain consistency. For example, the packet dropped due to route error or no route; 7) a few other
first packet has a payload of 4 bytes, and the second packet’s minor cases, e.g., unusual server configurations.
sequence number needs to advance by 4. As a result, we eventually labeled 38 places in the source
code where a packet gets dropped without changing states.
VIII. E VALUATION Because S2E works on the binary level, we map the source
code lines to binary addresses, and they are mapped to 47
Our evaluations of S YM TCP are run on an server with binary level drop points (as one source-level conditional state-
72 cores Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz, and ment can be translated into multiple basic blocks in binary) as
256GB memory. The host OS is Ubuntu 16.04 64-bit, and the summarized in Table I. To save space, we put the raw table in
guest OS is Debian 9.2.1 64-bit. We evaluate our system with an appendix.
Linux kernel version 4.9.3. We run S2E in parallel mode with
48 cores, which is the maximum number of processes S2E Currently, we use two seed packets as inputs to the sym-
currently supports. bolic execution: 1. a SYN packet with all 0s in its TCP option
fields; 2. a SYN packet with a TCP Timestamp option turned
on. In practice, with 1, we can cover most drop points and
A. Experiment Setup accept points but can rarely cover the 2 drop points related
to the TCP Timestamp option. With 2 as another seed packet,
Before evaluating the system, we first manually label all we are able to cover all drop points and accept points easily.
the drop points reachable from tcp v4 rcv() which is the We believe that the complete coverage of all accept and drop
TCP-level entry function for processing incoming packets. points is a good indication of our results.
Specifically, in the Linux kernel, since an incoming packet will
eventually be freed after being processed via kfree skb(), We employ an HTTP request with bad keyword “ultrasurf”
we inspect all invocations of it in the TCP implementation in our experiment:
(both direct and indirect through wrapper functions kfree skb
GET /AA...A#ultrasurf#<test_case_id>#
and tcp drop), and identify the program points or the branch
HTTP/1.1\r\nHost: local_test_host\r\n\r\n
statements (transitions between basic blocks such as if) that
satisfy the definition of a drop point (see §III-B). “A” is used to pad the HTTP request so that the first n

9
 TABLE III. I MPORTANT ACCEPT POINTS IN L INUX KERNEL V 4.9.3
packets before the follow-up packet will not contain the bad
keyword (by definitions in §III-B the first n packets may be Source file Line # TCP State Major Reason
accepted by the DPI). It is the follow-up packet that will carry tcp input.c 4461 Non-LISTEN OFO: Initial out of order segment
the bad keyword “ultrasurf” and the remaining part of the 4477 Non-LISTEN OFO: Coalesce
4533 Non-LISTEN OFO: Insert segment into RB tree
request. 4684 Non-LISTEN In sequence. In window.
6408 LISTEN Enter SYN RECV
tcp minisocks.c 773 SYN RECV Enter ESTABLISHED
B. Symbolic Execution Results
In our experiments, we send symbolic packets with 20,
40, and 60 bytes in total, including the TCP header and to probe the DPI. This dataset includes 56,787 test cases
the payload. As discussed in §V-B, since we symbolize the generated in around one hour which covers 37 drop points
TCP data offset header field, the length of the TCP header is in binary (after filtering infeasible drop points).
variable. For example, if we send a TCP packet of 60 bytes, Since the original dataset is too large, we cull out 10,000
it always has a 20-byte TCP basic header, and the length of test cases by sampling the dataset, and then use the sampled
the TCP option can vary between 0 and 40-byte. As a result, dataset to probe the DPI. The original dataset is highly
the rest will be the TCP payload (from 0 to 40 bytes as well). imbalanced, ranging from 2 to 9,790 test cases for different
We choose not to symbolize the length of the entire packet or drop points. To make it more balanced, we undersample the
the payload because more or fewer bytes in the payload does majorities while keeping the minorities intact. We order the
not really affect how TCP accepts or drops a packet. drop points by the number of their corresponding test cases,
As shown in Table II, when we send 1 symbolic packet, we and use the 50th percentile as a threshold. For the drop points
can cover only 8/9/8 drop points with a TCP packet of 20/40/60 whose corresponding numbers of test cases are below the
bytes. By comparing the drop points covered, we found that threshold, we keep them intact; for the ones above the thresh-
the 40-byte case can cover one more drop point than the 20- old, we proportionally sample the test cases corresponding to
byte case, which checks the TCP MD5 option. The 60-byte the overly represented drop points.
case covers one less drop point than the 40-byte case because Finally, since we consider every path not reaching a drop
it misses a drop point when the TCP data offset is larger than point as an accept path, the accept paths can be diverse and
the actual TCP packet size. Because the TCP data offset is by overwhelming in number. To sample them, we explicitly label
design no more than 60, if we pick the actual size of a TCP some important accept points, as listed in Table III, which
packet to be 60, the condition can never be satisfied. Finally, indicates TCP state changes and data entering receive buffer.
by sending 1 symbolic packet, we can only cover drop points During sampling, we group the test cases by the sets of labeled
in TCP LISTEN state. accept/drop points they reached.
When we send 2 symbolic packets, we can cover 16/19/18
drop points with 20/40/60 bytes of TCP options and payload. C. Evaluation against DPI
The increased coverage of drop points is because we can now We evaluated our sampled test set of 10,000 candidate
cover drop points in TCP SYN_RECV and part of them in insertion/evasion packets against 3 DPI systems, 2 open-source
ESTABLISHED. In addition, the 40-byte case covers 3 more NIDSes, Zeek (formerly known as Bro), Snort, and a nation-
drop points related to TCP options, i.e., MD5 and Timestamp. wide censorship system, the Great Firewall of China (GFW).
The 60-byte case still covers one less drop point related to
TCP data offset. We downloaded the latest version of Zeek (2.6) and Snort
(2.9.13) at the time of writing, and conducted the experiment
When we send 3 symbolic packets, we can cover 31/39/38 against the GFW on August 18, 2019.
drop points with 20/40/60 bytes of TCP options and payload.
The increased coverage of drop points are because of more Out of 10,000 test cases, we found 6,082 test cases can
drop points in ESTABLISHED state covered, and also cases evade Zeek, including 5,771 cases caused by insertion packets
like data overlapping. The 20-byte case covers much less since and 311 cases caused by evasion packets; 652 test cases can
it doesn’t send packets with a payload. evade Snort, including 432 cases caused by insertion packets,
and 220 cases caused by evasion packets; 4,587 test cases
We take a further look at the 8 drop points not covered by can evade the GFW, including 1,435 cases caused by insertion
any of our experiments. 2 of them requires the TCP receive packets and 3,152 cases caused by evasion packets. For GFW,
window size becomes 0. That means the server’s receive buffer most of the successful test cases caused by evasion packets
has to be full. This is very hard to achieve in reality and we are due to the “SEQ ≤ ISN ” strategy listed in Table VI,
don’t want to flood the server. 1 drop point requires TCP Fast as a common condition shared by many test cases. For Zeek,
Open to be enabled on the server. The other 5 drop points are though it has a similar “SEQ < ISN ” strategy, most of such
also infeasible due to various reasons. Overall, all 8 uncovered test cases are successful for different reasons, i.e., due to some
drop points are either not of interest or cannot be reached in preceding packets turning into insertion packets (as Zeek has a
reality. Furthermore, we found that 2 of the covered drop points very loose check on incoming packets). For example, the third
are reached when the TCP state is in CLOSE_WAIT, which packet has a SEQ number less than ISN, which is an evasion
we ignore. packet, but the second packet is an insertion packet so the test
case works because of the insertion packet.
Because the 40-byte experiment can already cover all of the
drop points covered by the 20-byte and 60-byte experiments, To reason about the successful test cases and abstract them
we use the dataset generated from the 40-byte experiment into high-level evasion strategies, we conducted postmortem

10
analysis and evasion strategies summarization. For Zeek and server’s receive window, the data will be ignored by Zeek, but
Snort, even though we treat them as blackboxes when generat- Linux will accept the data in window (an evasion packet).
ing candidate insertion/evasion packets, they are actually both
open-sourced, which allows us to pinpoint the underlying cause
of evasion. In order to expedite this process, we replay the E. Snort
successful cases and record the binary execution trace of the
DPI for each case. Then, we group the cases by the execution Snort implements OS-specific TCP state machines, includ-
trace of the data packet containing the sensitive keyword which ing Windows, Linux, and Mac OS; its TCP implementation
evaded the detection of the DPI (the trace therefore explains is the most rigorous among the three DPIs. However, from
why this occurred), For Snort, we additionally record the trace our results, even its Linux version still has discrepancies from
caused by processing the server’s ACK packet as some checks the Linux kernel we analyzed. The strategies we found are
performed on Snort are delayed until the ACK packet is seen. listed in Table V. In general, Snort checks the SEQ number
In the end, we still manually verify the cases within the same for control packets but doesn’t check ACK number. Also, it
group in case they actually belong to different reasons for doesn’t check TCP MD5 option and accepts in-window SYN,
evasion. FIN, and RST packets too liberally. Whenever it receives
an in-window SYN or RST packet, it will tear down the
For GFW, since it is really a blackbox, we have to TCB (matching the behavior of older versions of Linux); and
make hypotheses about the success reasons from prior knowl- whenever it receives an in-window FIN packet, it will mark the
edge [48] and then validate them. Specifically, we first replay connection as CLOSED and discard data which SEQ number
the captured packet traces and verify if the result is stable; this larger than the end SEQ number of the FIN packet. On the
eliminates the noisy results caused by random events such as contrary, the latest Linux doesn’t accept any SYN packet in
packet loss or GFW overload. Then we slightly tweak the TCP ESTABLISHED state, and requires SEQ number of FIN or
header fields of the insertion/evasion packet and then replay RST packet to be equal to rcv_nxt. In addition, Snort also
the modified packet trace. If it cannot work, then it’s likely the accepts FIN or RST packet with out-of-window ACK number
discrepancy is caused by that field. or TCP MD5 option, which will be discarded by Linux. Most
of these strategies have also been mentioned in [37] (though
We summarize a few featured evasion strategy (not a not all of them are tested in practice), and the usage of TCP
complete list) for each DPI in the next few sections. Overall, MD5 option was done in [48].
we not only rediscovered already known strategies but also
found 14 novel strategies comparing with previous works using Now we discover two novel strategies unique to the Snort
manually crafted insertion/evasion packets. implementation. The first strategy is related to how Snort
implements TCP Timestamp option validation (it is the only
D. Zeek (formerly known as Bro) DPI we are aware of that attempts to perform timestamp
checks). Interestingly, we found its implementation to be
Zeek [34] is very liberal in accepting incoming packets.2 It slightly different from Linux in 2 ways: 1) Snort doesn’t check
is therefore relatively easy to bypass using insertion packets. timestamp for RST packets in SYN_RECV state (as mandated
We list some strategies in Table IV. In most cases, it only by RFC 7323) while Linux does. 2) In PAWS checking, if the
looks at the TCP flags of a packet but does not check SEQ TSval in the current packet is older than that in the last packet,
or ACK number for TCP control packets, e.g., SYN, RST, it will reject the current packet. However, due to slightly
FIN. This makes many strategies that were previously reported different implementations of the check of Snort and Linux, the
feasible [37], [25], [48]. For example, whenever Zeek receives acceptable TSval ranges are “off by two”. As a result, say if
a SYN packet in an existing connection, it simply tears down the first packet has a TSval of 0x80000000 and the second
the TCB and creates a new one. But Linux doesn’t accept packet has a TSval of 0 or 0xffffffff, then Linux will
out-of-window SYN packets in SYN_RECV state or any SYN accept the second packet, but Snort will reject it. The pseudo-
packets in ESTABLISHED state. As a result, an attacker can code of their implementations can be found in the appendix.
easily inject a SYN packet (as insertion packet) to tear down
the TCB and recreate a TCB with a different ISN that Zeek will The second novel strategy is related to the urgent pointer
keep track of, thus allowing later packets to evade detection. processing logic, which is notoriously ambiguous [36] and
often implemented incorrectly, even in major OSes such as
Another interesting strategy which we have not seen ap- Linux [22]. Simply put, an urgent pointer is supposed to allow
plied (only hypothesized in [37]) in any prior work: TCP RFC TCP to specify some range of data in the payload to be marked
793 allows data in SYN packet to be buffered and delivered as urgent, which will be treated differently when a receiver sees
to the user only when the connection is fully established, but it (e.g., immediately pushed to the application layer using a
Linux doesn’t buffer data in SYN packet unless in the TCP separate interface [22]). In Snort, it interprets the urgent pointer
Fastopen cases. In this case, Zeek correctly implements the as the offset to the last byte of the urgent data and simply
RFC and accepts data in SYN packets. However, this allows discards all of the bytes before this offset. In Linux though,
an attacker to attach junk payload in a SYN packet as “cover” it consumes 1 byte of urgent data (right before the urgent
for the actual data sent in later packets. pointer offset) which is stored in a separate place, and leaves
In addition, we also found a novel evasion strategy that was the remaining payload intact. Our system initially discovered
not mentioned in any prior work: if we send a data packet with an evasion packet with urgent flag and urgent pointer set to
SEQ number less than the client ISN but has partial data in a random location in a packet (which happens to point to
an insignificant padding byte), and therefore preserving the
2 Zeek does log weird packets to a weird.log for offline analysis. semantic and the keyword in the HTTP request. However,

11
 TABLE IV. S UCCESSFUL STRATEGIES ON Z EEK V 2.6

Strategy TCP state Insertion/Evasion packet Linux Zeek

† SYN with data L/SR/E (I) SYN packet with data Ignore data Accept data
† Multiple SYN SR/E (I) SYN packet with out-of-window SEQ num Discard and send ACK Reset TCB
† Pure FIN E (I) Pure FIN packet without ACK flag Discard (may send ACK) Flush and reset receive buffer
† Bad RST/FIN SR/E (I) RST or FIN packet with out-of-window SEQ num Discard (may send ACK) Flush and reset receive buffer
† Data overlapping SR/E (I) Out-of-order data packet, then overlapping in-order data packet Accept in-order data Accept first data
† Data without ACK SR/E (I) Data packet without ACK flag Discard Accept
† Data bad ACK E (I) Data packet with ACK > snd nxt or < snd una - window size Discard Accept
∗ Big gap SR/E (I) Data packet with SEQ > rcv nxt + max gap size (16384) Accept Ignore later data
∗ SEQ < ISN SR/E (E) Data packet with SEQ num < client ISN and in-window data Accept in-window data Ignore
* TCP State: L - Listen, SR - SYN RECV, E - ESTABLISHED. (I) - Insertion, (E) - Evasion. † - Old strategy, ∗ - New strategy.

TABLE V. S UCCESSFUL STRATEGIES ON S NORT V 2.9.13

Strategy TCP state Insertion/Evasion packet Linux Snort

† Multiple SYN E (I) SYN packet with in-window SEQ num Discard and send ACK Teardown TCB
† In-window FIN E (I) FIN packet with SEQ num in window but 6= rcv nxt Ignore FIN (may accept data) Cut off later data
† FIN/ACK bad ACK E (I) FIN/ACK packet with ACK num > snd nxt or < snd una - window size Discard (may send ACK) Cut off later data
† FIN/ACK MD5 SR/E (I) FIN/ACK packet with TCP MD5 option Discard Cut off later data
† In-window RST E (I) RST packet with SEQ num 6= rcv nxt but still in window Discard and send ACK Teardown TCB
† RST bad timestamp SR (I) RST packet with bad timestamp Discard Teardown TCB
† RST MD5 SR/E (I) RST packet with TCP MD5 option Discard Teardown TCB
† RST/ACK bad ACK num SR (I) RST/ACK packet with ACK num 6= server ISN + 1 Discard Teardown TCB
∗ Partial in-window RST E (I) RST packet with SEQ num < rcv nxt but partial data in window Discard Teardown TCB
∗ Urgent data SR/E (E) Data packet with URG flag and urgent pointer set Consume 1 byte urgent data Ignore all data
before urgent pointer
∗ Time gap SR/E (E) Data packet timestamp = last timestamp + 0x7fffffff/0x80000000 Accept Ignore
* TCP State: L - Listen, SR - SYN RECV, E - ESTABLISHED. (I) - Insertion, (E) - Evasion. † - Old strategy, ∗ - New strategy.

Snort discards all the data before the urgent pointer offset and (including packets of 8 bytes or fewer) only after the 3-way
fails to reconstruct the HTTP request. handshake. This explains why this strategy works perfectly in
SYN_RECV state only.
F. Great Firewall of China The last set of novel strategies are related to tearing down
the state on GFW. First, we found FIN packets or malformed
The GFW conducts a wide range of censorship on different
FIN/ACK packets with data can cause the GFW to tear down
network protocols, such as HTTP/HTTPS, DNS, Tor, etc.
its TCB, but without data it does not work. More interestingly,
Although it has a relatively lenient checking on individual
if we first send some in-order or out-of-order data packets and
packets, it’s known to have some sophisticated and robust
then send the FIN or malformed FIN/ACK packet, the FIN
mechanism to thwart desynchronization attacks according to
or FIN/ACK packet does not have to have data. This seems
recent research [48]. In addition to the strategies that were
to indicate that GFW will agree to accept FIN packets only
previously known, we also identify several novel strategies
after some data have been transmitted (otherwise the FIN is
which we will describe below.
suspicious and will not be accepted). Similarly, we found an
Interestingly, we found that the GFW ignores data packet out-of-window SYN packet with data or a retransmitted SYN
with a start SEQ number less than or equal to the initial packet with data can also desynchronize the GFW (causing it
sequence number (ISN) but has in-window data, whereas to synchronize its expected sequence number to the one in the
Linux accepts the in-window data. Therefore the strategy SYN packet) but they don’t work without data. For RST packet
discovered by our system is to send such an evasion packet with a bad timestamp, it only works in SYN_RECV state since
with a sensitive keyword as in-window data (and with padding Linux only validates timestamp on RST packet in SYN_RECV
automatically prepended to cover the bytes that are out-of- state but not in ESTABLISHED state. None of the strategies
window). were reported in the latest study of GFW [48].
Another interesting and surprising finding is that the GFW Comparing our strategies with previous works on GFW
ignores data segments whose sizes are less than or equal to with manually crafted packets [48], [29], we have rediscov-
8 bytes. This is discovered through a small first data packet ered all the TCP-layer strategies used in [29] (except the IP
(remember each of our packets has a maximum payload length and HTTP layer strategies which are beyond our scope). In
of 20), which is simply ignored by the GFW. Missing the addition, we have rediscovered all the primitive strategies used
first data packet will cause the GFW to miss the fact that in [48], except that they also discovered compound strategies
it is an HTTP request and subsequently ignore the sensitive that can evade multiple types of GFW devices, based on
keyword. However, we found this strategy works perfectly in their manually inferred GFW model. Specifically, Bad RST,
SYN_RECV state only but not ESTABLISHED. To understand Bad Data, and Data without ACK are old strategies, and the
the reason, we conducted further investigation. It turns out that other strategies are all new. Strategies SEQ ≤ ISN and Small
in ESTABLISHED state, this strategy can only evade one type segments are completely new, while the other new strategies
of GFW devices that inject RST/ACK packets, but not the are subtle variations of known strategies that no longer work.
ones injecting RST packets [48]. The GFW devices injecting This demonstrates the power of an automated tool that is
RST packets will establish a TCB and start monitoring payload capable of discovering such subtle variations.

12
 TABLE VI. S UCCESSFUL STRATEGIES ON THE GFW

Strategy TCP state Insertion/Evasion packet Linux GFW

† Bad RST SR/E (I) RST packet with bad checksum or TCP MD5 option Discard Teardown TCB
† Bad data SR/E (I) Data packet with bad checksum or TCP MD5 option or bad timestamp Discard Accept
† Data without ACK SR/E (I) Data packet without ACK flag Discard Accept
∗ SEQ ≤ ISN SR/E (E) Data packet with SEQ num ≤ client ISN and in-window data Accept in-window data Ignore
∗ Small segments SR (E) Data packet with payload size ≤ 8 bytes Accept Ignore
∗ FIN with data SR/E (I) FIN packet with data and without ACK flag Discard Teardown TCB
∗ Bad FIN/ACK data E (I) FIN/ACK packet with data and bad checksum or TCP MD5 option or bad timestamp Discard Teardown TCB
∗ FIN/ACK data bad ACK E (I) FIN/ACK packet with data and ACK num > snd nxt or < snd una - window size Discard Teardown TCB
∗ Out-of-window SYN data SR (I) SYN packet with SEQ num out of window and data Discard and send ACK Desynchronized
∗ Retransmitted SYN data SR (I) SYN packet with SEQ num = client ISN and data Discard Desynchronized
∗ RST bad timestamp SR (I) RST packet with bad timestamp Discard Teardown TCB
∗ RST/ACK bad ACK num SR (I) RST/ACK packet with SEQ num 6= server ISN + 1 Discard Teardown TCB
* TCP State: L - Listen, SR - SYN RECV, E - ESTABLISHED. (I) - Insertion, (E) - Evasion. † - Old strategy, ∗ - New strategy.

IX. D ISCUSSION AND LIMITATIONS terminate any further exploration. We plan to use the result
we obtain from online testing to prune the offline analysis in
Path Explosion. In our evaluation, we show that processing the future.
only three symbolic packets can already lead to path explosion
— tens of thousands of paths (the result of handling three Handling Overlapping Data as Evasion Strategies. Our
packets) generated in an hour. This is because there can model currently does not handle overlapping data well and
be multiple different paths reaching the same drop/accept cannot generate all data overlapping strategies as done man-
point. Each of these paths corresponds to a unique sequence ually in prior work. This is because it is necessary to model
of packets (determined by the path constraints), which may how the TCP implementation evicts data in the buffer. For
potentially lead to various evasion and insertion strategies. example, in certain operating systems, if data overlapping is
detected, they prefer to discard the old copy and accept the
In order to tackle with path explosion, besides restricting new one. More generally, we need to model how a packet
symbolic execution within the scope of TCP code, we have may retroactively change the effect of a previous packet, and
also made some pruning decisions based on our domain at the moment our model assumes the effect of each packet
knowledge. We summarize them in one place as follows is independently exerted and cannot be revoked. We plan to
(details discussed in §IV and §V): 1) bound occurrences of handle this corner case by extending our model as future work.
TCP option fields by allowing each TCP option to occur only
once, since redundant options are not useful in triggering any Extending S YM TCP to Other TCP Implementations /
new code; also we only allow at most 5 TCP options in a DPIs / Network Protocols / Server-side. Although we pick
packet, since most of the options are independent of each other a specific version of Linux kernel to evaluate our system, our
thus complex combinations of options are unlikely useful; system is not restricted to any specific version and can be easily
2) terminate an execution path once reaching a drop point, applied to other versions as well. The minimal requirement is
because packets reaching drop points don’t cause any state to label all drop points, and optionally, some critical accept
changes; 3) terminate an execution path once the connection is points (to group accept paths), as shown in §VIII. Since
in a state that cannot further deliver data, e.g., CLOSE_WAIT; the TCP implementations doesn’t change much across kernel
4) carefully label accept and drop points, we are aiming at version, it should take less efforts for someone with experience
covering all accept and drop points but not all execution paths, to label another version. It took us less than an hour to
therefore reduce the search space. do the labeling on the most up-to-date Linux kernel version
(v5.4.5). In order to apply our method to another OS or TCP
At the moment, we randomly sample from these paths with implementation much different from the current one, we may
equal probability and do not differentiate or prioritize them. need to do more path pruning depending on the coverage,
However, a better solution is to understand the relationships i.e., if symbolic execution cannot cover all desired accept and
among these paths and avoid visiting paths that are unlikely to drop points, manual analysis is required to improve coverage.
lead to any fruitful results. One example is that for different Extending S YM TCP to other DPIs is easy. With results from
paths reaching the same accept point, we know that they symbolic execution, we can immediately probe the new DPI
correspond to packets accepted by the server, but we hope with the generated candidate packets; however, needed is the
that they are ignored by the DPI. In such cases we should manual analysis of the results. Extending S YM TCP to another
theoretically prefer longer paths, because they go through protocol is in principle possible (we believe the insertion and
more corner cases (e.g., more checks or different conditions of evasion definitions are general). However, it can be tricky
acceptance) and the DPI is less likely to handle them perfectly. due to protocol-specific adaptations. For example, our pruning
Another example is that, in our evaluation, we find that there decisions and abstractions are specific to TCP. Furthermore,
are many packet sequences sharing the same prefix of two if the protocol uses crypto functions, they must be explicitly
accept packets, and the second packet happens to be a valid handled, since SMT solver is unable to solve complex con-
evasion packet; this means that regardless of what the third straints accumulated in crypto functions [5], [30]. Besides, we
packet is in a sequence, it will always succeed in eluding need to label drop and accept points. These aspects will require
the DPI for the same reason (Figure 4). Unfortunately, during additional research.
the offline path exploration phase, we are unable to tell if
the second packet will be a successful evasion packet and In our demonstration, we use S YM TCP to help the client

13
side to elude DPI. Our approach can be applied to the server logic on Linux, which may be handled differently on DPIs.
side as well. In that case, we will need to model the client-
side TCP implementation, i.e., run symbolic execution on the Symbolic execution of network protocol implementations.
client’s TCP implementation. For example, if the client is In the past decade, symbolic execution has emerged as a
using Linux, the process should be similar to what we do to powerful formal verification technique and been widely ap-
model the server-side TCP implementation. Note that, since plied in the analysis and verification of network protocol and
the client is the initiator of a TCP connection, we will need network function implementations. For example, in [14], [15],
to consider TCP states corresponding to the initiator, e.g., the authors employ symbolic execution to extract the accept
exploring execution paths related to the SYN_SENT state. and reject paths in essential components of the TLS protocol,
i.e., X.509 certificate validation and PKCS#1 signature ver-
Defenses: Traffic Normalization and Per-Host Packets Re- ification, to find semantic bugs by cross-validating different
assembly. To mitigate DPI elusion attacks, solutions have been implementations. Kothari et al. [27] use symbolic execution to
proposed to normalize the traffic [23], [18], [47], where packets find protocol manipulation attacks where a malicious endhost
are actively manipulated and sometimes additional packets are can induce a remote peer to send more packets more aggressive
injected to confirm the result of the previous packet. These than it should. Song et al. [45] explore the possibility of
normalization strategies are deemed to prevent many evasion sending multiple packets in symbolic execution, and they
strategies. However, they are based on a large number of aim at finding low-level and semantic bugs given rule-based
hand-crafted rules (38 rules for TCP in [23] without formal specifications extracted from protocol specifications.
guarantees. We believe our automated system can in fact be DPI model inference. Ideally, if we can infer the DPI model
a great test against these defenses. Unfortunately we are not (i.e., state machine) automatically and completely, then it is
aware of any real-world implementations. Another strategy much easier to identify the discrepancies with the endhost’s
is proposed in [39], where the authors argue that the DPI’s state machine. Argyros et al. [2], [1] proposed the first
behaviors should be tailored to each host that it is responsible algorithm that learns symbolic finite automata with enough
for protecting (e.g., those in intranet). In theory, this strategy is queries and observations of a target system. The algorithm
sound, but in practice it comes with high cost, as the behavior is applied to regular expression filters, TCP implementations
of the DPI needs to be customized for different operating and Web Application Firewalls (WAFs), to do fingerprinting
systems (and even across many versions). Snort is the closest and discover evasion attacks. Similarly, Moon et al. [31]
to this line of thinking; unfortunately its Linux version of TCP synthesize high-fidelity symbolic models of stateful network
state machine is shown to be clearly vulnerable. Furthermore, functions (including TCP state machines of DPI middleboxes),
in certain contexts, e.g., state-level censorship, it is simply by generating queries and probes offline (albeit it requires the
infeasible to build per-host profiles of the majority of machines availability of the network function’s binary). Unfortunately,
on the Internet. the completeness and accuracy of the inferred model is in-
herently dependent on the queries. Therefore, we choose to
X. R ELATED W ORKS consider the DPI a complete blackbox and do not attempt
to learn its state machine explicitly. To some extent, though,
Evading Deep Packet Inspection. A major line of research on we indeed attempt to “learn its model” by generating proper
evading deep packet inspection is unilateral traffic manipula- queries to it (with the guidance of a Linux TCP state machine).
tion, by injecting crafted network packets to desynchronize the
DPI system from one endhost. This attack is practical since it Grammar-based fuzzing and exhaustive testing. Generating
needs to be deployed on only a local host, and doesn’t require meaningful inputs guided by a grammar that describes their
any cooperation from the remote host. The underlying idea formats can be beneficial to fuzzing [8], [21], [35]. However,
dates back to 1998 in a report by Ptacek et al. [37]. They fuzzing tends to generate overly many inputs and in our case
proposed the idea of insertion and evasion attacks on NIDS and will be inefficient in testing all the candidate packets. Further-
enumerated a variety of implementation-level discrepancies in more, defining a grammar or model at the implementation-
TCP and IP protocols. The discovered strategies are based on level requires a thorough analysis of all the subtleties of TCP.
analyzing out-of-date DPIs and operating systems (FreeBSD Therefore, models extracted from the specification are not
2.2), and many of the strategies no longer apply. Khattak et sufficiently detailed to capture the intricacies of the protocol.
al. [25] and Wang et al. [48] followed the same principle In contrast, our work can be viewed as attempts to “extract”
to study evasions against the Great Firewall of China and the implementation-level model.
demonstrated their effectiveness in practice. Li et al. [29]
conduct a comprehensive measurement that leverages similar XI. C ONCLUSION
TCP and IP level discrepancies to evade a wide range of
middleboxes such as traffic classification systems in multiple In this paper, we explore the use of symbolic execution
ISPs and the censorship systems in China and Iran. All of the to guide the generation of insertion and evasion packets at
above research rely on manual analysis of the TCP implemen- the TCP level for automated testing against DPI middleboxes.
tations in operating systems and reverse engineering of DPIs. We developed a system from end to end following this idea
In this work, we propose to make an important step towards and demonstrated its effectiveness with both known and novel
automating the evasion tests of DPI systems. A concurrent strategies against three popular DPIs: Zeek (Bro), Snort, and
work by Bock et al. [9] automates censorship evasion strategy GFW. The system can be easily extended to other DPIs. We
discovery by mutating existing packet traces. In contrast, we believe our work is an important step towards automating the
propose a more principled approach to search for the evasion testing of DPI middleboxes in terms of their robustness against
strategies, by targeting the corner cases in packet processing evasion.

14
 ACKNOWLEDGMENT [11] C. Cadar, D. Dunbar, and D. Engler, “Klee: Unassisted and automatic
generation of high-coverage tests for complex systems programs,”
We would like to thank Muhammad Faizan Ul Ghani, who in Proceedings of the 8th USENIX Conference on Operating
helped us with data analysis, and Hang Zhang for his helpful Systems Design and Implementation, ser. OSDI’08. Berkeley, CA,
USA: USENIX Association, 2008, pp. 209–224. [Online]. Available:
comments. We thank the anonymous reviewers for their in- http://dl.acm.org/citation.cfm?id=1855741.1855756
sightful feedback. This research was partially sponsored by the [12] C. Cadar and K. Sen, “Symbolic execution for software testing: Three
U.S. Army Combat Capabilities Development Command Army decades later,” Commun. ACM, vol. 56, no. 2, pp. 82–90, Feb. 2013.
Research Laboratory and was accomplished under Cooperative [Online]. Available: http://doi.acm.org/10.1145/2408776.2408795
Agreement Number W911NF-13-2-0045 (ARL Cyber Security [13] Y. Cao, Z. Qian, Z. Wang, T. Dao, S. V. Krishnamurthy, L. M.
CRA). The views and conclusions contained in this document Marvel, Y. Cao, T. Dao, L. M. Marvel, Z. Wang, Z. Qian, and S. V.
are those of the authors and should not be interpreted as repre- Krishnamurthy, “Off-path tcp exploits of the challenge ack global rate
limit,” IEEE/ACM Trans. Netw., vol. 26, no. 2, pp. 765–778, Apr.
senting the official policies, either expressed or implied, of the 2018. [Online]. Available: https://doi.org/10.1109/TNET.2018.2797081
Combat Capabilities Development Command Army Research [14] S. Y. Chau, O. Chowdhury, M. E. Hoque, H. Ge, A. Kate, C. Nita-
Laboratory or the U.S. Government. The U.S. Government is Rotaru, and N. Li, “Symcerts: Practical symbolic execution for exposing
authorized to reproduce and distribute reprints for Government noncompliance in X.509 certificate validation implementations,” in
purposes notwithstanding any copyright notation here on. It 2017 IEEE Symposium on Security and Privacy, SP 2017, San Jose,
was also partially supported by NSF award CNS-1652954, CA, USA, May 22-26, 2017. IEEE Computer Society, 2017, pp.
503–520. [Online]. Available: https://doi.org/10.1109/SP.2017.40
CNS-1619391, CNS-1718997, and ONR under grant N00014-
[15] S. Y. Chau, M. Yahyazadeh, O. Chowdhury, A. Kate, and N. Li,
17-1-2893. “Analyzing semantic correctness with symbolic execution: A case study
on pkcs# 1 v1. 5 signature verification.” in NDSS, 2019.
[16] T. Chin, K. Xiong, and C. Hu, “Phishlimiter: A phishing detection and
R EFERENCES mitigation approach using software-defined networking,” IEEE Access,
vol. 6, pp. 42 516–42 531, 2018.
[1] G. Argyros, I. Stais, S. Jana, A. D. Keromytis, and A. Kiayias, [17] V. Chipounov, V. Kuznetsov, and G. Candea, “S2e: A platform for
“Sfadiff: Automated evasion attacks and fingerprinting using black-box in-vivo multi-path analysis of software systems,” in Proceedings of
differential automata learning,” in Proceedings of the 2016 ACM the Sixteenth International Conference on Architectural Support for
SIGSAC Conference on Computer and Communications Security, ser. Programming Languages and Operating Systems, ser. ASPLOS XVI.
CCS ’16. New York, NY, USA: ACM, 2016, pp. 1690–1701. New York, NY, USA: ACM, 2011, pp. 265–278. [Online]. Available:
[Online]. Available: http://doi.acm.org/10.1145/2976749.2978383 http://doi.acm.org/10.1145/1950365.1950396
[2] G. Argyros, I. Stais, A. Kiayias, and A. D. Keromytis, “Back in black: [18] S. Dharmapurikar and V. Paxson, “Robust tcp stream reassembly in
towards formal, black box analysis of sanitizers and filters,” in 2016 the presence of adversaries,” in Proceedings of the 14th Conference on
IEEE Symposium on Security and Privacy (SP). IEEE, 2016, pp. 91– USENIX Security Symposium - Volume 14, ser. SSYM’05. Berkeley,
109. CA, USA: USENIX Association, 2005, pp. 5–5. [Online]. Available:
[3] Nebuad, isps sued over dpi snooping, ad-targeting pro- http://dl.acm.org/citation.cfm?id=1251398.1251403
gram. [Online]. Available: https://arstechnica.com/tech-policy/2008/ [19] H. Dreger, A. Feldmann, M. Mai, V. Paxson, and R. Sommer,
11/nebuad-isps-sued-over-dpi-snooping-ad-targeting-program/ “Dynamic application-layer protocol analysis for network intrusion
[4] R. Baldoni, E. Coppa, D. C. D’elia, C. Demetrescu, and I. Finocchi, detection,” in Proceedings of the 15th Conference on USENIX
“A survey of symbolic execution techniques,” ACM Comput. Surv., Security Symposium - Volume 15, ser. USENIX-SS’06. Berkeley,
vol. 51, no. 3, pp. 50:1–50:39, May 2018. [Online]. Available: CA, USA: USENIX Association, 2006. [Online]. Available: http:
http://doi.acm.org/10.1145/3182657 //dl.acm.org/citation.cfm?id=1267336.1267354
[5] S. Banescu, C. Collberg, V. Ganesh, Z. Newsham, and A. Pretschner, [20] G. Finnie, “Isp traffic management technologies: The state of the art,”
“Code obfuscation against symbolic execution attacks,” in Proceedings Heavy Reading. Report for the CRTC, 2009.
of the 32nd Annual Conference on Computer Security Applications, [21] P. Godefroid, A. Kiezun, and M. Y. Levin, “Grammar-based whitebox
ser. ACSAC 16. New York, NY, USA: Association for Computing fuzzing,” in ACM Sigplan Notices, vol. 43, no. 6. ACM, 2008, pp.
Machinery, 2016, p. 189200. [Online]. Available: https://doi.org/10. 206–215.
1145/2991079.2991114 [22] F. Gont and A. Yourtchenko, “On the implementation of the tcp urgent
[6] R. Bendrath, “Global technology trends and national regulation: Ex- mechanism,” RFC 6093, Jan. 2011.
plaining variation in the governance of deep packet inspection,” in [23] M. Handley, V. Paxson, and C. Kreibich, “Network intrusion
International Studies Annual Convention, vol. 15, no. 18, 2009. detection: Evasion, traffic normalization, and end-to-end protocol
[7] R. Bendrath and M. Mueller, “The end of the net as we know it? semantics,” in Proceedings of the 10th Conference on USENIX
deep packet inspection and internet governance,” New Media & Society, Security Symposium - Volume 10, ser. SSYM’01. Berkeley, CA,
vol. 13, no. 7, pp. 1142–1160, 2011. USA: USENIX Association, 2001, pp. 9–9. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1267612.1267621
[8] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet,
M. Kohlweiss, A. Pironti, P.-Y. Strub, and J. K. Zinzindohoue, “A [24] Transmission control protocol (tcp) parameters: Tcp option
messy state of the union: Taming the composite state machines of kind numbers. [Online]. Available: https://www.iana.org/assignments/
tls,” Commun. ACM, vol. 60, no. 2, p. 99107, Jan. 2017. [Online]. tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1
Available: https://doi.org/10.1145/3023357 [25] S. Khattak, M. Javed, P. D. Anderson, and V. Paxson, “Towards
[9] K. Bock, G. Hughey, X. Qiang, and D. Levin, “Geneva: Evolving illuminating a censorship monitor’s model to facilitate evasion,”
censorship evasion strategies,” in Proceedings of the 2019 ACM in Presented as part of the 3rd USENIX Workshop on Free and
SIGSAC Conference on Computer and Communications Security, Open Communications on the Internet. Washington, D.C.: USENIX,
ser. CCS 19. New York, NY, USA: Association for Computing 2013. [Online]. Available: https://www.usenix.org/conference/foci13/
Machinery, 2019, p. 21992214. [Online]. Available: https://doi.org/10. workshop-program/presentation/Khattak
1145/3319535.3363189 [26] J. C. King, “Symbolic execution and program testing,” Commun.
[10] A. Boukhtouta, S. A. Mokhov, N.-E. Lakhdari, M. Debbabi, and ACM, vol. 19, no. 7, pp. 385–394, Jul. 1976. [Online]. Available:
J. Paquet, “Network malware classification comparison using dpi and http://doi.acm.org/10.1145/360248.360252
flow packet headers,” Journal of Computer Virology and Hacking [27] N. Kothari, R. Mahajan, T. Millstein, R. Govindan, and M. Musuvathi,
Techniques, vol. 12, no. 2, pp. 69–100, May 2016. [Online]. Available: “Finding protocol manipulation attacks,” in Proceedings of the
https://doi.org/10.1007/s11416-015-0247-x ACM SIGCOMM 2011 Conference, ser. SIGCOMM ’11. New

15
 York, NY, USA: ACM, 2011, pp. 26–37. [Online]. Available: specifications,” IEEE Trans. Softw. Eng., vol. 40, no. 7, pp. 695–709, Jul.
http://doi.acm.org/10.1145/2018436.2018440 2014. [Online]. Available: https://doi.org/10.1109/TSE.2014.2323977
[28] A. Kuehn and M. Mueller, “Profiling the profilers: deep packet in- [46] R. Tahboub and Y. Saleh, “Data leakage/loss prevention systems (dlp),”
spection and behavioral advertising in europe and the united states,” in 2014 World Congress on Computer Applications and Information
Available at SSRN 2014181, 2012. Systems (WCCAIS). IEEE, 2014, pp. 1–6.
[29] F. Li, A. Razaghpanah, A. M. Kakhki, A. A. Niaki, D. Choffnes, [47] M. Vutukuru, H. Balakrishnan, and V. Paxson, “Efficient and robust tcp
P. Gill, and A. Mislove, “Lib·erate, (n): A library for exposing (traffic- stream normalization,” in Proceedings of the 2008 IEEE Symposium
classification) rules and avoiding them efficiently,” in Proceedings on Security and Privacy, ser. SP ’08. Washington, DC, USA:
of the 2017 Internet Measurement Conference, ser. IMC ’17. New IEEE Computer Society, 2008, pp. 96–110. [Online]. Available:
York, NY, USA: ACM, 2017, pp. 128–141. [Online]. Available: https://doi.org/10.1109/SP.2008.27
http://doi.acm.org/10.1145/3131365.3131376 [48] Z. Wang, Y. Cao, Z. Qian, C. Song, and S. V. Krishnamurthy, “Your
[30] I. Mironov and L. Zhang, “Applications of sat solvers to cryptanalysis state is not mine: A closer look at evading stateful internet censorship,”
of hash functions,” in Proceedings of the 9th International Conference in Proceedings of the 2017 Internet Measurement Conference, ser.
on Theory and Applications of Satisfiability Testing, ser. SAT06. IMC ’17. New York, NY, USA: ACM, 2017, pp. 114–127. [Online].
Berlin, Heidelberg: Springer-Verlag, 2006, p. 102115. [Online]. Available: http://doi.acm.org/10.1145/3131365.3131374
Available: https://doi.org/10.1007/11814948 13 [49] I. Yun, S. Lee, M. Xu, Y. Jang, and T. Kim, “QSYM : A practical
[31] S.-J. Moon, J. Helt, Y. Yuan, Y. Bieri, S. Banerjee, V. Sekar, W. Wu, concolic execution engine tailored for hybrid fuzzing,” in 27th
M. Yannakakis, and Y. Zhang, “Alembic: Automated model inference USENIX Security Symposium (USENIX Security 18). Baltimore, MD:
for stateful network functions,” in Proceedings of the 16th USENIX USENIX Association, Aug. 2018, pp. 745–761. [Online]. Available:
Conference on Networked Systems Design and Implementation, ser. https://www.usenix.org/conference/usenixsecurity18/presentation/yun
NSDI’19. Berkeley, CA, USA: USENIX Association, 2019, pp. 699– [50] The z3 theorem prover. [Online]. Available: https://github.com/
718. [Online]. Available: http://dl.acm.org/citation.cfm?id=3323234. Z3Prover/z3
3323291 [51] Y. Zhang, Z. M. Mao, and M. Zhang, “Detecting traffic differentiation
[32] M. L. Mueller and H. Asghari, “Deep packet inspection and bandwidth in backbone isps with netpolice,” in Proceedings of the 9th ACM
management: Battles over bittorrent in canada and the united states,” SIGCOMM Conference on Internet Measurement, ser. IMC ’09. New
Telecommunications Policy, vol. 36, no. 6, pp. 462–475, 2012. York, NY, USA: ACM, 2009, pp. 103–115. [Online]. Available:
[33] S. J. Murdoch and S. Lewis, “Embedding covert channels into tcp/ip,” http://doi.acm.org/10.1145/1644893.1644905
in Proceedings of the 7th International Conference on Information
Hiding, ser. IH’05. Berlin, Heidelberg: Springer-Verlag, 2005, pp.
247–261. [Online]. Available: http://dx.doi.org/10.1007/11558859 19
A PPENDIX
[34] V. Paxson, “Bro: A system for detecting network intruders in real- A. A complete list of drop points in Linux kernel v4.9.3
time,” Comput. Netw., vol. 31, no. 23-24, pp. 2435–2463, Dec. 1999.
[Online]. Available: http://dx.doi.org/10.1016/S1389-1286(99)00112-7 All of the source-code-level drop points we labeled can be
[35] V.-T. Pham, M. Böhme, and A. Roychoudhury, “Model-based found in Table VII.
whitebox fuzzing for program binaries,” in Proceedings of the
31st IEEE/ACM International Conference on Automated Software
Engineering, ser. ASE 2016. New York, NY, USA: Association
B. TCP PAWS checking in Linux and Snort
for Computing Machinery, 2016, p. 543553. [Online]. Available: As shown in the pseudo-code Listing 1 and Listing 2, the
https://doi.org/10.1145/2970276.2970316
acceptable TSval ranges of Linux and Snort are “off by 2”.
[36] J. Postel, “Transmission control protocol,” RFC 793, Sep. 1981.
[37] T. H. Ptacek and T. N. Newsham, “Insertion, evasion, and denial of 1 i f ( ( s i g n e d i n t ) ( l a s t p a c k e t −>t s v a l −
service: Eluding network intrusion detection,” SECURE NETWORKS c u r r e n t p a c k e t −>t s v a l ) <= 1 ) {
INC CALGARY ALBERTA, Tech. Rep., 1998. 2 / / PAWS c h e c k s u c c e e d e d
3 }
[38] A. Quach, Z. Wang, and Z. Qian, “Investigation of the 2016
linux tcp stack vulnerability at scale,” SIGMETRICS Perform. Eval. Listing 1. Pseudo-code of Linux PAWS (timestamp) check
Rev., vol. 45, no. 1, pp. 8–8, Jun. 2017. [Online]. Available:
http://doi.acm.org/10.1145/3143314.3078510 1 i f ( ( s i g n e d i n t ) ( ( c u r r e n t p a c k e t −>t s v a l −
[39] U. Shankar and V. Paxson, “Active mapping: resisting nids evasion l a s t p a c k e t −>t s v a l ) + 1 ) < 0 ) {
without altering traffic,” in 2003 Symposium on Security and Privacy, 2 / / PAWS c h e c k f a i l e d
2003., May 2003, pp. 44–61. 3 }
[40] Y. Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, Listing 2. Pseudo-code of Snort PAWS (timestamp) check
A. Dutcher, J. Grosen, S. Feng, C. Hauser, C. Kruegel et al., “Sok:(state
of) the art of war: Offensive techniques in binary analysis,” in 2016
IEEE Symposium on Security and Privacy (SP). IEEE, 2016, pp. 138–
157.
[41] D. Smallwood and A. Vance, “Intrusion analysis with deep packet
inspection: increasing efficiency of packet based investigations,” in 2011
International Conference on Cloud and Service Computing. IEEE,
2011, pp. 342–347.
[42] M. Smart, G. R. Malan, and F. Jahanian, “Defeating tcp/ip stack
fingerprinting,” in USENIX Security, 2000.
[43] Snort - network intrusion detection & prevention system. [Online].
Available: https://www.snort.org/
[44] R. Sommer and V. Paxson, “Enhancing byte-level network intrusion
detection signatures with context,” in Proceedings of the 10th ACM
Conference on Computer and Communications Security, ser. CCS ’03.
New York, NY, USA: ACM, 2003, pp. 262–271. [Online]. Available:
http://doi.acm.org/10.1145/948109.948145
[45] J. Song, C. Cadar, and P. Pietzuch, “Symbexnet: Testing network
protocol implementations with symbolic execution and rule-based

16
 TABLE VII. A LL DROP POINTS LABELED IN L INUX KERNEL V 4.9.3
Source file Line number TCP State Major Reason Total Covered
tcp ipv4.c 1404 Non-ESTABLISHED TCP checksum error 1 1
1607 Any TCP header length <20 1 1
1609 Any TCP header length >TCP packet size 2 1
1617 Any TCP checksum error 2 1
1655 SYN RECV TCP MD5 option check failed 1 1
1672 SYN RECV ACK number != server ISN + 1 1 1
1690 Non-SYN RECV TCP MD5 option check failed 1 1
tcp input.c 3616 Non-LISTEN Challenge ACK (the ACK case) 1 1
3736 Non-LISTEN ACK number >server send next 1 1
3750 Non-LISTEN ACK number older than previous acks but still in window 1 1
4503 ESTABLISHED OFO packet overlap 1 1
4641 ESTABLISHED Empty data packet 1 1
4657 ESTABLISHED Receive window is zero 1 0
4716 ESTABLISHED End SEQ number <= rcv nxt (Retrans) 1 1
4729 ESTABLISHED SEQ >= rcv nxt + window (out of window) 1 1
4745 ESTABLISHED Receive window is zero 1 0
5195 ESTABLISHED SEQ number <copied seq (SEQ num too old) 1 1
5270 Non-LISTEN PAWS check failed (Timestamp) 1 1
5284 Non-LISTEN Challenge ACK (SYN) (out-of-window) 1 1
5291 Non-LISTEN SEQ out of window 4 3
5325 Non-LISTEN Challenge ACK (RST) 3 3
5333 Non-LISTEN Challenge ACK (SYN) 1 1
5453 ESTABLISHED Packet length <TCP header length 1 0
5487 ESTABLISHED TCP checksum error 1 1
5531 ESTABLISHED Packet size <TCP header length —— TCP checksum error 2 1
5534 ESTABLISHED No RST and no SYN and no ACK flag 1 1
5911 LISTEN ACK flag set 1 1
5914 LISTEN RST flag set 1 1
5918 LISTEN SYN and FIN flags set 1 1
5925 LISTEN No RST and no SYN and no ACK flag 1 1
5947 Non-LISTEN Fastopen tcp check req failed 1 0
5951 Non-LISTEN No RST and no SYN and no ACK flag 1 1
6141 Non-LISTEN SEQ ≥ rcv nxt 1 1
tcp minisocks.c 634 SYN RECV Retransmitted SYN 1 1
716 SYN RECV PAWS check failed —— SEQ out of window 2 2
735 SYN RECV SYN or RST flag set 1 1
745 SYN RECV No ACK flag 1 1
758 SYN RECV TCP DEFER ACCEPT drop bare ACK 1 1
Overall 47 39

17