Page images
PDF
EPUB
[blocks in formation]

A second major area of concern that affects network viability is that of network management. Even without the concerns of security, networking presents significant administrative, economic, and procedural issues such

[merged small][ocr errors][merged small][merged small]

Lessened local control, autonomy, and self-sufficiency.

Committee-oriented decisions on how policy is to be implemented (and perhaps in the development of the policy itself). Such decisions tend to be, at best, democratic and do not necessarily address the long-term needs.

Network accounting practices are complicated by a number of factors such as: (also see NEU-73)

If the resource to be used is selected explicitly by the user or implicitly based on loading, etc.

If the "unit of currency" is dollars or some comparable amount of service to be given in return

If non-uniform accounting procedures are used at
the various sites

4.

Network membership standards may need to be developed to ensure a certain base-level of services, availability, documentation, etc.

The need for security adds other requirements and complications such as:

The need for uniform (or at least consistent) definitions

of security levels, user ID, authentication mechanisms, etc.

Concerns as to whether accounting information contains any sensitive use information (analogous to "traffic analysis").

[blocks in formation]

The network must provide adequate facilities to meet the responsiveness and throughput requirements of its users. The diversity of these needs may or may not be a problem, depending on the manner in which resources are allocated (e.g., dedicated lines, switched lines, or dynamically multiplexed such as packet switched). These latter tradeoffs will be discussed in Section 5, but our concern at this point is to establish the types of traffic that must be handled.*

One such type of traffic is control. These messages will typically be very short, will require rapid response, and will be sent asynchronously with respect to regular information flow. A second type of traffic is what we might call interactive or conversational, and a third is bulk traffic such as file transfers or I/O streams. The needs of these three types of traffic vary, with the first needing very rapid set-up but relatively low data transmission bandwidth, while the third has just the opposite requirements. Conversational needs are at some mid-point between the other two, leaving us with the requirement for providing a broad spectrum of network capabilities.

Actual use of the network is also assumed to be of a wide diversity of applications, including batch (remote job entry and output), interactive, and computer-to-computer resource sharing. The level of activity is assumed to be quite heavy, probably supporting a few thousand users. The intent of the specification and the design tradeoffs is to provide generality, either directly or via expandability along open-ended design features.

2.7.4

Separation of Data Processing and Data Communications

Few people would disagree with the notion that there should be a clean separation between data processing and data communications; the argument comes about when one tries to draw the line that separates the two. For

Adapted from reference POU-73.

example, is a Front End Processor (FEP) part of the data communications or the data processing? Does this answer depend on the functions the FEP performs, e.g., off loading HOST* functions of buffering, preprocessing, character translation, etc.? What if these same functions were provided in an IMP-like* device; would the IMP then become part of data processing? Conversely, are the network control programs* in the HOST's part of the data communications? Are they, when they are part of the TIP (Terminal-IMP)? Does encryption equipment always fall on one side or the other (or perhaps define the separation)? The list could go on and on.

If the dividing line between data communications and data processing is so
ill defined, why does it really matter? It matters to some people because
their very jobs may depend upon it. It matters to others because they want
to be involved in the problems of one area to the exclusion of the other.
It matters to those who must integrate the two disciplines, and they are
typically the only ones who see it as it really is--not one dividing line,
but rather a series of layers in which each layer is built upon the one
below it, with the lower levels becoming increasingly transparent to its
design and operation. (Ideally, a level is dependent only upon the one
level directly below it, but some lower level aṭtributes must be considered
in most real-world designs.)

If the notion of a network being viewed as one entity, a "supra computer"
(AND-72), is to be met, the functions of data processing and data com-
munications must be considered as part of an integrated overall system
design. Only with this level of control over the design and development
can we reach a meaningfully viable and secure network.

ARPA Net terminology.

3.

NETWORK SECURITY MECHANISMS AT THE SECURITY CONTROLLER/HOST LEVEL

The previous chapter discussed general policy matters and requirements that must be considered in the design of a secure network. These issues form the top-level constraints, guidelines, measures of quality, etc. that will be needed in order to determine and evaluate the tradeoffs related to possible network security mechanisms. These mechanisms will be distributed across a number of entities, which occur at different levels of the network structure as shown in Figure 3-1.

In addition to the usual terminals, HOST computers, etc. that would be expected in a network, we have added a new HOST-level entity called the Security Controller (SC), which will mechanize those third-party control functions described in the earlier requirements section. Since our concern is primarily with network security issues beyond those of a single/HOST system, our major concern at the HOST/SC-level will be with the Security Controller. However, we will consider the HOST and terminal subsystems to the extent necessary to present an integrated view of the overall network.

The HOST systems are considered to be the composite of hardware, operating system, program, and data resources, and include a variety of mechanizations for sharing of such resources, e.g., processing RJE work, offering time-sharing services, etc. In addition, some of the HOST's could be considered to be "mini-HOST's" in the sense that they offer some minimal direct service to their users, but primarily provide terminal or RJE access to the network and its wide variety of resources.* Regular HOST's may or may not have directly attached terminals: but as shown in the figure such terminals can not have the same end-to-end protection as provided for a terminal with a dedicated Intelligent Cryptographic Device (ICD).

The mini-HOST would differ from an "intelligent terminal" in that the miniHOST would multiplex its services over a set of conventional terminals, while the latter is normally viewed as one composite entity. For our purposes, the primary concern is the effect of multiplexing, so the intelligent terminal would be treated like any conventional terminal.

[blocks in formation]

Figure 3-1. The Levels Involved In a Secure Network

[blocks in formation]
[graphic]
« PreviousContinue »