1. dFence: Transparent Network-based Denial of Service Mitigation CSC7221 Advanced Topics in Internet Technology Presented by To Siu Sang Eric (07016080) 7 April 2008 Ajay Mahimkar, Jasraj Dange, Vitaly Shmatikov, Harrick Vin, Yin Zhang Department of Computer Sciences, The University of Texas at Austin

2. Agenda 1. Introduction 2. Middlebox 3. Performance 4. Critique

3. Introduction  DoS Attack  Unspoofed data floods  The attacker can launch a data flood from a legitimate address by completing the TCP handshake and then flooding the bandwidth with data traffic  Too many unspoofed connections  The zombie completes the TCP handshake, conforms to congestion control measures, and then overwhelms the server with a large number of requests  NAPTHA attacks  the attacker opens a legitimate connection, immediately closes it without sending FIN/RST, and opens another connection from a different zombie machine  Botnet attacks  the attacker commands a large number of compromised computers to bombard the victim with HTTP or other requests.

4. Objective  Design and build a transparent network-based defense system capable of mitigating a broad range of large- scale, distributed DoS attacks directly inside the network, without requiring software modification at either routers or end hosts.  NOT to design a DoS attack detection method OR identify the attacker  But focus on a design of DoS attack mitigation method

5. Main Features  Transparency  No modifications of client or server software requires  Middlebox is introduced  Compatibility with existing routing infrastructure  Employs standard intra-domain routing and tunneling mechanisms  On-demand invocation  Dynamically introduced into the data path when customer is being attacked  Insert a middlebox when DoS attack is detected  Remove a middlebox when DoS attack is no longer exists

6. Main Features  Scalability  Allows ISPs to multiplex the same defense infrastructure to protect many customers  Minimal impact on legitimate connections  Low latency cost for the legitimate flows  Versatility  Can apply stateful mitigation policies to defend against the entire spectrum of Dos attacks

7. Middlebox  Design for ISP to deploy and serve for their customers  When an attack is detected by customer, they request ISP to insert middleboxes to mitigate DoS attack  The routing updates are sent to redirect all of a victim’s incoming and outgoing traffic through middleboxes

8. Middlebox

9. Connections Table  Maintain two tables for connections management  Src-Dest Table  Connection Hash Table

10. Src-Dest table  A hash table indexed by SrcIP–DestIP pair  It keeps counting currently open connections for each pair  To prevent the attacker from filling the connection table with a large number of connections entries, a threshold is maintain for each entry  If the threshold is exceeded, no new connections can be established for that entry

11. Connection hash table  Both Inbound Traffic & Outbound Traffic Protection  Maintain a Connection Hash Table to summarize on– going TCP connections  Flow definition  source IP & port number, destination IP & port number  Offset  difference between sequence number  Timestamp  time of last packet of this connection  Service bits  Pre-existing / Splice / Conformance  InboundPacketRate  the rate of incoming packets for each time interval

12. Flow pinning  Stateful mitigation requires both direction of traffic pass through the same middlebox  A hash h(f) of flow ID f is used to determine the home middlebox  e.g.

13. Inbound Traffic Interception

14. Outbound Traffic Interception

15. State bootstrapping  Dynamic state management Q: How to handle existing connections when the middlebox is inserted? A: State bootstrapping  An interval to establish a Connection Table for the existing legitimate connections  An existing connection is considered as legitimate if both inbound and outbound traffic exists  According to the research, Bootstrap interval can be set to 5 to 10 seconds  Other connections need to re-connect to the server

16. State bootstrapping

17. State removal  Dynamic state management Q: How to handle new connections when the middlebox is removed A: State removal  Middlebox will continue to serve the ongoing connections if there exists some connections affected by mitigation policies such as SYN cookie  New connections pass through middlebox without applying any policies  The decision to remove a middlebox can be only made by the middlebox itself

18. Middlebox failure recovery  Solution for the middlebox failure due to software or hardware errors or traffic overload  All middleboxes will agree on a global home middlebox table  Each middlebox is responsible for a subset of the entries  Clockwise next-hop neighbor of a middlebox M i will perform a backup an take over the flows if M i is failed or over loaded

19. Outsourced SYN cookies  Mitigating spoofed attacks  Do not require any modifications to the server TCP software  Three way handshake outsource from server to middlebox M i  M i request client C i to send a zero payload packet to M i  If M i receive data packets with no zero payload, before handshake, M i will drop the packet

20. Outsourced SYN cookies

21. Policy Decision Logic

23. Evasions and attacks on the Middlebox  Exhausting the connection state  Attacker want to fill up the connection table  Solution:  Limit the number of connections using a threshold  Adaptive traffic variation  Attacker employ an ON/OFF attack pattern  Solution  Avoid rapid introduction and removal of middleboxes  The duration of removal interval is randomized

24. Evasions and attacks on the Middlebox  Werewolf attack  Attacker behave legitimately, and then start bombarding the server with attack traffic  Solution:  Periodically re-measuring traffic sending rates  Multiple attacks  Attacker try to overwhelm the dFence infrastructure by launching multiple attacks on several destination network  Solution:  Scales up the number of middleboxes

25. Performance

27. Critique  Require a large number of middleboxes must be introduce into the dFence infrastructure  A large scale of middleboxes need to be share the workload to ensure a low latency for the legitimate connections during failure recovery or load balance

28. Q & A Section  Thank you very much