DoS Protection for UDPBased Protocols

1
DoS Protection for UDP-Based Protocols

• presented by
• Guillaume Saggioro (NT030298X)

2
Overview

• Introduction
• IKE protocol
• Fragmentation attack
• Defenses
• Conclusion

3
Introduction

• Since IP Packet reassembly requires reassembly, a
  DoS attack can be mounted by swamping a
  receiver with IP fragments

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
• gtgtStateless cookie protection

5
Stateless cookie protection

• Defend against attackers that sends traffic from
  fake source address

6
Stateless cookie protectionprinciple
Conn_init, _at_IPA
cookie (_at_IPA)
A
B
cookie
Keeps no state No additional computation
A
B
Conn_init, _at_IPA, cookie)
A
B
cookie(_at_IPA) cookie ?
Conn_ack
Sends Ack if OK
A
B
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 !!

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

9
Basic structure of IKEv1 main mode
By using up reassembly ressources, attacker can
block reassembly
gA mod p, cookie
A
B
Alice, cert, proof Im Alice
A
B
Large message (certificate)
Bob, cert, proof Im Bob
A
B
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
  doesnt get locket out during the initial IKE
  handshake

11
How feasible is this attack ?
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

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)

14
Small initial Message Defense
Crypto proposed, gA mod p
A
B
Crypto acc, cookiec, gB mod p
gA mod p, cookie
A
B
A
B
C, infos from msg12,Alice, cert, proof Im
Alice
A
B
Alice, cert, proof Im Alice
Bob, cert, proof Im Bob
A
B
A
B
Bob, cert, proof Im Bob
4-msg handshake Message 3 depends on fragmentation
A
B
With optional add. Round trip
15
The necessary implementation modification

• Ike is above UDP, which is above IP gt 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)

16
The guessed IP address attack

• Attackers can guess IP addresses on the preferred
  list gt frag attack
• To prevent time limited preferred list !!
• Typically between message 3 and SA establishment

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

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
  Bobs 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 (offset0, UDP protocol, port500)
• Layer violation !! (IP looks at UDP header)

19
Avoiding-IP-Fragmentation Defense

• Design IKE so that it does not depend on IP
  fragmentation
• gtPMTU discovery
• gtReassembly on IKE end peers
• Each application-fragment has to carry the
  cookie!
• Good protection, but complicate the protocol
  state machine

20
Using-an-IP-option-for-the-cookie defense

• IKE informs IP of the strategy for cookie
  verification
• Carry Bobs 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
• Alices IKE inserts the IP option with Bobs
  cookie in all the handshake message following
  receipt of Bobs 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.

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

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

23

• Thank you.