Experiments with Linux DiffServ

March 31, 2000

 

Project Title:

Protecting Network Quality of Service Against Denial of Service Attacks

Organization:

N. C. State University

Contract Number:

F30602-99-1-0540

Program:

Tolerant Networks

Project Website:

http://www4.ncsu.edu/eos/users/r/reeves/rtcomm/ARQOS/main.htm

 

Testbed

All the testbed machines are running RedHat Linux version 6.0 with kernel version 2.2.14.  DiffServ version 8 and a snapshot of the latest iproute2-2.2.4 are also installed.  We are using MGEN-3.2(with a minor bug fix to make the software work with Linux) to generate the data traffic. The MGEN tool also marks the traffic with the appropriate DS field values (AF/EF/BE) as specified in the configuration file.

Two of our testbed machines, are configured as DiffServ routers incorporating the functions of policing flows and forwarding data based on DS field markings. The other four machines function as traffic sources and sinks.

The software for the DiffServ functionality is patched into the Linux Kernel and includes several traffic control functions such as Token Bucket Filter(TBF), Class Based Queueing(CBQ), Generalized Random Early Discard(GRED), FIFO etc. These kernel functions can be configured by user applications using a utility called traffic control (tc).

Each QoS device is first associated with a queueing discipline. Each queueing  has a queue assigned to it. In the queueing discipline, filters are used to distinguish between classes. Routers are configured using scripts to implement AF or EF classes.  For example, the AF class can be configured by using scripts that adjust CBQ or GRED parameters.

Experiments

We have experimented with various software configurations and their effect on observed QoS for the AF, EF and BE DiffServ classes. 

The main focus of our experiments was to gain a better understanding of the Linux DiffServ implementation and also give us insight into the design/implementation vulnerabilities that could be exploited by denial of service attacks. 

BE flow while another generated a moderate background BE flow and the actual application data(EF/AF/BE) flow. The test application we used to observe the actual QoS obtained was an audio application called TCP_Talk. We modified this program to support a command line argument for the type of service (EF/AF/BE) which would be reflected in the DS field value of the generated audio packets. A network congestion environment was created by replacing the link between the two DiffServ routers with a 10 Mbps Ethernet link (End systems were connected to the DiffServ routers over a 100 Mbps Ethernet link).

When the audio flow was marked as BE traffic, it suffered from poor audio quality and long latencies. When marked as an EF flow, the audio quality was unaffected by the presence of large(> 10Mbps) background BE flows.  The throughput observed of EF flows was also significantly higher than that for BE flows.  Other experiments were also conducted using AF/EF flows and by varying the magnitude of the background flow. In all cases, the EF/AF flows experienced better performance compared to the BE flows, as expected.  Example plots are shown below: