Date: Thu, 22 Apr 2004 18:29:51 +1000 (Australia/ACT) From: Darren Reed <avalon@caligula.anu.edu.au> To: silby@silby.com (Mike Silbersack) Cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) Message-ID: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> In-Reply-To: <20040422031525.E19921@odysseus.silby.com> from "Mike Silbersack" at Apr 22, 2004 03:16:12 AM
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Mike Silbersack, sie said: > On Thu, 22 Apr 2004, Darren Reed wrote: > > > 1. RSTs exactly at last_ack_sent (always accepted) > > > > To pursue this thought further, if a FIN has been sent or received > > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something > > else) then receiving an RST at this point should be much less of a > > problem, yes ? > > > > The only drawback is I've seen sessions where there's a last ditch > > attempt to get data through even though a FIN has been received. > > > > Darren > > Are you suggesting that we use the strict check during the ESTABLISHED > phase, and the window-wide check during all other phases? Possibly :) I don't think it is important for session setup, but at the end of a session, you generally want it to disappear from your connection table sooner rather than later, right ? Furthermore, you're more likely to get a RST after a FIN has been sent, by either party, if you send another ACK because the other guy has decided to remove the socket already. Does this make sense ? Although this makes me wonder, what's the implication here for FIN packets - is there none ? The draft refers to SYNs (which do get special treatment) and RSTs (just more violent FIN packets.) If someone injects a FIN packet the way they would have done a RST, what are the implications ? Does a packet storm ensue ? Does the FIN get ignored ? Do FIN packets also need to be challenge-responsed now ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404220829.i3M8TpcB022690>