Refusing Pings on Core Routers??? A new trend?

Fri Oct 20 07:00:27 UTC 2006

On Thu, 19 Oct 2006, Jeremy Chadwick wrote:

> I am absolutely fine with ICMP being prioritised last, but those
> scenarios induce more questions; "so ICMP is prio'd last, which
> would mean the router is busy processing other packets, which could
> mean your router is over-utilised either CPU-wise or iface-wise
> since we're seeing 250ms at your hop and beyond".  48 hours later,

No, that is not neccessarily true. I know of at least one vendor that 
punts all ICMP (on certain versions of their HW) to CPU, and the CPU is 
normally not otherwise involved in packet forwarding, so seeing latencies 
on ICMP (perhaps due to some housekeeping going on) doesn't at all mean 
other packets are being delayed. It might, of course.

Then we also have the problem of people not understanding how traceroute 
works, ie sending UDP with low TTL going one way, then getting ICMP back, 
with the router expiring the TTL and generating the ICMP TTL-exceeded 
message, perhaps having to punt this to CPU first, or perhaps processing 
it on a linecard. To understand what you're seeing really means, you have 
to know all platforms involved in all hops both going there and back 
(return path perhaps being asymmetrical to the path you're seeing in 
traceroute).

But to your question regardnig filtering, I'd venture to guess that more 
and more people are going to filter access attempts to their 
infrastructure to hinder DoS attacks. If I were to build a brand new 
network today I'd use loopbacks and link addresses that I'd either filter 
at the border or not announce on the internet at all. Not announcing it at 
all of course brings the problem of people using "uRPF loose" and dropping 
these packets, which will break traceroute and other tools. Better might 
of course be to rate-limit traffic to the infrastructure addresses to a 
very low number, let's say 2 megabit/s or so. This will limit DoS attacks 
and break diagnostics during an attack, but will make traceroute work 
properly during normal conditions. Guess everybody have to make up their 
mind regarding these prioritizations when designing their networks. It's 
important to be aware of all aspects of course, and it's good we have 
these discussions so more people understand the ramifications.

Anyone know of a document that describes this operationally? This would be 
a good thing to include in an "ISP essentials" type of document.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se