[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
Hi Ari,
I actually agree with what you said. My only disagreement was that I thought
you were suggesting using a CPU-intensive algorithm (e.g. RSA) to sign the
data when a fast algorithm would work just as well. That was just a
misunderstanding of your previous message.
What I was trying to point out is that reflecting the state payload is
functionally equivalent to just sending the information when it is needed.
How you design the protocol is based on the tradeoffs involved. As Ted
pointed out, the design of the current IKE exchanges was a tradeoff of
responder state against network latency.
But within the Isakmp/Oakley framework, you are free to propose new phase 1
exchanges. We already have one proposal for a DoS resistant (against
CPU-usage attacks) exchange (base mode), and if it becomes necessary then
someone can invent a new exchange that has resistance to cookie clogging
attacks.
The state payload would work for this, but in terms of efficiency (in this
case, throughput), having the responder generate the SA proposal would be
more efficient. I don't see anywhere in Isakmp where it says that the
initiator must generate the proposals; if you are inventing a new exchange,
you are free to put the payloads in whichever message you want.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: