Date: Sat, 05 Jun 1999 18:27:17 -0700 From: Scott Michel <scottm@cs.ucla.edu> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-current@freebsd.org Subject: Re: net.inet.tcp.always_keepalive on as default ? Message-ID: <199906060127.SAA00862@mordred.cs.ucla.edu> In-Reply-To: Your message of "Sat, 05 Jun 1999 20:57:29 EDT." <199906060057.UAA20103@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> This wouldn't help the poor sod whose connection gets shot down every > eight days while he's not there and doesn't know what hit him. One thing that no one points out is that this "idle" connection is potentially a security threat. Even if the physical connection is iced and is reconnected later using the same IP and the TCP connection is restored because it was kept alive, this presents a whole new world of interesting exploits. It's non-trivial, but that doesn't stop people like Network Associates' Labs from publishing papers on the subject. It seems to me that the keepalive might improve the security situation in the case in addition to doing something about connections with unknown status. The "poor sod" in this situation deserves something untoward, IMNSHO. Protocols like ssh do send something periodically whereas telnet doesn't. Telnet is a well-known security problem. As others have pointed out, this is an endemic problem in applications generally speaking, where a long-term "idle" connection isn't treated as an exception or an an error. Your point on randomization is well taken and is generally what's taught in graduate Internet architecture related courses (ok, Lixia Zhang will drill this into your head here at UCLA, YMMV elsewhere.) Although a more conservative distibution would be [t-t/2, t + 2t]. :-) -scooter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906060127.SAA00862>