[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What do you do in the case of initiate collisions?

  Robert,  

> We run into the collision problem because 1) we have a lot of bi-
> directional traffic from multple hosts, and 2) we added a network 
> delay of about 5-10 seconds to simulate latency.  That latency 
> number could be a lot worse.  We were looking at the {power fail,
> 8am Monday morning} problem.
> 
> In the case where an ISAKMP SA between hosts does not exist, A and
> B start to negotiate within the latency window:
> 
> A ---> B   {HDR, SA} where Ci = cookie_a, Cr = 0, MID = 0
> B ---> A   {HDR, SA} where Ci = cookie_b, Cr = 0, MID = 0
> because at this point, B hasn't received A's request and vice-versa.
> 
> A ---> B   {HDR, SA} where Ci = cookie_b, Cr = cookie_a, MID = 0
> B ---> A   {HDR, SA} where Ci = cookie_a, Cr = cookie_b, MID = 0
> 
> Unless there is some protocol, such as x.25 address comparison, to
> deterministically decide which SA request to drop, I can't see anyway
> to avoid creating two ISAKMP SA's.  I don't think this is a security 
> problem, because both hosts have agreed to the proposals, but it's 
> kind of a pain because now you have two ISAKMP SA's and you have
> to decide between them.

You can't really just decide to delete one anyway-- in my opinion. If 
one side wanted PFS for identities as well as keys he'd remove the ISAKMP
SA as soon as the IPSec SAs were established. The other side may have
no such requirement on the IPSec SAs it's creating. (Imagine the 1st
is for telnet to a sensitive machine and is 3DES w/HMAC-SHA; the other
is just for ftp to a different host and is AH-HMAC-MD5. Pardon my
router-centric frame of mind).

The choice is easy. If you created it use it. You can modify your reaper
(assuming you've got a reaper) that could reap duplicate ISAKMP SAs
regardless of their lifetime if you really don't like having duplicates
lying around.

> Another issue, the Cisco reference implementation generates a single
> stamp to be used in generating the cookie.  In order to support multiple
> ISAKMP SA's between hosts, we will generate a cookie based on the
> the remote ip address and a thing stored in our ISAKMP SA.  Will this
> break anybody's implementation?

Ah, the good old cisco reference implementation.... I'll be changing that
realsoonnow. The cookie just has to be unique for the peer. This can be
done by setting the first 1/2 of the cookie to be random noise and the
rest to the hash of the stamp + the peer's address + whatever else you
feel like including in your cookies. That way in your example above
the cookie_a that is the result of A's initiation would be different than
the cookie_a that is the result of A's response to B's initiation. In fact,
it would be different than another cookie_a that is the result of another
initiation by A.

Since your construction of the cookie is completely up to you it shouldn't
break anybody's implementations.

  Dan.
References: