Add some discussion of rekeys-as-keepalives, and their potential

adverse effect on the life expectancy of a low-use connection over a
low-reliability network.

git-svn-id: svn://svn.tartarus.org/sgt/putty@5041 cda61777-01e9-0310-a592-d414129be87e

diff --git a/doc/config.but b/doc/config.but
index ed6600c..361d68e 100644 (file)
--- a/doc/config.but
+++ b/doc/config.but
@@ -2200,8 +2200,21 @@ used:
 }
 
 PuTTY can be prevented from initiating a rekey entirely by setting
-both of these values to zero. (Note, however, that the SSH server may
-still initiate rekeys.)
+both of these values to zero. (Note, however, that the SSH
+\e{server} may still initiate rekeys.)
+
+You might have a need to disable rekeys completely for the same
+reasons that keepalives aren't always helpful. If you anticipate
+suffering a network dropout of several hours in the middle of an SSH
+connection, but were not actually planning to send \e{data} down
+that connection during those hours, then an attempted rekey in the
+middle of the dropout will probably cause the connection to be
+abandoned, whereas if rekeys are disabled then the connection should
+in principle survive (in the absence of interfering firewalls). See
+\k{config-keepalive} for more discussion of these issues; for these
+purposes, rekeys have much the same properties as keepalives.
+(Except that rekeys have cryptographic value in themselves, so you
+should bear that in mind when deciding whether to turn them off.)
 
 \H{config-ssh-auth} The Auth panel