> You made this change, with the log message:
> 
> revision 1.194
> date: 2004/04/20 16:52:12;  author: itojun;  state: Exp;  lines: +51 -22
> - respond to RST by ACK, as suggested in NISCC recommendation
> - rate-limit ACKs against RSTs and SYNs
> 
> As far as I can tell, this is a reference to NISCC 236929.
> 
> While I have no objection to the rate-limiting, or double-checking received 
> RSTs, I cannot find any reason for the following change:
> 
> +                       } else if (tlen) {
> +                               tp->t_dupacks = 0;      /*XXX*/
> +                               /* drop very old ACKs unless th_seq matches */
> +                               if (th->th_seq != tp->rcv_nxt &&
> +                                   SEQ_LT(th->th_ack,
> +                                   tp->snd_una - tp->max_sndwnd)) {
> +                                       goto drop;
> +                               }
> +                               break;
> 
> As far as I can tell, it simply does not correspond to anything in your log 
> message, or in the NISCC advisory.
> 
> I can only assume that it is an attempt to prevent injection of bogus data 
> with a guessed ack number.  However, given that the sequence number has to be 
> in the window anyway, and it's not normally exposed, it occurs to me to 
> wonder whether this actually buys us anything.

	responding ancient email message: 

	NISCC report was about off-line attack (i.e. attacker does not sit
	between TCP server and client).  attacker does not know sequence 
	number, and he will do a brute-force attack (sending massive number of
	packets). the above clause is to reduce possibility of successful
	attack to 1/(2^32).  

itojun