Darren Reed wrote: > In some mail from Mike Silbersack, sie said: [ ... ] >> 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 ? My take on this is that connection setup and teardown phases are generally present (and thus vulnerable to attack) for a very short time interval compared with the time ESTABLISHED connections may persist, so using a strict check for that phase makes sense. > 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 ? Yes. > 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.) It's not clear to me that under the circumstances required for this attack, there is much difference between injecting a RST or a FIN, or anything else, for that matter: if you know or guess IP addresses, ports, and guess a sequence # in the window, you can inject a packet of data, too. That's enough to mangle any application-layer checksumming.... > If someone injects a FIN packet the way they would have done a RST, > what are the implications ? A FIN seems likely to be dropped as duplicate data: Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. A packet containing a FIN is unlikely to match the seq # exactly, and thus is likely to be overwritten by authentic packets, particularly a bare FIN. If you send a lot of data in the packet, perhaps it's more likely that your packet has some data that's accepted and thus the FIN gets processed, but big packets take longer for the attacker to send to send. -- -Chuck _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"