What is the functional role of CKY-I and CKY-R in ISAKMP (IKEv1)? According to RFC 2409:


  CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header.


Each CKY is a 64 bit value that is included in each ISAKMP Header in the Phase1 and Phase2 negotiation, and future ISAKMP informational exchanges.  And they are also used in the math for key generation.

Also in the ISAKMP RFC, I see that the Cookies are used to Identify the ISAKMP Security Association (SA):


  Per the base ISAKMP document, the ISAKMP SA is identified by the Initiator's cookie followed by the Responder's cookie 


(although I'm not sure what "base ISAKMP document" they are referring to)

Given all these describe what the CKY-I and CKY-R values are, I am curious to understand why they exist.  Effectively, what is the functional role they play?

If they solely exist to identify the SA, why not simply use an SPI value like IPsec does?  Or, why not simply pick a random arbitrary value to use and not include it in all the key material calculation?

Bonus question:  “How” are they created? I imagine they are random values, but I couldn't find any confirmation related to that in the RFCs.
What is the functional role they play?


They exist to identify the SA.  That is, when an IKE implementation receives an IKE packet, it is able to use the cookies to identify the SA that the packet corresponds to.


  Why not simply use an SPI value like IPsec does?


Why do you think there is some fundamental difference between the cookies that IKE uses, and the SPI that IPSec uses?  They are essentially the same; they are an arbitrary identifier that the allows the implementation to correlate incoming packets with SAs.  Now, there are some minor differences; most notably that an IKE packet contains the identifiers from both sides, while an IPSec packet only contains the identifier from the receiving side; however that difference doesn't change what those identifiers signify.


  how are they created?


Actually, the RFCs do not specify how the implementation selects its cookies, and for a good reason; that is something for the implementation to decide, and if the implementation can (for example) speed up the lookup by selecting nonrandom values, it is free to do so.

Now, there is a minor glitch for IKE cookies that do not reply to IPSec SPIs; since both the initiator and the responder cookies are in the IKE packet, then if both sides select nonrandom cookies (and use the same strategy), then there is a possibility for the implementation to get confused (as it won't know apriori which cookie is his, at least if the implementation can be both an initiator and a responder.  This possibility also exists if the cookies are selected randomly; however the cookies that sufficiently long that such a collision is, in practice, improbable.