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

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



We've also been giving this some thought.

Solution a) will cause unnecessary delays.

The problem with b) is that the simultaneous negotiations may result in two
different SAs (e.g. one ESP and one AH). So it might not be wise to break
one of the negotiations off. (This is a problem especially for phase 2
negotiations where it makes sense to have multiple IPSEC SAs between two
machines.)

Solution d) breaks things up when the deletes are sent simultaneously. In
this case, you go back to solution a).

Therefore, we like solution c) best. It did cause some interoperability
problems in the ANX bakeoff, since some implementations didn't support
this, and deleted the first SA pair that was negotiated when they finished
negotiating the second pair. Maybe it should be explicitly added to the
ISAKMP docs as a MUST.

Roy Shamir
Check Point Software Tech. Ltd.


At 09:09 AM 10/10/97 -0700, you wrote:
>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
>
>
>