On Thu, 6 Jan 2005, Mike Silbersack wrote:
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.
OK, time to chime in here - if you read Don's comments, the particular example he chose to use was BGP, where one end crashes and tries to bring up a new session. BGP stability in particular was also one of the main reasons this particular draft received so much attention recently. Now, I'm a network engineer, not a developer. And if there is one thing I would hate if a BGP process were to crash, it is for the reestablishment of this connection to be delayed for up to 30 seconds because the other end thinks it is a good idea to ignore these SYNs. So please - don't.
Why not stick to the procedures outlined in the draft as they are? The acronym "KISS" also comes to mind here, I don't really see that sending a few extra ACKs in this situation is a particularly relevant problem, I have problems seeing how this would realistically be used as a vector for a DoS or other nastiness.
/leg _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
