RFC 521

Restricted Use of IMP DDT ✨

Okay bestie, the title block first! 🎀 This is RFC 521, written by A. McKenzie from BBN-NET (NIC #16855) on 30 May 1973, in the Network Working Group. The header doesn't list a category, and it doesn't say whether this one obsoletes or updates anything.

So at the recent workshop on "Automated Resource Sharing on the ARPANET", everyone was obsessed with network security 🔥. Several sites felt that uncontrolled use of IMP DDT made access control mechanisms super vulnerable to interception or tampering.* Basically, anyone at the workshop agreed that DDT use should be way more controlled than it is now 💅. And as the network gets more and more operational, NCC use of DDT (which has to be coordinated with other DDT usage) keeps going up**, so we're seeing even more reasons to lock down access to the DDT mechanism 🔒.

Right now, and for the foreseeable future, it's important that the NCC can use DDT at any IMP at any time 👑. Sometimes site personnel also need to run a stand alone DDT after an IMP crash 🧚. And sometimes the NCC needs site personnel to operate the IMP DDT on its behalf if the network gets partitioned 🫶. The move so far has been protecting every DDT command that could mess with the running IMP program. You need sense switch 4 turned on at the site, or a software override flag enabled. Only the BBN IMP Teletype, the BBN TIP Teletype, and the PDP-1 can enable override 🔥. The NCC keeps an eye on these flags and reports any change in status 👀.

Now here's the plan: we're going to soon change the IMP system so that any access to IMP DDT needs the same enabling actions (sense switch four turned on, or override enabled from BBN) that are already required for core modification 💖. The NCC keeps the same ability to operate DDT that it has now, and site personnel can still operate DDT when the NCC asks them to 🌈. Just like today, the NCC will monitor the setting of sense switch four and take appropriate action if unauthorized use is observed 🕵️. We think this change is enough to discourage "hackers" 💀, but it is obviously not enough to protect a node against a determined and malicious attack ⚠️.

Heads up: this change discourages casual misuse. It does NOT protect a node from a determined, malicious attacker.

Also, we're not planning to stop the occasional use of DDT for communication between sites through "DDT" messages 💜. Right now there are two DDT commands, C and L, which set the single-character message and multi-character message headers respectively 💌. We'll keep this facility going, either by always allowing these DDT commands, or by putting some new code outside DDT for this purpose 🦋.

*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. 🛰️

       [ 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 ]