Actually, TCP RST is more than just a marketing
solution. In practice, if the sensor is fast enough, a
TCP RST can and often will prevent even single packet
attacks. Here is why...

A TCP RST does not cause orderly connection
termination. It causes immediate connection
termination. That is, the protocol stack is not
required to deliver pending data and typically does
not. If you also take into consideration that on most
operating systems, applications are not dispatched
immediately upon arrival of new data, there is a
window of opportunity for the protocol stack to
receive and process the RST even before the
application can read the previously received data from
the single packet attack!

On most operating systems, when a process is moved
from a wait queue to the run queue, it is not given
immediate control of the CPU unless it has a
"realtime" priority or the run queue is completely
empty. Therefore, it will on average have to wait half
a time slice before it can read its data. A typical
time slice is 10ms. If the IDS can get the RST sent in
under 5ms, it can often stop a single packet attack.
The odds go up if the IDS is faster or the server is
busy.

>On Tuesday, January 28, 2003, at 08:31 AM, Garbrecht,
Frederick wrote:
>
>> ummmm, just a technical quibble, but a TCP reset
wouldn't work with the
>> Sapphire worm because it propagates using UDP as
transport, not
>> TCP.....

>It is just a minor quibble because the point is that
the attack was
>completely contained in a single packet. The same
would have held true
>if it was over a TCP/IP connection. Once the attack
has been
>completed, a TCP RST would provide no value. It is
the proverbial
>closing the barn doors after the horse is already
out.
>
>RST is largely a marketing solution, not a technical
solution.
>
>Todd

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]