Use of the priming scheme: The SC could place a call to the
resource and thereby deliver the matching key (as given to the
requestor), at the expense of additional automatic call generation
capability at the SC. One end of the working connection must
still have call generation capabilities as in the first case.

If the SC (master ICD) is to be notified of the status of a connection that it attempted to establish, we must provide a mechanism by which a message can be returned to the SC. This is awkward, if not impossible, in the direct dial case since the ports are "tied-up" for the duration of the working connection, and hence can not be used to communicate status information to the SC. An auxiliary port could be utilized when a HOST is involved in a connection, but this would not handle the case of terminal-to-terminal connections. Messageoriented connections do not suffer any of these problems. Notifying the SC (master ICD) that a connection has been broken does not present any problem in either case, since at that point in time the ports are free.

5.3.6 Ability to Establish Priority Connections

Some priority control over access to the SC may be required, such that a high priority requestor is not locked-out or significantly delayed. Such problems are particularly of concern in those cases in which a physical resource is either permanently or temporarily dedicated to a user, such as the use of input ports for a direct dial scheme or use of the transmission ring in certain loop net designs. Priority override may be difficult in such cases since some preemptive capability is required. Multiplexed usage allows non-preemptive priorities since each "user" has control for a very brief period (milliseconds) and does not have control over who gets it next, i.e., can't hog the resource.

5.3.7

Establishing Connections in Process Addressed Nets

One added flexibility of broadcast nets (radio broadcast and loop nets) is that since all entities see each message, the physical location of a process can be made transparent to the message delivery vehicle. This feature is complicated considerably by the need for hardware-mechanized end-to-end protection, and for accountability and audit trail records.

Security aspects related to the usage of a connection include:

(1) vulnerability to traffic analysis, (2) spoofability via play-back of recorded (and possibly modified) messages, and (3) denial of service. In each case, we assume that the "enemy" has physical access to the communications net, at least to the extent that monitoring devices could be inserted. In other cases, modification (or insertion) of messages would also be possible, and at least some lines could be damaged or destroyed.

We have assumed that message leader information would be sent in the clear whenever any intermediate entities, such as message switches, need to determine how to route the flow. Such information might also be of interest to an enemy for traffic analysis purposes, e.g., to draw inferences from the occurrence, quantity and length of messages between two agencies. One obvious solution to this problem would be to encrypt the inter-node links on a link-by-link basis.

Depending on the encryption method, different spoofing methods can cause confusion, or at least errors, in communications. If a self-synchronizing method

is utilized, then play-back of recorded messages is possible and must be countered by the usage of sequence numbers or time stamps. If these mechanisms are not provided, one might still be able to recognize a duplicate message, unless it had been modified. However, modification of the cipher text would result in the error propagation effect and thereby introduce a large number of erroneous bits, helping to ensure that the forgery was detected. (Check sums could also be utilized to detect changes in other encipherment schemes).

Spoofing threats can be countered by: (1) detecting modified messages by use of error checks on the clear text, (2) detecting the "replaying" of legitimate messages by the use of encrypted sequence numbers or time stamps, and (3) discarding any messages that do not meet these checks.

Access to the physical communications net by an enemy results in a potential denial of service via the introduction of errors or, in the extreme, by cutting the wires or otherwise breaking the communications. Sufficient redundancy must be available to recover from such loss, preferably by some automatic mechanism.

The communications network should provide some degree of control over errors, i.e., the ability to detect and recover from a variety of erroneous conditions. In addition, control over the acceptance of messages needs to be provided to avoid congestion within the net whenever resources are allocated dynamically, and particularly so when error conditions affect the need for resources such as line capacity, buffers, etc.

Error control typically consists of adding redundancy bits to each segment of a message (character, block, etc.) based on some algorithm, and then checking upon reception to ensure that the algorithm is still satisfied. For connections that involve more than one physical link between the two parties, we have an additional option, namely whether error control should be on a link-by-link basis or performed as an end-to-end check, or possibly that both types of checks should be made. The factors which affect the decision include the average message delay, message throughput, buffer storage, and the completeness of checking. Message delay is affected since an error on any link results in a retransmission of the message over all the links through which it must pass. Similarly, this need also reduces the message throughput. The message buffering requirement is affected in a more subtle fashion since a given message must be saved in one place or other, making it relatively insensitive to the choice between the two methods, but doubling the buffer requirements when a combination of the two methods is utilized.

Completeness of checking is enhanced by utilizing end-to-end checks since these will detect intra-node errors as well as inter-node (link) errors. For example, the ARPA net error checks on a link-by-link basis do not detect errors that occur within an IMP, and some additional checking has been added in selected cases such as for critical routing information (BBN-73B).

Flow control is a necessary, and surprisingly complex aspect to networking which can significantly affect the delay and throughput of a net as well as minimize (or cause) bottlenecks, deadlocks, and critical race conditions. Factors that are involved include the criteria for accepting new messages into the net, reserving storage space, and indications that messages have been successfully delivered. The topic is a subject in itself, and will not be pursued in detail here, since the ARPA net has provided an ideal forum for such considerations and has produced significant results in this area (CER-74, KAH-72).

Very little security monitoring can be done at the communications net level other than attempting to ensure that denial of service threats do not result in a serious degradation to the network performance level. To perform this function, operational monitoring must be provided within the net, similar to the automated status reporting in the ARPA net (CRO-73). Such reports are readily available in a message-switching or broadcast net, but are probably not feasible in a direct dial net. The monitoring functions should be performed within the context of a network operation function (analogous to the ARPA net's Network Control Center), although there should be a means for this center to relay information to the Network Security Center whenever certain threshold conditions were exceeded.

Considerable attention must be paid to ensure that the network does not have an "Achilles heel" vulnerability which could be utilized to "crash" the entire network. Such vulnerabilities can readily exist in nets that have been

designed to allow remote access to network switches for debugging or reloading purposes from a centralized control center. Such facilities are desirable, and possibly even necessary, for maintenance of a net, but must be very carefully controlled if the net is to be safe from accidentally or maliciously induced crashes.

If ARPA net IMP-like switches are utilized in a net, the necessary control over debugging, reloading, etc. might be by means of an attached HOST-level device which would control these operations. Communication of debug commands would then be via this HOST-level device and could be controlled by means of the normal HOST-level protection mechanisms. Depending on the extent to which this protection need be applied, this HOST-level entity might even be one of the software "fake-HOST's" (such as exist in the IMP's).

Severe network degradation can also be caused by errors within a switching node which propagate to neighboring switches in an infection-like manner that soon affects the entire net. This is more than academic speculation as was discovered in the ARPA net when IMP errors lead to defective routing information being passed between IMP's which thereby caused an eventual network crash. Extensive check-summing of routing data and programs was added to avoid such error-induced problems. However, in a network of the type that we are considering, such conditions could also be maliciously induced since the switches are not necessarily protected. Therefore, additional controls are required to detect abnormal routing updates in this environment.

We will consider three separate topics in this final section; line control disciplines, TIP-related problems, and network architecture considerations.

Two basically different classes of line control disciplines are utilized to "package" messages for delivery from a source to a destination; the characteroriented disciplines such as IBM's Binary Synchronous Communications, and