Transcript A DoS Limiting Network Architecture

A DoS Limiting Network
Architecture
An Overview by
- Muthyala Karthik Reddy
- Evani Chaitanya
Introduction
Existing DoS defense mechanisms





Ingress filtering
Overlay based filtering
Traceback
Pushback of traffic filters
SIFF
Introduction
However


Only address an aspect of the problem but
not the entire problem
They do not provide a complete solution by
themselves
Introduction
The SIFF protocol (An overview)
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
TVA experiences reduced efficiency only when 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
Simulation Results
Effect of Imprecise Authorization
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 hosta to be seperately
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 previosly
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