From owner-freebsd-net Sun Apr 23 9:11:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 35E8437B565 for ; Sun, 23 Apr 2000 09:11:19 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA05698; Sun, 23 Apr 2000 12:11:10 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sun, 23 Apr 2000 12:11:09 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Assar Westerlund Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <5ln1mkom0h.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23 Apr 2000, Assar Westerlund wrote: > Robert Watson 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. 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. 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''. 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. 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