Re: 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
> an error reply which the other end can *trust*?  If error replies are not
> authenticated, the potential for denial-of-service attacks is mind-boggling.
> And authenticating them, at reasonable cost, is seriously hard.

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: [email protected]  http://www.math.ucla.edu/~jimc (q.v. for PGP key)