[outages] www.house.gov not reachable.

Carl Perry caperry at edolnx.net
Mon Sep 29 13:36:08 EDT 2008


Valdis.Kletnieks at vt.edu wrote:
> On Sun, 28 Sep 2008 17:43:00 CDT, "Laurence F. Sheldon, Jr." said:
> 
>> They apparently block ICMP as current best practice seems to require.
> 
> Ahem.  Who said "block ICMP' is BCP?  Yes, there's some ICMP things that
> you probably *should* block if they're to/from untrusted sources, but in
> particular, host/net unreachable ICMP shouldn't be blocked, and the next
> site I catch blocking 'Frag Needed' I'm gonna get on a plane and re-educate
> them with a clue-by-four regarding what they're doing to PMTUD.

I wouldn't say it's "best" practice, but it's "common" practice to drop
all ICMP traffic.  When I worked for a government contractor a few years
ago, we had to fight tooth and nail for them to enable 'Frag Needed' and
'Destination Unreachable' on as many routers/firewalls as possible.
Those changes were needed just so we could get to the point of figuring
out _why_ the network was broken.  Almost every cisco router or firewall
I saw on a government network control started with "any any drop" rule,
and ICMP never had an "accept" rule.  Best practice says drop everything
and permit what you need, most people don't realize how critical ICMP is.

It's been a few years since the "ping death" scares of 1997, do we
really need to stop dropping any ICMP traffic anymore?  My home internet
connection (AT&T DSL) drops not only ICMP Echo, but traceroute requests
as well. I understand that some saturated connections don't want ICMP
Echo requests going through, but in this age of fast processors in
routers we could rate limit instead of drop.  It's hard to determine an
outage is an outage when you can't perform basic connectivity tests.

 -Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/outages/attachments/20080929/979e36b1/attachment.sig>


More information about the Outages mailing list