On Thu, Mar 19, 2009 at 12:44:53AM +0000, John Dykstra wrote:
quoted text
> RFC793 says (Section 3.9) that not only should such segments be
> discarded, but that an ACK should be sent to the peer.  I can't see what
> that accomplishes, and it seems to badly interact with fast
> retransmit--under some conditions with crafted packets you can get the
> two stacks ACKing each other forever.  So I left that out of this patch:

I think part of the original intentions for the response ack is to
generate the "ack storm". In certain cases of tcp hijacking where the
attacker is trying to resynchronize a tcp session after injecting a
packet into the stream, an ack storm raises alerts in intrusion
detection systems. Most of the times, built-in measures reset the tcp
session given an unusual large number of acks (I'm not sure how or if
Linux does this).

This was partially the original reason I was looking into this. I
noticed that Windows does not send an ack back if the received ack has
a higher than expected ack number *and* higher than expected sequence
number. For some well crafted tcp hijacking cases, this increases the
attack success rate substantially.

It's beyond my knowledge of other implications such a response ack would
cause.

Cheers,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html