where <secret> is a randomly generated secret known only to the
responder and periodically changed and | indicates concatenation.
<VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was
generated since the last change to <secret> and that IPi must be
the
same as the source address it saw the first time. Incorporating
SPIi
into the calculation ensures that if multiple IKE_SAs are being
set
up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni into the hash
The real reason to hash the SPIs to the cookie is to make sure that
attacker cannot fetch one one cookie from the other end, and then
initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs
(and perhaps port numbers) so that the for the responder it looked
like there is lots of machines behind one NAT box who are all trying
to connect. As the cookie is tied to the SPIi the attacker cannot use
cookie multiple times.
