Asymmetric Cryptosystems
In asymmetric cryptosystems, the encryption key is different from the decryption key and it is infeasible to compute the decryption key from the encryption key. Encryption key is made public whereas decryption key is kept secret. The encryption and decryption are depicted in Figure 14.7. Public key cryptosystems are computationally expensive and hence not suitable for bulk data encryption. Key distribution does not pose any serious problem in public key cryptosystems.
The concept of public-key cryptosystems is a recent one: it was invented by Diffie, Hellman, and Merkle in 1976. This concept opened gates for the design of many cryptographic protocols that was impossible using private-key systems, for example,

reports, indicating how smoothly things are running at his/her branch. You will sift through the reports you receive, hoping to find smooth operations everywhere, but no doubt watching out for problems that need your attention. You might initiate a one-on­one dialogue with one of your problem branch offices, gather more data in order to understand the problem, and then pass down an executive order ("Make things change!") to the branch office manager. Implicit in this very common human scenario is an infrastructure for controlling the organization: the boss (you), the remote sites being controlled (the branch offices), your remote agents (the branch office managers), communication protocols (for transmitting standard reports and data, and for one-on­one dialogues), and data (the report contents and the quantitative measures of activity, productivity, and budget). Each of these components in human organizational management has a counterpart in network management.
The architecture of a network management system is conceptually identical to this simple human organizational analogy. The network management field has its own specific terminology for the various components of network management architecture, and so we adopt that terminology here. As shown in Figure 13.4 there are three principal components of network management architecture: a managing entity (the boss, that is you, in our above analogy), the managed devices (the branch office), and the network management protocol.
The managing entity is an application, typically with a human element in the loop, running a centralized network management station in the network operations center (NOC). The managing entity is the focal point of all activities associated with network management; it controls the collection, processing, analysis, and/or display of network management information. It is here that actions are initiated to control network behaviour and here that the human network administrator interacts with the network devices.
A managed device is a piece of network equipment (including its software) that resides on a managed network. This is equivalent to the branch office in our human analogy. A managed device might be host, router, bridge, hub, printer, or modem device. Within a managed device, there may be several so-called managed objects. These managed objects are the actual pieces of hardware within the managed device (for example, a network interface card), and the sets of configuration parameters for the pieces of hardware and software (for example, an intra domain routing protocol such as RIP: Routing Information Protocol). In our human analogy, the managed objects could be the departments within the branch office. These managed objects have pieces of information that are available to the managing entity. In the analogy, the MIB corresponds to quantitative data (measures of activity, productivity, and budget, with the latter being settable by the managing entity) exchanged between the branch office and the main office. Finally, also resident in each managed device is a network management agent, a process running in the managed device that communicates with the managing entity, taking local actions on the managed device under the command and control of the managing entity. The network management agent is the branch manager in our analogy.

BACK