On Wed, 21 Apr 2004, Don Lewis wrote: > > 1. Accept all RSTs meeting the criteria you just listed above. > > At this step, it would be better if we used the window size that was > advertised it the last packet sent, since that is what the sequence > number of the RST packet will be calculated from, while the window size > could have increased if data was consumed from the receive queue between > the time we sent the last packet and when we received the RST. > > It doesn't look like we keep the necessary data for this. Probably the > easiest thing to do would be to calculate the expected sequence number > in tcp_output() and stash it in the pcb. Do you have access to a system that exhibits the "RST at end of window" syndrome so that you could code up and test out this part of the patch? > It would be nice to be able to age invalid RST packets so that things go > back to normal when an attack ends, but this might enable slow speed > attacks. I think we can probably come up with something acceptable. If we just stop accepting RSTs for the next 30 seconds or so, that would significantly slow down the attack. Although slow speed attacks could still be possible, I don't see that as being too much of a risk. > We have to be careful not to falsely trigger the attack code if we ever > decrease the window size. > > RST packets with sequence numbers lower than (to the left of) the window > can be expected under normal circumstances if there are a number of > packets in flight when the peer decides to drop the connection. This > should not trigger a global attack status. Trigger a per-socket attack > status should be ok, because if the RST packets are legitimate, they > should trip the exact match test. We could make RST packets that are (left - window) not count towards the attack count, that should solve that problem. I think we have something that might work... Darren, PHK, etc - any comments? Mike "Silby" Silbersack _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"