Date: Sun, 23 Apr 2000 18:02:18 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Assar Westerlund <assar@sics.se>, freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) Message-ID: <200004232202.SAA47172@whizzo.transsys.com> In-Reply-To: Your message of "Sun, 23 Apr 2000 12:11:09 EDT." <Pine.NEB.3.96L.1000423120520.3461B-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000423120520.3461B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23 Apr 2000, Assar Westerlund wrote: > > > Robert Watson <rwatson@FreeBSD.ORG> writes: > > > Any idea what the default idle time before keepalives kick in is? > > > > Is it really keep-alive that's interesting here? Isn't it the > > retransmission timer? > > > > If somebody is doing "mbuf exhaustion", we will have un-acked > > outstanding data. And it should be the same case with "process > > saturation". > > Regardless of the mechanism, presumably the goal would be to sever > connections early on if they aren't demonstrating decent properties. Yes, but the difficulty is that there is no commonly agreed upon description of "decent properties." Just because you don't use TCP in a certain way, on unusal paths doesn't mean that it's wrong. > I.e., acknowledging data transmissions, et al. So give them 30 seconds, > and if they haven't acknowledged anything, cut them off. Far better than > the multi-minute delay, although still not ideal. Well, hell, a V.90 modem can tie itself into knots for 30 seconds trying to retrain. This is a little quick on the trigger, don't you think? Not to mention folks trying to use TCP on long-delay, crappy paths with connectivity that might be intermittant. TCP will sever connections on it's own if there is unacknowledge data. If you have a reasonable measurement of the RTT, you might choose to bias the timeout based on that; but to simply pick a number out of your hat which might reasonably be too small is wrong. > The reason for the keepalive timer suggestion was that it's already a > mechanism for detecting hosts that are not responding properly to TCP and > therefore should be disconnected. Making it slightly more agressive early > in the connection would have the effect of weeding out hosts that build > connections to make a request, but then ``disappear''. The keepalive mechanism is both poorly named (it's really a MAKE-DEAD mechansim), and a crock. If an application cares about idleness, then it should contain the mechanism to detect it. There's no reason why my TCP connection should be needlessly aborted when there's no unacknowledged data from either endpoint, and there's a transient connectivity failure. > Avoiding fragility and brittleness is a big issue, however. For example, > unwillingness to accept data quickly is not the same as unwillingness to > accept data at all. Of course, none of this solves the fundamental issue > with denial of service: if you offer a service that costs you something to > provide, and the capacity exists for someone to consume that service very > cheaply, then there is the opportunity for denial of service. The goal is > to sufficiently raise the bar that denial of service is relatively costly > to perform, which can be done by reducing opportunities for flooding, > reducing vulnerability to the easy attack channels, et al. I really wish folks would be much less quick to leap into screwing with the implementation of TCP. It has evolved to the state it's in over many years of painful experience and hard-won knowledge. Breaking TCP for perfectly reasonable uses is also a denial-of-service attack of sorts. Perhaps if you're concerned that random people are attacking your system by using the way TCP functions, you should instead use IPSEC to authenticate the remote party before allowing the connection to open? That at least addresses the a problem in a direct way, rather than introducing further unintended consequences by changing the way the TCP works. louie > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004232202.SAA47172>