Why should an IKE responder change the cookie secret 'frequently'?

Question

IKEv2 has the concept of a COOKIE mode, to attempt to prevent state exhaustion from floods of initiation requests from non-existent IP addresses:

Two expected attacks against IKE are state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. These attacks can be made less effective if a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them.

An initiator sends a request to a responder; the responder constructs a cookie using a secret the initiator doesn't have plus details from the request and sends it back to the initiator. The initiator then repeats the request but this time with the cookie attached, thereby proving that they can receive packets sent to the source IP address of request.

The RFC recommends how the cookie could be constructed:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

Where Ni, IPi and SPIi are non-secret values that uniquely define requests from an IP address.

The RFC goes on to say that

The responder should change the value of <secret> frequently, especially if under attack.

Why does the RFC make this recommendation?

Strongswan implement this by limiting the number of uses of a secret to 10000. Windows embeds a time value with a resolution of 150 seconds (see para 28) into the cookie.

If the secret is never changed, then once an attacker has seen a response for a given source IP and request parameters, they can then spam the responder with requests alongside a correct cookie. So there is certainly a good reason to change it at some stage.

But (assuming a good hash function) the cookie doesn't leak useful information about the secret to the flooding attacker. So without changing the secret more often than, say, daily at most, this scheme seems to provide protection against the stated goal (state exhaustion from floods of requests from IP addresses outside of the attacker's control). An attacker needs to observe a response from the responder to a request from each IP address that they want to send requests from before the responder will maintain any state for that request.

So why "frequently"?

(A legitimate answer might be "why not?" - I'm just wondering if there's anything more to it.)

Answer 1

Suppose that the "secret" is kept unchanged for weeks. As an attacker, I could make many connections without IP spoofing, spread over several weeks. I would thus gather possibly millions of "valid cookie values", each for a given source IP address and associated parameters (the Ni, IPi and SPTi values from the RFC). This is the preparation step.

Then, when the attack should actually occur, I replay them all en masse, within a 5 minutes time frame, with the required IP spoofing so that the cookie values match, forcing the server to allocate resources for millions of clients. This will drown the server quite effectively.

By construction, this attack is limited to the number of valid cookies ("valid" in the sense of "will be accepted by the server at the time of attack") that the server could generate. Every change of secret invalidates old cookies. By changing the secret often, the maximum size of the set of currently valid cookie values is kept low, avoiding the attack described above.

Now, of course, claiming that the secret should be changed "more often" in case of attack is just a shamanistic dance to propitiate the Spirits of IT Sec. Similarly, when I see that a homemade construction of "hash the data with the secret appended" is described as "a good way", I cringe and growl and shed tears of blood. Haven't they heard of HMAC ? Do you want to follow cryptographic advice from people who have not heard of HMAC ?