The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 2 Issue 27

Saturday, 15 Mar 1986


o Overload of a different sort [Air traffic stoppage]
Ted Lee
o Cordless Phones Cry Wolf!
Peter G. Neumann
o The Mob Breaks into the Information Age
Mike McLaughlin
o [Non]computerized train wreck
Mark Brader
o Ballot Integrity; Specialization in Decision-Making
Tom Benson
o Network Security, Integrity, and "Importance"
Kurt F. Sauer
o Modems
James R. McGowan
o Info on RISKS (comp.risks)

Overload of a different sort [Air traffic stoppage]

Fri, 14 Mar 86 12:26 EST
This may or may not involve a computer, but I think it did.  Those of
you travelling in the Southeast yesterday were made well aware that the
Atlanta airport was thrown into a complete chaos by the thunderstorms in
the area, and this rippled throughout the air transport system.  To make
a long story short, I managed to get out of Augusta on a plane that was
five hours late, which was okay since that had me leaving Augusta only
two hours after I was supposed two, and my connecting flight was also
two hours late.  The computer part is this.  After we boarded in Atlanta
the pilot announced he had called for his air traffic control clearance
and was told that flow control into Minneapolis was in effect and there
would be an indefinite delay.  Those of you who have had nothing to do
with air traffic control may not realize that in the late 60's or early
70's a change was made in the way the over-all air traffic was
controlled:  instead of stacking planes up over destinations when
traffic got crowded, a national system was instituted to monitor and
control the general flow, not allowing a plane to depart until there was
a clear slot for it to land in.  This is all coordinated between the
terminal air traffic control computers and a central computer in
Washington.  Anyway, we sat for about another half hour and the pilot
called again.  Same answer.  He and/or the Delta operations people used
a little common sense:  the weather in Minneapolis was just fine and
they could understand no reason why the airport should be congested --
they called Washington and after someone checked around received the
answer "there shouldn't be any flow control into Minnapolis; someone got
their wires crossed." We left in five minutes, having been on the ground
for nearly an hour by either a computer error or human error only
possible because the computers were installed to manage a humanly
unmanageable task -- almost certainly the error was caused by the
overload generated to handle the disrupted schedules throughout the


Cordless Phones Cry Wolf!

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Sat 15 Mar 86 12:00:04-PST
The SF Chronicle 15 March 1986 has a news story about cordless phones making
``ghost'' phone calls to the emergency number 911 (and presumably to other
numbers as well).  The cordless phones, which send out and respond to radio
frequencies, behave strangely when their batteries start to run down.  In
addition, other household appliances can spur cordless phones to start
diaing spontaneously.  Michael Moos (president of the National Emergency
Number Association) was quoted: ``Frequencies given off by other appliances
-- micorwave ovens, blenders and even fluorescent lights -- interfere with
the cordless phones and make them start dialing.''  On an average day, at
least 12 of the 2000 calls received by Santa Clara County's 911 system are
such ghost calls.  [Cf. heart pacemaker interference, Sputnik triggering
garage door openers, automotive CB interference, etc., in past RISKS.]  PGN

The Mob Breaks into the Information Age

Mike McLaughlin <mikemcl@nrl-csr>
Fri, 14 Mar 86 15:17:48 est
INFOSYSTEMS, Vol 33, No. 3, March 86 carries subject article, beginning
on page 40.  Also several other computer security items.  Ought to help
sell a few password systems, at least. - Mike McLaughlin

[Non]computerized train wreck

Fri, 14 Mar 86 08:45:38 EST
The wreck of a VIA Rail Canada train and Canadian National freight
train on February 8 was mentioned in this forum.
      [See Martin Minow, RISKS-2.9; Chuck Weinstock, RISKS-2.12]
I think it's worth pointing out that the accident has been attributed
to human error, specifically by the CN engine crew, both of whom were
among the 23 killed.  (Not 30+ as feared originally.)  They drove past
a stop signal which both men should have seen.

Not only was this NOT a case of computer malfunction, but indeed, a more
fully computerized system (with cab signalling and automatic train stopping)
would probably have prevented the accident.

Mark Brader

     [A fine example of the risks having to include people, not just
      computers, and of a more pervasive role of the computer than meets
      the eye -- indeed a more human-oriented computer system might have
      helped!  Thus, even though it appears NOT to be a computer problem,
      we discover that the computer could have done better!  But, of course,
      don't blame the computer system.  Blame the people who specified,
      designed, and implemented it -- not JUST the train operator(s).  PGN]

Ballot Integrity; Specialization in Decision-Making

Tom Benson 238-5277 <<T3B%PSUVM.BITNET@WISCVM.WISC.EDU<>
Fri, 14 Mar 86 10:54 EST
I don't want to extend this discussion of ballot integrity, but my
understanding is that in Pennsylvania there is a registration number
on the ballot when it is given to the voter, but the voter tears it
off and retains it, so the ballot when in the ballot box is not
traceable to the voter.

I'm curious about the tone of some of the discussion on this issue.
Granted we shouldn't assume the absolute integrity of non-computerized
voting without careful scrutiny.  But some of the contributions seem, if
I am not mistaken, to justify computerized balloting on the grounds of
a broad (and unarguable) assumption that "any balloting process can be
subverted."  Sure.  But the object is to insure insofar as possible that
it won't be, and that means, primarily, protecting (1) secrecy, and
(2) accuracy.

Does anyone have an opinion on the question of how the local situation,
in this case RISKS, may influence the general consideration of the issue?
That is, RISKS is devoted to an interest in computers, not voting. Does
that, explicitly or implicitly, influence the question of what ought to
be relevant to the decision process?  I'm not complaining, nor am I
criticizing previous comments by correspondents or the editor.  What I am
trying to do is draw attention, as a communication scholar, to another
potential RISK: the use of electronic mail and digests with clear agendas
may inhibit the generalism needed to address substantive problems. Does
anyone have instances of this in their experience? (Note: I understand that
the problem is not limited to computers; committee work in general suffers
from this problem).


     [Hmm.  For some reason I am rarely accused of undergeneralizing.
      I keep mumbling that to deal with RISKS, we must do so holistically,
      and that the computer is only a small part of what must concern us --
      even though it is the primary justification for the existence of this
      forum.  Any weak link can be devastating.  RISKS indeed tends more
      toward breadth than depth, toward ALL RISKS than just computer risks.
      Indeed a few other people have commented that we have strayed off into
      the subjects of THEIR on-line forums!  I don't really think there is
      too much danger that we are too narrow.  But discussion is welcome if
      relevant to RISKS.  PGN]

Network Security, Integrity, and "Importance"

"Kurt F. Sauer" <>
Fri, 14 Mar 86 18:46:51 CST
Tom's Perrine's question about the Interface Message Processors' (IMP)
security [RISKS-2.23] is a really well-founded one.  As I see it (and I
haven't spent much time thinking about it, really), we can design a
network's security procedures based on some information and management

Try answering some of these questions about the network you manage or

            o How critical is the general network operation?

This can be based on many things, not the least of which include the value
of the tokens passed on the network and the desirability or necessity of
proper message reception.

            o How confidential are the messages?  Are patterns,
              themselves, classified?

Traditional cryptology can be applied to "entire messages" (or whatever the
DIRNSA will let you get away with), but would releasable routings disclose
critical paths?  Would they "give away" operational information which should
be protected?

            o  Can message speed be increased for vital information
               whose delivery is paramount?  I'm not sure that this is as
               much a security problem as it is a basic applied-computer-
               science question.  Some feel that packet precedence systems
               are unnecessary; some feel otherwise.

The Defense Data Network (DDN), which is comprised of the ARPAnet and the
MILNET, serves a mighty diverse consumer market.  Universities, research
facilities, commercial institutions, and government operations all share the
facilities of the network.

Currently, some classified (i.e. sensitive) operations make use of the DDN.
Systems like the COINS-CINCPAC project now use the DDN as a transport
medium; loss of the medium would have at least some impact on CINCPAC's
intelligence operations.  For such setups, the basic network security is
ensured through fail-secure cryptographic setups which are only able to
prepend one specific message header to an already encrypted packet.  (One
thus gets around the red-black interface problem with packet addressing.)
And physical security is ensured by using guards, locked doors, and the like
at the point of security interface, and at all secured locations.

But this doesn't address the Internet physical or electronic security in
general.  I believe that the Defense Data Network Program Plan has a
scheduled dis-integration of the DDN parts very soon.  Obviously we have
already traversed the ARPA/MIL separation, but more is soon to come.  With
the introduction of Internet Private Line Interfaces (IPLIs) (and, based on
various community needs, estimates for numbers of IPLIs are nearly 1000--and
probably higher), the network can divide itself such that hosts will not
talk to non-community-of-interest hosts.  The "big plan" includes folding
MINET, MILNET, SACDIN (!), and IDHS (!!) into one network:  the DDN.  The
current ARPAnet will remain an R&D network, essentially isolated completely
from the DDN.

I haven't been watching the network events (due to my absence) for about a
year now, so I don't know how far along we are in this plan.  But if it's
implemented (we're all waiting for BLACKER, so budgetary holdbacks may well
intervene), then "vital network nodes" would be physically secured, with the
ability to fold ARPAnet into DDN in the event of a crisis where additional
redundancy is required to limit network failures due to attacks on the

Perhaps someone who really knows a lot about these things could comment on
the physical security side of the DDN house.  For those of you who are
interested, I have some citations to references which I would be happy to
share with persons on the ARPANET or MILNET; I will respond only to e-mail
        Kurt F. Sauer
        Tulsa, Oklahoma

Internet:   ks@a.cs.okstate.EDU       UUCP:     ks@svo.UUCP

Modems [still... enough already?]

James R. McGowan <jrm@Ford-wdl1.ARPA>
Fri, 14 Mar 86 16:48:27 PST
In re the modem controversy:  the originating modem contains circuitry
to detect answering tones (in the range of 2000-2400 Hz.) It should
remain silent until it does detect the answering carrier (at least
if the modem claims to be Hayes standard.) However, other sounds on the
telephone line (noise, human voice, even just picking up the phone)
can sometimes excite th detection circuitry and software, resulting
in the originating modem turning on its tone generator.  Sorry, but
Phil does know what he's talking about.
                Jim McGowan

    [Let's BLOW the WHISTLE on this one.  There's no modem operandi.  PGN]

Please report problems with the web pages to the maintainer