Cookie serve as an identifier for the remainder of the messages in the protocol.
Consider TCP SYN flooding, which is a prototypical DoS attack. Each
TCP SYN request causes the server to do a little work (create a SEQ number,
for example) and to keep some amount of state. That is, the server
must remember the so-called half-open connection so that it can complete
the connection when the corresponding ACK arrives in the third step of the
three-way handshake. It is this keeping of state that an attacker can exploit
to create a DoS. If the attacker bombards a server with a large number of SYN
packets and never completes the resulting half-open connections, the server
will eventually deplete its resources. When this occurs, the server cannot
handle legitimate SYN requests and a DoS results.
To reduce the threat of DoS in IPSec, the server Bob would like to remain
stateless as much as possible. The IPSec cookies are supposed to help Bob
remain stateless. However, they clearly fail to achieve their design goal. In
each of the main mode protocols, Bob must remember the crypto proposal,
CP, from message one, since it is required in message six when Bob computes
proofB. Consequently, Bob must keep state beginning with the first
message. The IPSec cookies therefore offer no significant DoS protection.
