CHAPTER THREE, Network Services Management Framework

Transcription

1 CHAPTER THREE, Acronyms and Terms 3-3 List of Figures Introduction Architecture Entity Identification & Addressing Management Domain Registration and Information Service Resources Access Control Security Model Management Communications Services NSMF Protocol Data Unit Management Messages Management Sessions Services Management Function 3-10

2 Chapter Three, Page 3-2/12 This page was intentionally left blank.

3 Chapter Three, Page 3-3/12 Acronyms & Terms DNS INMF INSMF MDRIS MDRS MIB NSMF PDU SMF SMFPL SNMP 3-11 Internet Domain Name System 3-5 Internet-standard Network Management Framework 3-5 Internet 3-5 Management Domain Registration and Information Service 3-6 Management Domain Registration and Information Server 3-7 Management Information Base Protocol Data Unit 3-6 Services Management Function 3-11 SMF Programming Language 3-7 Simple Network Management Protocol

4 Chapter Three, Page 3-4/12 List of Figures Figure 1: components. 5

5 Chapter Three, Page 3-5/12 1 Introduction Chapter Two presented a detailed analysis of the most important limitations of the Internet-standard Network Management Framework (INMF). As stated before, these fragilities are difficult to overcome just with added mechanisms or extensions to the model. This motivated the creation of a new network management framework based on new architecture paradigms and with no information model or management data model requirements. The major requirements for this new framework were described on Chapter One and this chapter will introduce that framework and the conceptual solutions encountered to integrate all relevant concepts and technologies developed in the last years in the field of network management. The Internet (INSMF) project was the author s first effort to present a framework to overcome the most important limitations of the INMF by defining a complete network services management distributed architecture that provided services management functions with any desired level of functionality. This initial framework evolved to the present version, named Network Services Management Framework (NSMF), which is now a reference management framework conceptualization, adequate for management of almost any computer network services platform. The NSMF primary goal is to become an independent and generalist management architecture, integrating the most relevant (recent and past) concepts on network services management studied, developed, or introduced (with more or less adaptation) on any management framework with some repercussion on the computer networks community. Although being an engineer s project, the development of the NSMF does not have the commercial or fast implementation concerns and constraints of the INMF and other widely deployed management technologies. It has no politic constraints also, nor is dependent on any complete network protocols framework/stack. Entity Access Control Model Hierarchical & Distributed Architecture Security Model Management Domain Registration & Information Service Access Control Model Management Communications Services Management Messages Management Sessions NSMF/EACM Protocol Data Unit Service Management Function SMF Protocol Iteractions SMF Primitives SMF Programming Language SMF Definitions Base Figure 1: components. This chapter introduces the NSMF by presenting its three major components, also depicted on Figure 1: Architecture the NSMF is based on a hierarchical organization of management domains complying to the Entity Access Control Model (EACM), supporting entity and network resources access control, a broad range of security mechanisms (including entity authentication, management data content verification and confidentiality, management data compression, non-repudiation assurance and a complete key management system), entity and domain naming and addressing, and a Management Domain Registration and

6 Chapter Three, Page 3-6/12 Information Service (MDRIS); this service is provided by a special type of management entity, termed Management Domain Registration and Information Server (MDRS). Communications Model this framework defines two types of integrated management communications transport protocols or services that the management entities have to comply to be able to effectively communicate with each other: a connectionless management communications service defined as Management Messages and a connection-oriented management communication service defined as Management Sessions. Both types of communication services use the same NSMF Protocol Data Unit (PDU). Functional Model this component is defined by all functionalities enabled by the Services Management Function (SMF) concept; this is, probably, the most important single concept integrated on the NSMF, which is a procedure implementing a group of well defined services management actions/functions, and may include re-use of other SMFs. So, the NSMF is like a reference framework for definition and implementation of network services management frameworks. Other specific management frameworks could use only the concepts and mechanisms needed to match their pre-defined functional and conceptual requisites, without the need to deploy a management system implementing the complete NSMF definition. 2 Architecture The distributed architecture of the NSMF is defined on the EACM and its main concepts are the Network Services Management Entity (or just management entity) and the Network Services Management Domain (or just management domain). Each management entity is either a provider of a network management service through its Network Services Management Access Point (NSMP), as defined on Chapter Two, or a network management service user (or both). In the first case the entity is named a Management Server (in the INMF it is named an Agent) and in the second case it is named a Management Client (in the INMF it is named a Manager). A management entity can have several management roles but that classification is less relevant and it will be presented later on Chapter Four. The key elements on the EACM architecture are: Entity and Management Domain based Architecture this specifies an hierarchical with multilevel functionality domain organization; each management domain and each management entity must register a management name which will be mapped to one or several transport and/or network addresses by the MDRIS. Management Domain Registration and Information Service this integrated sub-service provides a way for management domains and entity s profiles to be securely registered, distributed and accessed when needed; an entity s profile will include several registration parameters (like the entity s name, network and transport layer addresses, management role, etc), security parameters (like security keys and supported security mechanisms), default access control levels and associated keys and its functional compliance. In the case of a management server, the functional compliance should list the supported SMFDB modules or individual SMFs (which correspond to a complete or incomplete set of management functions of one or more network management services); in the case of a management client it should list, if possible, an indication (prediction) of the SMFDBs or individual SMFs that the entity will expect to use. Each management entity must register its profile on one MDRS of the management domain it wants to be part of. Management Communications with Resources Control this model defines secure management communications between management entities, with the capability of dynamically limit the functionality of management procedures or the consumption of network and local device resources depending on the entities involved and the state of the network and the devices during the time of execution of the management procedure. Functional requisites for the security mechanisms to be used on the model with additional definition of default mechanisms for implementing authentication, confidentiality and data integrity on management communications. One of the aspects of this model is the use of default security mechanisms based only on private symmetric keys. The distribution of entity

7 Chapter Three, Page 3-7/12 profiles, including their security parameters and secret keys, is based on a trusted registration and distribution process defined on the MDRIS. Entity Backup Mechanism the EACM permits the definition of several instances of a management server as the backup servers that should be used when the active entity fails. 2.1 Entity Identification & Addressing The identification of the NSMF entities is based on a double hierarchic domain structure, each one resembling the hierarchic structure used on the internet s domain and host naming. But, unlike the internet generic names, these NSMF names are of mandatory use, that is, the identification of management entity is only possible through the use of its NSMF name, so, each entity will have, at least, one NSMF name a sequence of string labels. The addressing flexibility and the native support for connectionless management communication messages and connection oriented management communication sessions to encapsulate the NSMF protocol units, makes possible to use directly network protocols on lower levels of network frameworks or even link level protocols (although in this last case no communication between entities on different data links on networks that do not provide routing on this level would be possible). Furthermore, the EACM provides support for indirect addressing, or proxying, with no limit on the number of proxying levels. Although the initial INSMF recommended an architecture for the internal conceptualization of a management entity [118], the NSMF does not define or recommends this architecture or any other because the present framework complies with the conceptualization introduced on Chapter One for network management services, in which these are regarded as black boxes where it is only needed to define the interfaces. 2.2 Management Domain Registration and Information Service This service is part of the EACM model and is provided by the MDRSs of a management domain and must support the SMFs defined for this special network services management service that implements management procedures for: Domain & Entity registration (including access control parameters), Definitions of hierarchic domains relationships, Security information registration and maintenance, that is, a key management service, and Accessing information about management domains and management entities. 2.3 Resources Access Control One of the most important aspects of the EACM is the capacity for defining levels of access to the various types of resources available on a network device or on the network. These levels are defined by default on a management domain basis, but can be redefined by each entity acting as a management server, both by adding support to other local resources types or supporting additional access control levels for the same default access control levels. The management clients obtain their default access control levels based on theirs registered profiles, but can negotiate further access levels for each particular management communication with each particular management server. The definition of these access control levels takes into account the type of resources being used by each SMF issued by the management clients on the management servers. Unlike the access control of Management Information Base (MIB) objects on the INMF, for example, that associates a single fixed level of access (from a very limited set of available levels) for each MIB object to a Simple Network Management Protocol (SNMP) manager, the access control on the EACM associates a single dynamic level of access (from a potentially infinite range of levels) to each type of resource (from a potentially infinite range of types of resources) to a EACM management client using a security key for each access level or group of levels.

8 Chapter Three, Page 3-8/ Security Model The security requisites of the EACM were defined taken into consideration the most traditional security threats considered for management frameworks like masquerading, information modification, deletion or disclosure and a less common security threat was studied and classified to be of some importance for modern network services management frameworks: non-repudiation of authority of issued management procedures. Other security threats were considered less relevant to network services management (like traffic analysis or denial of service) or can be reduced to a particular or combined form of the previous threats (like information sequence or timing modification), so these can be assured indirectly or just ignored. In light of the previous remarks, the most important goals of the EACM concerning security can be briefly listed: guarantee of entity/data authentication and management information confidentiality, verification of correct sequencing and integrity of management information and, when required, non-repudiation assurance of management procedures authority. These goals should be attainable using a set of pre-defined mechanisms, identified by an EACM Security Model Identification Tag (SECM-IDT) and applicable to each management communication between two management entities. While an entity can support several security models, only one security model can be applied to each management communication. It becomes obvious that both entities involved must support the security model applied to that particular management communication. The security mechanisms to be applicable on the EACM must not use external protocols and must not rely on external security mechanisms. Further more, the security model of the EACM must define a set of functional goals for each mechanism and the protocol syntax imposed. This way, several present and future alternatives can be used for each of the mechanisms for: Encryption the EACM needs an encryption method to be applied to the appropriate part of the NSMF PDU so confidentiality can be supported. The standard encryption mechanisms defined, at present, to be applicable on the EACM are based on traditional symmetric key encryption methods, being the most important the Advanced Encryption Standard. i There is also default support for Triple Data Encryption Standard and other methods can be applied (Serpent, Twofish, RC6, Mars and Saffer++) but are not defined as EACM standards at this time. Keyed Message Digest this is needed to ensure authentication (by itself or in conjunction with the encryption method) and verification of data integrity of the appropriate NSMF PDU part. It was decided to adopt, as an EACM standard, the Key-Hashing for Message Authentication mechanism with the possibility to use three well known message digest methods: Message Digest 5, RIPEMD and Secure Hash Algorithm 1. Key Management the EACM has a well defined mechanism for renovation (creation and deletion) of the keys/secrets of the management entities registered on management domain. In direct relation to key renovation is the need for a method for key transfer (distribution) between management entities. The EACM provides standard support for two key renovation approaches: o Local Renovation The keys are only created (or renovated) locally on the entity o owning the keys and then sent encrypted to one of the MDRSs of the domain; and Distributed Renovation The keys are created (or renovated) at the same time by the entity owning the keys and by the MDRSs through the use of a pre-defined mathematical process; this mathematical process should be supported on the domain by the Management Domain Registration & Information Service, executed on one MDRS and issued by the entity owning the key; this approach is safer because the keys values are not exposed (even if the previous methodology uses encryption) since they are not on transit on the network during the renovation procedure. Data Compression there can be an optional use of a lossless data compression mechanism that will help to minimize network bandwidth consumption and, if applicable, to reduce the security vulnerability of the original data stream of the appropriate NSMF PDU part/section. At this moment, the EACM defines only one data lossless compression mechanism, based on the Huffman compression algorithm concept. Since several algorithms exist based on this i At this time no references are given on these mechanisms. Later on Chapter Four these mechanisms the EACM security model will be further detailed and adequate references will be included.

9 Chapter Three, Page 3-9/12 traditional approach, the EACM only defines the syntax rules of how to represent the code table to be applied by the entity performing the decompression. This way, an added flexibility is achieved and the entity implementing the decompression does not need to know exactly which algorithm was used to construct the table of codification. It will be up to the entity making the compression to adopt the compression algorithm that better suits its goals (speed of compression, rate of compression, resource consumption, etc) as long as it is a lossless method and the compression codification table dos not yield any ambiguity and follows the syntax rules defined by the EACM. Non-Repudiation Assurance finally, the EACM should provide, although optionally, mechanisms for assurance of non-repudiation. This mechanism should guarantee non-repudiation using any MDRS on the management domain as the third party, trusted by the other entities on the management domain. The most common situation where the use of such mechanism is useful is when a management server wants to ensure that a management client can be identified as the responsible entity for an executed management procedure that resulted on some kind of functional constrain, even if the client had permission to do so. The management server is able to report the authority of the management procedure since the mechanism defined on the EACM guarantees that the reported client is the only entity (non MDRS) able to issuing the damaging management procedure. This allows that a management server reports any SMF issued by a management client, optionally including a resulting configuration status field. 3 Management Communications Services One of the major assets of the NSMF is the ability to provide its own management data transport service, the Management Communications Service. Furthermore, management communications can be connectionless, through Management Messages, or connection oriented, through Management Sessions. The first type is of mandatory implementation, while the later is of optional deployment. On modern network services frameworks, where the classification of traffic for effective quality of service deployment is important, it is an advantage being able to provide independent transport services adapted to specific needs of management services. Comparatively, the Management Messages transport service is more complete and, in the same proportion, exigent on entities resources than the Internet User Datagram Protocol. On the other hand, the Management Session transport service, although less complete and exigent than the Internet Transmission Control Protocol, is much more focused on the needs of a network services management framework and, in particular, on the NSMF functional requisites. While management server s confirmation of reception of SMF execution requests can be obtained through a higher level SMF interaction, the only available method for the management client to confirm reception of SMF management results from the server is by using management sessions. 3.1 NSMF Protocol Data Unit Both types of transport services use the same NSMF Protocol Data Unit (NSMF PDU) to encapsulate the management data. Each PDU used for management messages is named a message part while each PDU used for management sessions is named a session segment. Each message or session identification tag must be assigned by the management client and should be randomly generated, or, at least, the client should guarantee that no two active messages or sessions have the same identification tag. Chapter Five details the NSMP PDU syntax and semantics. 3.2 Management Messages A management message can include one or several SMF execution requests or SMF responses and can occupy one or several NSMF PDUs, in which case, each PDU will be a management message part. When a management message has more than one part, none of its SMFs should be split across different parts. Each management message part can use its own security model and security keys. Each entity s identification field of each management message part must include the entity s address.

10 Chapter Three, Page 3-10/12 There is no management data flow control on management messages, that is, there is no confirmation of messages reception (or message parts) from both entities. i Each management message part is a unique piece of management data and the only dependency on different message parts is the message identification tag and the numbering of all parts must be sequential. The management server must only start the execution of the SMFs included on the management message after the successful reception and processing of the entire message. Management messages must also be used to open management sessions between a management client and a management server (although management sessions can be opened from inside other management sessions between the same entities). Messages can also be used to close active management sessions between the same entities, but this is only recommendable on special situations (management sessions should be closed using primitives transferred on the management session itself). Management messages should be simple to implement and should consume very view resources on the management entities, so, this should be the preferred management communications service when no special reliability requirements must be assured. 3.3 Management Sessions A management session is a simple connection oriented management communication that has three states (otherwise is undefined): Opening Session, Data Exchange and Closing Session. It is always the entity acting in the role of management client to request the establishment of a management session. When the management session enters the data exchange phase or state, the entities can exchange SMF execution requests and SMF responses subjected to management data flow control controlled by two types of windowing parameters: time window and traffic window. The later type has also three sub-types of windowing management that takes into consideration three different management data traffic parameters: number of bytes, number of session segments and number of SMF primitives. This capability is very important because it defines a complete management data flow control at various management data semantic levels and complemented with a time window. Additionally, management sessions implementation must take into consideration the consumption of one of the two resources associated with management sessions and that are negotiated when establishing the session (opening phase): management session lifetime (or management session time to live) and management session traffic quota. There are other session parameters negotiated on the opening phase that will be described in detail on Chapter Five. An added advantage of the management sessions is that each management session always uses the same implied pair of session keys (one for each entity). So, the lifetime of a management session is also constrained by the lifetime of both session keys. Finally, it should be noted that management sessions consume more entity and network resources than management messages. They should be used only on situations where it is needed a greater control and reliability on the management data transfer or when resource consumption and computing power is not a relevant concern. 4 Services Management Function The SMF concept has changed little since its adoption on the initial INSMF. With this new paradigm, management entities deploy management procedures (including management data access, manipulation and processing) by means of functions defined in a definitions base or through code delegation. Each network service should create a Service Management Function Definitions Base (SMFDB) with SMF definitions divided by levels of functionality and type of management (like Monitoring, Configuration, Accounting, Performance and Security), when applicable. For example, the NSMF has already defined a special group of SMFs integrated on the MDRIS. i Although encapsulated SMF execution requests can be confirmed even when using management messages, this is a feature deployed on a higher layer interaction and will be detailed on Chapter Six.

11 Chapter Three, Page 3-11/12 At this point, we shall present a brief list of the functional capabilities natively provided or supported by the NSMF due to the integration of the SMF concept: Events & Alarms this mechanism is easily implemented on the NSMF through the use of a SMF, delegated or not, with conditional execution parameters; or on the SMF code itself. The first approach permits using any SMF as an event/alarm handler, while the second is preferable when creating dedicated event/alarm handlers with more complex trigger conditions. Expression Evaluation this is done in a completely transparent way on the SMF definition or explicitly on a delegated SMF code. Operations Scheduling all types of management procedures conditional execution, including time delayed or scheduled, are available with SMF concept, either by means of direct conditional execution parameters or SMF code definition. Management Delegation this is obtained through the use of delegated SMF code. i In this case, there s only one mandatory SMF Programming Language (SMFPL) to delegate SMF code, but other forms of code can be delegated as long as the target entity supports the chosen language (like Java, Active X or XML). The SMFPL is intentionally simple (all language operators, constructs, conditional statements, mathematical and boolean functions, data manipulation, etc, is represented using the same SMF syntax) but powerful enough for efficient delegation of management code. This pragmatic approach favours the ease of implementation and the creation of various levels of management. It is possible to delegate SMF mobile code that will delegate itself or other code to other management entities. Parameters Inspection it is possible to a management client to inspect SMF parameters while the SMF is still executing on the management server; this is a powerful feature for implementation of effective and advanced network services monitorization (which could be very helpful for deployment of prediction algorithms of active management systems). Policy Management the NSMF does not impose any Information Model or Management Data Model which leaves the door open to any form of management information approach, including policy management. The SMF concept and the infinite range of functionality levels permitted to management procedures are a very attractive recipe for deployment of complex policy management platforms with multi-level management information or data models. Chapter Six will present a detailed description of all aspects of the SMF concept, from its definition to its use for deployment of these advanced network management technologies. As a closing remark on this chapter, this author points out article [118] that gives an implementation example of an Internet Domain Name System (DNS) management service complying with the original INSMF. Nevertheless, it includes the definition of several SMF functions of a prototype DNS SMFDB. i There is no provision of direct delegation of management entities (also known as mobile agents), because this feature can be modelled as a special case of deployment of code delegation using an underlying runtime component.

12 Chapter Three, Page 3-12/12 This page was intentionally left blank.