Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fw

看板FB_security作者時間22年前 (2004/04/23 00:31), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串14/23 (看更多)
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 _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
文章代碼(AID): #10X_D500 (FB_security)
討論串 (同標題文章)
完整討論串 (本文為第 14 之 23 篇):
文章代碼(AID): #10X_D500 (FB_security)