Re: [Hipsec] Cookie

> Thanks, Jukka, for your suggestion. However, I fail to see

I improved my proposal. The main objective in the cookie is to reject the packet before signature check and other packet handling.

The new version do following things:

1. fast-hash check
2. sha-1
3. hmac (the previous sha-1 is used with this hmac)

Finally, it is only twice as time consuming as draft-06 proposal. The meaning of my email is to raise more discussion related to cookies :-)

> However, as we talked later after you send your message, there

Right. Below is the new version of my proposal:

Precomputation#1 by the Responder:

     Zeroes the COOKIE TLV.
     Creates a signed R1 and caches it.
     Save R1 for long time

Precomputation#2 by the Responder:
     Generate a random number KEY with index KEY-ID.
     Save KEY with KEY-ID for a Delta time (~1 minute).

Responder:
     Creates COOKIE TLV:
             Generates a random number I.
             Generates a random number J.
             Sets up the challenge difficulty K.
             Compute hash = Ltrunc(SHA-1( I | HIT-I | HIT-R | J ), K)
             Compute hmac-R = HMAC(KEY, hash)

             Store I, K, hash, hmac-R and KEY-ID in into the cookie.
             Send cookie in R1.

Initiator:
     Generates repeated attempts to solve the challenge until a matching
     J is found:
     Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == hash received in R1.
     Send I, J, K, hmac-R and KEY-ID in a Cookie in I2.

Responder:
     Compute "fast-hash" XOR =  HIT-I ^ HIT-R ^ hmac-R
     if XOR exists in memory -> reject
     Computes hash := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K )
     Gets the KEY matching KEY-ID
     Computes hmac-I =  HMAC(KEY, hash)
     Verifies hmac-R reiceived in I2 packet and just computed hmac-I
     	Reject if hmac-R != hmac-I
     	Accept if hmac-R == hmac-I
     Saves XOR.
     Keeps n last XORs in the memory. The size of n depends on the size of
     Delta time. Smaller Delta time means smaller n.

• Jukka Ylitalo

  ---