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 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 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"). 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 If the notion of a network being viewed as one entity, a "supra computer" 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. |