As of August 19 2003, OIT Remote Access Services (dial-in services) discards any ICMP Echo Request packets sent by dial-in clients.
This measure was necessary due to the Microsoft Windows "Blaster" worm. The high rate at which Blaster-infected Windows computers scan for potential victims places an extreme CPU load on the OIT Remote Access Servers. The result is that all dial-in clients (not just the Blaster-infected Windows computers) experience severe performance problems; often dial-in clients are randomly disconnected. Left unaddressed, OIT Remote Access Service would be unusable.
As the scanning performed by Blaster-infected Windows computers consists of ICMP Echo Request packets, we have chosen to discard all ICMP Echo Request packets sent by dial-in clients.
ICMP Echo Requests packets are used for network diagnostics, often to test the reachability of a target. Dial-in clients will not be able to use these programs. For example, the popular "ping" program sends ICMP Echo Request packets (and expects to receive ICMP Echo Response packets); because the ICMP Echo Request packets will be discarded, the "ping" program will be useless.
The standard version of the "traceroute" program does not send ICMP Echo Request packets (it sends UDP packets), so it continues to function. However, some versions of traceroute do send ICMP Echo Request packets; those versions will not be useful.
Note that we are only blocking ICMP Echo Request packets sent by dial-in clients. We are not blocking ICMP Echo Request packets sent to dial-in clients, nor are we blocking ICMP Echo Response packets sent by dial-in clients. Therefore, while it is no longer possible to ping from a dial-in client, it is possible to ping to a dial-in client.
Since dial-in service is provided to an OIT netid/password, rather that to particular machine, the best we can do is to disable OIT Remote Access Service to any OIT netid found to be using a Blaster-infected system to dial-in.
When the Windows Blaster worm first appeared, we attempted to do exactly that. We attempted identify dial-in sessions that were the source of the Blaster worm traffic, determine the OIT netid being used for the dial-in session, and then disable OIT Remote Access Service for the netid.
We quickly found that infected computers are able to dial into (and break) OIT Remote Access Service much faster than it is possible to identify these infected systems and block the OIT netids -- even when we devoted a person to doing only this all the time.
The approach proved impractical because too many Windows computers are infected with this worm. Essentially, every Windows system newer than Windows 98 (and not been patched to fix the Windows bug exploited by the worm and remove any existing infection) becomes infected with this worm within a few seconds of being attached to the Internet.
This is not a complete solution to problem caused by Blaster-infected dial-in clients; filtering those ICMP Echo Request packets still places significant CPU load on the OIT Remote Access Servers.
Our experience indicates that filtering those packets allows our low-end Remote Access Servers (those supporting low-speed charged and non-charged dialin, dialout, and OutFAX) to continue to operate, although in a noticably degraded mode, as long as no more than one Blaster-infected client is dialed-in at a time. When more than one Blaster-infected client is simultaneously dialed-in to one of the low-end Remote Access Servers, service to all clients using that server degrades rapidly to the point of unusability.
Our experience is that filtering those packets allows our high-end Remote Access Servers (supporting high-speed dialin) to continue to operate acceptably even when several Blaster-infected clients are dialed-in simultaneously.