ikev2 DOS protection mechanisms

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

>>Re: protection for Alice from false responder DOS attack.
Yes. I agree it should be a MAY and not a SHOULD.

What do people think about the other DOS protection we added in this
version of IKEv2 (the fragmentation attack protection). We didn't
actually change the protocol, we just added implementation hints
for how to protect against this attack. And it convinced us, as we said
in the rationale document, to keep the handshake as an extra
round trip if Bob wants to use a stateless cookie, because then
we could guarantee that Bob does not need to keep state for reassembly
until he's gotten a valid cookie. Until he
gets a valid cookie from that IP address, the IKEv2 messages
are guaranteed to be sufficiently small not to need fragmentation.

If the IKE code can tell the IP reassembly code which IP addresses
should be preferred for reassembly resources, (and the protocol does
not require Bob receiving a very large message before he gets a cookie),
then Bob can really be stateless until the IP
address has sent a valid cookie.

In contrast, even though on paper a 4-message protocol might look like
Bob can be stateless, if packets are sufficiently large to need to be
fragmented, then Bob has to use state to reassemble the messages.
With the IKEv2 handshake, msg 1 is small, and the repeated msg 1, this time
with Bob's cookie, will still be small, so Bob will know before message 3
(which contains a cert and therefore might need to be fragmented) if this
IP address is worthy of using up reassembly resources.

Not all implementations will be able to have IKE pass hints to the IP
reassembly code, but I think it would be nice to have the handshake
designed to *enable* people to write their code that way, in case
fragmentation DOS attacks become prevalent.

Anyway, comments?

Radia