[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
> Thinking about future ISAKMP denial of service attacks
> on UDP has lead me to these system-centric risk reduction
> architectural observations (sorry for the mouthful ...)
You mention DOS attacks on UDP. Is there an alternative? TCP clearly
hasn't solved this problem.
> (1) ISAKMP is most vulnerable to DoS attack during the
> initial set up.
>
> (2) Risk is reduced by minimizing set-up time and maximizing
> non-setup processing (time).
>
> (3) Therefore, one trade-off goal in architecture and
> vs risk could be based on creating an architecture
> which minimizes ISAKMP set-up(s).
We've considered the vulnerability to attacks on against memory and
processing exhaustion.
Neither of these are attacks that take place 'during' a set-up. These are
attacks which force the creation of set-ups and hence the consumption of
memory and processing time.
The protocol already tries to minimise (defer) the processing effort until
the host is reasonably certain that it's not being spoofed. The trouble
here is that this causes to retain state until authentication is performed
later in the protocol and this leaves it open to a memory consumption attack
or even, still, a resource depletion attack if the attacker opens a number
set-ups before proceeding to the next stage. What allows this is that the
delays inherent in the Internet force hosts to hold sessions open for a
reasonable time to allow a 'distant' peer time to respond.
I think the points here would be to minimise the state held for
pre-authentication sessions and minimising the effort require to
authenticate a session. These two points apply particularly to the
responder, assuming the threats are on the 'public' side of the gateway.
One way to minimise the state held is for the responder to sign its state
and return it to the initiator. One way to minimise the processing used is
to employ symmetric authentication algorithms rather than public key
algorithms. Symmetric key based solutions don't scale so this doesn't
affect the need for a PKI.
> (4) Establishing long standing tunnels with ISAKMP
> (tunnel mode) vs. shorter duration host-to-host
> exchanges (transparent mode) may significantly
> reduce ISAKMP DoS risk.
Other than these are different applications, I would agree.
> This does imply that the complexity of 'trying to do it
> all' with IPSEC/ISAKMP is weakening the integrity of
> the system architecture (mentioned in the other thread
> on 'IPSEC complexity').
This is probably the greatest risk.
> Controversy may continue in the 'complexity vs. robustness'
> debate, and it is possible that organizations will migrate
> to tunnel mode centric architectures to reduce DoS risk.
>
>
> Finest Regards,
> Neo
Chris