<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Methods of IPD normalization to counteract IP timing covert channels</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>K. Kogos</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>A. Sokolov</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>National Research Nuclear University MEPhI (Moscow Engineering Physics Institute)</institution>
          ,
          <addr-line>31 Kashirskoe Sh., 115409, Moscow</addr-line>
          ,
          <country country="RU">Russia</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2017</year>
      </pub-date>
      <fpage>118</fpage>
      <lpage>126</lpage>
      <abstract>
        <p>Covert channels are used for information transmission in a manner that is not intended for communication and is difficult to detect. We propose a technique to prevent the information leakage via IP covert timing channels by inter-packet delays normalization in the process of packets sending. Recommendations for using the counteraction methods and choosing parameters were given. The advantage of our approach is that the covert channel is eliminated or limited preliminary, whereas state of the art methods focus on detecting active IP covert channels that may be insecure.</p>
      </abstract>
      <kwd-group>
        <kwd>Covert channel</kwd>
        <kwd>IP timing channel</kwd>
        <kwd>elimination</kwd>
        <kwd>limitation</kwd>
        <kwd>traffic normalization</kwd>
        <kwd>inter-packet delays</kwd>
        <kwd>capacity</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        Information in covert timing channel can be encoded by varying packets transfer rates (or inter-packet times) [
        <xref ref-type="bibr" rid="ref3 ref4 ref5 ref6">3, 4, 5, 6</xref>
        ] and
by packet sorting [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Storage channels in networks can be encoded in packet lengths [
        <xref ref-type="bibr" rid="ref8 ref9">8, 9</xref>
        ] or packet header fields (TTL, TOS,
ID, Checksum, etc.) [
        <xref ref-type="bibr" rid="ref10 ref11 ref12 ref13">10, 11, 12, 13</xref>
        ]. Network covert channels are described on Fig. 1.
      </p>
      <p>Сovert channels in networks</p>
      <sec id="sec-1-1">
        <title>Timing</title>
      </sec>
      <sec id="sec-1-2">
        <title>Storage</title>
      </sec>
      <sec id="sec-1-3">
        <title>Packet rates</title>
        <p>Interpacket times</p>
      </sec>
      <sec id="sec-1-4">
        <title>Packet order</title>
      </sec>
      <sec id="sec-1-5">
        <title>Packet lengths</title>
      </sec>
      <sec id="sec-1-6">
        <title>Header fields</title>
        <p>Channel doesn t
pose a threat</p>
        <p>Not take action</p>
      </sec>
      <sec id="sec-1-7">
        <title>Changing the system architecture</title>
      </sec>
      <sec id="sec-1-8">
        <title>Identification</title>
      </sec>
      <sec id="sec-1-9">
        <title>Analysis</title>
        <p>· Possibility to create a covert channel
· Possible damage (covert channel
capacity)</p>
        <p>Channel poses a threat</p>
        <p>The identification problem is to find the potential covert channels that can be realized in the analyzed system. The second
step is the analysis of identified channels to assess the threat level of each covert channel. If channel poses a threat to the
protected system the following measures can be applied: elimination, limiting, detection. Ideally covert channels should be
identified and removed during the design phase. Covert channels in networks can be eliminated by traffic encryption and
normalization (protocol headers, packet lengths, inter-packet times). If a channel cannot be eliminated its capacity should be</p>
        <p>
          Image Processing, Geoinformation Technology and Information Security / K. Kogos, A. Sokolov
reduced by using limiting techniques [
          <xref ref-type="bibr" rid="ref14 ref15 ref16 ref17 ref18">14, 15, 16, 17, 18</xref>
          ]. Auditing and detection methods can be used to detect the operating
covert channels [
          <xref ref-type="bibr" rid="ref19 ref20 ref21 ref22 ref4">4, 19, 20, 21, 22</xref>
          ]. These methods are based on the detection of non-standard or abnormal behavior. Covert
timing channels in networks can be eliminated only by normalizing inter-packet times. But this measure reduces the
communication channel bandwidth. Method parameters must be correctly selected to minimize the negative impact on network
performance.
        </p>
        <p>The rest of the paper is organized as follows. First, we give an overview of existing methods of covert channels construction
and counteraction in Chapter 2. In Chapter 3, we introduce recommendations on the choice of parameters of covert channel
elimination method. In Chapter 4, we consider two ways to limit covert channels capacity. In Chapter 5, we provide
experimental results to demonstrate counteraction methods effect on network performance. Our conclusions are presented in
Chapter 6.</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>2. Related Work</title>
      <sec id="sec-2-1">
        <title>2.1. Methods of covert timing channels construction</title>
        <p>
          Covert information can be encoded by varying packet rates or inter-packet times. The covert sender varies packet rate
between two (binary channel) or more packet rates each time interval. The receiver decodes the covert information by measuring
the rate in each time interval. The sender and receiver need a mechanism for synchronization of the time intervals. Timing
channel where the sender either transmits or stays silent in each time interval (on/off channel) is a special case of binary channel
[
          <xref ref-type="bibr" rid="ref3">3</xref>
          ]. Authors of [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ] implemented the on/off timing channel. In their scheme the covert data is divided into frames and
synchronization between sender and receiver is achieved through a special start sequence at the beginning of each frame. There
are variants of the timing channels that does not require synchronization between sender and receiver because the covert
information is encoded directly in the inter-packet times of transmitted packets [
          <xref ref-type="bibr" rid="ref23 ref24">23, 24</xref>
          ].
        </p>
        <p>
          Authors of [
          <xref ref-type="bibr" rid="ref25">25</xref>
          ] developed an indirect covert channel that exploits the fact that a host s CPU temperature is proportional to
the number of packets per time unit it processes and a host s system clock skew depends on the temperature. The channel
requires an intermediary that receives and sends packets to both covert sender and receiver. The covert sender either sends
packets to the intermediary or stays silent. The covert receiver estimates the intermediary s clock skew by observing a series of
timestamps in packets sent by the intermediary. There are other implementations of thermal covert channels [
          <xref ref-type="bibr" rid="ref26">26</xref>
          ].
        </p>
        <p>
          Covert timing channel can be organized through packet sorting [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ]. Sender can transmit a maximum of log2n! bits because a
set of n packets can be arranged in any n! ways. This approach requires per packet sequence numbers to determine the original
packet order. The method only modifies the sequence numbers, thus keeping payload unchanged.
        </p>
      </sec>
      <sec id="sec-2-2">
        <title>2.2. Methods of covert channels counteraction</title>
        <p>
          Admissible covert channel capacity depends on the kind of protected information and on the amount of leaked information,
which is critical. TCSEC assumes that covert channels with maximum bandwidths of less than 1 bit per second are acceptable in
most application environments [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]. According to IBM guidelines, channels with bandwidths lower than 0.1 bits per second can
exist. There is no special need to counteract them. Channels in range from 0.1 to 100 bits per second can exist when absolutely
necessary [
          <xref ref-type="bibr" rid="ref27">27</xref>
          ].
        </p>
        <p>
          Capacity of covert timing channels in networks can be limited by adding random delays to the packets. Fig. 3 shows the
framework of using traffic control module [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ]. Network covert timing channel exploitation takes place here. An innocent
process request the OS kernel to send a network packet, then covert message sender can somehow interfere with this procedure
(for example, delay response), after that the remote covert channel receiver eavesdrops related packets and decodes the message.
No matter whether there are covert channels, the traffic controller will get in on the network packet send out procedure.
        </p>
        <p>Sender</p>
        <p>Process</p>
        <p>Modulate</p>
        <p>Trusted
components</p>
        <p>Traffic
controller</p>
        <p>OS kernel
Network
devices</p>
        <p>Receiver
Eavesdrop</p>
        <p>Network</p>
        <p>Image Processing, Geoinformation Technology and Information Security / K. Kogos, A. Sokolov</p>
        <p>For each network connection, traffic control module maintains some information (network address, port number, connection
type, previous packet's outgoing time, etc.). When an application sends out a packet, traffic controller will intercept the packet,
look up the network connection information and add a random delay to the packet (fixed delays could be easy filtered by covert
channel users). Delay of nth packet will be calculated according to the formula:</p>
        <p>Tn  f (tn , k)  Rand (k)  tn ,
(1)
where tn denotes the time interval between current and previous packet-sending request, k is a configurable parameter
(0  k  1), Rand(k) function generates a random number ranged from 0 to k. Hence, Tn will be a random value from 0 and up to
k  tn . Experimental results shows that the covert communication achieved nearly 100% encode/decode correctness when traffic
control was disabled. With the traffic control enabled, the error rate rapidly raised to about 50%.</p>
        <p>Gateway is often used to prevent the data transmission from higher security level to lower. Gateway is located between the
sender with low security level and receiver with high security level (Fig. 4). When the gateway receives a packet from low it
stores it into a buffer and sends an acknowledgment (ACK) to low. Then it transmits the packet to high and waits for an ACK. If
the ACK is received the gateway removes the packet from the buffer.</p>
        <p>
          However, when the buffer is full the gateway must wait for high to acknowledge a received packet until another packet from
low can be stored in the buffer. The time of sending an ACK to low is directly related to the time of receiving an ACK from
high. High can ensure the buffer is always filled and vary the rate of its ACKs. In this manner, he can exploit the covert channel.
The PUMP model reduces this covert channel capacity [
          <xref ref-type="bibr" rid="ref16 ref17">16, 17</xref>
          ].
        </p>
        <p>Gateway
Low</p>
        <sec id="sec-2-2-1">
          <title>Data</title>
          <p>ACK</p>
        </sec>
        <sec id="sec-2-2-2">
          <title>Data</title>
          <p>ACK</p>
        </sec>
        <sec id="sec-2-2-3">
          <title>High</title>
          <p>Network covert timing channels can be eliminated only by normalizing inter-packet times. But this measure reduces the
communication channel bandwidth. Method parameters must be correctly selected to minimize the negative impact on network
performance.</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3. Covert timing channels elimination</title>
      <p>Inter-packet times normalization makes it necessary to delay the transmission of packets and generate dummy packets. It
reduces the network performance. So, method of covert channels elimination should be used only if the leakage of a very small
amount information is unacceptable. Parameters of inter-packet times normalization method must be correctly selected to
minimize the negative impact on communication channel capacity.</p>
      <p>Input data for the calculation of the best inter-packet time value kt can include:
1. empirical distribution of inter-packet time over a long period of time,
2. maximum acceptable packet queue delay lt,
3.  equal to the allowable part of packets which may be delayed for a time greater than lt.</p>
      <p>Following conditions must be met when inter-packet times normalization to kt is performed:
1. communication channel bandwidth is not less than the set value,
2. percentage of packets which are delayed for a time greater than lt is not more than  ,
3. number of dummy packets is minimal.</p>
      <p>One of the following values can be used instead of  and lt:
1. maximum allowable average packet delay davgt,
2. maximum acceptable part of dummy packets.</p>
      <p>Suppose we have a distribution of inter-packet time (Fig. 5). The minimum value of the inter-packet interval is equal to t and
maximum equal to mt.
. . .</p>
      <p>mt</p>
      <p>T</p>
      <p>Let the inter-packet times are normalized to kt. The device processes packets for an infinitely small time and its queue is
empty at the moment. When two packets with at interval arrive to the device, there will be the following. The second packet
  at    at 
will be delayed for kt  at , if at  kt . The second packet will be delayed for   kt  1 kt   kt  at    kt  kt  at and

 at 
 kt </p>
      <p>1 dummy packets will be generated and sent by the device, if at  kt .</p>
      <p>So, when n+1 packets with a1t, a2t,..., ant intervals come to the device, delay of the (i+1)th packet is equal to
where d0t  0 and Ndi is a number of dummy packets sent after receiving the ith packet (during the ait):
The smaller the inter-packet time kt, the less packet queue delay and the greater the number of dummy packets.
Let the inter-packet time is a discrete random variable  obeying the distribution law in Table 1.</p>
      <p>dit  di1t  (Ndi 1)kt  ait ,
Nфi   ait ktdi1t  1 .
2t
p2
…
…
(m – 1)t
pm - 1
mt
pm
n
where Nd is a number of dummy packets sent during the  ait after receiving the first packet.</p>
      <p>i1</p>
      <p>The inter-packet time after normalization should not exceed the average value in the initial distribution to avoid the constant
increase in queue length. That is, the following inequality must be satisfied:
where E ( ) is the expected value of a variable  .</p>
      <p>Image Processing, Geoinformation Technology and Information Security / K. Kogos, A. Sokolov</p>
      <p>One should choose a value of kt for witch this probability is not greater than  . Furthermore, the value of probability should
be as close to  as possible to minimize the amount of dummy packets. In choosing the value of kt based on the maximum
acceptable part of dummy packets ( Nd ) one should select the minimum suitable kt value to minimize packet delays.</p>
      <p>n  Nd
We consider two use cases of communication channel:
1. file transfer only,
2. real-time data transfer (e.g. VoIP, Skype).</p>
      <p>
        The maximum packet queue delay is not too important, if the channel is not being used for real-time data transmission.
Allowable average packet delay or acceptable percentage of dummy packets should be used as input data in this case. If you use
a channel for real-time data transfer, it is essential to ensure good communication quality. Therefore, the inter-packet time kt
should be calculated based on the maximum acceptable packet delay. For example, packet jitter should not exceed 30
milliseconds to provide an acceptable quality of a Skype call [
        <xref ref-type="bibr" rid="ref28 ref29">28, 29</xref>
        ].
      </p>
    </sec>
    <sec id="sec-4">
      <title>4. Covert timing channels limitation</title>
      <p>If a non-zero covert channel capacity is allowed one can use partial inter-packet times normalization. Such methods have less
negative impact on the communication channel.</p>
      <sec id="sec-4-1">
        <title>4.1. Normalization by several inter-packet times</title>
        <p>Let two values of inter-packet times after traffic normalization be allowed: k1t and k2t. Inter-packet time equal to k1t will be
observed at the output if the queue is not empty in k1t after sending the last packet. If the queue is empty at this moment the inter
packet time equal to k2t will appear at the output. It will be a dummy packet if the queue also is empty in k2t after sending the
last packet.</p>
        <p>Violator can affect the inter-packet times by passing packets to the channel and use covert channel. Let the random variable X
take the values 0 or 1 in accordance with the inter-packet times (k1t or k2t) at the output. p is the probability of observing
packets with an interval equal to k1t. Then entropy of X is equal to:</p>
        <p>The average time between two consecutive outgoing packets is pk1t  (1  p)k2t . So, capacity of covert timing channel that
can be built is:
(6)
(7)
(8)
H ( X )   p log2 p  (1 p) log2 (1 p) .</p>
        <p>C 
 p log2 p  (1 p) log2 (1 p)
pk1t  (1 p)k2t</p>
        <p>,
where (1 p)k1t  pk2t holds.</p>
        <p>It is possible to use more than two values of inter-packet delays.</p>
      </sec>
      <sec id="sec-4-2">
        <title>4.2. Normalization by several packet transfer rates</title>
        <p>T 
NT   Nq</p>
        <p> k2t ,</p>
        <p>Let there are two inter-packet delays: k1t and k2t ( k1t  k2t ) which correspond to two fixed packet transfer rates. During each
interval T inter-packet times are fixed and equal to k1t or k2t (packets are transmitted at a constant rate). Rate can change or
remain the same at the time points T i (i = 1, 2,…). Selected transfer rate depends on the number of packets received at the last
part of the T and the number of packets in the queue. Lower rate (which correspond to k2t) will be set at the time T  j if
where NT  is the number of packets received during the time interval ( T  j  T  , T  j ); Nq is the amount of packets in the
queue at the moment. Otherwise, a high data transfer rate will be established.</p>
        <p>When using this method, covert channel capacity is:
С  log2 r ,</p>
        <p>T
T  log2 r</p>
        <p>Ca</p>
        <p>.
where r is the number of transfer rates. In this case r = 2.</p>
        <p>Parameter T should be chosen depending on the predetermined allowable capacity of covert channel Ca.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>5. Experimental results</title>
      <p>This chapter provides experimental results to demonstrate the effect of inter-packet times normalization on network
performance. Two use cases of network are reviewed: file transfer only and real-time data transfer. For each of these cases we
have two empirical distribution of inter-packet time (under high and low network load). The best values of inter-packet time was
calculated for several input data sets.</p>
      <sec id="sec-5-1">
        <title>5.1. Covert channels elimination during file transfer</title>
        <p>(9)
(10)</p>
      </sec>
      <sec id="sec-5-2">
        <title>5.2. Covert channels elimination during real-time data transfer</title>
        <p>lt, sec.
0.005
0.010
0.020
p(T)
lt, sec.
0.005
0.010
0.020
T, sec.</p>
        <p>Nd
n  Nd</p>
        <p>T, sec.</p>
        <p>Nd
n  Nd
0.92
0.85
0.71</p>
        <p>The following dependencies were identified using a covert channel limit method that allows two packet transfer rates (Fig.
10, 11).</p>
      </sec>
      <sec id="sec-5-3">
        <title>5.4. Comparison of counteraction methods</title>
        <p>Three techniques of inter-packet delays normalization were applied under the same conditions. The requirement for the
average packet delay was specified. The parameters of each method have been calculated to ensure a minimum effect on the
communication channel performance. The values of the covert channel capacity and part of dummy packets are shown in the
Table 8.</p>
        <p>Inter-packet times normalization makes it necessary to delay the transmission of packets and generate dummy packets.
Parameters of inter-packet times normalization method must be correctly selected to minimize the negative impact on
communication channel capacity. Channel performance requirements may be different. They depend on how you use the
channel. The results also show that the packet delays and the number of dummy packets are strongly depend on the
communication channel load.</p>
        <p>Image Processing, Geoinformation Technology and Information Security / K. Kogos, A. Sokolov</p>
        <p>Complete normalization of inter-packet delays is only way to eliminate covert timing channels. However, this measure
greatly reduces the communication channel capacity and should be used only if the leakage of a very small amount information
is unacceptable. In other case, one can use methods of partial inter-packet times normalization which limit covert channel
capacity.</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Acknowledgements References</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Lampson</given-names>
            <surname>BW</surname>
          </string-name>
          .
          <article-title>A note on the confinement problem</article-title>
          .
          <source>Communications of the ACM</source>
          ,
          <year>1973</year>
          :
          <fpage>613</fpage>
          -
          <lpage>615</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <article-title>[2] Department of defense standard. Department of defense trusted computer system evaluation criteria</article-title>
          ,
          <year>1985</year>
          ; 116 p.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Padlipsky</surname>
            <given-names>MA</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Snow</surname>
            <given-names>DW</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karger</surname>
            <given-names>PA</given-names>
          </string-name>
          .
          <article-title>Limitations of end-to-end encryption in secure computer networks: technical report</article-title>
          .
          <source>Bedford: MITRE Corporation</source>
          ,
          <year>1978</year>
          ; 11 p.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Brodley</surname>
            <given-names>C</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cabuk</surname>
            <given-names>S</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shields</surname>
            <given-names>C.</given-names>
          </string-name>
          <article-title>IP covert timing channels: design and detection</article-title>
          .
          <source>Proc. CCS</source>
          <year>2004</year>
          :
          <fpage>178</fpage>
          -
          <lpage>187</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Cabuk</surname>
            <given-names>S.</given-names>
          </string-name>
          <article-title>Network covert channels: design, analysis, detection, and elimination : for the degree of doctor of philosophy</article-title>
          . Indiana: Perdue University,
          <year>2006</year>
          ; 111 p.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Hovhannisyan</surname>
            <given-names>H</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lu</surname>
            <given-names>K</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wang</surname>
            <given-names>J.</given-names>
          </string-name>
          <article-title>A novel high-speed IP-timing covert channel: Design and evaluation</article-title>
          .
          <source>Proc. 2015 IEEE International Conference</source>
          <year>2015</year>
          :
          <fpage>7198</fpage>
          -
          <lpage>7203</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Ahsan</surname>
            <given-names>K</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kundur</surname>
            <given-names>D</given-names>
          </string-name>
          .
          <article-title>Practical data hiding in TCP/IP</article-title>
          .
          <source>Proc. ACM Wksp. Multimedia Security</source>
          ,
          <year>2002</year>
          ; 8 p.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Yao</surname>
            <given-names>Q</given-names>
          </string-name>
          , Zhang P.
          <article-title>Coverting channel based on packet length</article-title>
          .
          <source>Computer Engineering</source>
          <year>2008</year>
          ;
          <fpage>34</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Zhang</surname>
            <given-names>L</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Liu</surname>
            <given-names>G</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dai</surname>
            <given-names>Y.</given-names>
          </string-name>
          <string-name>
            <surname>Network</surname>
          </string-name>
          <article-title>Packet Length Covert Channel Based on Empirical Distribution Function</article-title>
          .
          <source>Journal of networks</source>
          <year>2014</year>
          ;
          <volume>9</volume>
          (
          <issue>6</issue>
          ):
          <fpage>1440</fpage>
          -
          <lpage>1446</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Kundur</surname>
            <given-names>D</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ahsan</surname>
            <given-names>K.</given-names>
          </string-name>
          <string-name>
            <surname>Practical Internet</surname>
          </string-name>
          <article-title>Steganography: Data Hiding in IP</article-title>
          .
          <source>Proc. Texas Wksp. Security of Information Systems</source>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Lucena</surname>
            <given-names>NB</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lewandowski</surname>
            <given-names>G</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chapin</surname>
            <given-names>SJ</given-names>
          </string-name>
          .
          <article-title>Covert Channels in IPv6</article-title>
          .
          <source>Proc. Privacy Enhancing Technologies</source>
          <year>2005</year>
          :
          <fpage>147</fpage>
          -
          <lpage>166</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <surname>Alsaffar</surname>
            <given-names>H</given-names>
          </string-name>
          , Johnson D.
          <article-title>Covert channel using the IP timestamp option of an IPv4 packet</article-title>
          .
          <source>Proc. The International Conference on Electrical and Biomedical Engineering</source>
          <year>2015</year>
          :
          <fpage>48</fpage>
          -
          <lpage>51</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Mavani</surname>
            <given-names>M</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ragha L</surname>
          </string-name>
          .
          <article-title>Covert channel in IPv6 destination option extension header</article-title>
          .
          <source>Proc. 2014 International Conference on Circuits, Systems, Communication and Information Technology Applications</source>
          ,
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>Hu</surname>
            <given-names>WM</given-names>
          </string-name>
          .
          <article-title>Reducing timing channels with fuzzy time</article-title>
          .
          <source>Journal of Computer Security</source>
          <year>1992</year>
          ;
          <volume>1</volume>
          (
          <issue>3</issue>
          -4):
          <fpage>362</fpage>
          -
          <lpage>372</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Trostle</surname>
            <given-names>J. T.</given-names>
          </string-name>
          <string-name>
            <surname>Modelling</surname>
          </string-name>
          <article-title>a fuzzy time system</article-title>
          .
          <source>Journal of Computer Security</source>
          <year>1993</year>
          ;
          <volume>2</volume>
          (
          <issue>4</issue>
          ):
          <fpage>291</fpage>
          -
          <lpage>310</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Kang</surname>
            <given-names>MH</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moskowitz</surname>
            <given-names>IS</given-names>
          </string-name>
          .
          <article-title>A pump for rapid, reliable, secure communication</article-title>
          .
          <source>Proc. First ACM Conference on computer and communications security</source>
          <year>1993</year>
          :
          <fpage>119</fpage>
          -
          <lpage>129</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Kang</surname>
            <given-names>MH</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lee</surname>
            <given-names>DC</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moskowitz</surname>
            <given-names>IS</given-names>
          </string-name>
          .
          <article-title>A network version of the pump</article-title>
          .
          <source>Proc. 1995 IEEE Computer society symposium on research in security and privacy</source>
          <year>1995</year>
          ;
          <fpage>144</fpage>
          -
          <lpage>154</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <surname>Wang</surname>
            <given-names>Y</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chen</surname>
            <given-names>P</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ge</surname>
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mao</surname>
            <given-names>B</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Xie</surname>
            <given-names>L</given-names>
          </string-name>
          .
          <article-title>Traffic controller: a practical approach to block network covert timing channel</article-title>
          .
          <source>Proc. International Conference on Availability, Reliability and Security</source>
          <year>2009</year>
          :
          <fpage>349</fpage>
          -
          <lpage>354</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <surname>Mahajan</surname>
            <given-names>AN</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shaikh</surname>
            <given-names>IR</given-names>
          </string-name>
          .
          <article-title>Detecting Covert Channels in TCP/IP Header with the Use of Naive Bayes Classifier</article-title>
          .
          <source>International Journal of Computer Science and Mobile Computing</source>
          <year>2015</year>
          ;
          <volume>4</volume>
          (
          <issue>6</issue>
          ):
          <fpage>1008</fpage>
          -
          <lpage>1012</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <surname>Rezaei</surname>
            <given-names>F</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hempel</surname>
            <given-names>M</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shrestha</surname>
            <given-names>PL</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rakshit</surname>
            <given-names>SM</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sharif</surname>
            <given-names>H</given-names>
          </string-name>
          .
          <article-title>Detecting covert timing channels using non-parametric statistical approaches</article-title>
          .
          <source>Proc. IEEE International Wireless Communications and Mobile Computing Conference</source>
          <year>2015</year>
          ;
          <fpage>102</fpage>
          -
          <lpage>107</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <surname>Venkataramani</surname>
            <given-names>G</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chen</surname>
            <given-names>J</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Doroslovacki</surname>
            <given-names>M.</given-names>
          </string-name>
          <article-title>Detecting Hardware Covert Timing Channels</article-title>
          .
          <source>Journal IEEE Micro</source>
          <year>2016</year>
          ;
          <volume>36</volume>
          (
          <issue>5</issue>
          ):
          <fpage>17</fpage>
          -
          <lpage>27</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <surname>Rezaei</surname>
            <given-names>F.</given-names>
          </string-name>
          <article-title>A Novel Approach towards Real-Time Covert Timing Channel Detection : for the degree of doctor of philosophy</article-title>
          . Linclon: The University of Nebraska,
          <year>2015</year>
          ; 136 p.
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <surname>Berk</surname>
            <given-names>V</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Giani</surname>
            <given-names>A</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cybenko</surname>
            <given-names>G</given-names>
          </string-name>
          .
          <article-title>Detection of covert channel encoding in network packet delays : technical report</article-title>
          . New Hampshire: Thayer school of engineering of Dartmouth college,
          <year>2005</year>
          ; 11 p.
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [24]
          <string-name>
            <surname>Sellke</surname>
            <given-names>SH</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wang</surname>
            <given-names>C-C</given-names>
          </string-name>
          ,
          <article-title>Bagchi S</article-title>
          . TCP/IP Timing Channels:
          <article-title>Theory to Implementation</article-title>
          . Indiana: Purdue University,
          <year>2009</year>
          ; 9 p.
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [25]
          <string-name>
            <surname>Murdoch</surname>
            <given-names>SJ</given-names>
          </string-name>
          .
          <article-title>Hot or not: revealing hidden services by their clock skew</article-title>
          .
          <source>Proc. 13th ACM conference on computer and communications security</source>
          <year>2006</year>
          ;
          <fpage>27</fpage>
          -
          <lpage>36</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [26]
          <string-name>
            <surname>Masti</surname>
            <given-names>RJ</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rai</surname>
            <given-names>D</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ranganathan</surname>
            <given-names>A</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Muller</surname>
            <given-names>C</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Thiele</surname>
            <given-names>L</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Capkun</surname>
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Thermal Covert</surname>
          </string-name>
          <article-title>Channels on Multi-core Platforms</article-title>
          .
          <source>Proc. 24th USENIX Security Symposium</source>
          <year>2015</year>
          ;
          <fpage>865</fpage>
          -
          <lpage>880</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [27]
          <string-name>
            <given-names>IBM</given-names>
            <surname>Knowledge</surname>
          </string-name>
          <article-title>Center</article-title>
          . URL: http://www-01.ibm.com/support/knowledgecenter (05.
          <fpage>01</fpage>
          .
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [28]
          <article-title>Inside Skype for Business</article-title>
          . URL: http://blog.insidelync.com/
          <year>2012</year>
          /06/a
          <article-title>-primer-on-lync-audio-quality-metrics/ (05</article-title>
          .
          <fpage>01</fpage>
          .
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          [29]
          <string-name>
            <surname>Alreja</surname>
            <given-names>A.</given-names>
          </string-name>
          <article-title>Understanding quality of experience alerting</article-title>
          .
          <source>Redmond: Microsoft Corporation</source>
          ,
          <year>2011</year>
          ; 15 pp.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>