Dropping ping at peak times

I monitor a variety of things with three Smokeping installations. Looking at
an overview of all the monitoring at peak times [1000-1600 on weekdays], one
can immediately spot which lines are with a certain "channel focused"
wholesale ISP because jitter and packet loss are atrocious. When questioned
about this, the excuse is that they de-prioritise ICMP in peak times in
favour of "business applications", so ICMP is apparently not a useful
diagnostic tool. This seems like complete and utter bullshit to me; surely
ICMP traffic is dwarfed by everything else; watching a video on Youtube
probably accounts for more bandwidth usage in a minute than a month's worth
of ICMP echos.

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
18:47:05 up 88 days, 1:58, 1 user, load average: 0.46, 0.82, 0.68
Qua illic est accuso, illic est a vindicatum

alexd wrote:
> I monitor a variety of things with three Smokeping installations. Looking at
> an overview of all the monitoring at peak times [1000-1600 on weekdays], one
> can immediately spot which lines are with a certain "channel focused"
> wholesale ISP because jitter and packet loss are atrocious. When questioned
> about this, the excuse is that they de-prioritise ICMP in peak times in
> favour of "business applications", so ICMP is apparently not a useful
> diagnostic tool. This seems like complete and utter bullshit to me; surely
> ICMP traffic is dwarfed by everything else; watching a video on Youtube
> probably accounts for more bandwidth usage in a minute than a month's worth
> of ICMP echos.
>
ICMP flooding is a well known form of DOS.


Many ISPs deliberately block it.

On Wed, 22 Sep 2010 19:06:26 +0100, The Natural Philosopher wrote:


> ICMP flooding is a well known form of DOS.
>
>
> Many ISPs deliberately block it.

Most *idiots* block it carte blanche without understanding how important
it can be. Still, if they are equally happy to have their error messages,
path discovery and source quench packets ignored then I guess that is
fair.

One wonders how many clock cycles are wasted dropping ICMP packets -v-
how many it would take to bloody answer the request.

Sensible people may elect to selectively block ICMP, or rate control it.
If you happen to have attracted a DDoS attack from a BOTNET worrying
about some kiddie trying to give you the ping of death falls quite beyond
the wayside.




--
BT Openreach Engineers - all they need to supply for work is their own
socks and pants

"alexd" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I monitor a variety of things with three Smokeping installations. Looking
>at
> an overview of all the monitoring at peak times [1000-1600 on weekdays],
> one
> can immediately spot which lines are with a certain "channel focused"
> wholesale ISP because jitter and packet loss are atrocious. When
> questioned
> about this, the excuse is that they de-prioritise ICMP in peak times in
> favour of "business applications", so ICMP is apparently not a useful
> diagnostic tool. This seems like complete and utter bullshit to me; surely
> ICMP traffic is dwarfed by everything else; watching a video on Youtube
> probably accounts for more bandwidth usage in a minute than a month's
> worth
> of ICMP echos.
>
> --
> <http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
> 18:47:05 up 88 days, 1:58, 1 user, load average: 0.46, 0.82, 0.68
> Qua illic est accuso, illic est a vindicatum
>

This may be of interest
http://fruk.net/index.php?fruk=f8lure

bod43 wrote:
> On 22 Sep, 19:03, alexd <troffa...@hotmail.com> wrote:
>> I monitor a variety of things with three Smokeping installations. Looking at
>> an overview of all the monitoring at peak times [1000-1600 on weekdays], one
>> can immediately spot which lines are with a certain "channel focused"
>> wholesale ISP because jitter and packet loss are atrocious. When questioned
>> about this, the excuse is that they de-prioritise ICMP in peak times in
>> favour of "business applications", so ICMP is apparently not a useful
>> diagnostic tool. This seems like complete and utter bullshit to me; surely
>> ICMP traffic is dwarfed by everything else; watching a video on Youtube
>> probably accounts for more bandwidth usage in a minute than a month's worth
>> of ICMP echos.
>
>
> PingPlotter does RTT monitoring with arbitrary protocols.
>
> Fine piece of kit.
>
> http://www.pingplotter.com/
> Just in case there is anyone reading this who has never
> heard of Google:-)
>
> My view is that blocking ICMP echo is simply stupid.
>
>

Just give me your IP address and I will exceed your bandwidth allowance,
cost you money and bring your connection to a halt using just PING.

That's how smart you are.
>

On Thu, 23 Sep 2010 06:49:05 +0100, Andy Burns wrote:

> The Natural Philosopher wrote:
>
>> bod43 wrote:
>>
>>> My view is that blocking ICMP echo is simply stupid.
>>
>> Just give me your IP address and I will exceed your bandwidth
>> allowance, cost you money and bring your connection to a halt using
>> just PING.
>
> And if you tell me *your* IP address, but you cleverly block ICMP, that
> stops me exceeding your bandwidth allowance how?

And doesn't it also depend (cost and allowance-wise, anyway) on whether
the ISP actually caps upload?



--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning protection* - a w_tom conductor

Andy Burns wrote:
> The Natural Philosopher wrote:
>
>> bod43 wrote:
>>
>>> My view is that blocking ICMP echo is simply stupid.
>>
>> Just give me your IP address and I will exceed your bandwidth allowance,
>> cost you money and bring your connection to a halt using just PING.
>
> And if you tell me *your* IP address, but you cleverly block ICMP, that
> stops me exceeding your bandwidth allowance how?
>
At least I don't reflect the packets back..

And I can ask ICMP to be blocked by my ISP.

Bob Eager wrote:
> On Thu, 23 Sep 2010 06:49:05 +0100, Andy Burns wrote:
>
>> The Natural Philosopher wrote:
>>
>>> bod43 wrote:
>>>
>>>> My view is that blocking ICMP echo is simply stupid.
>>> Just give me your IP address and I will exceed your bandwidth
>>> allowance, cost you money and bring your connection to a halt using
>>> just PING.
>> And if you tell me *your* IP address, but you cleverly block ICMP, that
>> stops me exceeding your bandwidth allowance how?
>
> And doesn't it also depend (cost and allowance-wise, anyway) on whether
> the ISP actually caps upload?
>
>
>
well upload isn't the issue.

If you have a well placed high bandwidth machine under your control on
the net - say a hosted server..you can flood the targets downlink with
packets. These are received by your target and can *fully saturate* the
link. The uplink will be long gone anyway as its lower bandwidth *if you
reflect the pings*..

Smurfing (ICMP flooding) was and maybe still is, a way to overload the
network layer, under which conditions some stacks crash, and others have
been known to become vulnerable to other forms of attack.

Also, to fully implement ICMP is to e.g allow broadccast pings to work
on a whole network: that means one ping will get sent to every machine
on a network, and if they all answer...nightmare!

So I can fully understand why many ISP's would be likely to push ICMP
packets down the priority list, or block them altogether.

I certainly block incoming pings as far up the line as I can..as seems
to be necessary.

My last router regularly reported smurfing attacks on almost a daily basis

On Thu, 23 Sep 2010 06:14:01 +0100, The Natural Philosopher wrote:


> Just give me your IP address and I will exceed your bandwidth allowance,
> cost you money and bring your connection to a halt using just PING

And that will;
1. Do what to your own allowance?
2. Do what to your own connection
3. Have you kicked from IDNET faster than you can say "I am Michael
Black, and I'm a fraudster"



--
BT Openreach Engineers - all they need to supply for work is their own
socks and pants

On Thu, 23 Sep 2010 08:00:10 +0100, The Natural Philosopher scribe:

>
> I certainly block incoming pings as far up the line as I can..as seems
> to be necessary.

Have you considered that blocking ICMP pings does not actually stop the
packet from entering your network? You may drop or not reply to it, but
none the less the packet has traversed your network and used your
bandwidth. Ignoring the ISP blocking ICMP (and I've yet to find one that
do this, but note some give ICMP a lower QoS), that packet still hits
whatever is stopping it on your WAN side. You can still be flooded with
packets of this nature. Responding to them is somewhat academic.

>
> My last router regularly reported smurfing attacks on almost a daily
> basis

I've witnessed several Draytek routers reporting this, and then crash and
burn trying to 'protect' against it. This with ICMP blocking in place and
anti DoS measures enabled. So even taking these steps, the network goes
down - so the point of blocking/disabling on anything other than
enterprise class, multi-routed, load balanced networks is arguably
pointless.