On Wed, 5 Jan 2005, Mark Allman wrote:
I ran this idea by Randall Stewart who has done a bunch of thinking on this topic (and, helped produce one of the current internet-drafts on the topic). He swayed me that my initial hit (above) might not be quite right. Below is Randall's response to my forward of Mike's note (forwarded with permission). This is a case that had not occurred to me and leaves me thinking maybe ignoring SYNs is not quite the right approach. However, I think there could be times when ignoring SYNs might be fine. E.g., if the connection is moving right along and there are other packets being transmitted and ACKed and we see a SYN that it should be ignored.
FWIW.
allman
Don convinced me of the same thing, using similar reasoning.
I think that you're right that "there could be times when ignoring SYNs might be fine." I think that we track how long a connection has been idle; my plan is to only respond to SYNs if the connection has been idle for more than 30 seconds or more. That should ensure that we handle the client crashing case properly (even if the client reboots instantly, it'll keep retransmitting SYNs for more than 30 sceonds), but also ensure that we do not let a forged SYN flood prod us into sending unnecessary ACKs. I'll try to get this coded up this weekend.
(Yes, rate limiting ACKs to these types of SYNs would also help, but it would be nice to not send any unnecessary packets.)
Thanks for Randall's response, it provided some useful insight into the situation.
Mike "Silby" Silbersack _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
