RE: SOI QUESTION: 3.1 DoS protection

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

Michael Thomas asks:
	
	   The real question is what advantage the IKEv2
	   4/6 message exchange confers.
	   
It's easy to make the IKEv2 exchange 4 messages all the time, but it
doesn't come for free, so we made an arbitrary decision to do it
that way. The costs of doing it always as 4 messages are:

a) it makes message 3 always longer (so if most of the time you can
run without needing to ask for a stateless cookie, there will be fewer
bits on the wire)

b) it makes the encoding messier, because part of message 3 has to
be encrypted and part of it in the clear

c) it makes it hard to protect against a fragmentation DOS attack.

***********
The fragmentation DOS attack we described in the IKEv2 spec. The
relevant snippet is:

 Note that one of the denial of service attacks that cookies are
   designed to thwart is exhaustion of state at the target by creating
   half-open connections. This defense would be ineffective if there
   were another equally easy way for an attacker to consume state at the
   target. IKE runs over UDP, and may send messages sufficiently large
   that they must be fragmented. But accumulating fragments of UDP
   packets consumes state at the target, so if an IKE responder were
   required to accept and reassemble UDP packets from unknown sources,
   another equally easy denial of service attack would be possible.

   To thwart the UDP reassembly buffer attack, the IKE responder SHOULD,
   when it detects that it is under attack, have a mechanism to inform
   IP reassembly to only accept UDP fragments from IP addresses from
   which it has received a valid cookie and to refuse to accept UDP
   fragments from all other IP addresses. To facilitate this, the
   IKE_SA_init message SHOULD be kept under 500 octets and responders
   MAY reject fragmented IKE_SA_init messages.

Basically, with avoiding sending large stuff like certificates
until the cookie has been returned, it allows a fairly simple way that
implementations can be organized in order to avoid attackers swamping
memory with needing-to-be-reassembled packets. I'm not sure anyone
has worried about this attack yet, but this design would enable conversations
using IPsec, and which have returned valid cookies, to get preferential
treatment. It does require some layer violation in order for IKE to
tell the reassembly code which IP addresses to give preferential
treatment to.

Note that none of the proposed protocols are "always" 4 messages. They all
expand, for instance, if Alice, in message 1, chooses a Diffie-Hellman group
that Bob does not support. As it happens, I was arguing for the folding-in-
everything-in-4-messages variant from the start, but was (good-naturedly)
outvoted by the other authors who were saying having it sometimes 6 messages
for stateless cookies wasn't a big deal, because it could also sometimes
need to be 6 messages for other reasons. But when Charlie came
out with the fragmentation
attack argument, it convinced me that I like it this way better.

I don't think it's a big deal either way (unless
fragmentation attacks become the next annoying DOS, in which
case it would be nice to prepare for it). But changing
over into the 4 message variant is easy enough to do.

Radia