Extended timeout for new TCP connections

[Nico Williams]

On IRC I expressed concern that the value of 10 seconds is related to
OTP requirements but being applied to all KDC requests
indiscriminately.  I think this is both, inappropriate and
undesirable.  My recommendation is that you make this value
configurable for OTP and non-OTP requests.

On a related note, I think we ought to have an application-layer ACK
with average processing time and standard deviation for the type of
KDC-REQ that the client last sent.  This would be requested/enabled by
a kdc-option.  This would make timeouts much more adaptive and would
(if widely deployed) prevent clients from having timeouts that are too
aggressively short (which are risky as they can cause a load spike to
reinforce itself).  For example, if a KDC crashed immediately after
accepting a TCP connection then if the client knew the KDC to send
ACKs, or if the KDC had sent an ACK before crashing, then the client
could timeout much faster than in 10 seconds without causing undue
load on the next KDC.  This could be particularly useful for PKINIT,
maybe future PKCROSS, and for KDCs that use LDAP too, as well as for
OTP (where the KDC could even send a second ACK indicating that
because of token state synchronization the request will require an
extra N seconds).

In the meantime, I agree that at least a TCP socket's being connected
is a much better indication of likely success than we get with UDP
(where we get none).

Nico
--