From owner-freebsd-security Sat Jan 22 7:19:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id EBE3F14DD8 for ; Sat, 22 Jan 2000 07:19:32 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id IAA04633; Sat, 22 Jan 2000 08:19:26 -0700 (MST) Message-Id: <4.2.2.20000122081057.01992100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:19:23 -0700 To: sthaug@nethelp.no From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <57539.948531872@verdi.nethelp.no> References: <4.2.2.20000122002353.019b9c10@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:04 AM 1/22/2000 , sthaug@nethelp.no wrote: > > You're right. Actually, shouldn't RST- be tossed, > > since you should never reply to a RST? > >Try tcpdump -n 'tcp[13]&4==4' and you'll see a steady stream of RST+ACK >packets. Yes, I forgot: the ACK flag most certainly can be on when RST is on. A RST+ACK is actually specified as the standard response in two situations in the RFC. In fact, the packets evoked by stream.c are RST+ACK packets. RST+SYN and RST+FIN should definitely be dropped. I don't know what one would do with RST+URG or RST+PSH; I would tend to think that one would want to drop these rather than letting them modify the state of any connection, since they could be part of an attack. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message