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