DoS Limiting Network Architecture - Presentation by Saurabh Lalwani

1. Presentation On:- A DoS Limiting Network Architecture Xiaowei Yang David Wetherall Thomas Anderson Presented by- Saurabh Lalwani

2. This Presentation covers: • Design of Traffic Validation Architecture to limit the impact of DoS. • The TVA Protocol. • Full range of attacks have been addressed. • Simulations results for TVA are shown proving it better than others. • Deployment of the architecture. • Pros and Cons of this mechanism.

3. What is DoS? • A denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended users. • Generally, the purpose of DoS attacks is to prevent an Internet site from functioning efficiently or at all, temporarily or indefinitely. • One common method of attack involves saturating the target machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable.

4. Introduction • DoS attacks have been of major concern considering the reliability of internet. • Proposed defense mechanisms. • Ingress Filtering • Overlay Filtering • Traceback • Pushback of Traffic Filters • SIFF • The above mentioned mechanisms did not provide complete solution. Hence, a better mechanism was required.

5. Ingress Filtering (RFC 2827) • Is a technique used to make sure that incoming packets are actually from the networks that they claim to be from. • Packets coming into the network are filtered using ISP if originating from an unknown network. • Limitation – • Works Only with edge routers. • The destination needs to know which IP addresses of each of the networks to which it is communicating.

6. Traceback • Determines the origin of the attack. • Requires privileged access to routers. • Uses routers to create tables to reconstruct the path of unwanted traffic. • Limitation – • Destination becomes aware of it only if attack sustains for long. • Fails if the attacking frequency is varied. • Attacking from multiple hosts.

7. Pushback A mechanism in which the congested router asks the upstream routers to limit the amount of traffic during the time of severe congestion which can be due to flash crowd or denial of service attack. Limitation – No way of distinguishing between flash crowd, i.e, requests from good clients, and DoS attacks.

8. SIFF (Stateless Internet Flow Filter) • Privileged Communication is established by providing clients with capability token via handshake protocol. Privilege Token Limitation – Short capability length (2 bits).

9. The Solution : Traffic Validation Architecture (TVA) • Covers the shortcomings of previously discussed mechanisms. • Counters attacks that: • Flood the setup channel • Exhaust router state • Consume network bandwidth • Allows destination to control the number of packets it receives.

10. TVA Design Overview • Packets with Capabilities • Bootstrapping Capabilities • Destination Policies • Unforgeable Capabilities • Fine-Grained Capabilities • Bound Router State • Efficient Capabilities • Router Changes and Failures • Balancing Authorized Traffic • Short, Slow or Asymmetric Flows

11. Capabilities • A piece of information authorizing a packet. • Must be unforgeable. • Cannot traverse readily across senders or destinations (valid only between a specific source and a specific destination). • Routers must be able to verify capabilities explicitly. • Each packet carries unique stamp which is necessary for its validation. • Must expire to cut-off unneeded sender. TVA Design Overview

12. Bootstrapping Issues • Acquiring capabilities without having capabilities by sending request packets. • Once capabilities are obtained, the communication is bootstrapped. • Fair queuing combined with path identifiers prevents overwhelming requests from legitimate clients. TVA Design Overview

13. Destination Policies • Policies depend on the role destination plays in the network. That is, a client and a public server • A client establishes contact with the server and is not contacted otherwise. • A public server can temporarily block a misbehaving client. TVA Design Overview

14. Unforgeable Capabilities • Capabilities should not be forgeable. • Each router generates its pre-capability and attaches it with the outgoing packet. • Router verifies the hash using its secret. • Router changes its secret at twice the rate of timestamp rollover. • Destination receives these pre-capabilities, preventing spoofed attacks. TVA Design Overview

15. Fine-Grained Capabilities • Designed to tackle with false authorizations which can cause the DoS until capability expires. • Limits the amount of data and period of validity. • Two hashes are required now instead of one. TVA Design Overview

16. Bound Router State • Router memory can get exhausted if the attacker creates authorized connections across a target link. • Router state is maintained only for flows with valid capabilities and send faster than N/T. • For newly arriving packets, router begins a byte count and associates a minimal time-to-live with the state. TTL = L*(N/T) ; L Length of the packet TVA Design Overview

17. Consider the router creates a capability at time “ts” valid uptil “ts + T”, then it allows data till the ttl field is decremented to zero, after which the router state is reclaimed. TVA Design Overview

18. Efficient Capabilities • Long key length ensures security and short key length expedites the communication. • To increase the efficiency, we use long capabilities to ensure security and cache capabilities at routers so that they can subsequently be omitted for bandwidth efficiency. • Necessary condition for proper working – senders must know when routers will evict their capabilities from the cache. • If capabilities are not found in the router’s cache, the packets will be demoted to legacy packets. TVA Design Overview

19. Reduced Packet Overhead • No separate packet is needed to obtain capabilities. • Capability Header adds 8 bytes to packet header for each router on path. • Furthermore, router’s cache entry also helps in reducing the overhead.

20. Impact of Router Changes • Route change invalidate capabilities causing packets to traverse through different path. • Packets are demoted and forwarded as legacy traffic. • When destination receives it, it marks a bit in the return packet, informing sender to request new capabilities. • Consequent packets are sent as request packets again.

21. Balancing Authorized Traffic • Balancing of the authorized traffic is done by fair-queuing based on the authorizing destination IP address. • To limit the number of queues, a bounded policy is used which only queues those flows that send faster than N/T. • Low-rate flows receive FIFO service. • For Low-rate flows fairness is not guaranteed but FIFO prevents starvation. TVA Design Overview

22. Short, Slow or Asymmetric Flows • TVA is designed to run efficiently for long, fast flows. • For short or slow connections can be inefficient. • Overall impact is small assuming maximum traffic to be of long flows. TVA Design Overview

23. The TVA Protocol • Consists of three elements • Packets that carry capability information. • Hosts that act as senders and destinations. • Routers that process capability information.

24. Packets with Capabilities • Capabilities are piggybacked rather than using separate packets. • There are two types of packets • Request Packet • Regular Packet • Both the packets share an identifying capability header. The TVA Protocol

25. Common Header • Is the opening tag of both request and regular packets. • The “type” field gives important information about the outgoing packet.

26. Request Packet • Carry a list of blank capabilities and path identifiers, that are filled in by routers. The TVA Protocol

27. Regular Packet • Have two formats: • Carry both flow nonce and a list of valid capabilities. • Carry only a flow nonce. • A regular packet with a list of capabilities may be used to request new set of capabilities The TVA Protocol

28. Senders and Destinations • A sender first sends a request piggybacked on the first packet. • If the destination chooses to authorize, it sends a response with TCP SYN/ACK, else sends TCP RST. The TVA Protocol

29. Routers • Process packets according to the capability information and forwards them. • Shares the capacity of each outgoing link with three classes of traffic: • Request Packets • Regular Packets • Legacy Traffic • Add pre-capabilities and even a path identifier (if it is at the trust boundary) The TVA Protocol

30. Routers (Contd.) • The cache entry stores the: • Valid capability • Flow nonce • Authorized bytes to send • Valid time • TTL • Byte Count • Various checks are done to know the type of incoming packet. • The packet is demoted to be of legacy traffic if neither its nonce nor its capabilities are valid. The TVA Protocol

31. Simulation Setup • Bottleneck link is shared by: • 10 legitimate users each sending a file of 20KB thousand times using TCP (efficiency is 53.3%). • 1-100 attackers • One legitimate destination and one colluder at the far end. • TVA is changed to rate-limit capacity requests to 1% of link capacity. • Attack intensity is varied by changing the number of attackers. • The timeout for TCP SYN is fixed at one second with up to eight transmissions being performed.

32. The data exchange aborts connection if its retransmission timeout for a regular packet exceeds 64 seconds or the frame has been retransmitted more than 10 times. Simulation

33. First Scenario Legacy Packet Floods • Legacy Traffic is considered to be 1Mbps. • The result of the simulation is shown below: Simulation

34. Legacy Packet Flood (Contd.) • With TVA, almost 100% completion is present because TVA treats legacy traffic with lower priority than request traffic. • Performance of SIFF degrades slowly because it treats both legacy and request packets equally. • Pushback performs well until the number of attackers is increased, after which it performs poorly. The reason being that it is unable to differentiate between attack traffic and legitimate traffic. • With the Internet, the legitimate and attack traffic are considered alike and hence the probability for a successful file transfer decreases exponentially. Simulation

35. Second ScenarioRequest Packet Floods • Attacker is flooding the destination with request packets at 1 Mbps. • Assumption the destination was able to differentiate between requests from legitimate users and attackers. Simulation

36. Request Packet Flood (Contd.) • With TVA, requests from attackers and legitimate users are queued separately so that excessive packets from the attackers will be dropped off. • Behavior of SIFF is similar to the previous case as it treats both legacy and request packets as same. • Pushback and Internet also treat them as the regular data traffic. Simulation

37. Third ScenarioAuthorized Packet Floods • TVA still completes the transfer although time taken increases. Simulation

38. Authorized Packet Flood (Contd.) • TVA allocates bandwidth equally among all users, allowing colluder and destination to have bandwidth fairly allocated. • As the number of colluders increase, although the bandwidth allocated to each of them decreases but no one starves, consequently increasing the transfer time. • With SIFF, legitimate users are completely starved when the intensity of the attack increases because the request packets are treated with lower priority. • Internet and Pushback behave in the same manner described in the previous two scenarios. Simulation

39. Scenario 4Imprecise Authorization Policies • Even if the attacker gets the authorization and starts flooding the destination, TVA capabilities will expire after sometime hindering further inflow of packets. • Once the destination realizes that a sender is misbehaving, it stops renewing the capabilities. • In SIFF, the expiration of capabilities depend on changing the router secret. Simulation

40. Imprecise Authorization Policies (Contd.) Simulation

41. Implementation • The TVA was prototyped using Linux netfilter framework. • AES-hash is used as the first hashing function and SHA 1 as the second. • A kernel packet generator was used to generate different packets and send them through the router to check the behavior of TVA. • The average number of instruction cycles for the router to process each type of packet was recorded.

43. Security Analysis • The security of TVA depends on ability of the attacker to obtain capabilities for router. • Use of cryptographic hash functions is made having a sufficient amount of key which changes every 128 seconds making it practically impossible to break. • Since the IP source and destination addresses are included, an attacker who steals the packets cannot use them unless he know the router’s secret.

44. Deployment • The design requires both routers and hosts to be upgraded. • Routers can be upgraded incrementally, at trust boundaries and locations of congestion. • Hosts must also be upgraded by setting proxies at the edges of customer networks.

45. Pros • Overhead is reduced since no separate request packet is required to acquire capabilities. • Secured transmission with the help of capabilities. • Request Traffic is prioritized ahead of the legacy traffic. • Resistant to infrequent router failures. • Making use of router’s cache entry to expedite the communication. • Rate-limiting the bandwidth helps in minimizing the effect of bad authorizations.

46. Cons • All the routers need to be synchronized in time, a condition difficult to achieve. • Little protection if a router gets compromised. • High bandwidth is needed for short, slow or asymmetric flows. • The assumption that the destination can differentiate between request packets from attackers and legitimate senders is weak. • After capabilities are validated for each router, packets must follow the same path or be demoted as legacy traffic.

47. Conclusion • The TVA makes effective communication possible between any two hosts despite a large number of attackers. • Simulation results show that the performance of TVA is better than existing mechanisms. • The implementation of TVA in the Linux kernel showed that TVA can run at gigabit speeds on commodity PCs.