The ARPAnet crash of 1980 was a bizarre event as Rosen (1981) stated “network-wide disturbances are extremely unusual in the ARPANET”. The event was caused by a somewhat coincidental failure of an Interface Message Processor (IMP) in two manners which created an unlikely situation and the failure. IMPs were the translation processes on the ARPAnet, there was a standard IMP that the ARPAnet used and each site used a computer that translated their protocols into the ARPAnet standard IMP. Essentially the IMP was a platform independent means of communication according to Clark (2000). In essence the failure occurred due to two IMPs performing incorrectly while updating the routing tables; IMP50, which was providing all updates at the time, was experiencing communication problems with IMP29, its communication pathway, which was dropping bits (Durrant (2007)). This led to an infinite loop situation where each communication received was deemed, by status codes, to be of a higher priority than the last, ad infinitum. This caused an effective denial of service to the network.
Once the issue had been identified it was corrected by repairing IMP29 and restarting IMP50 it was discovered that the network monitoring tools of the day were not being used. Hardware parity checking was disabled as it provided warnings when no problems existed (i.e. it “cried wolf”) and checksumming to monitor dropped bits was not used as it was presumed to take too many CPU cycles so as not to be of benefit, given the cost.
Although the issue was relatively simple to correct, once it had been found, it could have been avoided completely had network management tools been used. Today’s network management tools could have detected that IMP29 was dropping bits and alerted the system administrator to this error. Secondly, even if the error in IMP29 was not detected and corrected in time to stop the corrupted communication with IMP50, then network traffic and exception reporting could have informed the system administrator that there was unusual activity in the network traffic before the network was flooded with cyclical data. In addition the implementation of network monitoring tools requires network management to consider and plan for network traffic and to quantify unusual behaviour, which may have identified any likely issues before they occurred. The ARPAnet crash is an excellent example of why network monitoring tools are essential in critical networks.
Clark, W (2000) IMP — Interface Message Processor [Online]. Available at http://www.livinginternet.com/i/ii_imp.htm (Accessed 29 May 2011).
Durrant, L (2007) How the ARAPA Crash occurred [Online]. Available at http://lukedurrant.com/2007/05/the-internet-rfc-789-case-study-3-how-the-arapa-crash-occurred/ (Accessed 29 May 2011).
Durrant, L (2007) Faults and Solutions [Online]. Available at http://lukedurrant.com/2007/05/faults-and-solutions/ (Accessed 29 May 2011).
Rosen, E (1981) RFC 789: Vulnerabilities of Network Control Protocols: An Example [Online]. Available at http://www.ietf.org/rfc/rfc789.txt (Accessed 29 May 2011).