1. A DoS-limiting Network Architecture CSCE 715: Fall’06 Presentation by: Amit Jain Shantnu Chaturvedi

2. DoS (Denial of Service) Attacks

3.  Goal: To prevent legitimate users from using some service Usually accomplished by exhausting some resources (ie, bandwidth, CPU, memory) Intrinsic problem of Internet: any hosts can send packets to any other hosts without first acquiring permission  Effects 2001 study shows 4000 attacks a week Can bring down DNS root servers Lost of business estimation are in the billions Online extortion

4. Possible Defenses  Ingress Filtering - Source address filtering To prevent spoofing IP address Need widespread deployment Ineffective with more sophisticated attack, ie DDoS  Traceback Locate the source of the disrupting packets Does not prevent DoS since an attacker can still use a short TTL  Pushback Signal upstream nodes to rate limit misbehaving nodes How do you distinguish good from bad traffic?

5. Possible Defenses SIFF (Stateless Internet Flow Filter) Privileges & Unprivileged packet Routers Mark every packet Backward compatibility Marking space in the IP header. Routers mark every packet.

6. SIFF Packet Identifier Design  Flags field (3-bits). SF: Packet is non-legacy CU: Capability reply present or not  Capability: Marks modified by routers  Capability-Reply: recipients to signal to sender a capability

7.  Capabilities Senders obtain authorization from the receiver before sending the traffic  Anomaly detection Automated classification of “bad” flows Traffic flow and type information used Possible Defenses

9. Problems with current approaches  Each solution addresses an aspect of problem and not the overall issue.  Do not provide a complete solution, either Lack scalability Require substantial change in hardware

10. Goal  Provide a “comprehensive” solution to DoS  Receiver should also be able to control traffic directed towards it  Two legitimate nodes should be able to effectively communicate even during attacks  Bounded computation and memory  Incrementally deployable  Focus on lower-layer attacks (bandwidth, router memory)

11. TVA  Traffic Validation Architecture  Packet Capabilities  Cut to the heart of DoS problems  Destination control received packets  Counters a broader set of attacks  Automated validation of senders

12. Practical use of TVA  Can operate at Gigabit speed on inexpensive hardware  Incremental deployment.  Backward Compatibility.  Mix of spectrum of solutions.  Fine-Grained access control.

13. Traffic Validation Architecture 1.Packets with Capabilities. 2.Bootstrapping Issues. 3.Destination Policies. 4.Unforgeable Capabilities. 5.Fine-Grained Capabilities. 6.Bounded Router State. 7.Efficient Capabilities. 8.Balancing Authorized Traffic. 9.Short, Slow and Asymmetric Flows.

14. 1.Packets with Capabilities  Capability information present in each packets used by routers to provide preferential service.  Capabilities: Granted by destination. Unforgeable. Routers can trust packet capabilities without host authentication. Must be byte & time limited for destination cutoff. Add little overhead in computation and bandwidth.

15. 2.Bootstrapping Issues  To avoid the attacks on request messages itself  Tags each request with a 16 bit value derived from the incoming hardware interface  Tags are used to queue the requests.  Connection request packets do not contain capabilities and are rate limited (5%) at all network locations.  Fair queuing of requests combined with path identifiers helps counter attacks from legitimate users.

16. 3.Destination Policies  Client has only outgoing request. It accepts requests only if it relates to the previous request made by it.  Server grants the requests with initial number of bytes (N) and timeout (T).  Weak authentication of source address, so misbehaving senders are quickly contained by server.  Destination determines how to authorize request depending on role of destination in the network.

17. 4.Unforgeable Capabilities  Should not be forgeable or usable if stolen.  Each Router generates own pre-capability and attaches it to the forwarded packet.  Each router changes it’s secret at twice the rate of timestamp rollover.  The destination receives a set of pre-capabilities that correspond to a specific network path with fixed source and destination addresses.  Once authorized, the destination sends a list of capabilities to the sender.

18. 5.Fine Grained Capabilities  Routers perform the pre-capability hash check and capability hash check  Check if their local time > original time stamp + T  Check if N bytes have already been used for this connection  To tackle this problem, limit the data flow rate (N) as well as the period of validity (T) by returning these values to the sender.  Router State is used to count the bytes sent so far.

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

20. 6.Bounded Router State  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

21. 7.Efficient Capabilities  Capabilities should be efficient (Less overhead) as well as secure (long key length).  Long capabilities (64-bits) are used for security and then cached at routers for efficiency.  When a router receives a packet with a valid capability, it caches the capability relevant information and the flow nonce.  Subsequent packets then carry the flow nonce only and omit the list of capabilities.  Routers check the packets without capabilities using source & destination IP address and compare the cached nonce with the packet nonce.  Legacy packets are demoted by changing a bit in the capability header

22. 8.Balancing Authorized Traffic  Authorized flows between attacker and colluder may be malicious.  Simply give each capability a reasonable share of the network bandwidth.  Users get decreasing share of network bandwidth as the network becomes busier.  A fair queuing policy is used where the queues are limited by a bounded policy. Queue only the flows that send faster then N/T.  The low rate flows are limited by FIFO service with drops depending on timing of arrivals.

23. 9.Short, Slow and Asymmetric Flows  TVA experiences reduced efficiency only when the flows near the host are short; this can be countered by increasing the bandwidth  Effects on aggregate efficiency are small given that most bytes belong to long flows.  No overheads in exchanging handshakes.  All TCP connections between a pair of hosts are using a single capability. So, short flows are less likely.

24. The TVA protocol – Design Elements  Three Elements in protocol: Packets with capability information. Hosts as senders & destinations. Routers processing capability.

25. The TVA protocol Packets with capability information: IP packet header extended with capability header. Request packets:- Carry blank list of capabilities. Contain path identifiers filled by routers. Share an identifying pre-capability header. Regular packets:- Packets that carry flow nonce and list of valid capabilities. Packets that carry only the nonce. Renewal packets: A regular packet, used to establish new capabilities. Demoted packets: A packet that does not pass the capability test, treated as legacy packet

26. The TVA protocol Packets with capability information: Type field bits used to identify the type and format Type and capability. Return information. Demoted packet.

27. The TVA protocol Packets with capability information:

28. The TVA protocol Hosts as senders & destinations:  Sender sends request as part of TCP SYN.  If destination chooses to authorize, it sends response with TCP SYN/ACK.  To refuse transfer, destination sends empty capability list with TCP RST.

29. The TVA protocol Routers processing capability:  Processing of packets by capability information.  Sharing capacity of outgoing link between three classes of traffic: Request packets. Regular packets. Legacy traffic.

31. The TVA protocol Routers processing capability:  Request packets – processed after router adds path identifier and pre-capabilities.  Regular packets – forwarded after checking authorization information, updating cached information (Nonce and capability).  The packet is demoted to be a legacy packet if neither its capability nor it’s nonce is valid.

32. Simulation Results  Use of ns (network simulator) to simulate TVA, SIFF, pushback and legacy internet.  TVA is changed to rate limit the capability requests to 1% of link capacity.  Fixed length transfers between destination and legitimate users and destination under various attacks. Measure average fraction of completed transfers. Measure average time of transfers that complete.  Change in attack intensity – Vary number of attackers.  Timeouts of TCP SYN’s is fixed at 1 sec with up to 8 transmissions being performed.  TCP aborts connection if retransmission timeout > 64 sec for regular packet or packet transmitted > 10 times.

33. Simulation Results  Based on Dumb bell topology.

34. Simulation Results - Legacy packet floods  TVA: Legacy packets have lower priority than request traffic. So, average completion time remains small with attack intensity.  SIFF: Equal priority to legacy and request packets. When intensity of traffic exceeds the bottleneck bandwidth, it suffers losses.  Pushback: Performs well until large number of attackers distribute traffic on all links and attacks are harder to identify.  Legacy internet: Here the legitimate and attack traffic are treated alike and the probability of completed transfers approaches 0 as the number of attackers increase.

35. Simulation Results - Legacy packet floods

36. Simulation Results - Request packet floods  TVA: Request packets are rate limited and don’t reduce capacity for authorized packets. Packets separately queued.  SIFF: Both request and authorized packets are low priority. Results same as for legacy packets.  Pushback: Results same as for legacy packets.  Legacy internet: Results same as for legacy packets.

37. Simulation Results - Request packet floods

38. Simulation Results - Authorized packet floods  TVA: Destinations use fine grained capability to allocate bandwidth to senders. So, bandwidth between colluder and destination is rate limited.  SIFF: Request packets are dropped against authorized packets. So, request completion rate drops sharply when attack reaches bottleneck bandwidth.  Pushback: Treat request and authorized traffic as regular traffic. Results same as for legacy packets.  Legacy internet: Treat request and authorized traffic as regular traffic. Results same as for legacy packets.

39. Simulation Results - Authorized packet floods

40. Simulation Results – Imprecise authorization  TVA: Implements capabilities that expire after timeout and can be revoked by destination after finding misbehaving destinations.  SIFF: The expiration of a capability depends on changing the router secret, leaving the destination powerless in case of a misbehaving sender.

41. Simulation Results – Imprecise authorization

42. Implementation  TVA prototype using Linux netfilter on commodity hardware.  Legacy applications run without modification.  Router capability as kernel module, using: AES = first hash function. SHA-1 = second hash function.  Kernel packet generator to generate different types of packets.  Recording of the average number of instruction cycles for the router to process each type of packet.  Testing of Linux router forwarding speed for capability packets.  Implementation handles 100Mbps interface with off-the-shelf hardware.

43. Implementation Processing overhead for different packet types

44. Security Analysis  Security based on inability of attacker to gain capabilities for routers along path to destination.  Hashing scheme uses a sufficiently small key that changes every 128 sec. Breaking the key is practically impossible.  Attacker may observe pre-capabilities in requests by routers.  Stolen capabilities belonging to sender cannot be reused as this is included in the hashed value.  Masquerade as a receiver.  Attacker and colluder spoof the authorized traffic as sent by different sender S. This is thwarted by the fact that the per-destination queuing is used. Per-source queuing is not used as the sources cannot be trusted.

45. Deployment  Needs routers and hosts to be upgraded.  Incremental deployment.  Routers up gradation: At trust boundaries. At locations of congestion. Placement of inline processing box next to legacy router. No inter-router arrangements and alteration of routing. Deployment working back from destination for better attack localization.  Host up gradation: Occurring with proxies at edges of customer networks in form of NAT boxes. Not needed to upgrade individual hosts separately.

46. Conclusion  TVA limits DoS despite a large number of attackers.  Architecture is based on capabilities that enable destinations to authorize senders, in combination with routers to send authorized traffic.  Complete design to handle packet capabilities, initial request exchanges, destination policies, computation state requirements and router states.  With the TVA architecture; Legacy, Request and other authorized packets have little or limited impact on the performance of the legitimate users.  Practical design that runs at Gigabit speeds on commodity PC’s.  Design with easy transition and deployment on legacy network.

47. Thank you !!!!