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
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.
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.
1.1 BACKGROUND...1 1.2 RESEARCH GOALS...2 1.3 DOCUMENT OVERVIEW...3 CHAPTER 2 METHODOLOGY...5 2.1 INTRODUCTION...5 2.2 EFFICIENTLY SECURING SNMP...5
2.2.1 Alternatives for Securing SNMP ...5
2.2.2 Evaluating Alternatives for Securing SNMP ...6
2.3 DEVELOPING THE NETWORK MANAGEMENT SOLUTION...6
2.3.1 Alternatives for Distributed Management ...7
2.3.2 Developing the Network Management Solution...7
2.4 DEPLOYING AND TESTING THE SOLUTION...7
2.5 SUMMARY AND CONCLUSIONS...8
CHAPTER 3 ALTERNATIVES FOR SECURING SNMP...9
3.1 INTRODUCTION...9
3.2 USING INSECURE SNMP OVER IPSEC...9
3.2.1 Comparing SNMPv1 and SNMPv2c...9
3.2.2 An Overview of IPSec...11
3.2.3 Characteristics of Using SNMPv2c Over IPSec ...12
3.3 USING SNMPV3 ...14
3.3.1 Overview of SNMPv3...14
3.3.2 Characteristics of Using SNMPv3...16
3.4 COMPARING SNMPV2C-OVER-IPSEC AND SNMPV3 ...17
3.5 SUMMARY AND CONCLUSIONS...19
CHAPTER 4 EVALUATING ALTERNATIVES FOR SECURE SNMP...20
4.1 INTRODUCTION...20
4.2 THE TESTBED NETWORK...20
4.2.1 Hardware Used in the Testbed Network ...21
4.2.2 Software Used in the Testbed Network...21
4.3 THE EXPERIMENTS AND THEIR RESULTS...22
4.3.1 How Much Network Capacity is Consumed by a Secure SNMP Operation?22 4.3.2 How Much Processing Time is Consumed by a Secure SNMP Operation?..24
4.3.3 How Much Capacity is Consumed by an SNMPv3 Discovery Exchange? ...25
4.3.4 How Much Network Capacity is Consumed by an IPSec SA Negotiation? ..26
4.4 SUMMARY AND CONCLUSIONS...27
CHAPTER 5 ALTERNATIVES FOR NETWORK MANAGEMENT ...28
5.1 INTRODUCTION...28
5.2 ALTERNATIVE NETWORK MANAGEMENT PARADIGMS...28
5.2.1 Centralized Network Management...28
5.4.1 The Jasmin Script MIB Implementation ...36
5.5 SUMMARY AND CONCLUSIONS...36
CHAPTER 6 DESIGNING AND DEVELOPING THE SOLUTION...37
6.1 INTRODUCTION...37
6.2 OVERVIEW OF THE SOLUTION...37
6.3 DEVELOPING THE TOP-LEVEL MANAGER...38
6.3.1 Monitoring Utilization of the Backbone Network ...39
6.3.2 Dynamically Configuring Operational Parameters ...39
6.3.3 Monitoring Incoming SNMP Traps...40
6.3.4 Receiving Incoming Mid-Level Manager Updates...40
6.4 DEVELOPING THE MID-LEVEL MANAGER...40
6.4.1 The IfData Class...41
6.4.2 The SnmpData Class ...41
6.4.3 The Peer Class...41
6.4.4 The IfMonitor Class...41
6.4.5 The SnmpMonitor Class ...43
6.4.6 The MLMUpdate Class...43
6.4.7 The MLM Class ...44
6.4.8 The MyMLM Class ...45
6.5 MANAGER-TO-MANAGER COMMUNICATIONS...45
6.6 SUMMARY AND CONCLUSIONS...48
CHAPTER 7 DEPLOYING AND TESTING THE SOLUTION...49
7.1 INTRODUCTION...49
7.2 THE TESTBED NETWORK...49
7.2.1 Hardware Used in the Testbed Network ...50
7.2.2 Software Used in the Testbed Network...50
7.3 THE EXPERIMENTS AND THEIR RESULTS...51
7.3.1 Does the MbD Management Scheme Operate as Intended? ...52
7.3.2 How Much Capacity is Consumed by Centralized Monitoring?...54
7.3.3 How Much Capacity is Consumed by MbD Monitoring? ...54
7.3.4 How Much Capacity is Consumed by Control Communications? ...57
7.4 COMPARING THE CENTRALIZED AND MBD SCHEMES...58
7.5 SUMMARY AND CONCLUSIONS...60
CHAPTER 8 CONCLUSIONS...61
8.1 SUMMARY AND CONCLUSIONS...61
8.2 FUTURE WORK...62
REFERENCES ...64
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 commonly-used 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 non-secure 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.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 inter-network 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.
• 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 IPSec-enabled 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
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.
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.
2.2.1 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
proposed solution, so their advantages and disadvantages should be carefully assessed. Chapter 3 is focused on examining these alternatives in qualitative terms.
2.2.2 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 top-level 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
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?
2.3.1 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.
2.3.2 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.
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.
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.
3.2.1 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
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, 230 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
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.
3.2.2 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
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.
3.2.3 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.
3.2.3.1 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-to-end 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
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.
3.2.3.2 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.
0 8 16 24 31
Security Parameters Index Sequence Number
Payload
Padding (0 – 255 bits)
Pad Length Next Header Authentication Data
Figure 3-3. ESP extension 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
can be updated at intervals on the order days, loosening security to benefit network capacity.
3.2.3.3 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.
3.2.3.4 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.
3.2.3.5 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.
3.3.1 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.
• 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.
3.3.1.1 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].
3.3.1.2 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
features provided by SNMPv3 are far more secure and far more powerful than are those of SNMPv1 and SNMPv2.
3.3.2 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.
3.3.2.1 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.
3.3.2.2 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
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 4.
3.3.2.3 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 case-by-case dependencies that will be explored empirically.
3.3.2.4 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.
3.3.2.5 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
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 SNMP-enabled 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 IPSec-enabled 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.
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.
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.
4.2.1 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.
4.2.2 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.
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.
4.3.1 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 79 101 180
v2c over IPSec 136 152 288
v3 noAuthNoPriv 142 164 306
v3 authNoPriv 154 176 330
v3 authPriv 167 191 358
v3 noAuthNoPriv over IPSec 192 216 408
v3 authNoPriv over IPSec 208 232 440
v3 authPriv over IPSec 224 248 472
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
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 175 287 462
v2c over IPSec 232 344 576
v3 noAuthNoPriv 238 350 588
v3 authNoPriv 250 362 612
v3 authPriv 264 377 641
v3 noAuthNoPriv over IPSec 288 400 688
v3 authNoPriv over IPSec 304 416 720
v3 authPriv over IPSec 320 432 752
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 0.63 0.80
v2c over IPSec 1.00 1.00
v3 noAuthNoPriv 1.06 1.02
v3 authNoPriv 1.15 1.06
v3 authPriv 1.24 1.11
v3 noAuthNoPriv over IPSec 1.42 1.19
v3 authNoPriv over IPSec 1.53 1.25
v3 authPriv over IPSec 1.64 1.31
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.
4.3.2 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 (µs) Standard Deviation v2c 310.4 12.2 v3 noAuthNoPriv 525.9 6.5 v3 authNoPriv 591.7 6.1 v3 authPriv 696.8 57.7 v2c over IPSec 778.8 80.1
v3 noAuthNoPriv over IPSec 1057.0 19.4
v3 authNoPriv over IPSec 1160.0 21.2
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.
4.3.3 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
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 103 138 241
SNMPv3 authPriv over IPSec 160 192 352
4.3.4 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 204 2 main 108 3 main 208 4 main 208 5 main 96 6 main 96 7 quick 344 8 quick 320 9 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.
4.4 Summary and Conclusions
The following general conclusions comparing the SNMPv3 solution and the SNMPv2c-over-IPSec solution can be drawn from the experimental results.
The SNMPv3 solution consumes as much as 24 percent more network capacity than the 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 SNMPv2c-over-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.
