Secure SNMP-Based Network Management in Low Bandwidth Networks. H. Erik Hia. Master of Science in Computer Engineering

Transcription

1 Secure SNMP-Based Network Management in Low Bandwidth Networks H. Erik Hia Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Dr. Scott F. Midkiff, Chair Dr. Nathaniel J. Davis, IV Dr. Luiz A. DaSilva April 23, 2001 Blacksburg, Virginia Keywords: SNMP, Network Management, IPSec, DISMAN Script MIB Copyright 2001, H. Erik Hia

2 Secure SNMP-Based Network Management in Low Bandwidth Networks H. Erik Hia Dr. Scott F. Midkiff, Chair Computer Engineering (ABSTRACT) This research focuses on developing a secure, SNMP-based network management system specifically tailored for deployment in internetworks that rely on low-bandwidth backbone networks. The network management system developed uses a two-level hierarchy of network management applications consisting of one top-level management application communicating with several mid-level management applications strategically distributed throughout the internetwork. Mid-level management applications conduct routine monitoring chores on behalf of the top-level management application and report results in a way that makes intelligent use of the limited bandwidth available on the backbone network. The security framework is based on using SNMPv2c over IPSec. This research shows that the other security alternative considered, SNMPv3, consumes as much as 24 percent more network capacity than SNMPv2c over IPSec. The management framework is based on the Management by Delegation (MbD) model and is implemented using the IETF DISMAN Script MIB. This research demonstrates that the MbD-based management framework consumes only 2 percent of the network capacity required by the traditional, centralized management scheme.

3 Acknowledgments I would like to thank my advisor, Dr. Scott F. Midkiff, for his excellent guidance during my graduate studies. The extraordinary depth and breadth of his knowledge and his exceptional ability to communicate complex concepts were instrumental in both my decision to pursue a graduate degree and my development as a computer engineering student. I would also thank the other members of my advisory committee, Dr. Nathaniel J. Davis IV, and Dr. Luiz A. DaSilva for their gracious service. I would like to convey my sincere thanks to the family of Marion Bradley Via for the incredibly generous support offered by the Bradley Endowment. The benefits I received as a Bradley Fellow made my graduate studies possible. I would also like to thank Mr. John G. Rocovich for all the work he does to support the Bradley Department of Electrical and Computer Engineering. I would also like to thank the Office of Naval Research for their support during Summer 2000 through the Navy Collaborative Integrated Information Technology Initiative. I would like to express my deepest gratitude to my lovely wife, Sharon, and to my two wonderful children, Kyle and Jamie. It is through them that I truly live. Without their unwavering love and encouragement, I would not have sustained the six year effort required to reach this plateau in my life. I would also like to thank all the friends I have made here at Virginia Tech and those I grew up with in St. James, NY. Even though time and distance might separate us, they are never far from my thoughts. iii

4 Table of Contents CHAPTER 1 INTRODUCTION BACKGROUND RESEARCH GOALS DOCUMENT OVERVIEW...3 CHAPTER 2 METHODOLOGY INTRODUCTION EFFICIENTLY SECURING SNMP Alternatives for Securing SNMP Evaluating Alternatives for Securing SNMP DEVELOPING THE NETWORK MANAGEMENT SOLUTION Alternatives for Distributed Management Developing the Network Management Solution DEPLOYING AND TESTING THE SOLUTION SUMMARY AND CONCLUSIONS...8 CHAPTER 3 ALTERNATIVES FOR SECURING SNMP INTRODUCTION USING INSECURE SNMP OVER IPSEC Comparing SNMPv1 and SNMPv2c An Overview of IPSec Characteristics of Using SNMPv2c Over IPSec USING SNMPV Overview of SNMPv Characteristics of Using SNMPv COMPARING SNMPV2C-OVER-IPSEC AND SNMPV SUMMARY AND CONCLUSIONS...19 CHAPTER 4 EVALUATING ALTERNATIVES FOR SECURE SNMP INTRODUCTION THE TESTBED NETWORK Hardware Used in the Testbed Network Software Used in the Testbed Network THE EXPERIMENTS AND THEIR RESULTS How Much Network Capacity is Consumed by a Secure SNMP Operation? How Much Processing Time is Consumed by a Secure SNMP Operation? How Much Capacity is Consumed by an SNMPv3 Discovery Exchange? How Much Network Capacity is Consumed by an IPSec SA Negotiation? SUMMARY AND CONCLUSIONS...27 CHAPTER 5 ALTERNATIVES FOR NETWORK MANAGEMENT INTRODUCTION ALTERNATIVE NETWORK MANAGEMENT PARADIGMS Centralized Network Management Weakly-Distributed Network Management...29 iv

5 5.2.3 Strongly-Distributed Management Cooperative Network Management CHOOSING A NETWORK MANAGEMENT PARADIGM THE IETF DISMAN SCRIPT MIB The Jasmin Script MIB Implementation SUMMARY AND CONCLUSIONS...36 CHAPTER 6 DESIGNING AND DEVELOPING THE SOLUTION INTRODUCTION OVERVIEW OF THE SOLUTION DEVELOPING THE TOP-LEVEL MANAGER Monitoring Utilization of the Backbone Network Dynamically Configuring Operational Parameters Monitoring Incoming SNMP Traps Receiving Incoming Mid-Level Manager Updates DEVELOPING THE MID-LEVEL MANAGER The IfData Class The SnmpData Class The Peer Class The IfMonitor Class The SnmpMonitor Class The MLMUpdate Class The MLM Class The MyMLM Class MANAGER-TO-MANAGER COMMUNICATIONS SUMMARY AND CONCLUSIONS...48 CHAPTER 7 DEPLOYING AND TESTING THE SOLUTION INTRODUCTION THE TESTBED NETWORK Hardware Used in the Testbed Network Software Used in the Testbed Network THE EXPERIMENTS AND THEIR RESULTS Does the MbD Management Scheme Operate as Intended? How Much Capacity is Consumed by Centralized Monitoring? How Much Capacity is Consumed by MbD Monitoring? How Much Capacity is Consumed by Control Communications? COMPARING THE CENTRALIZED AND MBD SCHEMES SUMMARY AND CONCLUSIONS...60 CHAPTER 8 CONCLUSIONS SUMMARY AND CONCLUSIONS FUTURE WORK...62 REFERENCES...64 VITA...67 v

6 Chapter 1 Introduction Chapter 1 Introduction 1.1 Background The Simple Network Management Protocol (SNMP) [1] was developed in the late 1980 s to provide network operators with a simple tool they could use to manage their networks. It was intended to be an interim solution that would eventually be replaced by the more sophisticated Common Management Information Protocol (CMIP) [2]. The transition to CMIP never materialized, leaving SNMP as the industry-standard protocol used for managing today s Internet Protocol (IP) networks. While SNMP has served its purpose well, it has suffered from problems. Practical experience with the original version of SNMP and the exponential growth in the size and number of IP networks revealed fundamental deficiencies that needed to be addressed [3]. An improved version of SNMP, called SNMPv2c [4], was released in 1996, but two serious problems still remained unresolved. First, the practice of transmitting community strings (passwords) in clear text posed a severe security problem. Second, the commonlyused centralized management scheme, where a single network management station queries every device under management for low-level data, was found to scale poorly. The security problem has been addressed from varying perspectives. This research examines two techniques for securing SNMP traffic: (i) using SNMPv3 [5], the latest version of SNMP which includes inherent security capabilities, and (ii) using a nonsecure version of SNMP in conjunction with Internet Protocol Security (IPSec) [6]. The theme common to these approaches is that they both ensure the authenticity, integrity, and privacy of SNMP traffic. There are, however, qualitative and quantitative differences between these two approaches; these differences are examined in detail later in this thesis. The centralized management scheme begins to fail as the size of the network under management grows very large for at least two reasons: (i) the traffic generated by a network management station polling a large network can easily congest the network being monitored, and (ii) the network management station itself can be overwhelmed by the heavy workload realized when polling a large network, particularly when confronted with problems in the network. Solutions to the scalability problem have also been addressed from many perspectives; several of these solutions are discussed in this thesis. The theme common to most of them is that they strive to distribute the network monitoring work to entities dispersed throughout the network. These distributed schemes ease congestion in the network by acquiring and processing low-level data close to the origin of the data, and ease the workload presented to a central network management station by dividing its aggregate workload among a number of subordinate network management entities. 1

7 Chapter 1 Introduction 1.2 Research Goals The direction of this research evolved from work on the Navy Collaborative Integrated Information Technology Initiative (NAVCIITI) project sponsored by the Office of Naval Research (ONR). Task 3.1, Network Protocol Interoperability, of the NAVCIITI project involved investigating network infrastructure for the Virtual Operations Network (VON), which is a rapidly-deployable internetwork of naval vessels at sea [7]. The VON can be viewed as an internetwork of LANs, representing Navy ships from the U.S. and other countries, connected via a low-bandwidth wireless backbone network. This research is focused on developing an effective scheme for deploying secure SNMP-based network management in internetworks that rely on low data-rate backbone networks for internetwork connectivity and that require security to ensure privacy and authorized access. The VON is an example of such an internetwork. Many of the ideas developed here also have value for networks with high data rate optical fiber or broadband wireless backbones, although bandwidth consumption is less critical in such networks. Figure 1-1 shows a high-level representation of an internetwork with a low-bandwidth backbone network. Henceforth, this type of internetwork will be referred to as a low-bandwidth internetwork. Figure 1-1. A typical low-bandwidth internetwork. The main problem to be solved can be posed as follows. Suppose that Net 1 in Figure 1-1 hosts the top-level network management authority responsible for managing the overall network. How can the top-level network management authority securely monitor the entire internetwork without consuming an excessive amount of the limited capacity available on the backbone network? Furthermore, any reasonable solution to this problem must adhere to the following constraints. The solution must not impair useful network management functionality while striving to preserve the limited network capacity available on the backbone network. 2

8 Chapter 1 Introduction The security services provided must include message authentication, integrity, and confidentiality. The solution must be cost effective and promote interoperability, implying that standards-based, commercial, off-the-shelf components should be used. The solution must be easy to integrate into existing SNMP-based network management systems. The principal metric of interest for evaluating any proposed solution is the degree to which the solution consumes backbone network capacity as compared to the traditional, centralized monitoring model. The solution system is expected to reduce consumption of backbone network capacity by a factor of at least ten. A solution to the main problem has been realized using a two-level hierarchy of network management applications consisting of one top-level management application communicating with several mid-level management applications strategically distributed throughout the VON (e.g., one mid-level manager per Navy ship). Henceforth, the terms mid-level manager and top-level manager will refer to these management applications; human managers will be referred to as administrators. Each mid-level manager conducts routine network monitoring chores on its local network, analyzing and saving the raw data it collects. If the mid-level manager detects a critical problem, it notifies its assigned top-level manager via an SNMP Trap. Otherwise, the mid-level manager saves its data until instructed to transfer its data to its assigned top-level manager. The top-level manager monitors the backbone network, instructing its mid-level managers to transfer their saved data only when the top-level manager perceives that the current utilization of the backbone network is suitably low. The primary goal of this scheme is to push routine polling traffic off of the backbone network and onto the edge networks. The solution ensures the security of SNMP traffic by using SNMPv2c over an IPSecenabled network layer. As presented in Chapter 4, this security scheme was found to consume less network capacity than the SNMPv3 scheme and has the added benefit of providing security services to all applications that use IP, a property not provided by SNMPv3. The remainder of this thesis describes in detail how a solution to this problem was developed and how well that solution performs. 1.3 Document Overview This chapter introduces a very brief history of SNMP intended to illustrate the origin of the problems that are addressed by this research. Furthermore, the goals of this research are explained, and a snapshot description of the solution is provided. Chapter 2 describes the methodology that was employed to solve the main problem. The main problem was decomposed into two sub-problems: (i) deciding how best to secure 3

9 Chapter 1 Introduction SNMP, and (ii) developing a network management system that effectively preserves backbone network capacity. Solutions to these sub-problems were then aggregated into an overall solution, implemented on a testbed network, and evaluated through testing. Chapter 3 provides a qualitative comparison of the alternatives considered for securing SNMP. Two alternatives are covered: (i) using SNMPv3, and (ii) using SNMPv2c over IPSec. Chapter 4 describes experiments that were conducted to evaluate the alternatives for securing SNMP with respect to how much network capacity they consume. The chapter documents the testbed network used, the experiments that were conducted, and the results of those experiments. Chapter 5 provides an overview of alternative network management technologies considered for use in the network management system being developed. The overview discusses centralized network management, Remote Network Monitoring (RMON), Web-Based Enterprise Management (WBEM), Java Management Extensions (JMX), the IETF DISMAN Script MIB, Mobile Agents, and Active Networks. The chapter concludes with a more detailed description of the technology ultimately selected, the IETF DISMAN Script MIB, and introduces the Jasmin implementation of the IETF DISMAN Script MIB. Chapter 6 provides a description of the network management scheme developed to solve the main problem. The description documents the development of the top-level manager application, the mid-level manager application, and the communications between them. Chapter 7 discusses how the network management system under development was deployed on a testbed network and evaluated. The discussion describes the testbed and the experiments that were conducted to evaluate the solution network management system s effectiveness. The principal metric of interest is how much backbone network capacity is consumed by the solution network management system versus the traditional, centralized scheme. Chapter 8 draws conclusions learned from conducting this research and offers recommendations for further work. 4

10 Chapter 2 Methodology Chapter 2 Methodology 2.1 Introduction Developing a solution to the main problem was divided into three distinct phases. The first phase was dedicated to researching how to secure SNMP traffic while having the least negative impact on the degree to which SNMP consumes network capacity. The first phase effort concluded with the definition of a scheme for securing SNMP in the network management system being developed for this research. The second phase was dedicated to developing a network management system, using the security scheme defined earlier, that can effectively manage a low-bandwidth internetwork while preserving as much as possible the limited capacity available on the backbone network. The second phase concluded with the definition and development of a secure, network management system. The third phase was focused on deploying and testing the proposed network management system on a testbed network. This final phase concluded with a quantitative analysis of how effectively the solution network management system preserves backbone network capacity as compared to a centralized network management scheme. 2.2 Efficiently Securing SNMP Any scheme capable of securing SNMP will have associated costs in terms of increased network overhead, additional computational overhead, increased complexity of use, etc. Any credible solution to the problem addressed by this research must start by efficiently securing SNMP traffic. The main goal for securing SNMP was to ensure the authenticity, integrity, and privacy of SNMP traffic, while minimizing the inevitable increase in network overhead that accompanies these security services. It seems reasonable to approach securing SMMP by first carefully examining alternative methods for securing SNMP to establish a set of candidate solutions, and then to conduct empirical experiments to definitively establish which candidate solution is superior Alternatives for Securing SNMP There are many ways that SNMP traffic can be secured: (i) individual links can be secured using cryptographic black boxes, (ii) networks can be secured using network layer solutions like Internet Protocol Security (IPSec), and (iii) SNMP applications can be secured by directly incorporating security into the application layer software. The black box solution can be discarded immediately because there are no standards-based, black box technologies that can be readily incorporated into a low-bandwidth environment. The two remaining alternatives are exemplified by non-secure SNMP over IPSec, and SNMPv3. Both of these techniques are serious contenders for use in a 5

11 Chapter 2 Methodology proposed solution, so their advantages and disadvantages should be carefully assessed. Chapter 3 is focused on examining these alternatives in qualitative terms Evaluating Alternatives for Securing SNMP Empirical testing is the most definitive way to determine which of the candidate security schemes consumes the least network capacity. Towards that end, a testbed network implementing the candidate security schemes was built and used to run experiments that showed which scheme was superior. Chapter 4 documents the configuration of the testbed, the experiments run on the testbed, and the results of those experiments. The conclusion of Chapter 4 identifies non-secure SNMPv2c over IPSec as the security scheme that is used in the network management system being developed as part of this research 2.3 Developing the Network Management Solution The question of how to preserve the limited capacity available on a low-bandwidth backbone network can be decomposed into the following two questions. How can the volume of SNMP traffic traversing the backbone network be reduced without hindering network management effectiveness? How can a network management scheme take advantage of the variations that naturally occur in backbone utilization? When considering the first question, it is clear that a traditional, centralized, polling scheme must be abandoned in favor of some type of distributed scheme. The second question suggests that the network management system should be made sensitive to the current utilization of the backbone network. That is, the system should refrain from transmitting non-critical information when backbone utilization is high. Critical information should always be transmitted immediately. Initial thoughts into a suitable solution resulted in a distributed, hierarchical concept where top-level managers delegate routine polling chores to mid-level managers distributed throughout the internetwork. For example, in Figure 1-1, a mid-level manager would be installed in every local network, including the network that hosts the top-level manager. Each mid-level manager monitors it own local network on behalf of the top-level manager. The mid-level manager then reports results to the top-level manager in a way that makes intelligent use of the limited backbone capacity. This scheme relieves the toplevel manager of routine polling chores that require transmitting datagrams across the backbone network. The mid-level manager can be designed to use SNMP Traps to immediately report critical information to the top-level manager. SNMP Traps are asynchronous 6

12 Chapter 2 Methodology notifications sent by an agent that alerts a management station to a condition that requires attention. SNMP Traps offer the advantage of alerting the top-level manager to critical conditions as soon as they are detected. Non-critical information can be gathered, summarized, saved, and finally returned when utilization of the backbone is suitably low. This scheme makes the network management system sensitive to backbone utilization. In summary, the basic network management framework being considered consists of several mid-level managers, one for each network node in the internetwork, all reporting to a single top-level manager. Each mid-level manager collects and processes data only from its local network and returns that information to the top-level manager in an intelligent way. Critical information can be returned immediately via SNMP Traps. Non-critical information can be returned when utilization of the backbone network is below some predetermined threshold. The question is: does a distributed system like this already exist? And if not, can this system be constructed from existing components? Alternatives for Distributed Management In recent years, there has been an explosion in distributed systems research; many distributed computing systems are now available commercially and otherwise. The network management arena has not been immune to this explosion; there are many distributed network management systems in existence, including those based on World Wide Web technologies, Java, Mobile Code, Mobile Agents, and Active Networks. It is important for this research to leverage existing technologies to achieve its goals. Chapter 5 provides an overview of several network management technologies that were considered for use in the network management system under development. Chapter 5 concludes with a discussion of the technology ultimately chosen Developing the Network Management Solution The magnitude of the development effort was, of course, dependent upon the degree to which existing technologies could be leveraged. After researching those technologies that might be of use, the system development effort encompassed three basic needs: (i) developing the top-level management software, (ii) developing the mid-level manager software, and (iii) defining the communications between the top-level manager and the mid-level manager. Chapter 6 documents these three activities. 2.4 Deploying and Testing the Solution The final step of the research was to implement the solution system on a testbed network to ascertain how well it works. The main metric of interest in determining the system s value is the degree to which the system consumes backbone network capacity as compared to a traditional, centralized scheme. The design objective was to consume less than one tenth of the capacity required by the centralized scheme, with no loss of network management effectiveness. 7

13 Chapter 2 Methodology 2.5 Summary and Conclusions This chapter explained the methodology used to achieve the goals of this research. The research was divided into three phases. The first phase was dedicated to securing SNMP while having the least negative impact on the degree to which SNMP consumes network capacity. The second phase was focused on developing a network management framework that preserves backbone capacity without hindering network management effectiveness. The third phase was dedicated to evaluating the network management system developed for this research. The evaluation was based on how much backbone capacity was preserved by the management system as compared to the backbone capacity consumed by the traditional, centralized network management scheme. The design goal was to reduce consumption of backbone capacity by a factor of at least ten. 8

14 Chapter 3 Alternatives for Securing SNMP Chapter 3 Alternatives for Securing SNMP 3.1 Introduction This chapter presents a qualitative discussion of alternatives for securing SNMP-based network management traffic in low-bandwidth internetworks. The following qualities are sought for traffic in such a network. Tight security ensuring data authentication, integrity, and privacy. Cost effective interoperability implies using commercial, off-the-shelf, standards-based technologies. Low network overhead efficient message exchange in terms of message length and frequency of messages. Based on meeting the above objectives, two approaches are examined: (i) using an insecure version of SNMP over IPSec, and (ii) using SNMPv3. This chapter concludes with criteria that network administrators can consider when deciding how to best secure SNMP traffic in their own networks. 3.2 Using Insecure SNMP Over IPSec Before incorporating IPSec into this analysis, it is important to establish which insecure version of SNMP is best suited for this research. Towards that end, a comparison of SNMPv1 and SNMPv2c is provided Comparing SNMPv1 and SNMPv2c SNMPv2c incorporates enhancements to SNMPv1 that fall into two basic categories: enhancements to the original Structure of Management Information (SMI) [8], and enhancements to protocol operation. The enhancements to the SMI, called SMIv2 [9], effectively refine and clarify the original SMI to support the enhancements made to protocol operation [10]. Since the details of SMIv2 do not directly affect this analysis, they are not examined here. Instead, the analysis focuses on enhancements to protocol operation and their costs; these include the following. A new Get-Bulk request to facilitate retrieving multiple rows from a Management Information Base (MIB) table by using only one request message instead of several sequential Get-Next request messages. A new Inform message used for manager-to-manager exchanges. The Inform message is essentially an acknowledged trap that facilitates building hierarchy into a distributed network management system. An SNMPv1 response to a Get request is atomic; whereas an SNMPv2c response to a Get request is not atomic. For example, suppose a Get message 9

15 Chapter 3 Alternatives for Securing SNMP requests a long list of MIB variables, but one of the variables requested is not available. An SNMPv1 response will return an error status code with no values returned for the valid variables. An SNMPv2 response will return an error status code for the unavailable variable, but will also return values for all the valid variables. The non-atomic Get response translates to more efficient message exchanges and lower overall SNMP traffic. Several error status codes were added to better inform users about the cause of a failed operation. The improved error-reporting interface translates to fewer message exchanges needed to resolve problems. It is interesting to note that the above enhancements are implemented without incurring any substantial additional overhead. SNMPv2c uses the same basic message format and the same community-based security scheme as SNMPv1. The shared format is shown in Figure 3-1, where the Protocol Data Unit (PDU) field depends on the SNMP operation being invoked. Note that the authors of SNMP have chosen an atypical definition for a PDU. Usually, a PDU is thought of as the entire block of information that is logically communicated between peer layers. The authors of SNMP consider an SNMP PDU to be a subset of such a block [11]. Version Community PDU Figure 3-1. SNMPv1, SNMPv2c message format. Note that the length of a field in an SNMP message cannot always be stated in absolute terms because of the following two reasons. Some fields, by definition, vary in length. For example, community strings and user names both vary in length. Before passing the message to the transport layer, the Basic Encoding Rules (BER) associated with the Abstract Syntax Notation (ASN.1) are used to encode each field into a (type, length, value) triplet whose length is value dependent. For example, the length of a BER encoded 32-bit integer depends upon its magnitude (e.g., 2 is encoded in 3 bytes, 2 30 is encoded in 6 bytes). Therefore, the overall length of an SNMP message cannot be definitively determined without knowing all the values that are placed in each of its fields. This ambiguity in overall message length, combined with the wide range of polling frequencies possible in a typical network management policy, make static characterization of SNMP bandwidth requirements difficult. It could be argued that the above enhancements to protocol operations place additional load on the agent. However, a counter-argument would be that, in actual use, SNMPv2 s Get-Bulk request and superior error reporting sufficiently reduces the total number of message exchanges to overcome any additional load placed on the agent. Since 10

16 Chapter 3 Alternatives for Securing SNMP SNMPv2c is essentially a refined version of SNMPv1 that imposes no additional costs, SNMPv2c is the non-secure version of SNMP chosen for use over IPSec. Henceforth, incorporating IPSec into this analysis is considered with respect to SNMPv2c only An Overview of IPSec IPSec is a protocol suite that provides authentication, encryption, key management, and key exchange capabilities by defining header extensions to standard IP [6]. The header extensions support the following components of IPSec. Authentication Header (AH) [12] packets are authenticated using either Secure Hash Algorithm (SHA-1) or Message Digest 5 (MD5) keyed-message digests. Note that AH authenticates the entire IP packet, except for fields in the IP header that change in transit. Encapsulating Security Payload (ESP) [13] packets are encrypted using the Data Encryption Standard in Cipher Block Chained mode (DES-CBC). Note that ESP also employs an authentication feature, but ESP s authentication protects only the encrypted payload. If the IP header of an ESP packet requires authentication, then AH should be used in conjunction with ESP. Internet Key Exchange (IKE) [14] defines how principals agree on the protocols, keys, and algorithms that will be used during a secure communications session. IKE is based on the Internet Security Association and Key Management Protocol (ISAKMP) [15] and on parts of the Oakley key exchange protocol [16]. IKE negotiates and maintains the security features applied to a communications channel by establishing a security association (SA) between communicating entities. A security association is a set of protocols, algorithms, and keys that are applied to a communications channel, and can be thought of as a logical communications channel that has inherent security features. Security associations are built in one of two basic configurations: transport mode and tunnel mode. Transport mode security associations are intended for securing host-to-host communications. In transport mode, an IP tunnel is not used, leaving the addresses of the communicating machines exposed. Tunnel mode security associations are primarily intended for applying protection to IP tunnels established between security gateways. In tunnel mode, the addresses of the communicating machines are hidden in the encapsulated payload. AH and ESP can be used alone or in tandem, and each can be configured for use in either transport mode or tunnel mode. IKE uses two phases of operation, Phase 1 and Phase 2, to establish and maintain security associations. A Phase 1 exchange establishes an initial SA between communicating entities using either aggressive mode or main mode negotiation procedures. Aggressive mode requires two back-and-forth communication exchanges; whereas main mode requires three back-and-forth communication exchanges. The extra exchange used by main mode keeps the principal s identities private, providing an extra measure of security 11

17 Chapter 3 Alternatives for Securing SNMP over that provided by aggressive mode. A Phase 2 exchange uses quick mode to establish a new SA or to update an existing SA during a secure communications session already established by a Phase 1 exchange. A quick mode negotiation procedure exchanges three packets resembling a three-way handshake Characteristics of Using SNMPv2c Over IPSec Since both encryption and authentication services are needed to meet the aforementioned objectives, the following analysis assumes that the ESP feature of IPSec is used to provide both encryption and authentication services in a tunneled SA between two security gateways. Each security gateway protects and hides a LAN from the IP cloud traversed by the tunnel. A typical situation, shown in Figure 3-2, consists of an SNMP management station on one hidden LAN communicating with an SNMP agent on the other hidden LAN. Figure 3-2. A typical IPSec tunneled SA Scope of IPSec s Security Protection IPSec implements security features at the network layer. Therefore, its security features are available for use by higher-layer protocols that use IP. If security features are needed for other applications in addition to SNMP, then IPSec may be the most effective means for obtaining a general security solution. However, IPSec does not provide true end-toend security, even in a host-to-host SA [17]. The protection provided by IPSec does not extend above the network layer, leaving an unsecured gap between the network and application layers of the SA endpoints. While this gap might be more of a computer (or operating system) security issue than a network security issue, the existence of this gap could potentially be exploited by those with malicious intent, so it must be considered. Typically, IPSec does not protect the traffic traversing the LAN protected by the security gateway. Although host-to-host SAs could be used behind the security gateway, IPSec is usually not deployed on most SNMP-enabled network devices, so there probably is significant SNMP traffic traversing the LAN in the clear. This may or may not pose a problem, depending on the strength of the LAN administrator s security policy and how 12

18 Chapter 3 Alternatives for Securing SNMP well it is enforced. Nevertheless, this issue must be considered since the LAN s security could easily be compromised (e.g., by a user installing a modem without authorization). Although the IPSec framework is open to incorporating other encryption algorithms, only DES-CBC [18] (and NULL encryption) is required for conformance, providing a basic encryption standard to ensure interoperability. Since confidence in the security of 56-bit DES-CBC is rapidly eroding, the use of stronger encryption algorithms is encouraged Network Overhead Imposed by IPSec The ESP header extension defined by IPSec is shown in Figure 3-3. It includes several extra fields that impose additional overhead, creating an impact on the available network capacity, which in some cases may be very low. The security parameters index, sequence number, pad length, and next header fields are all fixed in length, consuming an additional 10 bytes. The authentication data field is variable, depending on the authentication scheme used; a typical length might be, for example, 96 bits for MD5-96. The padding field is provided to accommodate encryption algorithms that have length boundary requirements and to ensure that the authentication data field falls on a 32-bit boundary. Although not explicitly shown in Figure 3-3, the initialization vector (IV) required by the DES-CBC encryption algorithm is placed immediately before the encrypted payload [6]. Therefore, assuming MD5-96 authentication, 2 bytes of padding, an 8-byte IV, and including the additional outer IP header, an IPSec packet tunneled using ESP will transmit 52 bytes more than a standard IP packet delivering the same payload Security Parameters Index Sequence Number Payload Padding (0 255 bits) Pad Length Authentication Data Figure 3-3. ESP extension header. Next Header Of course, the packet sizes just mentioned do not include the overhead incurred by the Phase 1 or Phase 2 exchanges. The Phase 1 exchange occurs once when the tunnel is initiated, so its cost is negligible when amortized over the tunnel s lifetime. The frequency of Phase 2 exchanges is under administrative control and, thus, can be tailored to the desired security policy and available network capacity. Keys can be updated at intervals on the order of minutes, expending network capacity to benefit security, or keys 13

19 Chapter 3 Alternatives for Securing SNMP can be updated at intervals on the order days, loosening security to benefit network capacity Agent Overhead Imposed by IPSec The IPSec solution has the advantage of cleanly separating security processing from SNMP processing. That is, an SNMP agent would typically not be burdened with computationally expensive security processing. Accessing an SNMP agent would be hindered only if the agent is accessed via an SA that ends at the machine hosting the agent. If an agent s host machine is not IPSec enabled or if an agent s host machine is IPSec enabled, but the agent is accessed via an unsecured channel then accessing that agent would not be hindered by security processing Ease of Use With IPSec, security features are employed without directly involving application users, removing what is often the weakest point in a security system users having to remember passwords. Since SNMP operations should be invoked only by network administrators who should be well versed in user-level security policy, ease of use should not be a critical concern. However, if other applications need security protection, then ease of use would be a legitimate concern. In that case, the IPSec solution could be leveraged to great advantage Ease of Administration Key management and updating is automatically handled by the IKE protocols working within IPSec, relieving network administrators of these tasks. In large networks without this automation, these tasks can become overly burdensome. Automating key updates ensures that keys are frequently changed, greatly enhancing the overall security of the system. Thus, ease of administration is a strong, positive attribute of the SNMPv2c-over- IPSec solution. 3.3 Using SNMPv3 SNMPv3 is significantly more complex than either SNMPv1 or SNMPv2c, so a brief overview of the enhancements incorporated into SMNPv3 is provided here Overview of SNMPv3 The primary purpose for developing SNMPv3 was to address a serious shortcoming found in earlier versions a lack of strong security features. The group of enhancements introduced by SNMPv3 can be partitioned into three categories. A new architectural framework that imposes a structure on SNMPv3 entities that effectively promotes extensibility and streamlines future development. New security features that ensure message authenticity, integrity and confidentiality, and that provide fine-grained control over access to SNMP capabilities. 14

20 Chapter 3 Alternatives for Securing SNMP New administrative capabilities that enable remote configuration of the above security features. Of these three categories, the security capabilities and their associated costs are most relevant to this analysis. However, the other categories of enhancements do provide reasons to adopt SNMPv3 even if the security features are not always needed. For example, SNMPv3 incorporates a flexible mechanism for remotely configuring user access to SNMP capabilities, an attribute that could be useful in many situations. Despite the many changes incorporated into SNMPv3, an SNMPv3 message still carries an SNMPv2 PDU within it, meaning that SNMPv3 messages invoke the same operations as SNMPv2 messages, only in a secure fashion. The new security capabilities can be categorized into two areas: cryptographic features and access control features Cryptographic Features of SNMPv3 SNMPv3 employs The User-based Security Model (USM) [19] to provide cryptographic services. The USM currently uses either MD5 or SHA keyed message digests to ensure message authenticity and integrity, and DES-CBC encryption to ensure message privacy. These features are used to provide three distinct levels of security: no authentication with no privacy (noauthnopriv), authentication with no privacy (authnopriv), and authentication with privacy (authpriv). The USM provides for remotely configuring users and their keys by using SNMPv3 operations to manipulate objects in the USM Management Information Base (MIB). Earlier versions of SNMP provide no support for encryption. In fact, SNMPv1 and SNMPv2c both use a community string that effectively functions as a user password. Furthermore, the community string is transmitted as readable ASCII text. The obvious security risk posed by this scheme has compelled many vendors and network administrators to disable SNMP Set operations, effectively reducing SNMPv1 and SNMPv2c to simple network monitoring, versus management, systems [20] Access Control Features of SNMPv3 SNMPv3 employs the View-based Access Control Model (VACM) [21] to establish user access privileges. When making access control decisions, SNMPv3 cleanly and separately considers the user originating the message, the level of security applied to the message, the MIB view addressed by the message, and the type of operation requested by the message. These features provide network managers with very fine-grained control over access to SNMP capabilities. Furthermore, these features can be configured remotely by setting the appropriate objects in the VACM MIB. In contrast to SNMPv3, both SNMPv1 and SNMPv2c use an access control scheme that simply maps the user-supplied community string onto a MIB view. This method effectively bundles all access control considerations that are separately addressed by SNMPv3 into a single attribute the community string [22]. Clearly, the access control 15

21 Chapter 3 Alternatives for Securing SNMP features provided by SNMPv3 are far more secure and far more powerful than are those of SNMPv1 and SNMPv Characteristics of Using SNMPv3 Since both encryption and authentication services are needed to meet the aforementioned objectives, the following analysis assumes that SNMPv3 operations use the authpriv security level Scope of SNMPv3 s Security Features SNMPv3 implements security features at the application level, ensuring that the communication channel is truly protected from end to end. That is, unencrypted application data never leaves the application s memory address space. However, these security features are not available for use by other applications. DES-CBC is the only encryption standard currently described in the SNMPv3 documents, although other symmetrical encryption algorithms could be added in the future Network Overhead Imposed by Using SNMPv3 Implementing SNMPv3 s new security features requires a new SNMPv3 message format. The new message format is shown in Figure 3-4, including the ASN.1 names for each field in the message [23]. The new message format is considerably longer than the SNMPv2c message format. Again, for the same reasons as previously stated, the overall message length cannot be stated definitively. msgversion msgid msgmaxsize msgflags MsgSecurityModel MsgAuthoritativeEngineID MsgAuthoritativeEngineBoots MsgAuthoritativeEngineTime msgusername msgauthenticationparameters msgprivacyparameters contextengineid contextname PDU Figure 3-4. SNMPv3 message format. Another factor complicates this analysis of SNMPv3 network overhead. SNMPv3 uses the concept of timeliness as a scheme to thwart replay attacks. Briefly, one end of an 16

22 Chapter 3 Alternatives for Securing SNMP SNMPv3 exchange must be roughly aware of the other s measure of the current time, represented by its timeliness parameters. A discovery exchange often must precede an actual SNMP operation to allow one entity to learn the other s timeliness parameters. Clearly, SNMPv3 s longer header and its discovery procedure means that SNMPv3 will consume more link capacity than SNMPv2c, but exactly how much more it will consume depends upon several case-specific factors. For example, the SNMP management application suite may remember timeliness parameters between successive queries to the same target entity. If so, then the cost of a single discovery exchange can be amortized over several queries. If not, then every query must be preceded by a discovery exchange, a terribly inefficient scenario. These factors will be further explored by empirical testing, as discussed in Chapter Agent Overhead Imposed by Using SNMPv3 Embedding the aforementioned security features in the SNMP agent places additional computational load on the agent, possibly degrading the performance of devices with marginal capabilities. Again, quantifying these additional loads depends on many caseby-case dependencies that will be explored empirically Ease of Use SNMPv3 security services are invoked directly by application users, meaning that users have to remember passwords. This should not be problematic since SNMPv3 users should be security-conscious, administrative personnel. Sometimes, a management application suite will provide a facility for users to define default values for often used parameters, such as passwords. Such a facility relieves users from having to remember their passwords, but it also presents a potential security problem; these default values are often stored in a plain text file that must be carefully protected Ease of Administration There is no automated key update functionality incorporated into the SNMPv3 specifications. Network administrators must ensure that users change their passwords (keys) at appropriate intervals, or else do so for them. Keeping passwords updated should not be too troublesome, as SNMPv3 users should be security-conscious members of the network management staff. However, manually managing key updates in large networks could be daunting. 3.4 Comparing SNMPv2c-Over-IPSec and SNMPv3 While both SNMPv2c-over-IPSec and SNMPv3 can form the basis for implementing secure SNMP network management in low-bandwidth environments, there are fundamental qualitative differences between the two approaches. The SNMPv2c-over-IPSec solution implements security at the network layer, providing general security services for all applications as well as for SNMP. However, the security provided is not truly end-to-end. In contrast, the SNMPv3 solution implements security 17

23 Chapter 3 Alternatives for Securing SNMP at the application layer, providing a true end-to-end secure channel between communicating processes, but the security provided is not available to other applications. The SNMPv2c-over-IPSec solution appears easier to use and easier to administer than the SNMPv3 solution. Conversely, the SNMPv3 solution provides remotely configurable, fine-grained user management capabilities that are not available in SNMPv2c. These observations are consistent with the original principles that guided the IPSec and SNMPv3 design efforts. The IPSec design was intended to provide a general security solution that could be readily implemented in the global Internet. The SNMPv3 design was intended to address particular problems known to exist within a specific application s domain. Although compression is not part of SNMP or IPSec, compression may be an integral component of a network containing low bandwidth links, so considering compression is appropriate here. It is well known that compression must be applied before encryption. Since SNMPv3 applies encryption without compression at the application layer, using SNMPv3 could be inappropriate for networks requiring compression. The IETF s Network Working Group is developing a compression protocol for use by IPSec, the IP Payload Compression Protocol (IPComp) [24]. IPComp can compress IP packets prior to their being encrypted, and IPComp associations can be negotiated by the Internet Key Exchange Protocol. Therefore, IPComp could be integrated into the SNMPv2c-over- IPSec solution for networks that require compression. For any network of significant size, it would be unreasonable to insist that all SNMPenabled network devices be SNMPv3 compliant. Legacy devices remain in service, so the need to support older, insecure versions of SNMP is likely to persist. Deploying IPSec would be the best way to incorporate security into a network that needs to support older, insecure versions of SNMP. Conversely, some situations are better suited for SNMPv3. Consider a security gateway that separates a hidden LAN from a public internetwork, as shown in Figure 3-2. It is reasonable to expect that the security gateway s public interface will be attacked. Now, suppose that access to the security gateway s SNMP capabilities needs to be remotely reconfigured on a frequent basis. SNMPv3 s remotely configurable, fine-grained access control features would be well suited for the task, as would its true end-to-end security. Recognizing that both solutions have complementary strengths gives rise to a third possibility having SNMPv3 and SNMPv2c-over-IPSec coexist. Clearly, an IPSecenabled internetwork could use the SNMPv2c-over-IPSec solution for most routine network management tasks, while reserving the SNMPv3 solution for situations that require the unique advantages provided by SNMPv3. SNMP users could simply and dynamically choose the SNMP version, and the level of security in the case of SNMPv3, most appropriate for the task at hand. 18

24 Chapter 3 Alternatives for Securing SNMP 3.5 Summary and Conclusions The main characteristics of the SNMPv2c-over-IPSec solution are as follows. Security services are made available to all higher layer protocols that use IP. Strict end-to-end security is, arguably, not available. Ease of use security services are functionally invisible to users. Ease of administration IKE automatically handles key exchanges and updates. No provisions for remotely configuring user access to SNMP capabilities. It might be possible to incorporate effective compression. The main characteristics of the SNMPv3 solution are as follows. Does not provide security services to other applications. Provides true end-to-end security. Users directly invoke security features; they must remember their passwords. Administrators must diligently manage key (password) updates. Provides fine-grained, remote configuration of user access to SNMP capabilities. It is difficult or impossible to incorporate effective compression. By incorporating both solutions into the network management scheme, the individual strengths of each solution can be simultaneously realized. The SNMPv2c-over-IPSec solution could be deployed for most network management operations, with the SNMPv3 solution used for mission-critical tasks. The SNMP user can choose the solution best suited for the particular task at hand. The preceding analysis gives qualitative criteria that network administrators can consider when choosing a method for securing SNMP. However, the question of efficiency with respect to consumption of network capacity remains. Answering this question is the subject of Chapter 4. 19

25 Chapter 4 Evaluating Alternatives for Secure SNMP Chapter 4 Evaluating Alternatives for Secure SNMP 4.1 Introduction Chapter 3 explores the characteristics of two methods for incorporating authentication and encryption services into SNMP-based network management: (i) using SNMPv3, and (ii) using SNMPv2c over IPSec. This chapter seeks answers to the following questions. How much network capacity is consumed by a secure SNMP operation? How much processing time is consumed by a secure SNMP operation? How much network capacity is consumed by an SNMPv3 discovery exchange? How much network capacity is consumed by an IPSec security association negotiation? The remainder of this chapter describes the testbed network used to conduct experiments, the experiments designed to explore these questions, and the results and conclusions provided by running the experiments. 4.2 The Testbed Network The 10-Mbps Ethernet testbed network was constructed as two subnets connected by an exchange network, as shown in Figure 4-1. Figure 4-1. Testbed network. Hosts west and east represent IPSec-based security gateways protecting the subnets containing hosts sunset and sunrise, respectively. Host observer is used to capture packets traversing the exchange network connecting gateways west and east. 20

26 Chapter 4 Evaluating Alternatives for Secure SNMP Hardware Used in the Testbed Network All computers in the testbed are Intel-based personal computers with modest performance. They use Pentium and Pentium Pro processors with clock frequencies ranging from 120 MHz to 233 MHz. Each computer has between 32 MB and 64 MB of main memory Software Used in the Testbed Network All machines in the testbed run the Red Hat Linux operating system, version 6.1. Gateways west and east are configured to provide simple routing services between the networks they protect. The two security gateways, east and west, run Linux FreeS/WAN, version 1.4 [25], a freeware implementation of IPSec. The FreeS/WAN software is configured to establish both host-to-host and subnet-to-subnet tunnel-mode security associations between gateways east and west. All of the IPSec experiments described in this paper use the Encapsulated Security Payload (ESP) protocol to provide HMAC-MD5-96 authentication and triple-des encryption (the developers of FreeS/WAN refuse to support single DES because of its weakness). Note that the IPSec Security Associations between gateways east and west can brought up and down from the command line, facilitating testing with and without the use of IPSec. All computers in the testbed run NET-SNMP (a.k.a., UCD-SNMP), version 4.1 [26]. The NET-SNMP agent is multilingual, i.e., it supports several versions of SNMP. Specifically, the NET-SNMP agent supports SNMPv1, SNMPv2c, and SNMPv3. Additionally, the NET-SNMP software package provides several simple SNMP management applications, all of which support the previously mentioned versions of SNMP that apply to them. The NET-SNMP software suite provides authentication services, but does not provide encryption services on its own. However, it does easily link with the cryptographic libraries provided by OpenSSL [27], an open-source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TSL) protocols. Therefore, all of the computers on the testbed run OpenSSL to provide cryptographic services for use by NET-SNMP. All of the SNMPv3 tests described in this paper use HMAC-MD5-96 for authentication and/or (single) DES for encryption, depending on the SNMPv3 security level used. The host observer is equipped with Ethereal [28], a protocol analyzer used to capture and examine the traffic traversing the exchange network. Ethereal is particularly well suited for examining SNMP traffic because it easily links with the NET-SNMP libraries, enabling Ethereal to convert the numerical object identifiers carried by SNMP messages into human-readable form. 21

27 Chapter 4 Evaluating Alternatives for Secure SNMP 4.3 The Experiments and Their Results Several experiments were run, each designed to answer one of the questions cited previously. Although the primary purpose was to compare two authenticated, encrypted approaches to secure SNMP SNMPv3 using the authpriv security level, and SNMPv2c using authentication and encryption provided by IPSec several other scenarios were included to provide perspective. The following subsections explain the experiment designed and executed to address each question and then documents the results of the experiment How Much Network Capacity is Consumed by a Secure SNMP Operation? The network capacity consumed by a secure SNMP operation was examined by querying the SNMP agent running on sunset via an SNMP management application invoked on sunrise. The IPSec trials used a subnet-to-subnet tunnel-mode security association between gateways east and west. The IP packets generated by the SNMP operation were captured by the Ethereal application running on host observer. Table 4-1. IP Packet Sizes in Bytes for 1-Variable SNMP-Get Operation SNMP Version/Security Scheme Get Response Total v2c v2c over IPSec v3 noauthnopriv v3 authnopriv v3 authpriv v3 noauthnopriv over IPSec v3 authnopriv over IPSec v3 authpriv over IPSec The first experiment used an SNMP-Get operation to retrieve the syscontact variable from the MIB-II system group. Table 4-1 shows the sizes (in bytes) of IP packets carrying SNMP-Get messages, the sizes of the associated SNMP-Response messages, and the total size of the Get/Response exchange for several SNMP versions using various security schemes. Note that these results do not include overhead involved with SNMPv3 s discovery process or overhead involved with establishing or maintaining IPSec s security associations. These additional sources of overhead are examined in separate experiments. The second experiment was almost exactly like the first except that it used an SNMP-Get operation to retrieve seven variables from the MIB-II system group. Comparing the results of the second experiment to those of the first illustrates how the size of the IP 22

28 Chapter 4 Evaluating Alternatives for Secure SNMP packet s payload affects message efficiency. Table 4-2 shows the results of this second experiment in a format identical to that of Table 4-1. Table 4-2. IP Packet Sizes in Bytes for 7-Variable SNMP-Get Operation SNMP Version/Security Scheme Get Response Total v2c v2c over IPSec v3 noauthnopriv v3 authnopriv v3 authpriv v3 noauthnopriv over IPSec v3 authnopriv over IPSec v3 authpriv over IPSec It is clear from these tables that IPSec using ESP with HMAC-MD5-96 authentication and triple-des encryption typically adds about 57 bytes of overhead over that of a standard IP packet carrying the same payload. Similarly, SNMPv3 using HMAC-MD5-96 authentication and DES encryption typically adds about 89 bytes of overhead over that of a similar SNMPv2c packet. Note that these overhead results are stated in approximate terms because of variations in header field padding, inefficiencies imposed by the Basic Encoding Rules used to encode SNMP application data, and other reasons discussed in Chapter 3. Table 4-3. Ratios of IP Packet Sizes with Respect to SNMPv2c Over IPSec SNMP Version/Security Scheme 1-Variable Ratio 7-Variable Ratio v2c v2c over IPSec v3 noauthnopriv v3 authnopriv v3 authpriv v3 noauthnopriv over IPSec v3 authnopriv over IPSec v3 authpriv over IPSec To better indicate how these scenarios compare, Table 4-3 shows the ratio of the total number of bytes transmitted for each scenario to the number of bytes transmitted using the SNMPv2c-over-IPSec approach. Table 4-3 shows that SNMPv3 using the authpriv security level consumes as much as 24 percent more network capacity than SNMPv2c over IPSec. This percentage decreases as the size of the application-layer payload increases. 23

29 Chapter 4 Evaluating Alternatives for Secure SNMP How Much Processing Time is Consumed by a Secure SNMP Operation? The processing time consumed by a secure SNMP operation was examined by querying the SNMP agent running on gateway east via a test script invoked on gateway west. The test script ran twenty invocations of an SNMP-Get operation, retrieving the syscontact variable from the MIB-II system group. The IP packets generated by the SNMP-Get operation were captured by the Ethereal application running on host observer. There was no additional application-level traffic on the network. The IPSec trials in this experiment used a host-to-host tunnel-mode security association between gateways east and west, forcing the tunnel endpoint, east, to perform both IPSec processing and SNMP processing. A subnet-to-subnet tunnel-mode security association is used when the tunnel endpoints are distinct from the packet s source and ultimate destination. Note that this experiment was not ideal for comparing the computational overheads imposed by SNMPv3 and by IPSec. The results of this experiment depend on the performance capabilities of gateway east (200 MHz Pentium Pro, 48 MB memory) and the efficiency of the NET-SNMP and FreeS/WAN IPSec implementations. Further, NET-SNMP uses single-des encryption, but FreeS/WAN IPSec uses triple-des encryption. DES processing is computationally intensive, and triple-des is three times more computationally intensive than DES. Nevertheless, the results from this experiment can be used to gain insight and to draw conclusions in general terms. A processing time interval is defined as the time between Ethereal s capture of an SNMP- Get message and Ethereal s capture of the corresponding SNMP-Response message. Table 4-4 shows the mean processing time interval and the standard deviation computed for each approach. Table 4-4. Mean Processing Times for Secured SNMP Operations SNMP Version / Security Scheme Mean Time Standard (µs) Deviation v2c v3 noauthnopriv v3 authnopriv v3 authpriv v2c over IPSec v3 noauthnopriv over IPSec v3 authnopriv over IPSec v3 authpriv over IPSec

30 Chapter 4 Evaluating Alternatives for Secure SNMP The data shown in Table 4-4 depend on hardware performance. To provide a comparison that is independent of hardware performance, Table 5 shows the ratio of mean processing time for each scenario to that for the SNMPv2c-over-IPSec scenario. Table 4-5. Ratios of Mean Processing Time with Respect to SNMPv2c Over IPSec SNMP Version/Security Scheme Ratio v2c 0.40 v3 noauthnopriv 0.68 v3 authnopriv 0.76 v3 authpriv 0.89 v2c over IPSec 1.00 v3 noauthnopriv over IPSec 1.36 v3 authnopriv over IPSec 1.49 v3 authpriv over IPSec 1.87 Two general conclusions can be drawn from the data shown in Table 4-5. The computational overhead imposed by SNMPv3 using the authpriv security level and the computational overhead imposed SNMPv2c over IPSec are similar. Adding authentication and encryption to an SNMPv2c agent, whether by upgrading the agent to SNMPv3 or by installing IPSec on the device hosting the agent, doubles the processing overhead imposed by SNMP operations on that device. These conclusions show that the IPSec solution may be advantageous in situations where SNMP-enabled devices have marginal performance. The IPSec solution can protect network devices without burdening them by using a security gateway distinct from the devices needing protection How Much Capacity is Consumed by an SNMPv3 Discovery Exchange? To investigate the capacity consumed by an SNMPv3 discovery exchange, an SNMPv3- Get operation using the AuthPriv security level was invoked on host sunrise, querying the SNMPv3 agent running on host sunset. The ensuing discovery exchange was captured by the Ethereal application running on host observer. Table 4-6 shows the IP packet size (in bytes) for the discovery s SNMP-Get message, its corresponding SNMP-Report message, and the total bytes transmitted for the entire discovery exchange. The results shown in Table 4-6 confirm that an SNMPv3 discovery exchange is similar in size and function to a typical SNMP Get/Response exchange. Clearly, the overall overhead caused by SNMPv3 s discovery process depends heavily upon the frequency of 25

31 Chapter 4 Evaluating Alternatives for Secure SNMP discovery exchanges. Unfortunately, the SNMPv3-Get application provided by NET- SNMP initiates a discovery exchange for every invocation, effectively doubling the cost of SNMPv3-Get operations. Perhaps a more sophisticated SNMP management suite would remember the most recent timeliness parameters retrieved from each SNMPv3 entity with which it communicates, thus reducing the need for discovery exchanges. Table 4-6. IP Packet Sizes in Bytes for SNMPv3 Discovery Exchange SNMP Version Request Report Total SNMPv3 authpriv SNMPv3 authpriv over IPSec How Much Network Capacity is Consumed by an IPSec SA Negotiation? The experiment to determine the capacity used by IPSec s security association negotiation used the Ethereal application on host observer to capture all packets exchanged while a tunnel-mode IPSec security association between gateways east and west was established. For this experiment, the FreeS/WAN IPSec software was configured to update the security association between gateways east and west roughly every minute. Several of these updates were also captured by the Ethereal application running on host observer. Table 4-7 shows the IP packet sizes (in bytes) for all nine packets captured while the initial tunnel-mode security association was established. Table 4-7. Packets and Lengths in Bytes Required to Establish an IPSec Tunnel Packet # Mode Length 1 main main main main main 96 6 main 96 7 quick quick quick 80 The first six packets, totaling 920 bytes, comprised the Phase 1 negotiations using main mode. The remaining three packets, totaling 744 bytes, comprised the Phase 2 negotiations using quick mode. Therefore, establishing the initial IPSec tunnel between east and west using packets 1 through 6 required transmitting 1,664 bytes. Subsequent security association updates used quick mode negotiations identical to packets 7, 8, and 9, again totaling 744 bytes. 26

32 Chapter 4 Evaluating Alternatives for Secure SNMP 4.4 Summary and Conclusions The following general conclusions comparing the SNMPv3 solution and the SNMPv2cover-IPSec solution can be drawn from the experimental results. The SNMPv3 solution consumes as much as 24 percent more network capacity than the SNMPv2c-over-IPSec solution. However, the advantage shown by the SNMPv2c-over- IPSec solution deteriorates as the size of the application-layer payload increases. Much of the inefficiency of the SNMPv3 solution is due to the Basic Encoding Rules used to encode SNMP application data. The SNMPv2c-over-IPSec solution and the SNMPv3 solution impose similar amounts of computational overhead on network devices. Adding authentication and encryption services to an SNMPv2c-enabled device, whether by upgrading the device to SNMPv3 or by installing IPSec on the device, effectively doubles the processing overhead imposed by SNMP operations targeting that device. The SNMPv2c-over-IPSec solution can ease this problem by separating security processing and SNMP processing onto different devices. For most SNMP operations using the SNMPv2c-over-IPSec solution, the security gateway is distinct from the network device hosting the SNMP agent. Conversely, the SNMPv3 solution integrates security processing and SNMP processing into one application-layer process running on a single network device. An SNMPv3 discovery exchange consumes about 240 bytes of network capacity. The frequency of discovery exchanges depends on the sophistication of the SNMP application being used. If the SNMP application makes no provisions for storing the timeliness parameters it learns from one transaction to use with the next, then the discovery process is repeated needlessly, seriously degrading the efficiency with which SNMPv3 operations consume network capacity. Establishing a tunnel-mode IPSec security association consumes about 1,664 bytes of network capacity distributed across six IP packets. Subsequent security association updates consume about 744 bytes of network capacity distributed across three IP packets. A well-conceived IPSec software package should permit network administrators to configure the frequency of security association updates, allowing administrators to choose an update policy that conforms to their specific concerns. Frequent updates benefit security at the expense of network capacity, while infrequent updates undermine security to reduce consumption of network capacity. The quantitative analysis provided here formed the basis for deciding that SNMPv2cover-IPSec should be used in the network management system being developed through this research. The basic framework requires that an IPSec security gateway be used to provide backbone access for every network accessing the backbone. That is, all traffic traversing the backbone will be secured via IPSec. Management traffic on local subnets can be secured if necessary, but it is expected that this need will be rare. 27

33 Chapter 5 Alternatives for Network Management Chapter 5 Alternatives for Network Management 5.1 Introduction This chapter provides an overview of contemporary network management paradigms and the technologies that implement them. It begins with a simple taxonomy for classifying these paradigms and then goes on to provide an overview of those technologies that were considered for implementing the network management system of this research. The chapter concludes with a detailed discussion of the network management technology chosen to implement the network management system developed for this research. 5.2 Alternative Network Management Paradigms A simple taxonomy for classifying network management paradigms, introduced by Martin-Flatin et al. in [29] and extended in [30], will be used in the following discussion. This simple taxonomy classifies network management paradigms as being either (i) centralized, (ii) weakly-distributed hierarchical, (iii) strongly-distributed hierarchical, or (iv) cooperative. This section defines each of these paradigms and identifies contemporary technologies that exemplify them Centralized Network Management A centralized network management system is characterized by a single network management station polling all the manageable devices in the network. The devices under management host simple agents capable only of collecting low-level data and making it available to the central manager. The centralized manager is charged with retrieving low-level data from agents and presenting that data in a form useful to network administrators. Figure 5-1 depicts a centralized network management system. Early versions of SNMP were targeted for deployment in centralized management systems. Central Manager Agent Agent Agent Figure 5-1. A centralized network management system. Centralized systems work well in small networks with adequate capacity, but begin to suffer when the network grows large. For a low-bandwidth environment, a centralized 28

34 Chapter 5 Alternatives for Network Management network management scheme is unsuitable because the central manager will excessively consume backbone network capacity with routine polling traffic. Preservation of backbone network capacity is a key goal for the network management system being developed Weakly-Distributed Network Management A weakly-distributed management system is characterized by the presence of mid-level management entities that assume both the agent role and the manager role. The management framework is structured as a vertical hierarchy where mid-level managers communicate only with the top-level manger; mid-level managers do not communicate among themselves. Typically, the number of mid-level management entities is much smaller than the number of agents in the system. Figure 5-2 illustrates a weaklydistributed management system. Top-Level Manager Mid-Level Manager Mid-Level Manager Agent Agent Agent Agent Agent Agent Agent Agent Figure 5-2. A weakly-distributed network management system. SNMP using the Remote Monitoring (RMON) MIB is an example of a weaklydistributed network management system. Note that some network management technologies can implement both weakly-distributed and strongly-distributed paradigms, depending on the functional complexity given to mid-level managers. Mobile code is one technology that falls into this category. Mobile code is discussed in the next section The Remote Monitoring (RMON) MIB The Remote Monitoring MIB [31] extends the usefulness of SNMP by providing network administrators with the ability to collect subnetwork-level statistics versus device-level statistics. SNMP provides for collecting only device-level statistics such as the number of frames received on a particular interface. RMON provides for monitoring subnetwork-level information such as subnetwork utilization and error rate. Furthermore, these data are available in matrix form, indexed by Medium Access Control (MAC) address, enabling network administrators to observe these data with respect to any arbitrary pair of devices communicating on the subnetwork. The RMON specification 29

35 Chapter 5 Alternatives for Network Management also provides for generating alarms to notify a central manager in the event that a configurable alarm threshold is violated. The RMON2 [32] specifications were published in RMON2 provides for monitoring traffic with respect to network-layer protocols and above. This means that network administrators can now observe traffic statistics between communicating endpoints identified by IP addresses or application protocol, even if one endpoint is on a remote network. For example, a network administrator can now observe traffic statistics between the two endpoints of an , HyperText Transfer Protocol (HTTP), or File Transfer Protocol (FTP) session [33]. While RMON certainly adds significant value to SNMP-based network management, it does go far enough to justify using it as the foundation for the network management system being developed. Undoubtedly, RMON can help preserve backbone network capacity in a low-bandwidth environment by making available high-level data, but its potential is limited because the data it provides are statically defined. That is, a network administrator cannot dynamically program a RMON probe to collect arbitrary variables of interest. RMON is not flexible enough to completely overcome the problems being addressed in this research Strongly-Distributed Management Strongly-distributed systems are characterized by mid-level managers, fulfilling both the agent role and the manager role, that can communicate among themselves as well as with top-level managers. Figure 5-3 illustrates a typical strongly-distributed network management system. Top-Level Manager Mid-Level Manager Mid-Level Manager Mid-Level Manager Agent Agent Agent Agent Agent Agent Agent Agent Figure 5-3. A strongly-distributed network management system. Examples of network management systems that can be considered strongly-distributed are Web-Based Enterprise Management (WBEM), Java Management Extensions (JMX), and mobile code. 30

36 Chapter 5 Alternatives for Network Management Web-Based Enterprise Management (WBEM) Web-Based Enterprise Management (WBEM) [34] is a new approach to managing networks being promoted by an industrial consortium led by Microsoft, Cisco, Compaq, and Intel. WBEM promises to provide an open standard that reduces network management costs and improves interoperability by leveraging web-based technologies such as HTML and HTTP. Much of today s WAN management is conducted on proprietary, network management platforms that are very expensive to purchase, maintain, and extend. WBEM sidesteps the need for a proprietary platform by making management information available from ubiquitous web browsers. The WBEM system defines the following components. HyperMedia Management Schema (HMMS) provides a means for representing management data in a management protocol-independent format. HyperMedia Management Protocol (HMMP) provides for transmitting HMMS content over HTTP. HyperMedia Object Manager (HMOM) defines how management applications can access management objects in a distributed environment. With respect to the commercial marketplace, the jury is still out on WBEM because WBEM remains specific to Microsoft s operating systems [35] and there is skepticism regarding Microsoft s participation in developing an open standard [36], since Microsoft has traditionally been aggressive in defending its proprietary assets. Despite this concern, the commercial future of WBEM is promising due to the backing it enjoys from other powerful players in the information technology industry. With respect to the goals of this research, WBEM is not suitable because WBEM is not yet standardized, and WBEM does not attempt to address bandwidth conservation, nor is there an obvious way to apply WBEM in a way that preserves network capacity Java Management Extensions (JMX) The Java Management Extensions (JMX) [37] also targets leveraging web-based technologies to supplant the current platform-centric method of managing wide-area networks. The JMX architecture is composed of the following components [38]. JMX Manageable Resource can be a network device, a running process, or any other object. Non-Java objects (i.e., a proprietary SNMP agent) can be instrumented for JMX management by encapsulating the object in a Javabased wrapper. JMX Agent a management entity comprised of an MBean (Management Bean) Server and one or more Protocol Adaptors. The MBean Server exports the interface for invoking management operations on the Agent. A Protocol Adaptor provides for communications with the Agent using a variety of protocols (e.g., SNMP). 31

37 Chapter 5 Alternatives for Network Management JMX Manager provides for building distributed network management frameworks that interface with arbitrary numbers of JMX Agents. JMX provides for integrating otherwise incompatible management technologies into a single easier-to-use, less-expensive-to-implement, network management solution. Like WBEM, JMX is not yet an accepted standard, and it does not target preserving network capacity as a design goal, nor is it clear how one could use it to achieve such a goal. Therefore, JMX was not considered for use in the network management solution being developed in this research Mobile Code Mobile code refers to the ability to dynamically locate executable code somewhere in the network prior to invoking it. With respect to network management, this means that network management tasks can be implemented as mobile code and positioned close to the devices being operated on before being invoked. Goldszmidt and Yemini originated what is perhaps the best-known network management paradigm exploiting code mobility, the Management by Delegation (MbD) model [39, 40]. The MbD model suggests that centralized schemes fail because of the micromanagement problem created when a centralized manager is required to micro-manage inflexible, statically-defined, dumb agents. The micro-management problem can be solved by empowering agents with complex network management functionality transferred to them via mobile code. In 1999, the Distributed Network Management Working Group (DISMAN) of the Internet Engineering Task Force (IETF) defined the DISMAN Script MIB [41]. The DISMAN Script MIB is a standard SNMP MIB that includes an encapsulated run-time engine. The DISMAN Script MIB enables authorized users to install, invoke, suspend, resume, and abort management scripts written especially for the DISMAN Script MIB. It represents a powerful realization of the Management-by-Delegation (MbD) model. Clearly, the MbD approach, implemented by the DISMAN Script MIB, is a serious contender for use in the network management system under development. Custom network monitoring scripts could be transferred to strategically located DISMAN Script MIB agents, and those agents could monitor their local networks on behalf of the toplevel manger, returning their compiled data to the top-level manager in a way that makes intelligent use of the backbone network s capacity Cooperative Network Management Cooperative management systems are characterized by having nearly all devices capable of fulfilling the manager role as well as the agent role. Figure 5-4 illustrates a cooperative network management system. Note that the notion of a vertical hierarchy is replaced by a flattened, horizontal structure. 32

38 Chapter 5 Alternatives for Network Management Cooperative network management systems are the subjects of ongoing research. They are not ready to integrate into existing systems, so they are not suitable for use in the system being developed for this research. Nevertheless, this topic is briefly covered here for completeness. There are two fundamental threads in the research: (i) those based on mobile agents, otherwise known as intelligent agents or mobile processes, and (ii) those based on active networks. Agent /Manager Agent /Manager Agent /Manager Agent/Manager Agent/Manager Agent Agent /Manager Agent /Manager Agent Figure 5-4. A cooperative network management system. A cooperative management system can be built using cooperating mobile agents. Mobile agents differ from mobile code in that mobile agents transfer their state as well as their code. For example, suppose a mobile agent executing on node X has concluded that it needs to travel to node Y; the mobile agent can save its current state, move to node Y, and then resume execution. Mobile code, on the other hand, is transferred to a location where it is invoked and run to completion; mobile code cannot transfer itself at its own discretion to an arbitrary next destination. Readers interested in network management using mobile agents are directed to [42]. Cooperative network management can also be realized through active networks. Active networks are built using active network nodes that are capable of performing custom computation on the messages passing through them [43]. Programs are injected into an active network to invoke tasks on active nodes. For example, one could imagine injecting network management programs into an active network to accomplish monitoring tasks on active routers. Readers interested in active networks are directed to [43] and [44]. 5.3 Choosing a Network Management Paradigm The previous discussion provided an overview of some contemporary network management technologies that were considered for use in this research. The following summarizes that discussion and draws a conclusion regarding which technology should 33

39 Chapter 5 Alternatives for Network Management be used for developing a network management solution for a low-bandwidth environment. The centralized management scheme was discounted because it recklessly consumes the limited capacity available on the backbone network. The RMON technology is a valuable addition to SNMP, but it is not flexible enough to form the foundation for the network management system under development. Two web-based technologies were considered: WBEM and JMX. These two technologies are competing head-to-head for acceptance as the de facto standard for nextgeneration network management technologies. At this time, the outcome is not clear, for hybrid solutions are possible [45]. While these technologies are intriguing, they are not widely-accepted open standards, and they do not address the main goal of this research, minimizing the degree to which network management traffic consumes backbone network capacity. Mobile agents or active networks could be used to develop a solution, but these systems are far from being standardized, so they fail to meet the criterion that requires the solution to be a standards-based technology that can be efficiently incorporated into existing SNMP-based network management systems. The mobile code solution, based on the MbD model and implemented via the DISMAN Script MIB, was shown to be a strong contender for use. This was not coincidental. The IETF developed the DISMAN Script MIB because they recognized the value of an MbD solution that could easily integrate with existing SNMP-based network management systems. Therefore, the network management system being developed for this research is based on transferring network monitoring scripts that make intelligent use of backbone capacity to mid-level managers built with the DISMAN Script MIB. The next section provides a more detailed discussion of the DISMAN Script MIB. 5.4 The IETF DISMAN Script MIB The DISMAN Script MIB [41] is an SNMP MIB that facilitates the execution of network management scripts on remote agents. The DISMAN Script MIB provides the following capabilities. Transferring management scripts Invoking, suspending, resuming, and terminating management scripts Transferring arguments to management scripts Monitoring and controlling running management scripts Retrieving results from management scripts 34

40 Chapter 5 Alternatives for Network Management The DISMAN Script MIB does not impose restrictions on the scripting languages or runtime engines that are employed by a Script MIB implementation. The DISMAN Script MIB is composed of six tables organized into five groups as follows. The Language Group (smlanguagegroup) consists of the smlangtable and the smextsntable. The Script Group (smscriptgroup) contains the smscripttable. The Script Code Group (smcodegroup) contains the smcodetable. The Script Launch Group (smlaunchgroup) contains the smlaunchtable. The Running Script Group (smrungroup) contains the smruntable. The smlangtable is used to indicate which languages are supported by a Script MIB implementation. The smextsntable is used to indicate what language extensions, if any, are supported by a DISMAN Script MIB implementation. The smscripttable is a listing of all the management scripts installed on a DISMAN Script MIB implementation. It provides for (i) downloading or pulling scripts from a specified Universal Resource Locator (URL) via HTTP, (ii) reading, writing, and deleting scripts from local non-volatile storage, (iii) listing permanent scripts, and (iv) reading and editing a script s status. The optional smcodetable provides for transferring or pushing management scripts to a DISMAN Script MIB implementation via SNMP instead of HTTP, and for editing such scripts in place. The smlaunchtable lists all of the launch buttons known to a DISMAN Script MIB implementation. A launch button is a conceptual button that launches a particular script when pressed via an SNMP-Set operation. A launch button associates a particular script with script arguments and defines the scope of permissions that applies to a script during its execution. The smruntable lists all the running or recently-terminated scripts known to a DISMAN Script MIB implementation. It provides for (i) accessing the status of a running script, (ii) suspending, resuming, and aborting running scripts, (iii) accessing results returned by recently-terminated scripts, (iv) controlling the lifetime of a running script, and (v) controlling how long script results are retained in a smruntable. The DISMAN Script MIB differs from other MIBs in that it must be able to discern execute permissions as well as the read, write, and notify permissions required by ordinary MIBs. The DISMAN Script MIB accomplishes this by leveraging the Viewbased Access Control Model (VACM) defined by SNMPv3. Execute permissions are defined by configuring the VACM read/write permissions for appropriate Script MIB table objects. Basically, a script is executed under the run-time permissions associated 35

41 Chapter 5 Alternatives for Network Management with smlaunchowner. It is up to the run-time engine to map smlaunchowner to a runtime profile. See [46] for a detailed discussion of security aspects regarding the DISMAN Script MIB The Jasmin Script MIB Implementation An implementation of the DISMAN Script MIB has been developed and made openly available by a joint effort undertaken by the Technical University of Braunschweig and NEC Europe Ltd. The implementation is called Jasmin, an acronym for the Java-based Script MIB Implementation. The Jasmin Script MIB [47] is designed to run as a sub-agent running behind the NET- SNMP agent. On the front end, it attaches to the NET-SNMP agent as a dynamically loadable module, or via the Agent Extensibility (AgentX) protocol [48]. On the back end, it attaches to a Java-based run-time engine via the Script MIB Extensibility (SMX) Protocol [49]. Jasmin runs under UNIX and UNIX clones (e.g., Linux). It uses a configuration file to map smlaunchowner to an operating system security profile. Under UNIX, an operating system security profile maps to the UNIX user for the running process. Therefore, a Jasmin Script MIB running under UNIX requires that smlaunchowner is a legitimate system user. This requirement must be accounted for by the system under development. Since the Jasmin Script MIB can easily be integrated into the NET-SNMP/Linux environment already being used, the decision to use the Jasmin Script MIB as the basis for the network management system under development was easy to make. The consequence of this decision is that management scripts must be written in Java. (Note that Jasmin has recently added a Tcl-based run-time engine [50].) 5.5 Summary and Conclusions This chapter has reviewed several network management paradigms that were considered for use in the network management system developed for this research. The paradigms considered were: (i) centralized management, (ii) Remote Monitoring MIB, (iii), Web- Based Enterprise Management, (iv) Java Management Extensions, (v) Management by Delegation via the DISMAN Script MIB, and (vi) active networks. Ultimately, Management by Delegation via the Jasmin implementation of the DISMAN Script MIB was chosen to form the basis of the management system under development. With the basic components for the system identified, the design and implementation of the network management system began in earnest. This is the topic of Chapter 6. 36

42 Chapter 6 Designing and Developing the Solution Chapter 6 Designing and Developing the Solution 6.1 Introduction This chapter describes the design of the network management system, the development of the top-level manager and mid-level managers, and the definitions of the communications between the top-level manager and the mid-level manager. 6.2 Overview of the Solution The system developed in this research is based on the Management-by-Delegation model. The system uses a two-level hierarchy where a top-level manager delegates routine polling chores to several mid-level managers dispersed throughout the internetwork, one mid-level manager per network node. Figure 6-1 shows an example of the solution deployed in a small, four-node internetwork. Figure 6-1. A hypothetical low-bandwidth internetwork. The top-level manager is built as a group of cooperating applications, most of which use the Tkined network editor [51] as a front-end. The top-level manager regularly pings 37

43 Chapter 6 Designing and Developing the Solution each of its mid-level managers, using the observed round-trip time to estimate the level of congestion that exists in the backbone network. If the observed round-trip time is below a user-configurable threshold the mid-level manager is instructed to return all of its saved data in the form of an update message to the top-level manager; otherwise, the backbone is assumed to be too congested to warrant transmitting an update. This scheme makes the network management system sensitive to the current utilization of the backbone network. The mid-level manager is built as a network monitoring application that runs on the JASMIN implementation of the IETF DISMAN Script MIB. Each mid-level manager conducts routine polling chores on its local network, processes the collected data, and then returns those results to the top-level manager in a way that makes intelligent use of the limited capacity available on the backbone network. The mid-level manager uses SNMP Traps to immediately report critical information to the top-level manager. Noncritical information is gathered, summarized, saved, and finally returned to the top-level manager whenever the top-level manager instructs the mid-level manger to do so. This scheme relieves the top-level manager of routine polling responsibilities by delegating these responsibilities to distributed mid-level managers. The effect is to push routine polling traffic off of the backbone network onto the edge networks, preserving the limited capacity available on the backbone network without hindering network management effectiveness. The system uses IPSec to secure communications across the backbone network. At a minimum, one gateway-to-gateway IPSec Security Association is established between the top-level manager s network and each of its subordinate mid-level managers networks. Network management traffic on network nodes could be secured using IPSec or SNMPv3, but doing so is not necessary for this research. Network capacity on local networks is assumed to be adequate for whatever security policy is enforced by the local network administrators. In summary, the proposed solution uses SNMPv2c over IPSec for secure network management transactions traversing the backbone network. The network management hierarchy consists of several mid-level managers, one for each network node in the internetwork, all reporting to a single top-level manager. Note that the top-level manager could be replicated to provide redundancy. Each mid-level manager collects and processes data only from its local network and returns that information to the top-level manager in an intelligent way. Critical information is returned immediately via SNMP Traps. Non-critical information is returned when utilization of the backbone network is below some reasonable threshold. 6.3 Developing the Top-Level Manager The top-level manager consists of a set of cooperating applications written in Tcl and Java. The Tkined network editor that comes bundled with the Scotty [51] software package is used as a front-end for the Tcl-based VON-Monitor application. The 38

44 Chapter 6 Designing and Developing the Solution Tkined network editor is used because it (i) provides a graphical user interface for creating, configuring, and accessing network components, (ii) comes with several useful network management applications, including a DISMAN Script MIB application, and (iii) has a simple Tcl-based application programming interface. The VON-Monitor application monitors utilization of the backbone network, provides for dynamically configuring various operational parameters, and monitors incoming SNMP traps. A separate server was written in Java to listen for incoming update messages from midlevel managers Monitoring Utilization of the Backbone Network The VON-Monitor application pings each of its subordinate mid-level managers at regular, user-configurable intervals. If the ping comes back from a particular mid-level manager with a round-trip time below a user-configurable threshold, then the backbone network utilization is estimated to be low, and the mid-level manager is instructed to transmit all of its saved data to the top-level manager. If the ping comes back with a round-trip time exceeding that threshold, then the backbone network utilization is estimated to be too high to invoke an update. To indicate this condition, the icon representing the mid-level manager changes color to yellow. If the ping response never arrives, then connectivity to the mid-level manager is considered lost. To indicate this condition, the icon representing the mid-level manager changes color to red and flashes Dynamically Configuring Operational Parameters The VON-Monitor application provides for dynamic configuration of the multiple operational parameters. Table 6-1 describes these operational parameters. Parameter Polling Interval Interface Utilization Threshold Interface Error-Rate Threshold Update Interval Round-Trip Time Threshold Table 6-1. Operational Parameters for the VON-Monitor Application Description A mid-level manager polls each of its target devices once for each expiration of this interval. A mid-level manager will send an SNMP Trap to its assigned toplevel manager whenever it detects that a polled interface has a receive or transmit utilization exceeding this threshold. A mid-level manager will send an SNMP Trap to its assigned toplevel manager whenever it detects that a polled interface has a receive or transmit error rate exceeding this threshold. A top level manager pings each of its subordinate mid-level managers once for each expiration of this interval. A top-level manager will instruct a mid-level manager to transmit an update message only when the round-trip propagation time to the mid-level manager, as measured by ping, is below this threshold. Configuring any of the first three parameters requires communication between the toplevel manager and the target mid-level manager. This communication is implemented via simple, text-based, space-delimited Get and Set commands communicated via User 39

45 Chapter 6 Designing and Developing the Solution Datagram Protocol (UDP) sockets. The mid-level manager listens for commands from the top-level manger on UDP port The top-level manager uses any available port to send datagram commands and receives command responses on UDP port The syntax and semantics of manager-to-manager communications are discussed later in this chapter. The Update Interval and Round-Trip Time Threshold parameters are used within the VON-Monitor application. The user configures them through the graphical user interface without need for socket communications Monitoring Incoming SNMP Traps The top-level manager uses the NET-SNMP Trap daemon to receive incoming SNMP Traps. The NET-SNMP Trap daemon is configured to use the host system s logging facility to log all incoming SNMP Traps to a file, snmptrap.log. The VON-Monitor application uses Tkined s built-in event filtering capability to monitor all changes to the snmptrap.log file. When an entry is written to the snmptrap.log file by the Trap daemon, the VON-Monitor application echoes the entry to a window on the monitor Receiving Incoming Mid-Level Manager Updates The top-level manager relies on a Java-based server that listens on UDP port 6984 for incoming updates from subordinate mid-level managers. UDP transport was chosen because (i) the overhead of the Transport Control Protocol (TCP) associated with connection setup and teardown were thought to consume too much backbone capacity, (ii) updates are sent only when backbone utilization is thought to be low, so update datagrams have little chance of being lost, and (iii) even if an update is lost, it contains non-critical information that is expendable. To conserve backbone network capacity, mid-level managers compress their update messages in GZIP [52] format before transmitting them. Therefore, the top-level manager must uncompress incoming updates before processing them. Java was chosen for implementing this server because Java s application programming interface (API) has abstractions that make compressing and uncompressing data in GZIP format relatively easy. The format of update messages is discussed later in this paper. 6.4 Developing the Mid-Level Manager The mid-level manager was written as a Java application capable of being executed by the JASMIN implementation of the DISMAN Script MIB. The application is not intended to represent a thorough monitoring application; it is intended to demonstrate the kinds of things that can be done using the DISMAN Script MIB, and to generate SNMP monitoring traffic that can be measured during testing. To facilitate the development of the mid-level manager, the Java-based SNMP class library from AdventNet [53] was incorporated into the JASMIN run-time engine. Both 40

46 Chapter 6 Designing and Developing the Solution the AdventNet class library and the JASMIN run-time engine are implemented as Java archive (jar) files. Therefore, it was relatively simple to add the AdventNet classes to the JASMIN run-time engine using the Java jar tool. The mid-level manager is a multi-threaded application consisting of eight classes: (i) the IfData class, (ii) the SnmpData class, (iii) the Peer class, (iv) the IfMonitor class (v), the SnmpMonitor class, (vi) the MLMUpdate class, (vii) the MLM class, and (viii) the MyMLM class The IfData Class An IfData object is responsible for storing and providing access to all of the interface data that is gathered from a particular network interface by an IfMonitor object. An IfData object stores the following MIB variables from the MIB-II Interfaces group: (i) ifadminstatus, (ii) ifoperstatus, (iii) ifinoctets, (iv) ifinerrors, (v) ifoutoctets, and (vi) ifouterrors. In addition to these variables, an IfData object also stores the sysuptime variable from the MIB-II System group. The sysuptime variable is used to calculate rates of change in other variables as a function of time The SnmpData Class An SNMPData object is responsible for storing and providing access to all of the SNMP data that is gathered from a particular peer by an SNMPMonitor object. An SNMPData object stores the following MIB variables from the MIB-II SNMP group: (i) snmpinpkts, (ii) snmpoutpkts, (iii) snmpinbadcommunitynames, (iv) snmpinbadcommunityuses, (v) snmpinasnparseerrs, (vi) snmpouttoobigs, (vi) snmpoutnosuchnames, (vii) snmpoutbadvalues, and (viii) snmpoutgenerrs The Peer Class A Peer object represents an abstraction of a network device that is monitored by the midlevel manager. A Peer object stores some basic identifying information about the network device, including its IP address, the community string used to access it, the number of network interfaces it has, and a system description. The number of interfaces and the system description are learned from SNMP Get queries retrieving the MIB-II ifnumber and sysdescr variables. A Peer object also contains a single SnmpData object and a Vector of IfData objects. The Vector is essentially an array of IfData objects, indexed by ifnumber, containing one IfData object for each network interface in the peer machine. The Peer class provides access methods to get and set all of these objects The IfMonitor Class The IfMonitor class extends the Thread class and is, therefore, capable of running as a separate thread. An IfMonitor object is responsible for gathering information from the MIB-II Interfaces group associated with each Peer object in the Hashtable. Note that each Peer object may contain several IfData objects; the IfMonitor object polls information about all of them. 41

47 Chapter 6 Designing and Developing the Solution When the IfMonitor object is started, it first collects some basic information about each of the Peer objects in the Hashtable. This basic information includes both Peer-specific and IfData-specific information. The Peer-specific information includes the system description and the number of interfaces in the peer device. This information is retrieved from the MIB-II variables sysdescr and ifnumber. The IfData-specific information includes the interface description, type, and speed for each interface in the peer device. This information is retrieved from the MIB-II variables ifdescr, iftype, and ifspeed. After this basic information is collected and stored, regular polling can begin. Regular polling includes collecting and storing all of the MIB-II variables held by a IfData object. In addition to saving this data, the IfMonitor object checks for unusual conditions, alerting the top-level manager with an SNMP Trap whenever an unusual condition is detected. The IfMonitor object checks for high receive utilization, high transmit utilization, high receive error rate, and high transmit error rate. These calculations are mathematically simple, but there are subtle considerations that need attention. The interface receive utilization calculation is described to illustrate these subtleties. Equation 1 shows how the receive utilization is calculated. Note that the subscript indicates when a variable s value was collected. For example, if ifinoctets i was the value collected during the current polling interval, then the value ifinoctets i-1 was collected during the previous polling interval. Note that the 800 in the numerator is needed to maintain consistent units. The ifinoctets value is in bytes, the sysuptime value is in one-hundredths of a second, and the ifspeed value is in bits per second. The computed value, rxutil, is dimensionless. rxutil (ifinoctet s i - ifinoctets = (sysuptime -sysuptime i i-1 i-1 ) 800 ) ifspeed (Eqn 1) The first subtlety concerns the possibility of counter rollover, or the possibility that ifinoctets i is less than ifinoctets i-1, which causes the numerator to become negative. This possibility exists because the ASN.1 data type of the ifinoctets variable is counter. The counter type is a 32-bit number ranging from 0 to The counter type takes on the value of zero when incremented from its maximum value; that is, it rolls over. This condition must be checked for to ensure correct results. The second subtlety concerns the possibility that the SNMP agent being queried has rebooted between consecutive polling intervals. The ASN.1 data type of the sysuptime variable is TimeTicks, a count of 1/100 seconds maintained as a 32-bit positive value. This value should be reset to zero when the device is reinitialized, but other unusual events could leave this value in an unknown state [54]. To cover these contingencies, the IfMonitor object recognizes a reboot condition whenever the difference between successive sysuptime values is either negative, or greater than five times the polling interval. The presence of a reboot condition indicates that the data being analyzed is not 42

48 Chapter 6 Designing and Developing the Solution dependable, so the application abandons its analysis of the current network device and continues normally. The regular polling is conducted within an infinite loop. After every interface has been polled for the current round of polling, the IfMonitor thread sleeps for the user-defined polling interval before beginning the subsequent round of polling The SnmpMonitor Class The SnmpMonitor class also extends Thread, so it too runs as a separate thread. An SNMPMonitor object collects eight MIB variables from the MIB-II SNMP group and stores them in an SNMPData object. No rate calculations are computed by an SnmpMonitor object. The ability to analyze data and compute various rates is demonstrated by the IfMonitor class. The purpose of the SnmpMonitor class is to increase the number of MIB variables being monitored to facilitate measuring bandwidth requirements, and to demonstrate how easy it is to extend the mid-level manager application to monitor new MIB groups. The SnmpMonitor class is structurally identical to the IfMonitor class; it differs from the IfMonitor class only in the MIB variables it collects and how those variables are processed. This illustrates that the mid-level manager can easily be extended to monitor new MIB groups by adding (i) a new GroupMonitor class based on the IfMonitor class, (ii) a new GroupData class to store the collected data, (iii) editing the MLMUpdate class to dump the new Group data when updating the top-level manager, and (iv) ensuring that the MyMLM object starts the new GroupMonitor thread when the mid-level manager application is started. Adding functionality this way raises thoughts of object-oriented concepts such as polymorphism and inheritance. For example, the IfMonitor and SnmpMonitor classes could be derived from a common Monitor base class. While these classes share methods with similar functionality, those methods have different signatures. Undoubtedly, this difficulty could be overcome with a clever design. In the end, the effort required to incorporate true object-oriented design throughout a system this small was deemed excessive. If this application was to be extended to include many MIB groups, then an object-oriented approach would be justified. Perhaps this would be a good topic for further research The MLMUpdate Class The MLMUpdate class also extends the Thread class, enabling it to run as a separate thread. An MLMUpdate object is responsible for receiving and responding to commands from the top-level manager. When an MLMUpdate thread begins running, it opens UDP port 5984 and listens for commands arriving from its assigned top-level manager. Table 6.1 summarizes the commands understood by an MLMUpdate object. The detailed 43

49 Chapter 6 Designing and Developing the Solution syntax and semantics of commands understood by an MLMUpdate object are discussed below in Section 6.5, Manager-To-Manager Communications. Command Name Update Get Parameters Set Parameters Table 6-2. Commands Understood by an MLMUpdate Object Command Semantics This command instructs the mid-level manager to transmit all of its saved data to its assigned top-level manager. This command instructs the mid-level manager to inform its assigned toplevel manager of its currently used values for polling interval, utilization threshold, and error-rate threshold. This command instructs the mid-level manager to set its polling interval, utilization threshold, and its error-rate threshold to new values The MLM Class The MLM class stores and provides access methods for all of the mid-level manager s operational parameters. The mid-level manager s operational parameters are those parameters that are passed to the application when it is invoked. These parameters are reviewed in Section The MLM class is also responsible for storing all of the data retrieved via SNMP Get messages invoked by the IfMonitor and SnmpMonitor objects. The retrieved data is stored in a Hashtable object that contains Peer objects, indexed by IP address. Each Peer object contains an SNMPData object and a set of IfData objects, one for each interface in the peer device. For example, when the IfMonitor object collects interface data for an interface on the peer with IP address a.b.c.d, that data is stored in the IfData object that is held by the Peer object stored in the Hashtable with index a.b.c.d. The MLM class also provides a method for dumping all of the data held in the Hashtable. This method is called by the MLMUpdate object when the mid-level manager is instructed to send an Update message to its assigned top-level manager. The IfMonitor, SnmpMonitor, and MLMUpdate objects all run as separate threads, and all need access to the Hashtable. A locking mechanism is used to synchronize multithreaded access to the Hashtable. Without this feature, confidence in the Hashtable s integrity would be lost. The last step in the constructor for the MLM object is a call to a method that reads the peers file and constructs a Peer object for each peer identified in the peers file. Once a Peer object is constructed, it is inserted into the Hashtable where it is then ready to be filled with data from polling operations. 44

50 Chapter 6 Designing and Developing the Solution The MyMLM Class The MyMLM class contains the application s main method and is responsible for parsing arguments and initializing the application. Table 6.3 shows the optional arguments understood by a mid-level manager running on the JASMIN Script MIB. Table 6-3. Optional Arguments Understood by a Mid-Level Manager Argument Description -f filename Where filename is the full-path name identifying the peers file. The peers file is a space-delimited, text file that contains a set of IP address, community string pairs, one pair per line. The peers file identifies the IP addresses and community strings of the SNMP agents that should be polled by this mid-level manager. This scheme was chosen because the mid-level manager might be installed on a DISMAN Script MIB running in an administrative domain different from that of the top-level manager. The peers file essentially indicates which devices in the foreign domain are being made accessible to the mid-level manager. -t IPAddress Where IPAddress indicates the IP address of the top-level manager to which this mid-level manager should report. -m IPAddress Where IPAddress indicates the IP address that identifies this midlevel manager to its assigned top-level manager. This removes the ambiguity that arises when the mid-level manager resides on a multi-homed machine. -mc community Where community identifies the community string used to access this mid-level manager. -p PollingInterval Where PollingInterval indicates the polling interval in seconds that this mid-level manager should use. -u UtilizationThreshold Where UtilizationThreshold is a decimal fraction that indicates the utilization threshold that should be used by this mid-level manager. -e ErrorRateThreshold Where ErrorRateThreshold is a decimal number that indicates the error threshold in errors per second that should be used by this midlevel manager. After parsing input arguments, the main method instantiates an MLM object, an IfMonitor object, an SNMPMonitor object, and an MLMUpdate object. The main method then calls the start() method for each of the IfMonitor, SnmpMonitor, and MLMUpdates objects, starting a separate thread for each of those three objects. The midlevel manager application is then running, monitoring its local peers. 6.5 Manager-To-Manager Communications The top-level manager uses SNMP-based communications to install, invoke, and terminate mid-level managers. All other manager-to-manager communications take place using text-based messages that are sent via UDP datagrams. Commands and responses are formed from one or more textual lines composed of one or more textual tokens 45

51 Chapter 6 Designing and Developing the Solution delimited by spaces. Keywords are enclosed by angled brackets (e.g., <update>) to make parsing unambiguous. Tables 6-4 through 6-8 show the details of manager-to-manager communications. Message Syntax Semantics Response Table 6-4. The Get-Parameters Command Get-Parameters Command <getparams> This is a command sent by a top-level manager instructing a mid-level manager to return the current values for its polling interval, utilization threshold, and its errorrate threshold The mid-level manager responds with a Get-Parameters Response Message Syntax Semantics Response Table 6-5. The Get-Parameters Response Get-Parameters Response <params> A B C This is a mid-level manager s response to a Get-Parameters message where A is the current polling interval, B is the current utilization threshold, and C is the current error-rate threshold None Message Syntax Semantics Response Table 6-6. The Set-Parameters Command Set-Parameters Command <setparams> A B C This is a command sent by a top-level manager instructing a mid-level manager to set its polling interval to A, its utilization threshold to B, and its error-rate threshold to C None Message Syntax Semantics Response Table 6-7. The Update Command Update Command <update> This is a command sent by a top-level manager instructing a mid-level manager to transmit all of its saved data to its assigned top-level manager. The mid-level manager responds with an Update Response 46

52 Chapter 6 Designing and Developing the Solution Message Syntax Semantics Response Table 6-8. The Update Response Update Response <update> IPAddress <peer> IPAddress ifnumber sysdescr <if> ifnumber ifdescr iftype ifspeed rxutil txutil rxerrors txerrors ifadminstatus ifoperstatus TimeStamp <snmp> snmpinpkts snmpoutpkts snmpinbadcommunitystrings inbadcommuntiyuses inasnparseerrs outtoobigs outnosuchnames outbadvalues outgenerrs This is a mid-level manager s response to an Update Command. The above shows the basic syntax for an Update containing one polling round for a mid-level manager monitoring one device having one interface. The two lines following <snmp> are actually sent as one line in a Update Response. See the example Update Response shown in Figure 6-2 and the following discussion for clarification. None Figure 6-2 shows an example Update Response message. The line numbers are not part of the Update Response; they exist only to aid the following discussion. Line 1 indicates that this is an Update Response from the mid-level manager having IP address Lines 2 and 12 indicate that the mid-level manager is monitoring two Linux-based PCs having IP addresses and Line 1 <update> <peer> Linux west.nvlab i686 3 <if> 1 lo % 0% /01/01 12:19:39 PM 5 0% 0% /01/01 12:19:33 PM 6 <if> 2 eth % 6% /01/01 12:19:39 PM 8 0% 0% /01/01 12:19:34 PM 9 <snmp> /01/01 12:19:39 PM /01/01 12:19:34 PM 12 <peer> Linux east.nvlab i <if> 1 lo % 0% /01/01 12:19:39 PM 15 0% 0% /01/01 12:19:34 PM 16 <if> 2 eth % 0% /01/01 12:19:39 PM 18 0% 0% /01/01 12:19:34 PM 19 <snmp> /01/01 12:19:39 PM /01/01 12:19:34 PM Figure 6-2. An example Update Response message. 47

53 Chapter 6 Designing and Developing the Solution The data returned from peer (lines 2 11) are now examined. Line 1 indicates that the peer s IP address is and that it has 2 interfaces. The remainder of line 1 shows the value of the sysdescr MIB-II variable. Lines 3 8 are a record of the variables polled from the MIB-II Interfaces group. Lines 3 5 correspond to the peer s first interface. Lines 6 8 correspond to the peer s second interface. The data returned about the second interface are now examined. Line 6 indicates that interface s number is 2, its description is eth0, its type is Ethernet CSMA/CD, and that its speed is 10 Mbps. Lines 7 and 8 are records from two subsequent polling rounds; they show the same data items collected 5 seconds apart. Line 7 shows that the interfaces transmit utilization was 7 percent, the receive utilization was 6 percent, the transmit error-rate was 0 errors per second, and the receive error-rate was 0 errors per second. The remainder of line 7 is a timestamp indicating that this information was computed at 12:19:39 P.M. on February 1, Lines 9 11 are a record of the data collected from the peer s MIB-II SNMP group. Lines 10 and 11 are records from two subsequent polling rounds collected 5 seconds apart. Line 10 indicates that the value of snmpinpkts was 257, the value of snmpoutpkts was 257, the value of snmpinbadcommunitynames was 0, the value of snmpinbadcommunityuses was 0, the value of snmpasnparseerrs was 0, the value of snmpouttoobigs was 0, the value of snmpoutnosuchnames was 0, the value of snmpoutbadvalues was 0, and the value of snmpoutgenerrors was 0. The remainder of line 10 displays a timestamp indicating when these variables were collected. 6.6 Summary and Conclusions This chapter documented the design of the network management system under development. The system was designed using a top-level manager and multiple midlevel managers. The top-level manager was built using three cooperating applications written in Java, TCL, and the Scotty extensions to TCL. The mid-level manager was designed to execute as a management script running on the Jasmin Script MIB and was written entirely in Java. This chapter also defined the communication protocol used between top-level manager and mid-level manager. With the design and implementation of the network management system completed, work on testing its effectiveness began. Deploying and testing the network management system is the subject of Chapter 7. 48

54 Chapter 7 Deploying and Testing the Solution Chapter 7 Deploying and Testing the Solution 7.1 Introduction The MbD solution was deployed on a testbed network to verify that the system operates as intended. Testing of the system was performed to quantify how effectively the system preserves backbone network capacity. The capacity consumed by a traditional centralized polling scheme was used for comparison. The following sections describe the testbed s construction and the experiments that were conducted. The testbed configuration described here is similar to the testbed described in Chapter 4. Therefore, the following description provides an overview of the new testbed network that focuses on the differences between this testbed and the one described previously in Chapter 4. Details not covered here were left unchanged from the testbed of Chapter The Testbed Network The 10 Mbps Ethernet testbed network was constructed from two subnets connected via an exchange network, as shown in Figure 7-1. With respect to the VON environment, the and subnets represent distinct naval vessels, and the network represents the backbone network connecting them. The experiments that follow simulate one ship (the subnet) monitoring the other ship (the subnet). These results can be extrapolated to situations that involve more than two ships. Figure 7-1. The testbed network. Hosts east and west serve as IPSec security gateways protecting the and subnets, respectively. The top-level manager application (TLM) was run on dawn, and the mid-level manager application (MLM) was run within the Jasmin Script MIB installed on dusk. The mid-level manager monitored dusk and west, under the control of 49

55 Chapter 7 Deploying and Testing the Solution the top-level manager run on dawn. The sniffer machine was positioned to capture packets traversing the backbone network, allowing backbone capacity requirements to be measured Hardware Used in the Testbed Network All computers used in the testbed are Intel-based personal computers having a wide variety of performance capabilities. They use Pentium, Pentium Pro, and Pentium III processors with clock frequencies ranging from 120 MHz to 1.0 GHz. Each computer has between 32 MB and 512 MB of main memory. Since execution speed was not a primary concern for these experiments, the wide disparity in performance exhibited by these machines did not pose a problem Software Used in the Testbed Network All of the machines in the testbed, except for dawn, run Red Hat Linux version 7.0. Dawn runs Red Hat Linux version 6.1. In general, Red Hat version 6.1 proved to be less problematic than Red Hat version 7.0. The C compiler and C libraries shipped with Red Hat version 7.0 proved troublesome. Red Hat quickly supplied update packages intended to fix these problems, but experience showed that getting software packages to compile was still easier with version 6.1 than it was with version 7.0. The IPSec security gateways, east and west, run Linux FreeS/WAN, version 1.7. Two types of security associations were used for these experiments. A gateway-to-gateway, tunnel-mode security association was sufficient for the distributed, MbD experiments. A separate gateway-to-host, tunnel-mode security association was needed for the centralized experiments. The reason for this additional security association is addressed later. Both of these security associations employed MD5 authentication and triple DES encryption using Encapsulated Security Payload (ESP). SNMP services for all machines were provided by various versions of NET-SNMP. The Jasmin Script MIB requires NET-SNMP version 4.2. Therefore, version 4.2 was installed on dusk to support the Jasmin Script MIB. Version 4.2 was also installed on dawn, but west continued to use version 4.1. The top-level manager running on dawn required the Scotty software package, which in turn required Tcl/Tk version 8.3. The Scotty package supplies the Tkined network editor that is used as a front-end to the top-level manager software, and the Tnm extensions to Tcl that provide services useful for network management tasks. As with the earlier testbed, Ethereal was installed on the sniffer machine to capture and examine the traffic traversing the backbone network. 50

56 Chapter 7 Deploying and Testing the Solution 7.3 The Experiments and Their Results Several experiments were run to quantify backbone capacity requirements for both the centralized and MbD management schemes. In all of these experiments, a polling round is defined as the series of SNMP Get-Requests and Responses generated to monitor the two hosts on the subnet, dusk and west, during one complete polling interval. A polling round consists of 16 SNMP Get-Requests and 16 Responses, for a total of 32 frames. Monitoring west requires 9 Request/Response exchanges: 8 for monitoring interfaces (1 loopback, 3 Ethernet, and 4 IPSec virtual interfaces) plus one for the SNMP group. Monitoring dusk requires 7 Request/Response exchanges: 6 for monitoring interfaces (1 loopback, 1 Ethernet, and 4 IPSec virtual interfaces) plus 1 for the SNMP group. The larger-than-expected number of exchanges is due to the large number of interfaces on each machine, virtual or real. The actual MIB variables retrieved by a polling round are defined by the mid-level manager software and are described in Chapter 6. To facilitate these experiments, the mid-level manager software was written in a way that allowed it to be executed as either a stand-alone application or as a script running under the Jasmin Script MIB. The centralized experiments were performed by executing the mid-level manager on dawn as a stand-alone application. Under the centralized management scheme, all of the traffic generated by a polling round traverses the backbone network. The MbD experiments were performed by executing the mid-level manager on dusk as a script running on the Jasmin Script MIB. Under the MbD management scheme, the traffic generated by a polling round remains local to the subnet. In both scenarios, the Ethereal application running on sniffer was used to measure backbone capacity consumption. Note that most of these experiments were run first without any security services in place. That way, the traffic could be examined to understand the nature of the transactions being captured. With security services in place, the underlying protocols being carried by the Ethernet frame are obscured by ESP. Having seen a particular experiment run in-theclear as well as with encryption services in place increased understanding by enabling a one-to-one mapping to be established between clear frames and encrypted frames. Running distinct protocol analyzers on separate subnets could also have been used. It should also be noted that all of these experiments were run on an otherwise quiet network; that is, no other applications were generating traffic on the network. This resulted in very low variance in frame size for subsequent Request/Response transactions to a particular host. For example, the size of an SNMP Response for a particular MIB variable retrieved from dusk might be the same size every time because so few of the counters are changing, and those that are changing, are changing slowly. Having a quiet testbed is good because it removes experimental uncertainty that might otherwise be introduced by uncontrolled applications, but it also has consequences. It is reasonable to 51

57 Chapter 7 Deploying and Testing the Solution assume that these results exhibit less variance than what might be observed on a production network being exercised by real users. Experiments were executed to answer the following questions. Does the MbD scheme operate as intended? How much capacity is consumed by centralized monitoring? How much capacity is consumed by MbD monitoring? How much capacity is consumed by control communications? The following subsections document the experiments conducted to answer these questions and the results of those experiments Does the MbD Management Scheme Operate as Intended? Before capacity requirements testing was undertaken, it was important to verify that the MbD system worked correctly. The principle activities for verifying the MbD system consisted of ensuring that: (i) the top-level manager correctly monitors backbone utilization and invokes updates when backbone utilization is suitably low, (ii) the midlevel manager correctly monitors its target peers and sends an SNMP Trap when appropriate, and (iii) the manager-to-manager communications work correctly. To verify these functions, the MbD system was started and configured. Figure 7-2 shows a screen capture of the MbD network management system running on dawn. Figure 7-2. A screen capture of the MbD network management system in operation. 52

58 Chapter 7 Deploying and Testing the Solution The top window in Figure 7-2 shows the Tkined network editor loaded with the file describing the testbed network. The Tkined toolbar shows buttons for accessing several application menus. The Script-MIB application is a built-in application used for SNMPbased communications with DISMAN Script MIB implementations (e.g., installing, invoking, and terminating scripts). The VON-Monitor application is the custom-built application designed for this research. It provides UDP sockets-based communications between the top-level manager and mid-level managers. The Event application is a builtin application for configuring event-based filters. The Event application is configured to monitor incoming SNMP Traps; its window is open on the lower right of Figure 7-2. The window on the lower left of Figure 7-2 echoes incoming update messages; update messages are also appended to a log file. With all the top-level manager applications up and running on dawn, and the mid-level manager installed and invoked on dusk, verification began by first ensuring that the toplevel manager correctly monitored backbone utilization. The first experiments were conducted without IPSec security associations in place. With the Round-Trip Time threshold set to 1 ms, updates came in after every expiration of the update interval. In other words, the backbone network was always estimated to be underutilized, as it should, since no other traffic was loading the backbone. To simulate loading the backbone, 1024-byte ping packets were flooded between east and west. At the next update interval, the top-level manager detected a round-trip time exceeding the threshold and correctly ceased requesting updates from the mid-level manager. The Tkined icon representing the mid-level manager icon correctly turned yellow to indicate that the midlevel manager was not supplying updates. Once the flood of ping packets was stopped, the top-level manager correctly resumed collecting updates and returned the mid-level manager s icon to its normal color, black. Subsequent testing with IPSec security associations in place also worked correctly, but it was found that the Round-Trip Time Threshold had to be increased to 3 ms. The additional processing time required by the security gateways significantly increased propagation delay. The mid-level manager was similarly verified by first setting the mid-level manager s Utilization Threshold to 0.3. At that level, no SNMP Traps were delivered because no interface utilization was found to exceed 30 percent. Ping was again used to flood the backbone network, causing the receive and transmit utilizations of west s interface to exceed 30 percent. The mid-level manager correctly detected the high utilization and began sending SNMP Traps for each polling interval while the high utilization persisted. Once the flooding of the backbone ceased, the mid-level manager correctly ceased sending SNMP Traps. A word of caution should be raised here. Interface utilization traps on backbone interfaces can make a bad problem worse, as was illustrated in this experiment. When utilization on a backbone interface was found too high, the backbone was used to send SNMP Traps, making the problem even worse. Care should be taken when setting the mid-level manager s Utilization Threshold. 53

59 Chapter 7 Deploying and Testing the Solution The manager-to-manager communications consists of getting and setting each of the midlevel parameters from the top-level manager. Verifying that these important functions worked correctly was a simple matter of changing each parameter and observing the outcome. In all cases, the testing showed that manager-to-manager communications operated correctly. With basic verification of the MbD network management system complete, work began on quantifying capacity consumption How Much Capacity is Consumed by Centralized Monitoring? The experiment performed to answer this question used the mid-level manager as a standalone application running on dawn to monitor dusk and west. A tunnel-mode, gatewayto-gateway IPSec security association was used between east and west. Interestingly, this resulted in destination unreachable errors when dusk attempted to reach the interface on west. It was found that a second, tunnel-mode, gateway-to-host security association was required between east and west. Apparently, the FreeS/WAN IPSec software insists that the interface be accessed as a host destination on west, rather than as a gateway-ed destination on the subnet. At first, the destination unreachable error was thought to indicate a bug in the FreeS/WAN software because an arbitrary packet should either be shipped secured, if its source/destination profile fits a defined security association, or shipped in the clear if it does not. That is, it should never be denied transmission. On second thought, however, it is better to generate an error that will spur clarification than to erroneously ship traffic unsecured due to an ambiguity. The mid-level manager application was invoked on dawn and the traffic traversing the backbone was captured for analysis. Two security scenarios were examined; the first used ESP as discussed above, and the second used no security as a means for comparison. Five polling rounds were analyzed. Table 7-1 shows the results including the total number of bytes transmitted at the IP level per polling round. Ethernet framing overhead is not included because these experiments are intended to be link-layer independent. Table 7-1. Backbone Capacity Consumed by the Centralized Scheme (Bytes/Polling Round) Security Scheme # Packets Mean Total Bytes None ESP (MD5, 3-DES) Table 7-1 indicates that a typical, secured polling round requires transmitting 7,232 bytes. Therefore, if the centralized scheme is used with a polling interval of 60 seconds, then (7232 8) 60 = bits per second (bps) of backbone network capacity will be required to support polling activities. Table 7-1 also indicates that 1,700 of the 7,232 bytes, or 24 percent of the bytes transmitted, are used to support security services How Much Capacity is Consumed by MbD Monitoring? The backbone capacity consumed by the MbD approach depends on how often updates are sent across the backbone. At the expiration of every Update Interval, the top-level 54

60 Chapter 7 Deploying and Testing the Solution manager estimates backbone utilization (using round-trip time from ping) and invokes an update if its utilization estimate is suitably low. Henceforth, we assume that setting the Polling Interval to 60 seconds (1 minute) and the Update Interval to 360 seconds (6 minutes) is a reasonable way to use this system. Therefore, a lightly utilized backbone will see a ping request/response exchange, an Update Request, and a small Update Response every 6 minutes. The Update Response will carry 6 polling rounds worth of information. A heavily utilized backbone will see a ping response/request exchange every 6 minutes, but it will see Update Requests and large Update Responses on a less frequent basis. The frequency of Update Request/Response exchanges depends on how often the top-level manager finds the backbone utilization low enough to justify an Update. That is, a low Update Interval/Update ratio would indicate a lightly loaded backbone, and a high Update Interval/Update ratio would indicate a heavily loaded backbone. The ratio of Update Interval to Polling Interval was used to vary the frequency of Update messages. The overhead incurred by ping exchanges that do not invoke Updates was accounted for and added in by hand. For example, a heavily utilized backbone might justify an Update exchange only once for every 16 Update Intervals (96 minutes). This scenario could be simulated by setting the Update Interval to 96 minutes, while keeping the Polling interval set to 1 minute. The traffic captured from the backbone network would then include 1 ping request, 1 ping response, 1 Update Request, and 1 Update Response. The other 15 (imaginary) ping request/exchanges that failed to invoke an Update are not part of the capture, so they must be accounted for artificially. The technique just described is how the capacity tests for the MbD scheme were conducted, with one exception. To avoid unnecessarily long simulation times, the Update Interval and Polling Intervals were scaled down by a constant factor. Table 7-2 shows the results for testing the MbD scheme without security services in place. These results provide perspective when compared to the results for testing with security in place. An examination of the medium-heavy (med-heavy) row in Table 7-2 will help clarify the meaning of each entry. This row contains statistics for the unsecured test where the modeled workload was med-heavy, and the ratio of Update Intervals to Updates equals 8. It represents the scenario where the backbone utilization is heavy enough to justify an Update only once for every 8 Update Intervals, on average. An unsecured ping exchange transmits 164 bytes, 84 bytes for the request and another 84 bytes for the response. Therefore, this scenario includes = 1344 bytes of ping overhead. The unsecured Update Request was observed to be 36 bytes. The Update Response was larger than the 1500-byte Maximum Transfer Unit (MTU) for Ethernet, so the Update Response was fragmented into two packets. The first packet was observed to be 158 bytes in length, and the second was observed to be the maximum size for Ethernet, 1,500 bytes. The total number of bytes transferred under this scenario was, therefore, = 3038 bytes. 55

61 Chapter 7 Deploying and Testing the Solution Table 7-2. Backbone Capacity Consumed by the Unsecured MbD Scheme Modeled Workload Update Intervals to Updates Ratio Ping Overhead (bytes) Update Request (bytes) Update Response(s) (bytes) Total Sent (bytes) Light Med-Light Medium Med-Heavy Heavy The same technique was used to measure capacity consumption for the MbD scheme with security services in place. A tunnel-mode, gateway-to-gateway security association using ESP with MD5 and 3-DES was established between east and west. Each scenario was then tested five times with the resultant mean statistics shown in Table Modeled Workload Table 7-3. Backbone Capacity Consumed by the Secure MbD Scheme Update Intervals to Updates Ratio Ping Overhead (bytes) Update Request (bytes) Update Response(s) (bytes) Total Sent (bytes) Light Med-Light Medium Med-Heavy Heavy Comparing the med-heavy scenario of Table 7-3 to the med-heavy scenario of Table 7-2 proves interesting. The size of a secured ping exchange was observed to be 272 bytes, 136 bytes for both the request and response. Therefore, the med-heavy scenario includes = 2176 bytes of ping overhead. The secured Update Request was observed to be 88 bytes. Now, notice that the Update Response was inefficiently fragmented. An explanation for this inefficiency follows. The mid-level manager on dusk produced the Update Response, which was too big for the Ethernet link layer, so the IP layer on Dusk fragmented the datagram into two datagrams. One datagram was small in size (roughly 130 bytes) and the other was exactly 1,500 bytes, the maximum size payload allowed by Ethernet. Both datagrams

62 Chapter 7 Deploying and Testing the Solution were then sent to west, the default gateway for the subnet. West received the datagrams and, knowing that they belong to a defined IPSec security association, secured them in preparation for transmitting to east. The additional packet overhead required to support security services increased the small packet s size to 209 bytes and the large packet s size to something greater than Ethernet s 1500-byte MTU. Thus, the 1500-byte datagram was fragmented into one 136-byte datagram and one 1488-byte datagram. The end result was that three datagrams were sent over the backbone network, when two would have sufficed. Experimenting with the Ethernet MTU setting on dusk showed that an MTU of 1,442 bytes was the maximum MTU that did not cause fragmentation by the IPSec gateway, west. That is, an MTU of 1,442 bytes left enough headroom ( = 58 bytes) such that west could add IPSec overhead without exceeding the 1500-byte Ethernet MTU. Changing the MTU on west saved about 60 bytes of overhead for each doublefragmented packet. The savings realized might not be justified if reducing the MTU causes other problems. Since this research strives to be link layer independent, the MTU was returned to 1,500 bytes for all subsequent testing. However, the MTU issue just discussed certainly deserves attention How Much Capacity is Consumed by Control Communications? The only backbone-dependent communications not yet measured involves control communications. There are two basic types of control communications to consider. The first concerns communications between a mid-level manager and a Script MIB implementation. For example, to begin the monitoring operation, a top-level manager must install a script on a Script MIB implementation, then create and press a launch button to invoke it. The second type of control communication concerns communications between a top-level manager and a running mid-level manager. For example, a top-level manager can dynamically configure mid-level manager parameters. Table 7-4 shows the capacity consumed by the secure communications required to invoke the mid-level manager script on the Jasmin Script MIB. This involves transferring the script to the Script MIB, installing a launch button, and pressing the launch button. The executable jar file that contains the mid-level manager is 18,110 bytes in length. The pull operation instructs the Script MIB to retrieve the script via HTTP from a specified URL. Pulling the script required transmitting 50 packets totaling 24,344 bytes. Table 7-4. Secure Script MIB Control Communications Communication Primitive Total Packets Total Sent (bytes) Pull Script Create Launch Button Press Launch Button

63 Chapter 7 Deploying and Testing the Solution Creating the launch button passes arguments to the script and establishes run-time privileges for the script. Creating the launch button required transmitting 6 packets for a total of 1,504 bytes. Pressing the launch button invokes the script, and required transmitting 4 packets for a total of 664 bytes. In total, 26,512 bytes were transmitted to install and invoke the mid-level manager on the Jasmin Script MIB. While the complete operation is quite expensive, it is encountered only once. The top-level manager controls a running mid-level manager via simple get and set primitives sent via UDP datagrams. Table 7-5 shows the sizes of the three communications primitives that were defined in Chapter 6. Table 7-5. Secure Mid-Level Manager Control Communications Communication Primitive IP Packet Size (bytes) Get-Parameters Command 96 Get-Parameters Response 112 Set-Parameters Command 104 The control communications summarized in Tables 7-4 and 7-5 are typically used only when a new local network first joins the VON. Once a local network is part of the VON, these control communications are used infrequently, so the capacity consumed by them is amortized over extended periods of time. That is, the costs of these control communications are relatively small. 7.4 Comparing the Centralized and MbD Schemes A scenario for comparing the centralized and MbD schemes can now be presented using the capacity measurements developed throughout this chapter. It is still assumed that the MbD system is employed with the Update Interval set to 360 seconds (6 minutes) and the Polling Interval set to 60 seconds (1 minute). Table 7-6 lists the backbone capacity consumed by the secured centralized and MbD schemes for the five backbone workloads introduced earlier. It shows that the MbD scheme consumes only 2 percent of the backbone capacity that the centralized scheme consumes. Table 7-6. Comparing Centralized and MbD Capacity Consumption Modeled Time Interval # Polling Total Sent (bytes) Capacity Used (bps) Workload (seconds) Rounds Centralized MbD Centralized MbD Light Med-Light Medium Med-Heavy Heavy

64 Chapter 7 Deploying and Testing the Solution Another examination of the med-heavy scenario clarifies how this table was derived. The med-heavy scenario models the situation where, on average, 1 out of 8 Update Intervals results in an Update Request. Therefore, in a period of 8 Update Intervals (48 minutes or 2,880 seconds) the MbD scheme transmits 8 ping exchanges, 1 Update Request, and 1 Update Response, for a total of 4,097 bytes (from Table 7-3). Transmitting 4,097 bytes over 2,880 seconds equates to 11.4 bps. During that same 48-minute period, the centralized scheme would have performed 48 polling rounds. Since a single centralized polling round transmits 7,273 bytes (from Table 7-1), the total bytes sent by the centralized scheme is = bytes. Transmitting 347,136 bytes over 2,880 seconds equates to 964 bps. It should be stated that the MbD numbers shown in Table 7-5 do not include any of the control communications discussed earlier. For example, the mid-level manager must be installed and invoked before its benefits can be realized. These tasks require transmitting 26,512 bytes, which is less than 4 polling rounds worth of traffic using the centralized scheme. Therefore, the costs for installing and invoking the mid-level manager are recouped within the first few minutes of operation. In effect, the costs for control communications are relatively small. Figure 7-3 shows a graphical representation of the capacity required by the MbD approach as a function of workload measured by the ratio of Update Intervals to Updates. The graph shows that as backbone utilization goes up (Update Intervals per Update goes up), the overall capacity required goes down. This behavior is due to the compact, compressed format of the Update Response that enables a huge volume of information to be conveyed in a relatively small datagram. Capacity Required (bps) Workload (Update Intervals/Update) Figure 7-3. Capacity requirements for the MbD scheme. 59

65 Chapter 7 Deploying and Testing the Solution 7.5 Summary and Conclusions This chapter discussed the evaluation of the MbD network management system developed for this research. The evaluation focused on comparing the backbone capacity requirements of the MbD system with those of the centralized management approach. Towards that end, both the MbD system and the centralized scheme were deployed on a testbed network and their backbone capacity requirements were measured. The measurements have shown that the MbD approach consumes only 2 percent of the network capacity consumed by the centralized approach. Furthermore, the advantage offered by the MbD approach increases as backbone utilization increases. These results indicated that the MbD solution developed for this research provided a scalable, secure network management system that effectively preserves backbone capacity. 60

66 Chapter 8 Conclusions Chapter 8 Conclusions This chapter summarizes the research, provides conclusions, and offers suggestions for future work. 8.1 Summary and Conclusions This research was dedicated to developing a secure, SNMP-based network management system that can be deployed in internetworks that rely on low-bandwidth backbone networks. The main goal of the network management system was to make efficient use of the limited capacity available on the backbone network and to do so in a secure, standards-based way that promotes interoperability. The research was conducted in two phases. The first phase was aimed towards deciding how best to secure network management traffic, and the second phase was geared towards developing a network management system that possessed the required attributes, with emphasis on reducing backbone network utilization. Two means for securing SNMP traffic were considered: using SNMPv2c-over-IPSec, and using SNMPv3. An extensive qualitative analysis revealed that using SNMPv2c-over- IPSec provided several advantages over using SNMPv3. For example, IPSec provided a comprehensive security solution for all IP-based applications and was relatively easy to use and administer. SNMPv3 provided services for securing SNMP traffic only, and was more difficult to operate. Furthermore, experimental measurements showed that SNMPv3 consumed as much as 24 percent more network capacity than SNMPv2c-over- IPSec. These advantages confirmed the choice to make SNMPv2c-over-IPSec the preferred solution for securing SNMP operations. As an aside, the results presented by this research are also applicable to networks that deploy SNMPv1 instead of SNMPv2c. The advantages of using SNMPv2c instead of SNMPv1 are minor; they do not exclude SNMPv1 from consideration. The design of the network management system quickly focused on distributed concepts. It was clear from the beginning that a traditional, centralized polling scheme would consume too much of the limited capacity available on the backbone network. The proposed solution followed the Management by Delegation (MbD) model and was implemented using the IETF DISMAN Script MIB. The system was constructed as a two-level hierarchy composed of a top-level manager and an arbitrary number of subordinate mid-level managers. The system preserved backbone capacity by delegating network monitoring chores to strategically located mid-level managers that report management information to the top-level manager in a way that makes intelligent use of the limited capacity available on the backbone network. Critical information was returned immediately via SNMP Traps. Non-critical information was stored locally until backbone utilization was estimated to be low enough to justify its transmission. Testing and evaluating the solution network management system revealed that it consumed 61

67 Chapter 8 Conclusions around 2 percent of the backbone capacity required by the centralized scheme. Furthermore, the advantage shown by the MbD solution improved with increased backbone utilization, yielding a much more scalable solution. Therefore, the MbD system developed here clearly met its goals. This research can also be discussed in terms of Quality of Service (QoS). While this work did not focus on developing a QoS framework, it did indirectly implement a QoS policy for network management traffic. The network management system developed for this research partitioned network management traffic into two priority classes. Critical information received high priority; it was transmitted immediately via SNMP Traps without regard for the current utilization of the backbone network. Non-critical information received low priority; it was warehoused locally until backbone utilization was considered low enough to justify its transmission. 8.2 Future Work Future work on this system should focus on at least three fronts. First, the method used to estimate backbone utilization uses ping in a crude way. A method to improve it should be pursued. The difficulty lies in estimating backbone utilization without consuming capacity. One weakness in the current method is encountered when a manager (a midlevel manager, a top-level manager, or both) does not have an interface on the backbone network. In that case, the round-trip time reported by ping includes delay introduced by the local subnet hosting the manager. Congestion on the mid-level manager s subnet could then cause the top-level manager to over-estimate backbone utilization. Another potential improvement for estimating backbone utilization could be to use an adaptive round-trip time threshold for ping rather than the fixed threshold currently used. An adaptive threshold could compensate for variations in the network environment and relieve network administrators of having to manually ensure that the Round Trip Threshold parameter is properly set for each mid-level manager. One possibility could have the top-level manager maintain a moving average of the round-trip times returned by ping for each mid-level manager. The top-level manager could then decide whether or not to invoke an update from a particular mid-level manager based on the relationship between the latest round-trip time and its moving average. For example, suppose the toplevel manager pings a mid-level manager, M, and the round-trip time returned is T. The top-level manager might invoke an update from M if T is less than 1.5 times M s moving average of round-trip times. Following the decision, the top-level manager would incorporate T into the moving average of round-trip times maintained for mid-level manager M. The second front that should be pursued regards the warehousing of information collected by the top-level manager. As it stands now, the data is simply written to a log file and echoed to a management window. A good direction for future endeavors would be to insert the collected management information into a SQL database and provide a CGI 62

68 Chapter 8 Conclusions interface for accessing it via HTTP and HTML. In fact, early work on this front is underway as part of a related project, but no results are available at the time of this writing. The third front is concerned with Quality of Service. The network management system developed for this research is targeted for network environments that do not support QoS. However, this work is related to QoS because it implements a QoS policy for network management traffic in an indirect way. It seems natural to solidify this relationship by extending the MbD system to use network-provided QoS services when deployed in a QoS-enabled network. One possible idea would be to make the system capable of detecting whether or not QoS services are available in the network. The system could then use the network s QoS capabilities, if they are available, or use its own capabilities, if they are not. 63

69 References References [1] J. Case, M. Fedor, M. Schoffstall, and J. Davin, A Simple Network Management Protocol, RFC 1157, May [2] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, pp [3] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, pp [4] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, Introduction to Community-based SNMPv2, RFC 1901, January [5] J. Case, R. Mundy, D. Partain, and B. Stewart, Introduction to Version 3 of the Internet-standard Network Management Framework, RFC 2570, April [6] S. Kent and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November [7] Information Technology Interoperability, Naval Research Advisory Committee Report, NRAC 98-2, November [8] M. Rose and K. McCloghrie, Structure and Identification of Management Information, RFC 1155, May [9] K. McCloghrie, D. Perkins, and J. Schoenwaelder, Structure of Management Information Version 2 (SMIv2), RFC 2578, April [10] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, p [11] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, p [12] S. Kent and R. Atkinson, IP Authentication Header, RFC 2402, November [13] S. Kent and R. Atkinson, IP Encapsulating Security Payload (ESP), RFC 2406, November [14] Harkins, D. and D. Carrel. The Internet Key Exchange (IKE). RFC Internet Engineering Task Force. November [15] D. Maughan, M. Schertler, M. Schneider, and J. Turner, Internet Security Association and Key Management Protocol, RFC 2408, November [16] H. Orman, The Oakley Key Determination Protocol, RFC 2412, November [17] Anonymous, Linux FreeS/WAN Overview, available June 27, [18] C. Madson and N. Doraswamy, The ESP DES-CBC Cipher Algorithm with Explicit IV, RFC 2405, November

70 References [19] U. Blumenthal and B. Wijnen, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), RFC 2574, April [20] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, p [21] B. Wijnen, R. Presuhn, and K. McCloghrie, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), RFC 2575, April [22] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, pp [23] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, pp [24] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, IP Payload Compression Protocol, RFC 2393, December [25] Linux FreeS/WAN, available February 10, [26] NET-SNMP, available February 10, [27] OpenSSL, available February 10, [28] Ethereal, available February 10, [29] J. P. Martin-Flatin and S. Znaty, A Simple Typology of Distributed Network Management Paradigms, Proc. Eighth IFIP/IEEE Int. Workshop on Distributed Systems: Operations & Management (DSOM 97), Sydney, Australia, pp , October [30] J. P. Martin-Flatin, S. Znaaty, and J. P. Hubaux, A Survey of Distributed Enterprise Network and Systems Management Paradigms, J. Network Systems Management, vol. 7, no. 1, pp. 9-26, March [31] S. Wallbusser, Remote Network Monitoring Management Information Base, RFC 1757, February [32] S. Wallbusser, Remote Network Monitoring Management Information Base Version 2 Using SMIv2, RFC 2021, January [33] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. 3 rd ed., Reading, MA, Addison Wesley Longman, 1999, p [34] Distributed Management Task Force (DMTF), available February 8, [35] D. Hyde, Web-Based Management, available Feb. 8, [36] J. P. Martin-Flatin, S. Znaaty, and J. P. Hubaux, A Survey of Distributed Enterprise Network and Systems Management, Technical Report SSC/1998/024, SSC, EPFL, Lausanne, Switzerland, July [37] Java Management Extensions (JMX), available March 10,

71 References [38] Anonymous, Java Management Extensions White Paper, available March 10, [39] Y. Yemini, G. Goldszmidt, and S. Yemini, Network Management by Delegation, Proc. Int. Symp. Integrated Network Management, April 1991, pp [40] G. Goldszmidt and Y. Yemini, Distributed Management by Delegation, Proc 15 th Int. Conf. on Distributed Computing Systems (ICDCS 95), Vancouver, Canada, May 1995, IEEE Press, New York, NY, USA, [41] D. Levi and J. Schoenwaelder, Definitions of Managed Objects for the Delegation of Management Scripts, RFC 2592, May [42] M. Zapf, K. Herrmann, and K. Geihs, Decentralized SNMP Management with Mobile Agents, Proc. 6 th IFIP/IEEE Int. Symp. Integrated Network Management, May 1999, pp [43] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J, Wetherall, and G. J. Minden, A Survey of Active Network Research, IEEE Commun. Mag., vol. 35, Jan. 1997, pp [44] K. Psounis, Active Networks: Applications, Security, Safety, and Architectures, IEEE Commun. Surveys, vol. 2, no. 1, 1 st Quarter, [45] K. Terplan, Web-Based Systems and Network Management. Boca Raton, FL: CRC Press, 1999, p. 99. [46] J. Schönwälder, and J. Quittek, Secure Management by Delegation within the Internet Management Framework, Proc. 6 th IFIP/IEEE Int. Symp. Integrated Network Management, May 1999, pp [47] JAMSIN: A Script-MIB Implementation, available Feb. 8, [48] M. Daniele, B. Wijnen, M. Ellison, and D. Francisco, Agent Extensibility (AgentX) Protocol Version 1, RFC 2741, January [49] J. Schoenwaelder, and J. Quittek, Script MIB Extensibility Protocol Version 1, RFC 2593, May [50] Tcl/Tk, available April 8, [51] Scotty Tcl Extensions for Network Management Applications, available March 10, [52] The GZIP Home Page, available March 10, [53] AdventNet, available March 10, [54] D. Zeltserman and G. Puoplo, Building Network Management Tools with Tcl/Tk, Prentice Hall, Upper Saddle River, NJ, 1998, p

72 Vita H. Erik Hia was raised in the town of St. James, located on the north shore of eastern Long Island, NY. After graduating from Smithtown High School East, he found employment as a Technical Representative with Xerox Corporation. In 1983, Erik married his childhood sweetheart, Sharon, and they began pursuing their dream of a owning a beautiful home and starting a family. Unfortunately, the property values on Long Island were exploding, so despite their best efforts, Erik and Sharon were losing ground on attaining their dream. Clearly, something had to change. In 1985, Erik transferred within Xerox to Tarrytown, NY. Erik and Sharon bought a reasonably priced building lot in northern Dutchess County, and Erik spent every spare moment of the next year building a home with his own two hands and the help of some special friends. Meanwhile, Sharon gave birth to their first child, a son named Kyle. When the house was finished, local realtors took notice and begged for the chance to sell it. They soon brought offers that were too good to decline. Suddenly, Erik realized that the building experience was far more enjoyable and provided much better financial rewards than working for Xerox, so Erik resigned from Xerox and started a residential construction firm in During the next year Erik built another home for his family, and Sharon gave birth to their second child, a daughter named Jamie. Over the next several years, the Hia family enjoyed their new home, and Erik worked hard to develop the reputation of a fine craftsman in the residential construction industry. In 1994, the local economy began to slow down. After seven years of building, Erik s life was consumed by his business, and he began to realize that he did not want to spend the rest of his life in the building business. Then Sharon s company announced that they were moving to Roanoke, VA, and they offered Sharon a position at their new facility. Erik and Sharon decided to move to Roanoke, where Sharon would support the family while Erik embarked on a drastic career change. By 1995, Erik decided to earn an engineering degree and began studies at Virginia Western Community College in Roanoke, VA. After one year there, Erik transferred to Virginia Tech in Blacksburg, VA. Erik completed his B.S. in Computer Engineering in December He then chose to continue his studies at Virginia Tech in pursuit of the M.S. degree in Computer Engineering. In May 2001, Erik will complete his Master s degree, and the Hia family will move to Raleigh, NC, where Erik has accepted a Software Engineering position with Ericsson IP Infrastructure. In his new career, Erik will be developing protocol software for use in Ericsson s new line of high-speed, IP routers. 67