Restricted use of IMP DDT
A plan to restrict access to the IMP debugging facility.
McKenzie, A.M., "Restricted use of IMP DDT", RFC 521, DOI 10.17487/RFC0521, May 1973, <https://www.rfc-editor.org/info/rfc521>.
@misc{rfc521,
series = {Request for Comments},
number = 521,
howpublished = {RFC 521},
publisher = {RFC Editor},
doi = {10.17487/RFC0521},
url = {https://www.rfc-editor.org/info/rfc521},
author = {A.M. McKenzie},
title = {{Restricted use of IMP DDT}},
pagetotal = 2,
year = 1973,
month = may,
} RFC text
Network Working Group A. McKenzie
RFC #521 BBN-NET
NIC #16855 30 May 1973
Restricted Use of IMP DDT
At the recent workshop on "Automated Resource Sharing on the
ARPANET", considerable interest was expressed on the topic of network
security. In particular, representatives of several sites felt that
uncontrolled use of IMP DDT made access control mechanisms quite
vulnerable to interception or tampering.* Individuals at the workshop
seemed to be in general agreement that use of DDT should be much more
controlled than at present. In addition, as the network continues to
take on a more and more operational character, and NCC use of DDT (which
must be coordinated with other DDT usage) increases** we begin to see
other reasons for controlling access to the DDT mechanism.
Currently, and for the foreseeable future, it is important that the
NCC be able to use DDT at any IMP at any time. It is also sometimes
necessary for site personnel to be able to operate a stand alone DDT
after an IMP crash. Sometimes the NCC needs to ask site personnel to
operate the IMP DDT for the NCC if the network is partitioned. We have
protected all DDT commands that can affect the running IMP program by
requiring that sense switch 4 be turned on at the site, or a software
override flag be enabled. Only the BBN IMP Teletype, the BBN TIP
Teletype, and the PDP-1 can enable override. The NCC monitors these
flags and reports any change in status.
In line with this approach, we will soon modify the IMP system so
that any access to IMP DDT will require the same enabling actions (sense
switch four turned on or override enabled from BBN) now required for
core modification. This will still allow the NCC the same ability to
operate DDT which it now has, and will permit site personnel to operate
DDT at the request of the NCC. As is currently true, the NCC will
----------------
*Examples are easy to construct, but are intentionally omitted from this
document.
**DDT is currently used by the NCC operators for core verification, for
interface debugging, for loading TIP and VDH code, etc. There is
discussion of using DDT in conjunction with an "auto-dialer" to examine
a TIP's "view" of a modem port at the same time that the auto-dialer is
examining the outside world's "view" of the port, of running "automatic"
core verification, of loading Satellite IMP code, etc.
monitor the setting of sense switch four and take appropriate action if
unauthorized use is observed. We feel that this change will be
sufficient to discourage "hackers", although it is obviously
insufficient to protect a node against a determined and malicious
attack.
It should be noted that it is not our current intent to prohibit
occasional use of DDT for communication between sites via "DDT"
messages. Currently, there are two DDT commands, C and L, which set the
single-character message and multi-character message headers
respectively. We will continue this facility, either by always
permitting the use of these DDT commands, or by implementing some new
code outside DDT for this purpose.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
ISO Plain Language
On this page
§1Why DDT Access Was a Concern
At a workshop on automated resource sharing, participants raised concerns that uncontrolled use of IMP DDT could make access-control mechanisms vulnerable to interception or tampering. The RFC also notes that Network Control Center use of DDT was increasing.
DDT remained important for network operations, including diagnostics and loading code, so the issue was how to control access without removing operational use.
Workshop participants were concerned that unrestricted DDT use could expose or alter access controls. The Network Control Center still needed DDT for network work.
§2Enabling Protected DDT Commands
At the time of the RFC, commands that could affect the running IMP program required sense switch 4 to be on at the site or a software override flag to be enabled. Only the BBN IMP teletype, the BBN TIP teletype, and a PDP-1 could enable the override.
The RFC says the IMP system would soon be modified so that any DDT access required the same enabling actions. The Network Control Center monitored the flags.
Powerful DDT commands required a local switch or a software override. The RFC announces a planned extension that would require those controls for any DDT access.
§3Operational Use and Limits
The change was intended to preserve the Network Control Center's ability to use DDT at any IMP and to let site personnel operate DDT when asked by the Network Control Center. The RFC did not intend to prohibit occasional DDT messages between sites.
The author says the change should discourage hackers but acknowledges that it would not protect a node from a determined, malicious attack.
Operators would keep the DDT access they needed, and occasional DDT messages between sites would continue. The author says the safeguards would not stop a determined attack.