SoK: A Survey Of Indirect Network-level Covert Channels

Within the last few years, indirect network-level covert channels have experienced a renaissance with new ideas and evolving concepts. Logical network separation may now be crossed and the sending and receiving activities can be performed with temporal distance between sending and receiving operations. Despite these new developments, all indirect network covert channels share certain basic principles that allow a categorization. So far, the concepts of indirect network-level covert channels have never been systematized. In this paper, we introduce a taxonomy containing indirect covert channel patterns that allow a differentiated analysis of all known indirect network-level covert channels. We introduce additional definitions to unify the understanding of the domain and further identify crucial features of indirect covert channels to make them comparable and describable. We further discuss application scenarios as well as potential and already evaluated countermeasures against indirect covert channels. Further, we discuss observable trends and anticipated future developments in the research area of indirect network-level covert channels.


INTRODUCTION
Network-level Covert Channels (CCs) are used for steganographic data exchange between systems and are differentiated into direct and indirect CCs. An indirect CC is established when an intermediate node is exploited to store, represent or unintentionally redirect Covert Information (CI) between communicating parties.
Since 2019, indirect network-level CCs have experienced a renaissance, long after their first appearance in the 1990s. New ideas have emerged, for example the trend of storing CI in network protocol caches. Several techniques allow a temporal distance between the activities of a Covert Sender (CS) and Covert Receiver (CR), creating an asynchronous scenario [38]. The exploitation of shared physical devices for the exchange of CI, even if the CS's and CR's network are logically isolated [34], is another recent advancement. In addition to these new ideas, earlier implementations have been applied to additional protocols and in new environments. This fast development generates an urge for an appropriate systematization of available knowledge in the domain.
In this paper, we provide results of a literature analysis on indirect network-level CCs, covering publications from 1997 till 2021. We present a taxonomy that contains three so-called indirect CC patterns, which are used to group the discovered methods. We also introduce definitions and naming conventions for common terms and identify the crucial features of the indirect CC patterns. We analyze the utilization of so-called information hiding patterns [44] by indirect CCs to determine commonalities in their embedding and extraction methodology. Furthermore, we analyze the application scenarios for existing indirect network-level CCs and present potential countermeasures for every conceivable point between the CS and CR, at which a countermeasure can be located.
The remainder of this paper is structured as follows. In Sect. 2, we introduce the fundamentals of CCs, survey the known indirect network-level CCs and cover related work. Sect. 3 presents three indirect CC patterns for categorization as well as indirect CC features and naming conventions. In Sect. 4, we categorize existing indirect CCs based on our taxonomy, including their attributes, and discuss our observations. Furthermore, Sect. 5 summarizes already published application scenarios for indirect network-level CCs as well as potential and already evaluated countermeasures. We give an outlook on anticipated future developments in Sect. 6. Finally, Sect. 7 concludes.

FUNDAMENTALS
In the following subsections, we explain the fundamentals of CCs and survey published indirect network-level CC implementations. Finally, we cover related work.

Covert Channels
A CC is a communication channel between a CS and a CR to exchange CI in a stealthy or policy-breaking manner and was first introduced in [22]. CCs are based on exploitable carriers, the socalled overt channels or cover objects. Thus, a CC can be considered as a parasitic channel that nests into a legitimate communication. While there are also CCs defined for local systems (e.g., between local processes of an operating environment) all further mentions of CCs refer to network-level CCs. For network-level CCs, CS and CR exploit a communication protocol in such a way as it was never considered its purpose originally. The first network covert channels arose in the 1980s and exploited characteristics of local area networks [15,47]; several surveys (e.g., [31,46,50]) analyze and categorize network-level CCs. If a CS addresses more than one CR at the same time, this CC is also-called a multicast or broadcast CC.

CS CR
(a) Direct Covert Channel  Literature differentiates CCs into direct and indirect implementations [50]. For a direct CC, the CS and CR exchange information directly using a (modified) protocol, as shown in Fig. 1(a). There is no need for intermediary nodes to establish (or represent CI of) the CC, though the intermediaries are necessary to establish the overt channel. In contrast to this, an intermediate node has an essential role for an indirect CC, i.e. the intermediate node is involved stronger than a plain router. CI are not exchanged directly between the CS and the CR but are stored, represented or unintentionally redirected by the intermediate node ( Fig. 1(b)), e.g., with the purpose of communicating over a barrier. Further, CCs were historically divided into two categories -timing and storage channels [6], depending on how the CI is encoded. This categorization has been revised with the introduction of a taxonomy of information hiding patterns for CCs [44]. Such hiding patterns are recurring solutions for similar problems and allow precise grouping based on a template. A distinction is made between embedding and representation patterns. Embedding-pattern describe how the CI is embedded into a carrier, while representation patterns describe how this information is rendered recognizable by a CR. We provide additional background information on hiding patterns in appx. A.

Survey of Indirect Network-level CCs
We conducted a careful literature search using several publication databases, such as Google Scholar. To the best of our knowledge, the implementations listed below are considered to be all currently known indirect network-level CCs. The channels are grouped according to their alphabetically sorted protocol abbreviation. In the remainder, they will be referred by this abbreviation, and enumerated w.r.t. their historical appearance from 1 to . Thus, they will be shortened as Protocol.n. If no protocol has been specified in the source, we will refer to it as NET in the sense of protocolindependence.
802. 11. The IEEE 802.11 standard defines how information are exchanged in WiFi networks via the data link layer. In [54], an indirect CC has been described that exploits this standard (802.11.1). The CS forces clients to reconnect within a specific time-frame, transmitting bits per frame to a CR that observes the reconnect attempts. The clients are either directly controlled by the CS or indirectly forced to reconnect by manipulating 802.11 frames.
ARP. The ARP protocol maps the physical hardware address of a network device to its logical IP address. To reduce necessary discovery operations, the protocol stores information about known communication partners in a cache, the so-called ARP table. There exist four indirect CCs for ARP, two with and two without the exploitation of caches. In [38], the authors described how the ARP cache can be exploited for a steganographic data storage by modified ARP-requests. The extraction of the CI is made possible via SNMP, which is intended to query system status information. Linuxbased systems can store up to 127 entries (ARP.1) and Windowsbased systems up to 256 entries (ARP.2). There exist two more indirect CCs based upon ARP that have been described in [34]. ARP.3 exploits the fact that some routers forward ARP-requests if the target IP is set to a broadcast-address. Thus, the CS can address the CRs indirectly via an intermediate and transfer 8 bit of CI per ARP-Request. Further, ARP-requests affect the CPU load (ARP.4). A rate of 100 ARP-requests influences an intermediate node in such a way that the response time of other packets is delayed. A CR can measure this and extract CI from the intermediary.
CoAP. The Constrained Application Protocol (CoAP) is a lightweight communication protocol that has been designed for Internet of Things (IoT) and Industrial IoT devices and uses URLs and methods similar to HTTP to exchange information. In [18], the authors describe an indirect CC based on client resets (CoAP.1). Here, the CS forces the intermediate node to send RST-packets to several third-party nodes, where each node's reset is linked to a different hidden symbol. The CR monitors the resets in the network to decode the CI. The CC can transfer log 2 bit per reconnect ( being the number of nodes which can be exploited for a reset).
DHCP. By using the DHCP protocol, a server can assign intended network configurations specifically and generally to clients. In [34], two indirect CCs based upon DHCP have been described. DHCP.1 exploits the fact that some routers with an activated DHCP-server reply to DHCP-Requests with faked broad-and multicast source IP addresses. The DHCP-ACK is then sent via broad-or multicast to the given source address and can cross network borders, by exploiting routers as intermediate nodes. Besides this exploitation, DHCP influences the CPU load and the file system activity due to logging (DHCP.2) [34]. This can be exploited by a CS to create delayed acknowledgments to transfer 1 bit of CI through an intermediate node per CR request.
DNS. The Domain Name System (DNS) consists of several poolservers that resolve IP addresses to domain names (and vice versa) and refer available mail servers of a domain, among other features. A DNS-based indirect CC has been presented in [2] (DNS.1). The channel is based on the protocol's functionality of negative caching. The CC participants first agree on an ordered list of non-existent domain names. If a non-existent domain name was requested from a DNS server, an entry is added to the so-called NCACHE. To transmit CI, the CS sends a recursive request from one of these non-existent domains to a DNS server. One or more CRs can then extract the hidden message from this DNS server through a non-recursive query since the DNS server reports back an entry in the NCACHE. It must be noted that each DNS cache poisoning attack can also be applied to transfer CI. DNS poisoning was described in several papers [26,39,52]. Even though not intended for CCs, cache poisoning may be applied for indirect CCs, cf. [2], and can also target client-side DNS caches [1]. We waive these potential channels as they would apply a highly similar methodology as DNS.1.
HTTP. The HTTP is a stateless network protocol that allows the transport of hypertext documents and is mostly used to deliver web-content from a web server to a client application (mostly web browsers). In [4], several HTTP-based indirect CCs have been described that allow the exchange of CI between two HTTP servers through a client system. For HTTP.1, a server forces a client to transport CI via a redirect to another server. This has also been described in [11] with little variations. Cookies can be used by a CS to store CI on a client system for a later extraction by a CR (HTTP.2). For HTTP.3, referrer headers are used by a CS to redirect CI via a HTTP-client to another system. Further it is described, how active content like ActiveX can be used to force the client to transfer CI to another server (HTTP.4). In [10], the authors describe how an indirect CC can be established via BitTorrent trackers. The CS encodes CI in a modified, so-called infohash that is stored at the centralized tracker. Read and write operations can be performed via HTTP-requests (HTTP.5). Moreover, a HTTP-based Cross Site Request Forgery (CSRF)-Request can be exploited to increase the CPU load of an intermediary node to transfer CI. The CC has been described in [34] and increases the CPU load of a web server by a CS, repeatedly loading its websites in iframes. The increased response time of the web server can be observed by the CR (HTTP. 6) ICMP. The ICMP protocol is utilized to transport information and error messages for the Internet Protocol. In [12,50,51], an indirect CC is presented that utilizes ICMP echo requests. The CS encodes the CI as payload and also modifies the source IP field with the IP address of the CR. The CS sends the request to an intermediate node that answers with an ICMP echo reply and redirects the payload to the CR (ICMP.1). Ovadia et al. [34] describe how repeated ICMP requests influence the response time for other requests due to elongated acknowledgement times (ICMP.2). This delayed acknowledgement can be detected by a CR, transferring 1 bit of CI via an intermediate node. Since CCs for ICMPv6 can be realized in a similar way as in case of ICMPv4, we do not discriminate between the two protocols in the remainder.
IGMP. The IGMP protocol is utilized to organize IP multicast groups. In [34], the authors describe how IGMP can be exploited to establish a CC by IGMP membership queries via multicast IPs. The CS achieves the CI transfer by joining and leaving an IGMP group, forcing the intermediary to query if there are still hosts in this group. The CI is transferred through the Group-IP field that is controlled by the CS (IGMP.1).
MQTT. The Message Queuing Telemetry Transport protocol is used for the communication between IoT devices. It specializes in conveying status information of so-called topics through an intermediary node, carrying so called properties. This system makes topic-related information available to other systems that can send related queries. Six indirect CCs based upon MQTT have been described in [42]. Since the implementation of the MQTT protocol was designed to store data at an intermediary, there are several options to implement a steganographic data storage. MQTT.1 exchanges information between a CS and CRs by agreeing on all sub-topics of a first level topic. The name of the sub-topics are carrying the CI, transmitting Byte. MQTT.2 is based on topics that are arranged in a specific order. Each topic that is updated within a predefined time-frame by the CS represents a binary 1 and is observable by the CRs.For MQTT.3, the CS first needs to provide its unique identifier to the CR. Both, the CS and CR, are then able to create either a persistent session with the intermediary (representing a 1) or a nonpersistent session, representing a 0. The previous session type can be detected by the response of the intermediary. MQTT.4 exploits retained messages stored at the intermediary. The CS can transmit CI to CRs by sending a topic update, and setting the RETAIN flag to 1, forcing the intermediary to send a retain message to CR subscribers. Retain messages are also exploited by MQTT.5 to transmit bits. The CS and CRs must agree in advance on ordered topics, where a present retain message represents a 1, while an absent retain message represents a 0, transferring bits at once. MQTT.6 is realized by the CS manipulating the number of clients that are connected to the intermediary in a predefined time-slot. If more than the average number of clients are connected the CR, it represents a binary 1, otherwise a 0. Five additional indirect CCs have been described in [32]. MQTT.7 utilizes the order of properties of a MQTT Packet and can transmit bit of CI. MQTT.8 is created by either duplicating properties in one request or not (representing a boolean), sending bit of CI, depending on the number of transmitted properties. For MQTT.9, two MQTT clients (CS and CR) agree on two topics, whereby each client offers one topic and subscribes the to other topic. CS and CR can establish an bi-directional indirect CC, encoding a binary 1 or 0, depending on in which combination the topics are updated. MQTT.10 can transport a message of bit from a CS to CRs by agreeing on 2 topics, representing a binary number. For MQTT.11, the CS (a client) forces the MQTT broker to reconnect third party clients to transmit CI to an observer (the CR). Each third party system represents a symbol of a predefined alphabet.
NET. In [40], the authors describe a network-level CC that exploits a susceptibility to spectre in intermediary CPU caches. The intermediate node must be prepared in advance to transfer CI between the CS and the CR. The CS influences the architectural state of the CPU cache, and the CR can observe these states by delayed network packet response times (NET.1).
NTP. The NTP protocol provides the service of synchronizing the configured time between systems, which is achieved by so-called pool servers that can be accessed publicly. For NTP, two methods have been presented in [37] to transmit CI indirectly. NTP.1 describes that under certain circumstances, an intermediate node can be forced to store CI by establishing a broadcast-association. The extraction is accomplished by NTP command queries. The second indirect CC describes that CI can be stored in the Most Recently Used (MRU)-cache. The MRU-cache stores the last 120 communication partners with whom a time exchange took place and can be exploited to store CI. Since an NTP client rarely communicates with new NTP pool servers, these entries age slowly and remain in the MRU-cache with 4 bytes per entry (NTP.2). This procedure makes it also possible to store CI in NTP pool servers but the entries cannot be extracted within a few seconds since new systems keep making inquiries and thus rapid aging takes place (NTP.3).
SSH. The SSH protocol provides a protected shell service that allows to connect clients to remote servers. An indirect SSH CC is described in [34] and exploits the computational intensive ssh-key exchange between the CS and the intermediate node (SSH.1). This method can also be applied by the CR to extract information, by detecting increased reply runtimes due to increased CPU load.
TCP. The Transmission Control Protocol (TCP) defines how information are exchanged between two systems and is a reliable, ordered, and error-checked transport protocol. For TCP, an indirect CC was described in [35] (TCP.1). The CS encodes the CI into the ISN-Field and further modifies the source IP header field so that the IP of the CR is stored. The CS sends a SYN packet to the intermediate node, which replies with a SYN/ACK packet and redirects the CI to the CR that was designated in the source IP. Further, in [19,33] an indirect CC for TCP based on packet rate and timestamp modulation has been described. The CS manipulates the CPU temperature and load of the intermediary by sending requests to the intermediate node in a predefined time window. The CR sends a TCP packet to the intermediate node and can detect delays in acknowledgments (TCP.2). However, there exists a third indirect CC TCP.3 that has been described in [12]. The CS influences the intermediaries IPID counter by choosing an adequate window size, forcing the intermediate node to send back more packets than necessary. The CR then can extract the CI represented by the counter ID by sending a TCP packet.

Related Work
CCs have been extensively investigated in their different variants over the last decades. An early overview of several network CCs was provided by Handley and Sandford [17] and a less comprehensive survey was conducted by Llamas et al. in [25]. The first major survey that also provided a terminological advancement as well as a comprehensive analysis of fundamentals and countermeasures was published by Zander et al. [50]. Zhiyong and Yong performed a categorization of covert channels on the basis of entropy (three classes of covert channels were defined for variety entropy, constant entropy, and fixed entropy) [53]. Mazurczyk reviewed covert channels that exploit VoIP communications in [28], where he also analyzed available countermeasures. In 2014, Mileva et al. surveyed stateof-the-art TCP/IP related covert channels [31]. In 2015, Wendzel et al. categorized all network CCs published between 1987-2013 into so-called hiding patterns [46], which were extended in 2016 by Mazurczyk et al. [29], adjusted and extended in the years 2016-2021, and finally revised in summer 2021 by Wendzel et al. [44].
Indirect CCs have been described in several publications and can for example be found in [50]. The principle of a steganographic storage CI within building automation was described in [45] -it is therefore a cyber-physical dead drop, instead of one exploiting network protocol caches or states. Side channels are CCs that leak (sensitive) information without a sending-intention -a survey can for instance be found in [23]. In this paper, we essentially focus on covert channels with a sending intention. In [5], Baumann et al. describe how malicious scripts can be stored in browser caches. The injection is performed through a TCP injection and a CC controls which scripts are executed by the browser of the victim. In [24], the authors describe how to remotely exploit the Rowhammer attack described in [48]. A robust cache CC for cloud computing based on CPU caches has been described in [27]. In [49], the authors introduced a taxonomy for covert channels that base on attacks on speculative executions of dynamically scheduled execution of instructions by processors.
Several publications also deal with countermeasures for (indirect) network CCs. Already in 1983, Simmons described how a so-called warden can detect a CC between Alice and Bob [41]. Therein three wardens are described, a passive warden that only observes traffic, an active warden that removes steganographic content, and a malicious warden that modifies the content of a covert message by intent to influence CS and CR. There exist various countermeasures against CCs. A survey on passive wardens that detect covert channels was performed by [16]. VoIP CC-specific countermeasures were surveyed in [28]. Examples as well as current challenges and trends for covert channel countermeasures were analyzed by Mazurczyk et al. [29] and Caviglione [8]. Caviglione's results indicate that several methods are highly specialized, while there is a demand for more general approaches.

TAXONOMY AND NAMING CONVENTIONS
In this section, we first introduce our taxonomy for indirect CCs and define necessary terms. Afterwards, we identify crucial features for indirect CCs and introduce naming conventions to describe these channels precisely and enable their comparison.

Taxonomy
All CCs described in Sect. 2.2 are indirect network-level CCs that necessarily need an intermediate node for their implementation. This intermediary is the crucial commonality and can be described by the following definition: Definition 1 (Intermediate Node). An intermediate node for an indirect network covert channel is a crucial system that reflects, stores or represents CI. It is not necessarily aware of the fact that it is part of a covert channel.
Essentially, the intermediate node is a communication participant that is forced by the endpoints of a CC to take on an unforeseen role in the steganographic information exchange. However, the intermediate node may have been specifically and possibly unintentionally modified in advance so that it participates in the covert data transfer.
Nevertheless, there exist two variances of indirect CCs that allow a finer distinction. Some intermediary nodes are forced to unintentionally redirect CI to the CR, and some are forced to represent information so that the CR can later extract it. These dissimilarities allow the differentiation of indirect CC behavior into indirect CC

Redirector (R) Broker (B)
Proxy (B.P) Dead Drop (B.D) Figure 2: Patterns of Indirect Covert Channels patterns as presented in Fig. 2. The first indirect CC pattern introduced is the redirector pattern, in which an intermediate node is forced by a CS to unintentionally redirect CI to a CR. Further, a broker is forced by the CS to represent or store CI and has two variants: the proxy pattern, in which the CS manipulates the broker in such a way it represents the CI and the CR can extract the hidden information, and the dead drop pattern, in which the CS forces the intermediate node to store CI in a network protocol's cache so that a CR can extract it. These three indirect CC patterns are described and defined in the following subsections.

Redirector Pattern.
The redirector pattern is an indirect CC pattern that processes the steps as described in Fig. 3. In step a), the CS sends CI to a redirector. This intermediate node is forced to redirect the packet to a CR. Thus, a redirector is a specialized intermediate node that can be defined as follows: Definition 2 (Redirector). A redirector for an indirect network covert channel is an intermediate node that is forced by a (set of) manipulated packets to unintentionally redirect CI to another host; however, the CI are neither intentionally stored nor manipulated by the redirector.
The redirector is an active part of the CC but does neither store CI nor manipulate packets. The communication is never initiated by the redirector but forced by the CS to unintentionally redirect CI to the CR. The redirector, for example, can redirect unicast acknowledgements to the CR (like in TCP.1) or reflect broad-and multicast acknowledgements (like in IGMP.1).

Covert Sender
Covert Receiver  The implementation of the redirector pattern has the advantages that CS and CR are separated by the intermediary. Though, in some cases there is the disadvantage of a protocol violation, and for some implementations, the CS has to address the CR in each flow. These disadvantages can negate the described advantage.

Broker.
In contrast to the previous indirect CC pattern, brokers do not redirect packets but keep the state of a CI in a cache or are influenced in such way that the information can be extracted by the CR. Thus, a broker can be defined as follows: Definition 3 (Broker). A broker for an indirect network covert channel always has a passive role in a CC and never redirects CI from the CS to the CR.
There are two types of brokers -the CI-representing proxy and the CI-storing dead drop.
Proxy. The proxy is a broker that is influenced by the CS but it never redirects messages directly. The principle is presented in Fig. 4 and can be split into two segments. In the first segment (step a), further on called manipulation), the CS manipulates the proxy, and receives acknowledgements if the utilized protocol requires this. The CS has to repeat the manipulation until the proxy answers a request of the CR in a specific way (step b), further on extraction). Definition 4 (Proxy). A proxy for an indirect network covert channel is a broker that is influenced by a CS is in such a way that it replies to the requests from a CR at will of the CS.
The proxy has several advantages: (1) CS and CR do not have to address each other to exchange messages; (2) the CI disappears after extraction and complicates forensics. However, the proxy pattern has disadvantages, too: (1) CS and CR have to be active immediately one after the other, which might be correlatable by an observer; (2) the CC is difficult to coordinate due to timing issues.
Dead Drop. The dead drop is manipulated by a CS to store CI in a cache, i.e. in contrast to the proxy pattern, the CI remain at the dead drop. The CR then requests the dead drop that responds with these stored CI.
The general procedure of this indirect CC pattern is presented in Fig. 5(a). In step a), the CS manipulates the broker, and receives an acknowledgment if required by the (manipulated) protocol. The dead drop is forced to store the CI in a network protocol's cache (step b)). Finally, the CR requests the extraction and receives the CI from the dead drop. Further on, step a) will be referred to as manipulation, step b) as storage and step c) as extraction.
The time sequence of activities is sketched in Fig. 5(b). The CS is only active at the beginning of the information flow and communicates with the dead drop. The dead drop stores the CI, which is subject to an aging process and disappears after a certain time. We refer to this disappearance process as fading. The CR becomes active before the CI faded and extracts the information.
Thus, a dead drop can be defined as follows:  Definition 5 (Dead Drop). A dead drop for an indirect network covert channel is a broker that is forced by the CS to steganographically store CI in a network protocol cache to enable the CI's extraction by a CR.
Fading of CIs in Dead Drops. As mentioned, a dead drop's CI fades after some time. There are two possibilities for fading to occur. Either the cache rejects entries after a certain time or the entries are deleted by an event (e.g., the cache is a ring buffer that is already full but has to store a new entry). If the fading depends on time, we further will call it timed because the timing of the CI-loss can be calculated. If the CI-loss depends on an event, it will be called logic. There is a possibility that the fading depends on both, timing and events. This will further be called hybrid fading. If the dead drop allows logic or hybrid fading, the CS and CRs can influence the time of the CI disappearance. Let represent the covert information (CI). consists of the substrings 1 , . . . , , i.e. = 1 || 2 || . . . || , with || being the string concatenation. For both timed and logic fading, either individual substrings, or the combined substring can fade.
As already mentioned, timed fading can be exactly calculated if the storage time is known and depends on the injection speed. This is visualized in Fig. 6. The CS wants to store C on a dead drop and decides for an injection speed. is injected at the time and the injection of all succeeding substrings from 1 to has to be completed under constraint of the maximum storage duration to reassemble the whole message at the CR, while the fading starts after Δ , which is the point of 1 disappearing. Δ corresponds to the time that passes after Δ and until has faded. Therefore, different scenarios were found for the surveyed CCs: (1) Timed Fading of Individual Substrings: If 1 was written at the time 1 , it must be read by CR at the time 1 + Δ while must be read at + Δ .  Figure 6: Timed Fading of Individual Substrings logical condition was triggered (e.g., ARP cache limit was reached).
In general, if the CI are injected by even intervals, the increase is linear and also Δ will be linear. If the CS decides to inject CI exponentially with a decreasing interval, the fading will be increasing with time. If the CS injects CI logarithmically with a decreasing interval, the CI will fade with an increasing interval. For all cases, the fading is completed at Δ when all entries vanished. CS might apply classical real-time scheduling constraints to ensure that the secret message CI will be fully recoverable by the CR.
The dead drop pattern offers several advantages: (1) No direct communication between CS and CR is necessary after they agreed on transmission parameters; (2) a temporal distance between the activity of CS and CR is feasible; (3) several dead drops (for scaling and obfuscation) could be combined; (4) fading of the CIs complicates forensics and can be considered an advantage.
However, these advantages also come with the cost of a few disadvantages: (1) external influences can destroy CI; (2) there is a limited lifetime of the CI within the dead drop.

Features
Besides the indirect CC patterns, there are several features that affect the properties of indirect CCs. Many are relevant for all CCs but some only influence certain indirect CC patterns. These features are the fundamentals for a detailed description of indirect CCs and are incorporated into the naming conventions introduced in Sect. 3.3. A feature is represented by capitalized letters, while the characteristic of a feature is represented by a lower-case letter. We provide a brief overview of all features of each pattern in appx. B. Protocol Violation (V). In some cases, CS and CR are forced to violate a protocol's standard-conform behavior. This can be observed by wardens and has an influence on the detectability of the CC. The characteristic can be: • conclusive (c); • violated (v).

Authentication (A).
Depending on the utilized protocol to submit CI, it may be necessary for the CS and CR to authenticate themselves to the intermediate node. Some protocols may require optional authentication. Thus, the communication between CS, CR and intermediate node can be: • authenticated (a); • unauthenticated (u); • optional (o).
Remote Reachability (R). The utilized protocol can either be limited to local communication (for example within a collision or broadcast domain) or can allow remote communications across network boundaries (through a routable protocol). Thus, potential characteristics are: • local (l); • remote (r).
Bitrate (B). The bitrate describes the number of bits that can be transferred within one transmission attempt during the redirection, manipulation or extraction. The quantities are specified in n bits (n bit) or n bytes (n B).
Protocol (P). For indirect CCs, the chosen network protocol(s) provide fundamental conditions for most of the properties, especially authentication, reachability and the potential bitrate.
Information Hiding Pattern (H). The information hiding patterns describe how CI are embedded and represented using the particular network protocol. Further, they allow a quick overview of potential countermeasures and detectors as these can sometimes be applied to entire pattern groups. The naming convention of an information hiding pattern are described in [44] and consequently applied in this paper, too. We both refer to the embedding and the representation pattern for each CC. All hiding patterns mentioned in this paper are described in appx. A.

Proxy Features.
For the proxy pattern, it is crucial to describe how the proxy is influenced by the CS. For this reason, the following feature is introduced: Load Intensity (N). The CS has to influence the proxy, so it represents the CI. Therefore, a repetition of time-consuming actions (e.g., requests to the proxy) can be necessary so that the CR can recognize the CI. Obviously, such events ease detectability of the CC. The Load Intensity can thus be categorized as follows: • high (h, i.e. many repetitions of actions have to be performed by CS (like required for influencing the CPU load in TCP.2); • normal (n, i.e. no unusual repetition of actions by CS is required).

Dead Drop Features.
As dead drops utilize caches to store CI, the storage itself and the behavior of the CI have to be described.
The following features are additionally necessary for indirect dead drop CCs: CI Capacity (C). The (potential) CI capacity of a proxy or dead drop corresponds to the amount of CI that can be represented or stored. The quantities should be specified in n bits (n bit) or n bytes (n B).
CI Lifetime (L). The lifetime of CI has an influence on the attractiveness of a dead drop for attackers. A short lifespan makes it necessary to precisely coordinate the manipulation and extraction. This may negate the advantage of the temporal distance of CS and CR and may lead to suspicious network activities. Further, if the lifetime is too long, it can lead to entries being discovered by an observer in the dead drop. We therefore suggest dividing the lifetime into three levels: • volatile (v): < 1 min storage period; • temporary (t): < 1 h storage period; • persistent (p): ≥ 1 h storage period.
Volatile and persistent dead drops are suitable for the steganographic storage of information but are to be regarded as second choice for the reasons already mentioned. A temporary network protocol cache, however, offers a balanced lifetime until the CI fade. It is possible that the storage process allows all three states, e.g., if the CS can influence whether the CI fade or not. This is exemplified by the overflow of the brokers ARP-cache, as described in [38].
Fading (F). The fading is the second feature to complete the description for indirect dead drop CCs. This feature is important because it determines whether the CI's fading can be controlled by the CS and whether CS and has influence on detection and throughput. Like explained in Sect. 3.1.2, fading can be • timed (t), • logic (l), or • hybrid (h).

Naming Conventions
After we have described all the features, it is necessary to structure them to ensure clarity. Naming an indirect CC has always to begin with the implemented indirect CC pattern, followed by the optional storage features and the features of all utilized protocols. The naming construction is modular: if necessary, an additional second protocol, cache or the load intensity can be added.

Redirector Pattern
An overview of all redirector CCs is presented in Tab. 1 and the naming conventions are presented in Tab. 2. First, it seems like redirector CCs are mostly tailored for protocols without a available (or mandatory) authentication. This may base on the fact that the utilized protocols were defined decades ago, except for CoAP and MQTT (both defined or major revised in 2014, respectively). Further, redirector CCs apparently have been popular in the early 2000s and have been rediscovered in [34,42]

Proxy Pattern
The known proxy CCs and their features are presented in Tab. 3 and the naming conventions are applied in Tab. 4. Please note that for ARP.4, DHCP.2, HTTP.6, ICMP.2 and SSH.1, as described in [34], various protocols can be applied to extract information from the proxy. Such protocol switching was not described in [19,33] but due to their similar implementation, we assume it will also be possible to extract CI with another protocol. This seems to be mutual for all known proxy CCs. However, we listed these CCs only once with the same protocol applied for manipulation and extraction. All proxy CCs resort to excessive use of network packets to influence the proxy's acknowledgment behavior for other packets (which is recognizable by a CR). We assume it will also be possible to influence a proxy without numerous requests to represent CI, though it seems that until now it has never been implemented. This can for example be achieved by single requests, that block crucial resources of the proxy. For the existing CCs, the CI at the intermediary is always represented by a value like the CPU temperature or load. The utilized network protocols are not violated and for both, the manipulation and extraction, protocols that do not require authentication were preferred. Further, remote-access providing protocols are applied, though this may be because they are more widespread and common. These two observations can be explained by the fact that all implementations modify the response time, and this can be accomplished by numerous protocols. The bitrate is low and seems to be restricted to 1 bit. The hiding patterns used excessively for manipulation and extraction are the timing-based rate and throughput patterns ET2/RT.2n and ET1.1/RT1.1n. The CI are represented and embedded by the hiding pattern EN4.1/RN4.1n at the proxy. Indirect CCs implementing the proxy pattern had been known since 2003, but never had been further researched until 2019.

Dead Drop Pattern
Tab. 5 provides an overview of dead drop CCs and Tab. 6 applies the introduced naming conventions. We first analyze our observations for the intermediate system itself (i.e. CI lifetime and fading). Second, we analyze the features of the protocols that are used for the manipulation and extraction.
Dead Drop Features. The first dead drop CC had been described in 2003, nevertheless, a rapid growth of implementations over the last few years in various publications can be observed. Most dead drop CCs seem to exploit caches with logic fading. Until now, there are only few known timed fading caches (DNS.1, HTTP.2, HTTP.5 and NTP.1). The lifespan of the entries in the dead drop may either be exclusively volatile, temporary or persistent, or they can apply to all lifespan categories at the same time. Caches that have a single persistent and temporal CI lifespan seem to appear exclusively in combination with timed fading. It also can be observed that logic fading with a volatile lifespan occurs twice (NTP.3 and NET.1). Further, the CI capacity covers a large bandwidth from 1 bit to 800 bytes. The CI capacity depends on the nature of the dead drop and the number of maximum storable CIs. Furthermore, it is noticeable that almost all dead drop CCs use an information hiding embedding pattern that is based on a non-temporal modulation. In particular, the information hiding pattern EN4.1n/RN4.1n is most frequently used to embed CIs in dead drops. MQTT.1 has already been listed as a redirector, but can also be implemented as a dead drop if the CR has already subscribed to the topic at the time the CS sends the CI.   Manipulation & Extraction Features. The known dead drop CCs are not violating protocols and behave conclusive for both, their manipulation and extraction. Also, both remote and local communications can be exploited for the manipulation of dead drops. The extraction process of the CCs exploits only remote protocols to retrieve CI from the dead drop. Further, an authentication is usually not necessary to manipulate the dead drop. Only the MQTT CCs and NTP.1 can force the CS to use authentication. The only CC that necessarily requires an authentication for the manipulation is MQTT.6. Both, routable and local communications are used for storing CI at the dead drop, and the bitrate varies between 1 bit and 5 Byte. Like for the dead drop's storage segment, a focus on nontemporal hiding patterns can be also observed in the manipulation and extraction segment. The information hiding representation pattern RN4n.1n is used almost exclusively but the CCs MQTT.4, MQTT.5 and NET.1 also use timing-based information hiding patterns. During the extraction, the dead drop can force the CRs to authenticate themselves. Only with DNS.1, it is not possible to restrict the access. It can also be observed that the bitrate of the of an extraction is equivalent to the storage capacity. There seem to be no restrictions to limit a potential CI transfer, except for the amount of storable CI. The hiding pattern applied for the extraction also matches the hiding pattern that has been utilized for the manipulation. Though, it cannot be concluded that information hiding pattern-switching between manipulation and extraction is infeasible. Temporal information hiding patterns are used as well as non-temporal ones. Though, there seems to be a high focus on the information hiding pattern EN4.1/RN4.1n.

Discussion
After their first discovery in the late 1990s, indirect network CCs have been intensively analyzed by academic research. However, less than a third of all known CCs were described before 2019. It is remarkable that several indirect CC patterns have been rediscovered withing the last four years (maybe the earlier research was simply not widely recognized for over a decade). Our introduced taxonomy allows the systematic categorization of such indirect network CCs, even for future implementations. Especially the dead drop pattern ermerged in various publications in academia for the last two years, probably because it is applicable in different scenarios. Though, we expect that direct CCs will continue to make up a large fraction of the CCs that can be observed in academia and potentially in real-world networks. However, we anticipate that indirect CCs might be used for more demanding scenarios than direct CCs -especially the one shown in Fig. 7, originally described in [34], seems to be interesting, as logically separated networks can be crossed, even if the CS and CR cannot communicate directly. Further, the timely distance between the CS and CR in case of dead drop CCs has a major advantage that is not well-understood by administrators and security experts. So far, there has been a focus on hiding patterns based on non-temporal behavior. In addition to the value modulation information hiding pattern, there are plenty of other information hiding pattern implementations conceivable, leading to the risk of undetected and unobstructed CI flows. An exception therefore are the proxy CCs, that, until now, rely on temporal behavior. Considered overall, it is difficult to make an exact classification of the best and most innovative covert channels, as     Table 6: Naming Conventions Applied to Dead Drop Covert Channels these depend on various factors and each surveyed indirect CC contributes different ideas. If there is one to pick publication for each indirect CC pattern, in our opinion for the redirector pattern, the CCs presented in [4] are remarkable, as they are able to transmit a large amount of CI utilizing a wide spread carrier protocol. For the redirector pattern, [34] is impressive as the publication shows how redirectors can be implemented with various protocols, crossing logical separation. And to pick one publication for dead drops, we would like to emphasize the importance of [40] as it shows that the dead drop pattern can be utilized to access such a deeply rooted cache of a system, independent to a certain protocol.

APPLICATIONS AND COUNTERMEASURES
After we structured indirect CCs in patterns, we now can also discuss and compare application scenarios and countermeasures for each indirect CC pattern.

Application Scenarios
Although the implementations vary, the application scenarios for each CC of an indirect CC pattern are often similar. Though, not all application scenarios within the indirect CC pattern group are realizable with each indirect CC. In the following subsections, we will give an overview of the CCs of each indirect CC pattern. Fig. 3. The first application scenario is that the CS forces the redirector to bounce an acknowledgement to the CR. The principle of this action is also exemplified in Fig. 10(a). Network subnets may be crossed, depending on the specification of the utilized protocol. Examples for this exploitation can be found in [12,35,50,51] (ICMP.1 and TCP.1). Further, redirector CCs (ARP.3, DHCP.1 and TCP.1) have been applied to cross a logical network border [34]. The authors describe how a router logically separates two networks, the so-called node and guest network. Clients may be connected to one network but are not allowed to communicate to each other. The scenario is visualized in Fig. 7. The CS and CR are connected to a router, that separates the two networks of CS and CR. In the example of IGMP.1, the CS forces the router to send an IGMP membership-query via multicast to the CR, even if both, CS and CR, were logically separated. This procedure is also shown in Fig. 10(b). For ARP.1 and DHCP.1, a slightly varied method is applied. The source addresses are broadcast or multicast addresses, forcing the router to forward the message, even if the networks are separated. This can be achieved by a protocol violation as ARP-and DHCP-requests should never be sent from broadcast or multicast addresses. The method may also apply to other nodes than routers but has not been investigated yet. ICMP.1 and TCP.1 might also be available for this scenario as the source addresses are modified as described in Sect. 2.2 and can also contain broadcast or multicast addresses, which requires further investigation.

Host-Network
Guest-Network Figure 7: Logically Separated Covert Sender and Receiver 5.1.2 Proxy Pattern. The proxy CCs described in [34] have been applied in the same way as illustrated in Fig. 7 and already described in the previous section. However, the implementation does not rely on the redirection of packets. The channels ARP.4, DHCP.2, HTTP.6, ICMP.2 and SSH.1 influence a shared resource, the CPU of the router.
The CS busies the proxy's resources, and the resulting elongated packet runtimes can be recognized by the CR. This scenario can be applied to cross logical separation, due to the physical use of the same resource, and may also be applied to several other scenarios with physical shared resources between the CS and the CR. TCP.2 exploits this similarly, though the authors of [19,33] have not described a logical separation. The intermediary is stressed by requests of the CS and delays its answer to the packets of CR. This may also be applied to the same scenario as in Fig. 7.

Dead Drop Pattern.
The general scenario has already been visualized in Fig. 5(a). The CS stores CI at an intermediary system, where they remain until the CS extracts them. The application scenario of dead drops is in some cases limited to local communications. This applies to both manipulation ( Fig. 8(a)) and extraction. The CS of ARP.1, ARP.2 and NTP.1, for example, can only apply this scenario as they are confined to their collision-and broadcast-domains. However, the extraction is implemented with a remotely usable protocol that may even pass firewalls and network borders due to seemingly legitimate utilization. SNMP has been used for both ARP channels, while NTP command-queries have been used for NTP.1. The other CCs are not limited by local communications and can also be exploited remotely, like presented in Fig. 8(b). Due to their seemingly legitimate protocol usage, they may pass firewalls and network borders both for the sending and receiving process. Further, especially DNS.1, NTP.3 and TCP.3 are available for longdistance communications as they can exploit public infrastructure servers (e.g., DNS and NTP) or servers in general (in case of TCP) as a dead drop. In some use cases, MQTT is also available for such a scenario. Though not yet described, also an application scenario with a logical separation of devices seems to be possible. Theoretically, the intermediate node with shared physical access to CS and CR as described in Fig. 7 can be exploited equivalent to the CCs already described in NTP.2, ARP.1, ARP.2 and TCP.3. NET.1 is further interesting because the CC is not bound to a scenario with a specific protocol.

Potential and Evaluated Countermeasures
Indirect CCs always consist of a CS, an intermediate node, a CR and their according connections. At each of these elements, a warden can be placed like visualized in Fig. 9 [43]. The wardens will be referred to as 1 to 5 , corresponding to their location. All wardens may apply already existing countermeasures against direct CCs with existing steganalysis techniques. Eventually, the modification and influencing of temporal and non-temporal behavior is the basis to CI exchange between a CS and a CR. Existing countermeasures can be found, for example, in [3,8,13,29,50]. There are groups of countermeasures that can specially be applied for each indirect CC pattern. These will be described in the following subsections.   The redirector often applies a redirection of acknowledgments without any information stored at the intermediate node. The normal behavior of such a protocol is shown in Fig. 10(b) for IGMP.1, while the violation is presented in Fig. 10(a) for TCP.1. The application of IGMP.1 is conclusive because it mimics normal behavior of the protocol, while TCP.1 sends an ACK to a host that never sent an associated SYN. Each single warden is in a position to detect this violation on its own. 1 and 2 will for example only observe the SYN packet but never the ACK. 3 can detect the protocol-violating behavior of an acknowledgment sent to another host. 4 and 5 may detect an ACK in absence of a SYN, which is never supposed to happen (except for the so-called cold start problem [21]). Such a behavior is also observable with ARP.3, where the protocol is violated by broadcast source IPs that are not used for ARP-requests and can be observed by all wardens. However, a redirector CC does not always depend on protocol violations. DHCP.1 and IGMP.1 for example utilize broadcast and multicast messages combined with a legitimate acknowledgment. This is visualized in Fig. 10(b). However, the wardens may be able to detect this behavior anyway. 1 , 2 and 3 can detect an increased volume of packets from a single host, which may lead to detection. 4 and 5 may also recognize frequent broadcast and multicast messages but cannot determine the source and maybe have to assume network problems or more than one system causing these events. If a deviation from the normal amount of occurring network packets from a specific host is detected, the wardens 1 , 2 and 3 could also limit a potential covert channel. A targeted limitation typically requires the determination of normal network behavior and the application of detection heuristics, such as those focusing on inter-packet gaps (e.g., [7], [14]). Detected covert channels can then be slowed down or eliminated. Further, if a protocol is violated, the wardens 3 , 4 and 5 might block the suspicious traffic, for instance if only acknowledgments are detected. The wardens 1 and 2 are not able to block the traffic in advance, because the violation is not observable by them at this point. 3. The wardens 1 , 2 and 3 can detect requests, which are repeated many times within a short timespan, especially if they are sent from a single node. Besides this, 3 can also observe that the CPU temperature or load increases in intervals, encoding CI. The wardens 4 and 5 can detect delayed packets and the CI encoded within them. For this scenario, methods for detecting regularities in inter arrival times had been described in [7]. As all these CCs rely on delayed response times, the CI exchange can be limited and eliminated by response-time normalization performed by 3 and 4 . Examples for normalization were originally described in [36] for timing side channels and can be achieved by randomized response delays or fixed response times.

Dead Drop Pattern.
Dead drop CCs store CI at the intermediate node. Therefore, 3 may detect them by an adequate technique. In particular, countermeasures against non-temporal behavior and value modulation like described for instance in [13] are good choices, as this is currently the dominating hiding pattern. However, also temporal hiding methods are conceivable, though not yet described for dead drops. Traditional approaches, such as the SRM (see below), might be applicable to eliminate the dead drops on 3 . Also, an abnormal number of entries in network protocol caches can be observed by 3 . It will be hard to detect manipulations as the frequency of packets can be varied by the CS because CI can remain for a longer timespan at the intermediary. The wardens 1 and 2 could apply countermeasure techniques that detect the hiding patterns RN4.1n and RT2.n. It is likely that the cache will be flushed after an extraction. 3 may be able to detect this on its own as well as 1 and 2 , if they are somehow connected to 4 and 5 or vice versa, or if these wardens are connected to 3 . The wardens 3 , 4 and 5 can detect a singular event that transfers CI to the CR as the number of extracted CI seem not to be controllable and correlates with the maximum of stored CI in the cache. TCP.3 influences the IPID counter of the dead drop; the CS and CR packets have to be well coordinated to transfer the CI, as the IPID counter would otherwise increase and destroy the CI. 3 can detect the timely occurrence of these coordinated requests. This behavior of CS and CR can only be detected by 1 and 2 if they are connected to 4 and 5 (and vice versa), or if any of these wardens can exchange information with 3 . Further, 4 and 5 might apply a slightly modified detector for LSB steganography, as the least significant bit is the modified value. The limitation to a necessary number of entries can limit dead drop covert channels.
The ARP-caches, for example, can store up to 128/256 entries, depending on the operating system, and are exploited by ARP.1 and ARP.2. In modern IT environments, it is not necessary to allow that many entries, as the collision domains are most likely restricted to fewer hosts, or even only two communication partners. Further, Tab. 5 visualizes that protocols used for extraction often implement an optional authentication. An enforced authentication can limit such CCs in numerous instances because the dead drop can hereby be secured at least against extraction by unauthorized CRs. Limitation and elimination can also be performed by the warden 3, as dead drop CCs base on CIs that are stored in network protocol caches of intermediate nodes. This can be achieved by regularly clearing caches, which leads to the destruction of CIs. Regarding the detection, one can assume increased detectability when a longer lifespan of CI in the cache is given.
SRM-based Protocol Cache Analysis. One envisaged approach to analyze communication protocols regarding their potential for cache exploitation and dead drops could be based on the classical Shared Resource Matrix (SRM) methodology, which was originally developed by Kemmerer [6,20] and later enhanced by McHugh [30]. In the SRM, a software system is analyzed in a way that for each attribute a check is performed whether operations (performed by exclusive entities -CS and CR) can modify/read the attribute. If such a modify-read cycle is feasible, a potential covert channel is discovered. This concept could be adapted for communication protocol caches in a way that the protocol states and cache entries are considered as attributes and the sending and receiving actions are considered as operations.

THE ROAD AHEAD
We expect to observe the different indirect CC pattern-related ideas to be applied to additional network protocols and network environments in the future. Especially IPv6 and IoT networks will be an interesting research field for indirect CCs due to their increasing deployment. Further protocol types, such as VoIP-related ones or low-level protocols like Bluetooth, have not yet been investigated but can be considered to be exploitable, too. In [34], the authors mentioned an idea for the proxy pattern by passing physical barriers. This opens several options for proxies and might also be applied to indirect dead drop CCs by exploiting shared network resources like WiFi hotspots comparable to [54] or even specialized networkconnected and shared devices like printers; several resources that have to be accessible by clients from various networks can act as intermediate nodes for indirect CCs. Further, a mentionable development has been described in [40]. The authors exploited a cache that is not considered to be a network-protocol cache and was never meant to be accessible by a remote device. Another crucial development can be observed in [9]. Therein, the authors describe how to exploit the cloud service DropBox to exchange information between a CS and a CR by modifying files and their meta-data. The article has not been covered in our survey as it mixes network-and application-level CCs. However, the article is important for two reasons. First, it exploits a cloud service, which has not yet been well-investigated for indirect CCs. Second, it mixes concepts as it represents a novel hybrid class of CCs. Finally, future research work might show whether proxies without high load intensity (N ) and dead drops with hybrid fading (F) can be realized. We assume that NET.1 can be applied as a hybrid fading dead drop, however this has not been analyzed in [40].

CONCLUSION
We described the state and commonalities of the known indirect network-level covert channels (CCs). Similarities of these CCs were transferred into a taxonomy, which consists of three essential indirect CC patterns: the redirector, the proxy, and the dead drop. We provided definitions for the introduced terms, identified crucial features of indirect CCs and introduced naming conventions. This enabled us to systematically present and compare indirect CCs. Additionally, we described application scenarios, identified possible locations of wardens as well as potential and already evaluated countermeasures against each indirect CC pattern and potential future developments.
Our results have shown that the majority of indirect CCs appeared within the last three years, which can be considered a hint for a growing trend. Further, we determined that the known indirect CC patterns applied only a subset of the known information hiding patterns, i.e. several of the known steganography hiding techniques are currently not exploited for indirect CCs. Additionally, some of the information hiding patterns appeared to only be used for specific indirect CC patterns. The application of countermeasures against the most recent indirect CCs has not yet been investigated in full detail. We hope that our systematization of indirect CCs aids the development of precise countermeasures against current and upcoming indirect CCs.

A INFORMATION HIDING PATTERNS
We introduced indirect CC patterns while we also employed another form of patterns -namely information hiding patterns. While several of these information hiding patterns are defined in the original work [44], we only cover those information hiding patterns that we actually refer to in this paper. Moreover, the patterns taxonomy currently faces a revision which will result in improved pattern descriptions and will be available here: https://patterns.ztt.hs-worms.de.
Embedding patterns. All embedding patterns start with the uppercase latter E, followed by a letter that indicates the type (temporal (T ) or non-temporal (N )) and an identification number. Embedding patterns describe how information is introduced into a steganographic carrier. We referred to the following embedding patterns: ET1.1 Rate/Throughput Modulation: This pattern embeds a secret message by modulating the rate of events/elements. In the network CC context, events are, e.g., the appearance of a flow or a disconnect, while elements are network packets. ET2 Event Occurrence: The secret message is encoded through the temporal location of events; for instance the time at which a disconnect is triggered or at which a connection is established [44]. EN2 Elements/Features Positioning: The secret data is encoded through the position of elements/features in a sequence of the same (features are, e.g., the packet size or a header field). [44] provides the example of placing an IPv4 option header at a specific location of the option's list. EN3 Elements/Features Enumeration. The overall number of appearances of elements or features is altered to encode a secret message. EN4.1 Reserved/Unused (State/)Value Modulation: This pattern embeds the secret message by modulating reserved or unused states/values. In the network context this is, e.g., a value of a packet header field. A classical example is to store a secret bit in the unused IPv4 reserved bit. EN4.2 Random State/Value Modulation; in comparison to EN4.1 the modified packet header value is not reserved or unused but a randomized field, such as the TCP Initial Sequence Number (ISN), which predominantly allows the embedding of secret messages that appear pseudo-random (e.g., encrypted data).
Representation patterns. It is possible for a CC to correspond to a different embedding and representation pattern at the same time [44]. Representation patterns start with an R and describe how a previously embedded steganographic information is represented so that it can be recognized by a CR. The trailing letter (n) of each named pattern indicates its context, which is networking (in contrast to, e.g., f for filesystem steganography). We referred to the following representation patterns: RT1.1n Rate/Throughput Modulation: This pattern is the counterpart to the embedding pattern ET1.1. Here, the rate or throughput of a network connection is monitored by the CR to extract the secret information. RT2.n Event Occurrence: counterpart to ET2 (the secret information is represented by the occurrence of events visible for CR