Skip to content

Notes from Research Paper

Adarsh Honawad edited this page Oct 30, 2017 · 3 revisions

1. Introduction

Low-Rate TCP DoS Attack is a type of attack that is hard to detect by simple counter-DoS mechanisms because it is very cleverly performed in a way that the average rate of packets sent is still low. This type of attack uses the theory behind TCP Congestion Control mechanisms.

TCP congestion control operates on two timescales. On smaller timescales of round trip times (RTT), typically 10’s to 100’s of msec, TCP performs additive-increase multiplicative-decrease (AIMD) control with the objective of having each flow transmit at the fair rate of its bottleneck link. At times of severe congestion in which multiple losses occur, TCP operates on longer timescales of Re- transmission Time Out (RTO). 1 In an attempt to avoid congestion collapse, flows reduce their congestion window to one packet and wait for a period of RTO after which the packet is resent. Upon fur- ther loss, RTO doubles with each subsequent timeout. If a packet is successfully received, TCP re-enters AIMD via slow start.

This attack requires that the two hosts (attacker and sender) be connected to the receiver by at least one common link. The attack is based on flooding and congesting this link so that the packets sent by the sender fails. If the total traffic (DoS and TCP traffic) during a timescale that equals the RTT(Round Trip Time)-timescale (around 100ms), we can expect at least a few packets sent by the sender to be lost which will force the TCP flow to enter timeout and attempt to send a new packet RTO (Retransmission Time Out) seconds later. Now we start another burst of DoS flow exactly RTO seconds later, then we can expect the TCP flow to incur losses again and re-enter into timeout state, fails to exit timeout and throughput obtained will be zero.

Important Points:

Burst Length = RTT Timescale (around 100ms)

Burst Period = RTO Timescale (at least 1s but depends on the Congestion Control Mechanism used)

Note: If the burst period isn't very close to the RTO range but not equal, there will still be a decrease in throughput obtained but throughput will not be zero.

The author also mentions about the case of heterogeneous-RTT flows, when RTT values are different for different packets (?).

2. TCP'S Timeout Mechanism

The author talks about TCP Reno's timeout mechanism. TCP detects timeout when either of the following two events happen:

  • timeout from non-receipt of ACK's
  • receipt of three-duplicate ACK's

Setting of a RTO value is of important concern due to two reasons:

  • if set too low, spurious retransmissions may occur
  • if set too high, flows will wait unnecessarily too long

To address the former issue, Allman and Paxson experimentally showed that TCP achieves near-maximal throughput if there exists a lower bound for RTO of one second. (This also allows for clearing of congestion)

TO address the latter issure, TCP sender maintains two state variables:

  • SRTT (Smoothed Round-Trip Time)
  • RTTVAR (Round-Trip Time Variation)

Calculation of SRTT, RTTVAR, RTO are as follows:

Until the first measurement of RTT value, sender sets RTO value to three seconds.

Let the first RTT measurement be R' The host then sets

  • SRTT = R'
  • RTTVAR = R'/2
  • RTO = SRTT + max(G, 4*RTTVAR) where G denotes Clock Granularity (usually <=100ms)

On subsequent RTT measurements, R' are made:

  • RTTVAR = (1 - beta) * RTTVAR + beta * |SRTT-R'|
  • SRTT = (1 - alpha) * SRTT + alpha * R'

where alpha = 1/8 and beta = 1/4

Hence, final equation: RTO = max(minRTO, SRTT + max(G,4RTTVAR)) -- [1]

However, the above is only when RTT measurements are made. When RTT measurements aren't made, that is, when packet losses occur, sender enters the exponential backoff method where the congestion window is reduced to size of one and the RTO value is doubled every time the ACK is not received after RTO seconds.

Once the ACK has been received, RTT is calculated and the above formula [1] is once again applied.

Clone this wiki locally