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>)
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.)