[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

At 14:51 30.1.2000 -0500, you wrote:
>
>WG Members:
>
>We are hearing more and more concerns in the enterprise community
>that ISAKMP will be vulnerable to UDP denial of service attacks
>in the future.  This is a widely known and serious flaw, IMHO.
>
>----------------------------------------------------------
>FYI Review of RFC 2408: ISAKMP
>----------------------------------------------------------
>
>2.5.1 Transport Protocol
>
>ISAKMP can be implemented over any transport protocol or over IP
>itself.  Implementations MUST include send and receive capability for
>ISAKMP using the User Datagram Protocol (UDP) on port 500. 
>----------------------------------------------------------
>
>The specification above means that most vendors who read this
>will build ISAKMP on 500/UDP; which means that any malicious
>person with a clue as to how UDP DoS attacks can be done will
>be able to create chaos with the ISAKMP process during SA
>setup, etc.
>
>Vendors with a clue will build an alternate mechanism which allows
>ISAKMP to play using a more robust transport mechanism, at least
>TCP based, which raises the bar against simple UDP DoS attacks.
>
>I suggest the ISAKMP RFC address this vulnerability more directly because
>IPSEC and ISAKMP security issues such as this could be treated more
>openly in the RFC, perhaps even an ISAKMP protocol risk-analysis should be
>documented in the IETF process.
>
>Finest Regards,
>Neo
>

Folks, let me rephrase the problem to check if we're talking
about the same problem here:

The problem is that ISAKMP implementation do policy lookups, create state
and even do RSA or DH before the IP address of the sender is verified.
An attacker could send packets with random source IP address and
keep the ISAKMP machine very busy.

This could be solved by using another transport layer. For instance, here's my
antispoofing protocol:
- use UDP port 55555 instead of 500.
- a header with a ticket field is used (var length), after that a normal 
  ISAKMP packet. Compare that ticket with Ari Huttunen's state payload.
- before doing phase 1 ISAKMP exchange, the initiator requests a ticket
from the
  responder. Like, Initiator sends empty packet, Responder returns ticket
  (some array of bytes, opaque for the initiator, very much like ISAKMP
cookies).

If the sender uses wrong source addresses, he never gets my ticket
and can't attack my ISAKMP engine.

That antispoofing protocol looks too simple. Can somebody check whether this
would work?


Question is, why wasn't this build into ISAKMP? The normal ISAKMP
cookies could have been exchanged before sending the SA payload.
Would have taken an extra round-trip, of course.

Jörn Sierwald
References: