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

Re: Daemon Recovery



  Ted,

>    I have a problem for which I donot have a proper solution.
>    After a complete negotiation between two ISAKMP peers (A and B),
>    the peer B crashes. When B recovers, ip packets from A reach
>    B with SPI values strange to B. Can someone suggest a method
>    to stop A from sending packets using OLD SPI values.
> 
> Bill Simpson has proposed an unsecured ICMP message which tells host B
> that a particular SPI is invalid.  Unfortunately, there are some obvious
> and severe denial of service attacks one could accomplish with this
> tack.
> 
> I could imagine either requiring that the ICMP message be secured in an
> existing SPI from the same host.  A better solution might be to include
> in the ISAKMP negotiations a notification that at the successful
> conclusion of this SPI negotiation, all other SPI's for the same host
> should be discarded.  What do other people think?

  I'm not sure that would fix the problem. Peer A doesn't know peer B crashed
so it doesn't try to negotiate again. As far as A is concerned everything is
hunky-dory. B, on the other hand, silently drops the packets per the spec.

  I've been worrying about this for a while but for a different reason.
If one of the peers is doing Virtual Router Redundancy Protocol and the
failover happens this same situation can occur. To A it looks like nothing
happened. Same IP address, same everything, just all of a sudden everything
IPSec-wise stopped working. I was toying with the idea of an ISAKMP keep-alive 
message as a way to solve this. Periodically the peers could just remind each 
other of their continued viability and prove they still have the SKEYID state. 
If after some period of time a keep-alive was not received, the peer (A in the
example) could begin negotiation with the other peer (B in the example) and
then do as you suggest: throw away the old SPIs and start using the new ones.

  Any other potential solutions?

  Dan.



Follow-Ups: References: