From owner-freebsd-net Sat Dec 29 20:54:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 4813537B416 for ; Sat, 29 Dec 2001 20:54:36 -0800 (PST) Received: (qmail 58934 invoked by uid 3193); 30 Dec 2001 04:54:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Dec 2001 04:54:35 -0000 Date: Sat, 29 Dec 2001 23:54:35 -0500 (EST) From: Mike Silbersack X-Sender: To: Randall Stewart Cc: Bosko Milekic , Subject: Re: m_reclaim and a protocol drain In-Reply-To: <3C29BEF3.611BCAFE@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 26 Dec 2001, Randall Stewart wrote: > This comment facinates me. The reason we made SACK's in SCTP > revokeable is due to the potential DOS attack that someone > can supposedly lauch if you don't allow the stack to revoke. > > I can actually see the reason that Sally made the comments > and had us change it so that SACK's are revokeable. However > you argue to the contrary and I wonder which is correct. > > If you do not allow revoking it is the same as if a protocol > does not hold a drain() fucntion. A attacker could easily > stuff a lot of out-of-order segments at you and thus > fill up all your mbuf's or clusters (in my current testing > case). This would then yeild a DOS since you could no longer > receive any segments and leave you high and dry.... Heh, you nailed the reverse of the problem we've seen: Right now the easy way to cause exhaustion is to fill up _send_ buffers, via netkill. I guess if we solve that problem, out of order segments could be used for an attack too. Just FWIW, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message