A DoS-Limiting Network Architecture

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

2. Introduction Existing DoS defence mechanisms • Ingress filtering • Traceback • Overlay based filtering(SOS) • Pushback, network filtering • Capability based approach • SIFF(Stateless Internet Flow Filter) √ √ √ √

3. Introduction However • Only address an aspect of the problem but not the entire problem • They do not provide a complete solution by themselves

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. The TVA Protocol Design Elements • Packets carrying capabilities • Hosts that act as senders and destinations • Routers processing capability information

18. The TVA Protocol Packets with capabilities • Capabilities are Piggybacked as a part of the IP header • There are two forms of packets • Request packets • Regular packet

19. The TVA Protocol • Request packets • Carry blank list of capabilities and path identifiers filled in by the routers • Have an identifying capability header

20. The TVA Protocol • Regular packets • Packets carrying both flow nonce and capability information • Packets that carry only the flow nonce

21. The TVA Protocol

22. 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

23. 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

24. 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

25. Simulation Results • The simulation is based on a “dumbbell” topology

26. Simulation Results Legacy Packet Flood

27. Simulation Results Request Packet Flood

28. Simulation Results Authorized Packet Flood

29. Simulation Results Effect of Imprecise Authorization

30. 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

31. Implementation Processing Overhead and Peak Output Rates

32. 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

33. Conclusion • The TVA architecture provides a complete implementation where two legitimate hosts can communicate even during an attack • The design is based on theconcept 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

34. Thank You! • Questions?

35. Backup slides

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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