[Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)

Darren Reed avalon at caligula.anu.edu.au
Thu Apr 22 01:29:53 PDT 2004


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


More information about the freebsd-security mailing list