Are ICMP packets not important for a hosted machine?

[shimi]

See inline,

On Tue, Oct 19, 2010 at 7:23 PM, Ron Varburg <linux-il at hotmail.com> wrote:

>
>
> A Hosting service is blocking pings from the Internet to the hosted
> servers.
> It is possible to ping from the hosted servers to anywhere on the Internet,
> assuming that the packets are not dropped somewhere else, ofcourse.
> 1. Why would the hosting service bother with such a blockage?
>

Mitigating some of a Denial Of Service attack. If a machine replies to ICMP
Echo DoS attack, it doubles the amount of traffic it has to handle. Since
blocking ICMP Echo has no actual effect on any other thing beside of
checking if a machine is alive, they believe the benefit of not
"participating" in a DoS attack outweights the lack of ability to ping-test
the machine. (not to mention that it may be filtering just *some* of the
ICMP Echo packets, and may be responding to ICMP Echo if sent from a limited
set of IPs (for example a monitoring machine and/or the sysadmin's IP
pool...)


> 2. Is it reasonable to assume that more ICMP packets are blocked?
>

Yes, many people block ICMP alltogether, not realizing that ICMP Echo and
ICMP Echo Reply are not the only type of ICMP messages, and just block any
IP packet that has ICMP in it.


> 3. What are the implications of such a blockage? In particular,
>   assuming that each hop in a random path takes care to assure
>   connectivity to any nearest hop, one might think that ICMP packets
>   are not important and hardly used.
>
>
The annoying ones:
PMTU[1] breaks. If any router / medium in the middle cannot support the
client/server MTU (typically - 1500), and a packet with the DF[2] flag is
sent, it will be dropped "silently" and the sender wouldn't know, and
re-transmit the packet until the connection times out and dies.

The less annoying but non-too-interfering:
If a router on the way filters the packet due to some policy, or that some
router on the way has a dead link for the next hop, no ICMP notifying that
the host/net is unreachable will reach the client; Instead of immediately
knowing that it can't connect (and with a pretty good explanation on "why"),
the client would simply try to re-send a SYN packet over and over again,
until it gets into "timeout" state.

Hope I didn't miss anything :)

HTH,

-- Shimi

[1] http://en.wikipedia.org/wiki/Path_MTU_Discovery
[2] Don't Fragment. See http://en.wikipedia.org/wiki/IP_fragmentation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20101019/4686cade/attachment.html>