bit-oriented disciplines such as the Advanced Data Communications Control Protocol (ADCCP)*. A typical character-oriented discipline is shown in Figure 5-1(a) for comparison with the ADCCP as shown in part (b). The two schemes differ in several respects including:

Message framing, which is by DLE STX and DLE ETX for the
character-oriented discipline versus an 8-bit flag separator
to indicate the beginning of one message and/or the end of
the previous one.

Header control information, which is ad hoc for the former
compared to being defined (in an open-ended manner) for the
ADCCP.

The information field, which is an arbitrary number of
characters versus an arbitrary number of bits in length.

The handling of transparent text, which is by DLE-doubling
versus by "breaking up" accidental occurrences of the flag
pattern.

The need for character synchronization, which is a prerequisite to determining the DLE STX sequence, but is not required for the ADCCP framing scheme.

*"Line Control Procedures" by J. Gray, Nov. 1972, Proc of IEEE.

(a)

EXTRA DLE INSERTED BY

TRANSMITTING HARDWARE/

REMOVED BY RECEIVING
HARDWARE

Character-oriented line discipline (as used in the ARPA net).

Figure 5-1. Comparison of Character and Bit-Oriented Line Disciplines

Now that the ADCCP is becoming better known, future network designs will have to select between these two schemes rather than merely adopt a variation of the character-oriented discipline. Availability of an alternative has good and bad effects, e.g., it adds to the problems of integrating two or more networks, when different choices have been made for the individual nets.

There are no apparent security-related effects on the choice between the two methods, so the decision should be based on operational and compatibility

considerations.

5.7.2

Network Terminal Handling Considerations

The Terminal Interface Processor (TIP) was introduced into the ARPA net as a combination IMP and terminal handler. It has provided a useful terminal interface, and has avoided the problems of using a large HOST merely as a "front end" to the HOST that is providing a service.* However, problems in its usage have indicated that this is not the proper way to interface terminals to a network. Adding security requirements to the net has even further emphasized the TIP-related problems.

Some of the TIP problems related to security are simply that it was not designed with security in mind, e.g., it does not perform any authentication or authorization checking, nor does it keep any audit trail information. These factors could be added to a design (or redesign), but a more fundamental TIP problem arises when end-to-end encipherment is required. The TIP requires that certain control information be "intermixed" with the messages from the terminal, and therefore would require that (1) only the message text be enciphered, and (2) that the enciphered text not have any accidental control

*Such dual HOST problems include those of reliability, extra costs, delays, etc.

character bit patterns in it. These are similar problems at the Network

Control Program level, since the encipherment devices and NCP's are "crossed" as shown in Figure 5-2. This places the crypto device between the terminal and one NCP, and another between the two NCP's thereby eliminating the establishment of any straightforward, level-oriented control. A proper arrangement would clearly separate the levels.

5.7.3 Security Aspects of Different Network Architectures

Different network architectures, are vulnerable to somewhat different security threats, although in practically all cases the basic threat is via denial of service. We shall consider seven different architectures, expanding most of our earlier four categories into subclasses for this discussion. These nets will be:

5.7.3.1 A Dedicated Point-to-Point Net. A seemingly straightforward approach to controlling access between network entities is to directly interconnect all those devices authorized to communicate with each other, such that only those connections would exist in the net. If a given entity such as a HOST would change its security level during the day, an appropriate portion of its links would be enabled or disabled, giving some ability to adapt to change.

Several problems plague this simple scheme. In all but the smallest nets, the number of interconnection combinations quickly gets out of hand, since the number of meaningful connections tends to be a sizeable portion of the n (n-1) different possible links connecting n entities. Also, implied connections