Subject: ike2 reliable rekeying

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Mar 2003 10:00:03 -0500

I have a couple of concerns about rekying IKE-SAs and how simultaneous rekey
is currently spec'd. I also believe there is a simple way around the 
issue. My concerns
are:

- When simultaneous rekey does occur, you can end up with multiple SAs 
temporarily.
   In order to prevent explosion of SAs across multiple rekeys, one of 
the SAs needs
   to be deleted. The spec says to wait a random amout of time when this 
is detected and
   delete one of the SAs, altough which SA is not specified. There is 
clearly the possibility
    that each side will wait the same random time and delete different 
SAs, resulting in
    loss of  connectivity at least temporarily. IMHO, there will be 
applications where this
    is a very bad thing.

- My second concern is more a a matter of implementation difficulty. 
When multiple SAs do
   exist, you need to "accept incoming packets through either SA". This 
just seems rather ugly
   from my point of view.

Both these issues could be solved by using a rekey collision detection 
mechanism that could
work as follows:

1) When an IKE instance sends a rekey request on an IKE SA, it marks the 
SA with a rekey flag.
2) If an instance receives a rekey request with the flag set and before 
it has received a response to
     its request, it makes a choice as to which SA is  preferred. 
Preference could be based on peer
     address. If the request it sent is preferred, it drops the received 
request. Otherwise it responds
     normally.
3) If an instance receives a rekey request with the flags set, but after 
it has recieved a response to
     its request, it drops the request. This could occur due to packet 
loss and retransmission.
4) When an instance recieves a rekey request when the flag is not set, 
it prevents itself from
     originating new rekey requests.

This mechanism would prevent duplicate established SAs. The worst the 
could occur would be
an outstanding request on an SA when it received the delete payload from 
the preferred instance.

Of course this seems logical as I write it, but may appear non-sensical 
later, so I'd appreciate
comments.

Regards,
Jeff