[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: