A DoS Limiting Network Architecture

An Overview by

- Amit Mondal

Existing DoS defence mechanisms

Ingress filtering Traceback Overlay based filtering(SOS) Pushback of traffic filters Capability based approach SIFF(Stateless Internet Flow Filter)

Introduction

Introduction

However

Only address an aspect of the problem but not the entire problem

They do not provide a complete solution by themselves

Why TVA?

A robust approach to the earlier proposed methods using capabilities

Allows destination to control what it receives

Overcomes the shortcomings of current packet filtering techniques

Automated validation of senders without prior arrangement

The Traffic Validation Architecture (TVA)

Design Overview

Packets with capabilities and bootstrap issues Destination policies Unforgeable and fine-grained capabilities Bounded router state Efficient capabilities and authorized traffic balancing Short, Slow or Asymmetric Flows

The Traffic Validation Architecture (TVA)

Packets with capabilities

Each packet carries unique “stamps” that allows routers to validate them – capabilities

Must not require routers to trust the hosts Capabilities must expire to control the flow to destination Capabilities must be unforgeable Must cause little overhead both in computation and

bandwidth

The Traffic Validation Architecture (TVA)

Bootstrapping Issues

Connection request packets do not contain capabilities and are rate-limited at all network locations

Fair queuing of requests combined with path identifiers helps counter attacks from “legitimate” users

The Traffic Validation Architecture (TVA)

Destination Policies

Policies are assigned to a destination depending on its role in the network e.g. A client and a public server

A client accepts a request only if it relates to a previous request it had made

A public server initially grants all requests with a default set of bytes and timeout

The Traffic Validation Architecture (TVA)

Unforgeable Capabilities

It is required that a set of capabilities be not easily forgeable or usable if stolen from another party

Each router computes a cryptographic hash when it forwards a request packet

The Traffic Validation Architecture (TVA) It would be very hard to re-compute the hash value

without knowing the router’s secret The secret at twice the rate of the timestamp rollover and

capability validation is done with current or previous value

The destination receives a list of pre-capabilities with fixed source and destination IP, hence preventing spoofed attacks

The Traffic Validation Architecture (TVA)

Fine-Grained Capabilities

False authorizations even in small number can cause a denial of service until the capability expires

An improved mechanism would be for the destination to decide the rate of data flow (N) and also the time (T) along with the list of pre-capabilities

The Traffic Validation Architecture (TVA)

Bounded Router State

The router state could be exhausted as it would be counting the number of bytes sent

Router state is only maintained for flows that send faster than N/T

When new packets arrive, a new state is created and a byte counter is initialized along with a time-to-live field that is decremented/incremented

The Traffic Validation Architecture (TVA) Consider the router creates a capability valid for t + T,

then it allows data till the ttl field is decremented to zero, after which the router state is reclaimed

The Traffic Validation Architecture (TVA)

Efficient Capabilities

Inorder to efficiently use the bandwidth, only a single set of capabilities are computed for the entire flow

It is also required that for a secured set of capabilities, a longer set is used

To further reduce the load on the network, only a random nonce is sent with the subsequent packets and the router caches the previous nonces and compares them

The Traffic Validation Architecture (TVA)

Balancing Authorized Traffic

It is quite possible for a compromised insider to allow packet floods from outside

A fair-queuing policy is implemented and the bandwidth is decreased as the network becomes busier

To limit the number of queues, a bounded policy is used which only queues those flows that send faster than N/T

Other sender are limited by FIFO service

The Traffic Validation Architecture (TVA)

Short, Slow or Asymmetric Flows

Even for short or slow connections, since most byte belong to long flows the aggregate efficiency is not affected

No overheads are involved in exchanging handshakes All connections between a pair of hosts can use single

capability TVA experiences reduced efficiency only when all the

flows near the host are short; this can be countered by increasing the bandwidth

The TVA Protocol

Design Elements

Packets carrying capabilities

Hosts that act as senders and destinations

Routers processing capability information

The TVA Protocol

Packets with capabilities

Capabilities are Piggybacked as a part of the IP header

There are two forms of packets

1. Request packet

2. Regular packet

The TVA Protocol

Request packets

1. They carry a blank list of capabilities and path

identifiers filled in by the routers

2. They share identifying capability header

The TVA Protocol

Regular packets

1. Packets that carry both nonce and capability information

2. Packets that carry only the nonce

The TVA Protocol

The TVA Protocol

Hosts that act as senders and destinations

A sender first sends a request as a part of a TCP SYN

If the destination chooses to authorize it sends response with TCP SYN/ACK else sends TCP RST

The TVA Protocol

Routers processing capability information

Routers process packets according to their capability information and forward them

Each router shares the capacity of each outgoing link with three classes of traffic:

Request packets Regular packets Legacy traffic

The TVA Protocol

Request packets are forwarded after the router adds the pre-capabilities and the new path identifier

Regular packets are checked either for a valid nonce or a valid capability

The packet is demoted to be a legacy packet if neither its capability or nonce is valid

Simulation Results

The simulation is based on a “dumbbell” topology

Simulation Results

The TVA is changed to rate-limit the capability requests to 1% of link capacity

A measure of average fraction of completed transfers and the average time of transfer completed is taken

The attack intensity can be varied by changing the number of attackers

The timeout for TCP SYN is fixed at one second with up to eight transmissions being performed

The data exchange aborts connection if its retransmission timeout for a regular packet exceeds 64 seconds

Simulation Results – Legacy Packets The TVA maintains the average completion time to be

small because it treats legacy packets with lower priority than request packets

SIFF, however gives equal priority to both legacy and request packets, hence when the intensity of this traffic exceed the bottleneck bandwidth it suffers losses

When the number of attackers is large pushback finds it harder to identify attack traffic

In the internet, the attack and legitimate traffic is treated alike and the fraction of completed transfers approaches zero

Simulation Results

Legacy Packet Flood

Simulation Results – Request Packets In TVA, requests from legitimate users and attackers are

treated separately and are also rate limited. Excessive requests from attackers are dropped without

causing effecting legitimate users SIFF treats both requests and legacy packets as low

priority Both pushback and internet however, treat them as

regular data traffic

Simulation Results

Request Packet Flood

Simulation Results - Authorized Packets TVA uses fair queuing to allocate bandwidth to each

user, this allows colluder and destination to have a fair amount of bandwidth allocated

As the number of colluders increase, the bandwidth allocated to each user decreases but no one starves

Since the request packets in SIFF are treated with lower priority, the legitimate users are starved when intensity of attack increases

Both pushback and internet shows same results as legacy packet flooding

Simulation Results

Authorized Packet Flood

Simulation Results – Imprecise Authorization TVA implements capabilities that expire within a certain

amount of time, hence even if the destination grants authorization to all senders, it can be revoked

Once the destination realizes that a sender is misbehaving, it stops renewing capabilities

In SIFF, the expiration of capabilities requires the router secret to be changed, hence leaving the destination helpless

Implementation

The TVA was prototyped using the Linux netfilter that allows packet filtering running on off-the-shelf hardware

The hashing functions for capabilities were AES and SHA-1

A kernel packet generator was used to generate different kinds of packets for analysis

The average number of instruction cycles was recorded for processing each type of packet

The Linux router is also tested for how fast it could forward capability packets

Implementation

Processing Overhead and Peak Output Rates

Security Analysis

Since a cryptographic hash is computed over the keys that changes every 128 seconds, it makes it impossible to break the key

Since IP source and destination addresses are included, an attacker who steals the packets cannot use them unless he is co-located with the sender

Deployment

The design requires both routers and the hosts to be upgraded

The TVA architecture can be deployed incrementally across the network

The routers can also be slowly upgraded at the trust boundaries and locations of congestion

Hosts should also be upgraded by starting with proxies at the edge of customer networks

It is not required for individual host to be separately upgraded

Conclusion

The TVA architecture provides a complete implementation where two legitimate hosts can communicate despite even during an attack

The design being based on the concept of capabilities overcomes a large number drawbacks of the previously stated methods

A comprehensive design for handling various forms of packets, router states and destination policies

Simulation results show how the design meets all the described points