A DoS-Limiting Network Architecture Presented by Karl Deng Sagar Vemuri

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

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