The ISAKMP specification describes conditions in which one party of the protocol might inform the other party of some activity -- either deletion of a security association or in response to some error in the protocol such as if a signature verification failed or a payload failed to decrypt. These informational exchanges should not be responded to under any circumstances. It's too easy to get into a tight message loop where the peers notify each other about the messages that are being passed back and forth. Not worth it.

IKE exchanges maintain running initialization vectors (IV) where the last ciphertext block of the last message is the IV for the next message. To prevent retransmissions (or perhaps forged messages with valid cookies) from causing exchanges to get out of sync, IKE implementations cannot update their running IV until the decrypted message (1) passes some basic sanity check, and (2) has been determined to actually advance the IKE state machine, which means the message is not a retransmission.