DoS Protection for UDP-Based Protocols

1. DoS Protection for UDP-Based Protocols presented by: Guillaume Saggioro (NT030298X) NUS, School of Computing CS4236 Computer Security

2. Overview Introduction IKE protocol Fragmentation attack Defenses Conclusion NUS, School of Computing CS4236 Computer Security

3. Introduction Since IP Packet reassembly requires reassembly, a DoS attack can be mounted by swamping a receiver with IP fragments… NUS, School of Computing CS4236 Computer Security

4. Internet Key Exchange protocol IPsec key negotiating system Runs on top of UDP Relies on IP fragmentation to send large messages Deployed in hostile environment !! Must be able to establish security associations even while under attacks >>Stateless cookie protection NUS, School of Computing CS4236 Computer Security

5. Stateless cookie protection Defend against attackers that sends traffic from fake source address NUS, School of Computing CS4236 Computer Security

6. Stateless cookie protectionprinciple Conn_init, @IPA cookie (@IPA) B A cookie Keeps no state No additional computation A B Conn_init, @IPA, cookie’) B A cookie(@IPA) = = cookie’ ? Conn_ack Sends Ack if OK A B NUS, School of Computing CS4236 Computer Security

7. Fragmentation attacks IKE still subject to DoS threat Why ? Send large packets Depends on IP fragmentation requires storing fragmented packets Reassembly queue is limited !! NUS, School of Computing CS4236 Computer Security

8. How to prevent fragmentation attacks ? By redesigning IKE protocol various strategies we are going to explore… Everybody OK with fragmentation ??? N.B.:Strategies also applicable to other protocols that send large message on UDP NUS, School of Computing CS4236 Computer Security

9. Crypto proposed B A Crypto accepted, cookie A B gB mod p, cookie A B Basic structure of IKEv1 main mode By using up reassembly ressources, attacker can block reassembly gA mod p, cookie B A {“Alice”, cert, proof I’m Alice} B A Large message (certificate) {“Bob”, cert, proof I’m Bob} A B NUS, School of Computing CS4236 Computer Security

10. Defense, post-handshake Once the IPsec SA is successfully created, endpoints can protect themselves against fragmentation DoS attack by doing MTU discovery Frag by IPsec itself So we only have to ensure that SA establishment doesn’t get locket out during the initial IKE handshake NUS, School of Computing CS4236 Computer Security

11. How feasible is this attack ? NUS, School of Computing CS4236 Computer Security

12. DEFENSES We only need to ensure the IKE handshake completes in spite of this fragmentation attack ! How ?? Small Initial Defense First Fragment Defense Avoiding-IP-Fragmentation Defense Using-an-IP-option-for-the-cookie defense NUS, School of Computing CS4236 Computer Security

13. Small initial Message Defense Idea : Redesign the protocol s.t. : all messages are small until a cookie can be verified Pass a hint to the IP reassembly code as to which IP addresses should be preferred when reassembly ressources are limited (priority) NUS, School of Computing CS4236 Computer Security

14. Crypto proposed B A Crypto accepted, cookie A B gB mod p, cookie A B Small initial Message Defense Crypto proposed, gA mod p B A Crypto acc, cookie=c, gB mod p gA mod p, cookie A B B A C, infos from msg1&2,{“Alice”, cert, proof I’m Alice} B A {“Alice”, cert, proof I’m Alice} {“Bob”, cert, proof I’m Bob} A B B A {“Bob”, cert, proof I’m Bob} 4-msg handshake Message 3 depends on fragmentation A B With optional add. Round trip NUS, School of Computing CS4236 Computer Security

15. The necessary implementation modification Ike is above UDP, which is above IP > No channel by which IKE could give the IP reassembly code hints Not hard to implement such. (but layer violation !) Hints = preferred IP addresses (ones that have returned valid cookie) NUS, School of Computing CS4236 Computer Security

16. The guessed IP address attack Attackers can guess IP addresses on the preferred list > frag attack To prevent : time limited preferred list !! Typically between message 3 and SA establishment NUS, School of Computing CS4236 Computer Security

17. Make the extra message optional Extra round trip can be made optional (implemented in IKEv2) Use 4-msg handshake Revert to 6-msg scheme if number of partially handshakes goes over some threshold NUS, School of Computing CS4236 Computer Security

18. First Fragment Defense It is possible to protect against the fragmentation attack without adding an extra round trip for the stateless cookie Redesign message 3 (4-msg handshake) so that Bob’s cookie is the first item in the message, and to allow the reassembly code to pass the first fragment of an unassembled IP packet up to IKE (offset=0, UDP protocol, port=500) Layer violation !! (IP looks at UDP header) NUS, School of Computing CS4236 Computer Security

19. Avoiding-IP-Fragmentation Defense Design IKE so that it does not depend on IP fragmentation >PMTU discovery >Reassembly on IKE end peers Each application-fragment has to carry the cookie! Good protection, but complicate the protocol state machine NUS, School of Computing CS4236 Computer Security

20. Using-an-IP-option-for-the-cookie defense IKE informs IP of the strategy for cookie verification Carry Bob’s cookie in a newly defined IPv4 option If the cookie is a function of the IP address and a secret S, then IKE will inform IP of the function and S Alice’s IKE inserts the IP option with Bob’s cookie in all the handshake message following receipt of Bob’s cookie, s.t. IP can discard all fragments with bogged cookie Much more radical defense, even, against guessed-IP-address attack. It involves not only giving hints to IP reassembly code but actual code for verifying cookies. NUS, School of Computing CS4236 Computer Security

21. Conclusion Strategies for defense against a fragmentation DoS attack by UDP-based protocols Small messages + preferred IP addresses list Cookie = first fragment + preferred IP addresses list Own MTU discovery and fragmentation by IKE Cookies into a new IP option, Ike passes the cookie-verification algorithm to IP 2 first solutions are easy to implement NUS, School of Computing CS4236 Computer Security

22. References Main source: http://portal.acm.org The Internet Key Exchange (IKE) Harkins and Carrel, RFC 2409, 1998 Path MTU Discovery Mogul and Derring, RFC 1191, 1990 NUS, School of Computing CS4236 Computer Security

23. Thank you. NUS, School of Computing CS4236 Computer Security