Re: [Design] address inertia

On Mon, 17 Feb 2003, Henry Spencer wrote:
> On Mon, 17 Feb 2003, Jim Carter wrote:
> > ...rebooted), it will give an error reply to the other side, which will
> > immediately tear up the defective connection and try to rekey.
>
> In the wonderful world of IPsec, it's not that simple. How can you send

Agreed, east can't reasonably know if the error reply truly came from west. How's this for some heuristics that save the situation? I'm assuming west is a big server with lots of connections. A hacker starts sending out forged error replies on behalf of west, which east believes because they cannot be authenticated.

East has a minimum rekey interval, so once the connection is established, it won't rekey more frequently than (let's say) every 5 minutes. This minimizes CPU overload on east and thrashing on west.

East will continue to try to use the old connection until the new one is negotiated successfully, if it ever is. This keeps the hacker from making east cut communications when the next item happens... If packets are sent to a truly dead connection, presumably un-ACKed ESP packets will be sent again once the connection is renegotiated, if it ever is.

Symmetrically, west also has a minimum rekey interval, and if one of its partners is rekeying too often, or if the system load would impair timely rekeying, it ignores (drops or actively refuses) the rekey attempt from east.

With these heuristics, the error replies have their proper effect in the usual case that they are legitimate. A hacker can affect west, but not enough to significantly impair legitimate service. Back-version clients presumably will ignore the error replies, making no trouble for west. So the result is no worse than what we have now, and better if both ends understand the error replies, because spoiled connections can be renegotiated promptly.

James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc(at)math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)