Browse Prior Art Database

Vulnerabilities of network control protocols: An example (RFC0789) Disclosure Number: IPCOM000003838D
Original Publication Date: 1981-Jul-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 14 page(s) / 26K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E.C. Rosen: AUTHOR


SIGCOMM Computer Communications Review. It is being circulated

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 12% of the total text.

RFC 789

Vulnerabilities of Network Control Protocols: An Example

Eric C. Rosen

Bolt Beranek and Newman Inc.

RFC 789 Bolt Beranek and Newman Inc.

Eric C. Rosen

This paper has appeared in the January 1981 edition of the

SIGSOFT Software Engineering Notes, and will soon appear in the

SIGCOMM Computer Communications Review. It is being circulated

as an RFC because it is thought that it may be of interest to a

wider audience, particularly to the internet community. It is a

case study of a particular kind of problem that can arise in

large distributed systems, and of the approach used in the

ARPANET to deal with one such problem.

On October 27, 1980, there was an unusual occurrence on the

ARPANET. For a period of several hours, the network appeared to

be unusable, due to what was later diagnosed as a high priority

software process running out of control. Network-wide

disturbances are extremely unusual in the ARPANET (none has

occurred in several years), and as a result, many people have

expressed interest in learning more about the etiology of this

particular incident. The purpose of this note is to explain what

the symptoms of the problem were, what the underlying causes

were, and what lessons can be drawn. As we shall see, the

immediate cause of the problem was a rather freakish hardware

malfunction (which is not likely to recur) which caused a faulty

sequence of network control packets to be generated. This faulty

sequence of control packets in turn affected the apportionment of

software resources in the IMPs, causing one of the IMP processes

to use an excessive amount of resources, to the detriment of

other IMP processes. Restoring the network to operational

- 1 -

RFC 789 Bolt Beranek and Newman Inc.

Eric C. Rosen

condition was a relatively straightforward task. There was no

damage other than the outage itself, and no residual problems

once the network was restored. Nevertheless, it is quite

interesting to see the way in which unusual (indeed, unique)

circumstances can bring out vulnerabilities in network control

protocols, and that shall be the focus of this paper.

The problem began suddenly when we discovered that, with

very few exceptions, no IMP was able to communicate reliably with

any other IMP. Attempts to go from a TIP to a host on some other

IMP only brought forth the "net trouble" error message,

indicating that no physical path existed between the pair of

IMPs. Connections which already existed were summarily broken.

A flood of phone calls to the Network Control Center (NCC) from

all around the country indicated that the problem was no...