operational: icmp echo out of control?

Tue May 28 18:43:25 UTC 2002

On Tue, May 28, 2002 at 01:05:19PM -0400, Chris Woodfield wrote:

> The problem here is that other types of probes raise IDS alarms on way
> too many networks - the next-best method is to probe HTTP ports, but we
> don't want to have to pull down thousands of web pages just to get
> performance stats. So, they send a SYN, wait for the ACK, record the
> latency and send a FIN.  Sounds benign, but you'd be surprised how
> klaxons go off in response to this.

So what, someone sneezes on an ethernet cable and IDS alarms go off. :)

Theoretically, ICMP Echo should be less intrusive for performance
measuring since it is clearly only for this purpose, whereas doing an
actual TCP handshake could easily be mistaken for a port scan. But for so
many network admins, all they know is "ICMP bad".

Besides, if you thought ICMP was inaccurate, a TCP handshake is far worse.
First, you have no way of knowing if the TCP replies are the originals, or
if they have been retransmitted, so any single sample is pretty useless
for measuring reply time. Second, for most cases with TCP opens, you are
measuring the interaction time of the application process, not response
time from the kernel. Depending on how the application is written, and
what event model it uses, it is very likely to be doing other things
before and after it gets notified that there is a new connection, then 
does the accept().

Internet path measurement isn't simple, you're probably best off trying to 
get as much data as possible passively. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)