4

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

Community
  • 1
Michael
  • 2,118
  • 15
  • 26

1 Answers1

7

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 ?

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Thanks. I think this assumes that an attacker has access to millions of IP addresses over a number of weeks, but not at any one time (as a server can separately and trivially enforce a connection limit from one IP address). Maybe this is a valid threat model, but it doesn't sound overly plausible. Spirits of IT Sec - agreed, that would be a suggestion at a committee meeting which no-one could be bothered to think about or argue away. – Michael Feb 25 '13 at 22:04
  • The IP addresses need not be different. The `Ni` field is chosen by the client, so an attacker can use random `Ni` to get a lot of distinct cookies. The attack works better if many distinct IP addresses are used, because there are tools to block flood attacks which all come from the same IP. The point of the cookie is to resist flooding in DDos scenarios, i.e. we already _assume_ that the attacker has access to lots of IP addresses (otherwise, we have simpler ways to deal with the flood). – Tom Leek Feb 25 '13 at 22:12
  • The RFC suggests that the threat is from forged IP addresses and this is what cookie mode is trying to protect against. I concur (see my first comment) about easier protections against attacks from a single source IP address. So I think my conclusion is the RFC doesn't quite know what threats cookie mode is trying to counter, but at any rate changing the secret frequently protects you against some very specific threats. – Michael Feb 25 '13 at 22:24