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

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

I originally posted this only to the anx-sec list, but it seems to have
migrated to the ipsec list.  Here's the original text and some 
additional information on the problem.

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.

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?

-- Original Message Follows --

We're running into a bit of a problem and haven't found any specific
answers.  Basically, we need to know how people are resolving the 
problem where two systems start overlapping exchange sessions to
each other (the cross in the mail syndrome).

It looks something like this

A ----> B         (A initiates a session with B)
A <---- B         (B initiates a session with A)
A <---- B         (B responds to A's initial request)
A ----> B         (A responds to B's initial request)
etc..

This problem results in an ambiguity at the creation of the ISAKMP SA's or, 
if it occurs during QM exchanges, the creation of two pairs of IPSEC SA's
(one for each of the exchanges).  There are a variety of ways to resolve this

a) both back off and retry later.
b) collision resolution based on IP address or cookie comparison, etc.
c) just keep both pairs of SA's around and assume any of them can be used
  until they naturally age out.  This means that you may be sending on one set
  of SA's and receiving on another; does this break anything?
d) generate both pairs of IPSEC SA's and send a DELETE for the outbound SA
  you won't use (and a DELETE for the corresponding inbound SA after receiving
  the outbound SA DELETE).  Since this may delete one side from each pair of
  the SA's, does this break anything?
d) ignore the whole thing and hope it will go away, etc :^)
e) etc.

Has there been a consensus on how to handle this case?  If not, what are people
doing to handle this case.  

Also, it would seem that the handling should be different for the ISAKMP SA's
than for the IPSEC SA's or any other SA's created under the ISAKMP SA
umbrella. And does anyone's ISAKMP implementation allow more than one
ISAKMP SA per host (ie., per src.-dst. pair)?

Thanks,
rwt
---
Robert Tashjian
VPNet Technologies, Inc.
rwt@vpnet.com
Follow-Ups: