Transcript Vemuri

A DoS-Limiting Network
Architecture
Presented by
Karl Deng
Sagar Vemuri
Introduction
Existing DoS defence mechanisms






Ingress filtering
Traceback
Overlay based filtering(SOS)
Pushback, network filtering
Capability based approach
SIFF(Stateless Internet Flow Filter)
√
√
√
√
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 amount of data (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
ttl = L / N * T
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 added latency 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 packets
2.
Regular packet
The TVA Protocol

Request packets


Carry blank list of capabilities and path identifiers filled in by
the routers
Have an identifying capability header
The TVA Protocol

Regular packets


Packets carrying both flow nonce and capability
information
Packets that carry only the flow nonce
The TVA Protocol
The TVA Protocol
Hosts that act as senders and destinations

Sender first sends a request as a part of a TCP SYN

If the destination chooses to authorize it sends a
response with TCP SYN/ACK; else sends TCP RST
The TVA Protocol
Routers processing capability information


Process packets according to their capability information
and forward them
Shares each outgoing link with three classes of traffic:



Request packets
Regular packets
Legacy traffic
The TVA Protocol

Request packets: Forwarded after the router adds the
pre-capabilities and the new path identifier

Regular packets: Checked either for a valid nonce or a
valid capability

Legacy packet: 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
Legacy Packet Flood
Simulation Results
Request Packet Flood
Simulation Results
Authorized Packet Flood
Simulation Results
Effect of Imprecise Authorization
Implementation





Packet Filter - Prototype based on Linux
netfilter
Hashing functions: AES and SHA-1
To generate different kinds of packets Kernel packet generator
Average number of instruction cycles
recorded for processing each type of packet
Linux router also tested for how fast it could
forward the capability packets
Implementation
Processing Overhead and Peak Output Rates
Deployment




Design requires both routers and the hosts to be
upgraded
TVA architecture - can be deployed incrementally across
the network
Routers – can be slowly upgraded at the trust
boundaries and locations of congestion
Hosts – can be upgraded by starting with proxies at the
edge of customer networks
Conclusion




The TVA architecture provides a complete
implementation where two legitimate hosts
can communicate even during an attack
The design is based on the concept of
capabilities
A comprehensive design for handling various
forms of packets, router states and
destination policies
Simulation results show how TVA is better
than existing techniques
Thank You!

Questions?
Backup slides
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 – 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 - 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 – 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
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