2 Jan
2007
2 Jan
'07
9:31 p.m.
> [...RST handling...]
You don't want to just whack any connection that
gets an RST. [...]
Otherwise, somebody can have some real fun with your server by just
spraying random RST segments at you.
True. (At least if ths stack is for use on the open Internet. In some
rather closed environments, it may be perfectly acceptable to take down
a connection on any RST with the right address/port numbers.)
I code my RST handling code such that the RST has to
be within the
current receive window, which is how I read 793. I think I have
misread or misinterpreted, and I should include RST packets that are
in my window of previously sent (but not yet acknowledged) packets.
Not quite, I think. Rather, you should take an RST only when its
sequence number is right at the edge of the window, provided you send a
pure-ACK packet in response to an RST with a bad sequence number.
These make it significantly harder for third parties to shoot down your
TCP connections. If all they need to do is hit your window, the chance
of a random sequence number working is window-size/2^32, which can get
comparatively large, especially when window scaling is in use (though
admittedly I imagine a PCjr stack does not do window scaling :). But
if you accept an RST only when its sequence number is at your window's
edge, the chance is 1/2^32 regardless of window size. In order to take
down legitimately half-open connections, you need to communicate that
sequence number to the legitimate peer, which is what the pure-ACK in
response to wrong-sequence RSTs is for - to elicit a properly-sequenced
RST. (If you want to be really spiffy, rate-limit the pure-ACK
packets, so you can't be used to turn an RST flood into an ACK flood.)
I think this algorithm is written up in an RFC somewhere, but I forget
the number.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B