[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKEv2 & DoS protection
> > > Does this mean that if you want anti-clogging protection
> you need to
> > > send 6 messages, not 4?
> >
> > Yes. Deployment experience has shown that a box is usually not under
> > attack and that it would be nice to eliminate the overhead for the
> > usual (overwhelming majority) case.
> Yes, that's what I figured. Just making sure I understood.
In disussions related to DoS protection during the last few years, there
have been many suggestions for how to do DoS protection:
1. Mandatory stateless cookie exchange (e.g. Photuris)
2. Optional stateless cookie exchange (e.g. Oakley)
3. Random drop
4. STATE payload
5. Repeat payloads from message 1 in message 3
6. (5) with a round-trip optimization (e.g. JFK)
All of these work, although (3), which is what you're supposed to do with
modern day IKE, has a lot of undesirable properties.
(6) is a very clever optimization, and although I am a fan of doing things
just because they are cool, I can't help thinking that (2) is the superior
approach. When I heard that JFK was going to be state DoS resistant and
protect the identity of the initiator in a 4 message exchange, I was
initially very skeptical. But they did it, and I congratulate the authors
for resolving three seemingly incompatible goals.
But I guess the question on my mind is still "Okay, but so what." (6)
imposes severe restrictions on the format of the exchange. (2) is just a
modular DoS protection mechanism that could be grafted onto any key exchange
without degrading average case performance. (2) is a more generic solution,
and IMHO that makes it better.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
References: