Re: Async rekey?

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

Simon Tatham <anakin%pobox.com@localhost> writes:

>One useful feature of this is that it provides detection and intolerance of
>implementations that forget to rekey at all.

This is actually a bad thing in some cases.  In a lot of SCADA use the amount
of traffic sent over an SSH channel is tiny, so that it would take about
6.023e23 years before a sufficient amount of data is exchanged that rekeying
would be justified.  However since some systems insist on a rekey as often as
every thirty minutes (two to four hours seems to be the most popular cargo-
cult figure, although 4253 says one hour), there is often vastly more rekeying
traffic being exchanged than actual payload, including pathological cases
where the only traffic being exchanged during an entire rekey interval is the
rekey messages.

In addition because of the confusion over handling of rekeying (although this
may have gotten better over time, haven't looked for awhile) it leads to
really difficult-to-diagnose problems where the session suddenly dies for no
(non-self-inflicted) reason.

The de facto procedure for this in several implementations is just to ignore
rekeying and, once the other side doesn't want to go any further and the
session gets dropped, reconnect.  With non-interactive sessions where there's
no-one to sit there and fiddle with settings to make things work, having the
session go down and reconnect is just part of normal operations while having
data packets misplaced around a rekey while the crypto reports that everything
is functioning as intended leads to huge headaches.

It would be useful to have an extension to negotiate no rekeying, so the other
side doesn't drop the connection at regular intervals.

Peter.