I work for an information security company that is
dependant upon ICMP for network mapping purposes
(read: traceroute). On or about August 18, we were
told, our upstream provider began blocking ICMP
packets at its border in the Chicago NAP in an effort
to cut down on the propagation of 'MSBlast'. This has
effected our ability to accurately map our customers
networks.
We've been in contact with an engineer in this
provider's NOC who is either unable or unwilling to
remove this ACL for our block of IPs.
Currently, we've been given two options. (1) Deal
with the effect of the ACL until 'MSBlast' traffic
subsides, or (2) they are willing to reroute our
traffic out of the Chicago NAP to a border router
that, they claim, does not have the same ACL. The
problem with option 2 is that they would force us to
renumber. This is a problem for us, as it would
impact our customers as well.
What options can I take to my management that would
cause the least impact to the services we provide
while not causing undue work for our clients. Also,
what other options could I suggest to my upstream
provider?
I work for an information security company that is
dependant upon ICMP for network mapping purposes
(read: traceroute). On or about August 18, we were
told, our upstream provider began blocking ICMP
packets at its border in the Chicago NAP in an effort
to cut down on the propagation of 'MSBlast'. This has
effected our ability to accurately map our customers
networks.
We've been in contact with an engineer in this
provider's NOC who is either unable or unwilling to
remove this ACL for our block of IPs.
Currently, we've been given two options. (1) Deal
with the effect of the ACL until 'MSBlast' traffic
subsides, or (2) they are willing to reroute our
traffic out of the Chicago NAP to a border router
that, they claim, does not have the same ACL. The
problem with option 2 is that they would force us to
renumber. This is a problem for us, as it would
impact our customers as well.
What options can I take to my management that would
cause the least impact to the services we provide
while not causing undue work for our clients. Also,
what other options could I suggest to my upstream
provider?
Blocking ICMP in no way slows or prevents the propagation of MSBlaster.
ICMP echo requests and responses are, however, a byproduct of the
Welchia/Nachi worm and blocking this traffic will prevent the worm's
spread.
Tell your ISP it need _at most_ block ICMP echoes. If they are blocking
ICMP unreachables, which would break your traceroutes, they have broken
the Internet Protocol. (Period.) One can even be more specific about
blocking ICMP echo requests of a certain, atypical size to stop the Welchia
pings while letting other ICMP pass. See the list archives for detailed
instruction for how to do this for a variety of router platforms.
I can't possibly stand any ISP's blocking _ALL_ ICMP (alas it is happening now, I already know 5 ISP's around my area who's doing this as I speak) for any reasons.
If you want to *cough*cough*mitigate*/cough*/cough* impact of so-called BLASTER, please please please for the love of god, just block echo/echo replies.
Not to mention blocking icmp will not help stop the propagation of the worm.
Hmm noticed what I was to say has already been said, but to reiterate, if your
provider is blocking ICMP other than echo/echoreply .. in this case ICMP
unreachables and presumably fragments and other fundementally required icmps
they are seriously broken and I would insist they fix it or else you move away
You didnt clarify that in your mail tho, is it the icmp unreachables that you
arent getting or is your monitoring sending out icmp echos which are being
filtering?
if its the latter then you can easily workaround by modifying your monitoring
systems to use udp/tcp based probes which are probably better these days than
sending icmp across third party networks anyhow
winders does use udp instead of icmp in their tracert program, IIRC (or at
least they used to). At the risk of getting my head blown off, could we say
that was foresight
My thanks to everyone for their responses. The
consensus seems to be to get a new provider, epecially
if my current one is willing to break Internet
Protocol.
To clarify, since the question was posed several
times, we were told that they are blocking _all_ ICMP.
Xaffire/Matrix Systems apparently used ping packets that were the
same size as those being filtered by some ISPs. According to Xaffire
service providers implementing filters included Cable & Wireless and
Level 3.
Xaffire/Matrix Systems apparently used ping packets that were the
same size as those being filtered by some ISPs. According to Xaffire
service providers implementing filters included Cable & Wireless and
Level 3.
It does raise the question of whether ICMP Echo is a good mechanism for
monitoring systems that are across third party networks.
I personally think that filtering ICMP is becoming less useful and you would get
better results using other probe methods eg SYN/RST as deployed by numerous port
scanning tools eg nmap
The problems of PING monitoring have been around for a long time.
SRI-NIC.ARPA had to block PING in 1987 because so many sites kept
pinging the NIC, it was causing problems. I recall, but can't find,
in the old ARPANET a memo about the problem of people pinging the
IMP gateways.
The advantage of using PING is the site can block or rate-limit PING
without effecting their "real" services. Using SYN/RST is a higher
overhead probe, leaving the host with fewer alternatives when the
"monitoring" packets causes problems with the other services.
Most high visibility sites, like the Root Servers, Yahoo, Google, CNN,
BBC, Whitehouse.Gov, etc are under almost constant "attack" from people
monitoring their reachability. Almost no third-party monitors ask
permission to engage in the constant pinging/monitoring of the sites.
The Department of Defense used to report every PING or Traceroute attempt
as an "attack" on their networks. It was great for generating huge
numbers for Congress when asking for more money, but is it really a
usefull measurement.
PING is a useful tool. But if the target host blocks ping, it probably
shouldn't be considered an invitation to "monitor" the site with more
intrusive methods. On the other hand, if ISPs had zero tolorance policies
and enforced every term of their AUP in every instance, virtually every
network tool and network engineer would be considered network abuse.
