Date: Sat, 22 Jan 2000 08:19:23 -0700 From: Brett Glass <brett@lariat.org> To: sthaug@nethelp.no Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000122081057.01992100@localhost> In-Reply-To: <57539.948531872@verdi.nethelp.no> References: <Your message of "Sat, 22 Jan 2000 00:29:21 -0700"> <4.2.2.20000122002353.019b9c10@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:04 AM 1/22/2000 , sthaug@nethelp.no wrote: > > You're right. Actually, shouldn't RST-<anything else> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000122081057.01992100>