[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Daemon Recovery
Daniel Harkins writes:
> 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.
>
The keep-alive might not be a bad idea. This way A and B always knows
each other state.
It should also prevent another situation which another node, C, trying
to attack B by sending packets with bogus SPI to B with A's address.
In this case, A and B know that they both have good SKEYID state, so
the packet that B received must be corrupted and B could send ICMP
error message back to A, if B selected to do so to notify A of the
potential problem. The action should also be rate-limited to minimize
possibility of denial of service attack.
Ok, I admitted, I throw the above ideas together into a mixer, but it
might work.
-Pasvorn
References: