Secure LAN Management With SNMPv2 Over IPsec

Rizwan Aslam Butt NED University of Engineering & Technology

Karachi, Pakistan rizwan.aslam@neduet.edu.pk

Attaullah Buriro Pakistan Meteorological Department

Karachi, Pakistan buriro_06@hotmail.com

Abstract— SNMPv2 is the most popular Network Management Protocol for its simplicity, wide support in most of the Operating Systems and network devices. The weakness in SNMPv2 was lack of proper security mechanism which led to the improved version SNMPv3 in 1999 [1] .It required separate PKI infrastructure and lacked support in older network devices so it could not get wide popularity and adaptation. Therefore several alternate security proposals for securing SNMPv2 like use of IP Security (IPsec), TLS and SSH have been presented. In this paper we have presented a method of securing SNMPv2 based communication using IPsec, customized for SNMP packets only, without affecting other traffic in a LAN environment. We have also analyzed performance of this approach with the insecure SNMPv2 based communication and found that it incurred only 8.5% more delay and 1.2% to 1.4% extra overheads.

Keywords- SNMPv2; SNMP Security; IPsec

I. INTRODUCTION Network Devices have usually more than one interfaces,

running or configured services and a set of supported protocols. For a smooth operation and trouble less service provisioning it is necessary to have some network management system. Simple Network Management Protocol (SNMP) has no doubt emerged as the most popular Network Management protocol. It not only allows for the collection of management information from remote network devices as well as enables to configure them remotely [2].The first version of SNMP [3] lacked the bulk data transfer ability so the improved version SNMPV2 was developed by IETF working group in 1996. But with the increased trend of security threats and attacks the lack of security services in SNMP protocol was being questioned.SNMPv2c [4] was introduced with a community based security concept. The idea was very simple but since string had to be common for the whole group/community being managed, its leakage would compromise the security of all the group devices. Also it didn’t involve any encryption so sniffing was easy.Finally the current version SNMPV3 was introduced .But since SNMPv3 had its own headers for the provisioning of authentication, confidentiality, data integrity and non-repudiation as well as it required separate key management infrastructure in the entire network devices being managed which involved a lot of cost so it could not get much popularity. Since then people have been working on alternate solutions for securing insecure

versions of SNMP. The key solutions in this regard have been beautifully discussed in [5], namely; SSH [6], TLS [7] and DTLS [8].Separate papers these approaches have also been written e.g. SNMP over SSH [9] and SNMP along with IPSEC [10].In this paper we have demonstrated the use of IPsec in Transport Mode for the secure management of a LAN.

II. OVERVIEW OF SNMP SNMP allows systems administrators to monitor and control heterogeneous devices from a centralized location instead of physically checking each networked device. SNMP managers provide a unified view of the network's performance, fault, configuration and topology by retrieving information from SNMP agents based on TCP/IP protocol. It works on Client Server based model. The device loaded with the management process (software) is also termed as NMS while the devices loaded with client process (mostly a firmware) are termed as Clients. NMS queries all the clients for the desired management information on polling basis. The management information is also standardized in a Tree structure with each management parameter identified by a unique identifier (OID) and stored in a MIB file at both Manager and Client ends. The SNMP query from a Manager may be based on one of the following PDU Types;

• GetRequest: requests a single variable value from an agent by specifying its OID.

• GetBulk: requests values of a group of variables from an agent.

• GetNextRequest: requests the value of lexicographically next variable from the agent.

• SetRequest: change the value of a variable in the agent by specifying its OID.

• GetResponse: return the value of a variable or list of variables from agent, which is the response of the former three requests.

• Trap: asynchronous notification from agent to manager.

For more than one managed network elements (NEs), the manager polls all agents to retrieve management data and update the NMS as well as often stores important results specific to that netwok in a database.

The 6th International Conference on Telecommunication Systems, Services, and Applications 2011

978-1-4577-1442-9/11/$26.00 ©2011 IEEE 271

III. NETWORK SECURITY REQUIREMENTS A communication Network in order to be characterized as a

secure network should provide following security services [11].

a) Authentication: Means that the subjects and objects are what and who they claim to be. In a network environment, this is not only the identity of the user, but also the host and process involved.

b) Access control: It means that only the authorized users have access to the network resources. It restricts access to physical system, software and data.

c) Confidentiality: Provide privacy to the information and avoid it from disclosure to the unauthorized hosts. This is achieved by encrypting the data in a network.

d) Integrity: Means data remains unchanged during communication as well as protected from corruption and damage. This is often done through hashing techniques.

e) Availability: Surety that the service can be provided to a requesting party , authorized to access this service or data.

IV. OVERVIEW OF IP SECURITY There are three functional areas in which IP-level security

can be divided [12]: authentication, confidentiality, and key management. It can be used to provide protection to one or more "paths" between a pair of hosts, between a pair of security gateways, or between a host and a security gateway [13].It extends header of standard IP to include following components.

• Authentication Header (AH) [14] − Hold authentication

information for IP datagram .Using this header authentication can be performed using either Secure Hash Algorithm (SHA-1) or Message Digest 5 (MD5) keyed-message digests.

• Encapsulating Security Payload (ESP) [15] − This header provides Encryption service using the Data Encryption Standard in Cipher Block Chained mode (DES-CBC). If the IP header of an ESP packet requires authentication, then AH has to be used in conjunction with ESP.

• Internet Key Exchange (IKE) [16] − defines how principals agree on the protocols, keys, and algorithms.

IKE not only negotiates but also maintains the security features applied to a communications channel by establishing a Security Association (SA) between communicating entities. An association can be defined as a one-way relationship between a sender and a receiver that are willing to communicate using a common security parameter to exchange the data traffic. If a peer relationship is needed, for two way secure exchange, then two security associations are to be

established. Security services are afforded to an SA for the use of AH or ESP, but not both [17].

A. Transport and Tunnel Modes Both AH and ESP support two modes of use: transport and

tunnel mode. Transport mode provides end to end communication. In this mode only payload of IP is encapsulated. For Examples a TCP/UDP segment or an ICMP packet, all of which operate directly above IP i.e. network layer. ESP in transport mode encrypts and can optionally authenticate the IP payload but the IP header remains unchanged. AH in transport mode provides authentication to the IP payload and selected portions of the IP header.

Tunnel mode provides protection to the entire IP packet. In

this mode of operation after the AH or ESP fields are added to the IP packet, the entire packet plus security fields are treated as the payload of new IP packet with a new IP header. The entire original packet travels through a "tunnel" from one point to another; no routers along the way are able to examine it. Because the original packet is encapsulated, the new larger packet might have totally different source and destination addresses, enhancing security feature. [18].

V. EXPERIMENTAL SETUP In this section we present our experiment and results to

address the following questions regarding the two alternative solutions for securing SNMP.

1. How much network capacity and processing time is incurred by a insecure SNMP communication?

2. How much network capacity and processing time is incurred by an IPsec based secure SNMP communication?

To find the answers to these questions we designed a testbed network performed some experiments on it, using the tools described in the following section.

A. Tools and Softwares Used in the Experiment Following tools and softwares were used in our experiment.

• MIB BROWSER [19] – Manager Software for SNMPv1, SNMPv2 and SNMPv3.It can send SNMP queries to a SNMP agent as well as receive the returned response.

• Windows XP SNMP Agent – Supports SNMPv1 and SNMPv2.

• Wireshark [20] – Packet Sniffer and Network Analyzer.

B. Testbed Network A 100-Mbps Ethernet testbed network was constructed as

Shown in Fig. 1. It consisted of a single subnet of 192.168.21.0 with IP assignment as 192.168.21.165 for Host-

The 6th International Conference on Telecommunication Systems, Services, and Applications 2011

978-1-4577-1442-9/11/$26.00 ©2011 IEEE 272

A and 192.168.21.116 for Host-B. Host-A used Pentium coreTM i3-530 Processor with clock Frequency of 2.93 Gigahertz and 2 Gigabytes of RAM, whereas Host-B used Pentium Dual core processor with clock frequency of 3.2 Gigahertz and 1.5 Gigabytes of RAM. Both host were running Windows XP Operating System and were physically located in Radio Engineering Lab of NED University. Host-A was loaded with MIB BROWSER performing the role of SNMP Manager while Host-B had a running windows SNMP agent. A common community string was set between the Agent and Manager. Wireshark software was also installed in Host-A with following two capture filters configured.

1) Filter-1 Name = Snmp only

Filter-1 String = udp src port 161 or dst port 161

2) Filter-2 Name = Ethernet address

Filter-2 String = ether host 70:71: BC: 0D: D8:26

IPsec was configured in Transport Mode, with pre-shared key authentication, and a UDP filter on port 161 for capturing only SNMP Traffic entering and leaving Host-A with the help of windows XP Local Security Policy.

C. Experiment and Results We first disabled any local security policy at both Hosts,

generated some ICMP packets and internet traffic on the hosts to simulate the loaded condition and then used the MIB BROWSER to initiate SNMP WALK action from Host-A towards Host-B with Object Identifier (OID): 1.3.6.1.2.1.1.1.0 till 1.3.6.1.4.1.77.1.4.1.0. We captured the packets using Wireshark with the help of Filter-1 applied. We exported the captured data using CSV file format to Microsoft Excel and choose 120 random samples to plot the Graphs for the delay incurred between GetRequest and GetResponse packets, shown in Fig. 2.with average delay computed as 0.6699 milliseconds (ms). We also noted the Ethernet Frame size for both the packets with the help of Wireshark. The average frame size for GetRequest Packet was found to be as 82 Bytes and for GetResponse packet as 216 Bytes.

Now we used Local Security Policy feature of Microsoft Windows and customized it for encapsulating SNMP packets only .We did this with the help of filter options [21] available. We added two filters for the UPD port 161 such that only traffic coming and leaving from this port is encapsulated with IPsec. With this security policy applied we again started the SNMP WALK from Host-A towards Host-B action from MIB BROWSER and repeated the same data capturing and plotting process. This time we obtained the delay Graph shown in Fig. 3 with average delay now computed as 0.775 ms. The Ethernet

Frame size for GetRequest Packet was now found to be 118 Bytes and 246 Bytes for the GetResponse packet. Finally we have plotted the combined graph in Fig. 4, to compare the delay in the insecure and secure communication.

VI. ANALYSIS OF EXPERIMENTAL RESULTS From the above figures of Section C , it is clearly evident

that in securing the SNMP based communication using IPsec the delay in receiving the response packet increases to only 8.5% while the header sizes for GetRequest and GetResponse packets increases by 1.2% to 1.4% which means that IPsec configured for SNMP only didn’t degrade the system performance.

It is also worth noting that when we configured the IPsec for all the traffic above IP layer, it resulted in isolation of our machines from all other hosts on the NED’s Network as well as disconnection from internet because we could only communicate with the hosts configured with same IPsec security policy. This means that if we configure IPsec on our system we can’t communicate with non-IPsec network elements. However our proposed solution for SNMP over IPsec based network management approach didn’t isolate the network from outside world.

VII. CONCLUSION Based on the above results we can say that our proposed

customized IPsec solution for SNMP in transport mode is a viable option for secure Management of a LAN using SNMPv2.The extra overheads and delay incurred is not troublesome because machines today have very high computing power and for securing the communication we always have to pay some cost. Our proposed methodology provides with confidentiality, data integrity, authentication and non-repudiation services for which the cost paid in terms of a bit increased processing load and delays is negligible.

Figure 2.

Cisco Layer-2 (2950) switch

SNMP agent

(windows)

SNMP agent

(windows)

Host-A Host-B

Figure 1. Testbed Network

The 6th International Conference on Telecommunication Systems, Services, and Applications 2011

978-1-4577-1442-9/11/$26.00 ©2011 IEEE 273

Figure 3.

Figure 4.

ACKNOWLEDGMENT We would like to express our gratitude to all those who

have helped and encouraged us for writing this paper. Especially we acknowledge the support and guidance of Dr. Attaullah Khawaja and Dr.Shoaib Zaidi Co-Chairman and Chairman Electronics Department, for their kind support in conducting this research work.

REFERENCES

[1] D. Harrington, R. Presuhn, B. Wijnen, “An Architecture for Describing SNMP Management Frameworks,” Internet Engineering Task Force RFC 2571, April 1999.

[2] J.Case, R.Mundy , D.Partain, and B. Stewart. Introduction and Applicability Statements for Internet Standard Management Framework RFC 3410, December 2002

[3] J. Case , M Fedor,M. Schoffstall,J. Davin, “ A Simple Network Management Protocol (SNMP) , RFC 1157, May 1990.

[4] J. Case ,M. Rose,S. Waldbusser , “Introduction To Community-based SNMPv2” , RFC 1901 , January 1996.

[5] Jürgen Schönwälder , Senior Member, IEEE, and Vladislav Marinov. IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 8, NO. 1, March 2011

[6] T. Ylonen and C. Lonvick, “The Secure Shell (SSH) Protocol architecture,"SSH Communications Security Corp, Cisco Systems, RFC 4251,Jan. 2006.

[7] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2," Independent, RTFM, RFC 5246, Aug. 2008.

[8] E. Rescorla and N. Modadugu, “Datagram transport layer security , "RTFM, Stanford University, RFC 4347, Apr. 2006.

[9] Vladislav Marinov and Jürgen Schönwälder , “Performance Analysis of SNMP over SSH” , R. State et al. (Eds.): DSOM 2006, LNCS 4269, pp. 25–36, 2006.

[10] H. Erik Hia and Scott F. Midkiff , “Securing SNMP Across Backbone Networks” ,2001 10th IEEE International Conference on Computer Communication and Networks,pp. 190-196 .

[11] Periklis Chatzimisios , “Security issues and vulnerabilities of the SNMP protocol” , 2004 1st International Conference on Electrical and Electronics Engineering.

[12] S. Kent and R. Atkinson, “Security architecture for the Internet Protocol,” Internet Engineering Task Force RFC 2401, November 1998.

[13] William Stalling , “Cryptography and Network Security Principles and Practices”, 4ed, pp. 484.

[14] S. Kent and R. Atkinson, “IP authentication header”, Internet Engineering Task Force RFC 2402, November 1998.

[15] S. Kent and R. Atkinson, “IP encapsulating security payload (ESP),” Internet Engineering Task Force “, RFC2406, November 1998.

[16] Harkins, D. and D. Carrel. “The Internet key exchange (IKE),” Internet Engineering Task Force RFC 2409, November 1998.

[17] William Stallings, Cryptography And Network Security” , 4ed , pp. 489-490.

[18] William Stallings, Cryptography And Network Security” , 4ed , pp. 492. [19] iReasoning Networks , MIB Browser (Personal Edition) ,

www.ireasoning.com/mibbrowser.shtml. [20] WireShark by EthReal , from www.wireshark.org website. [21] FreeBSD Diary , http://www.freebsddiary.org/ipsec-wireless-xp.php

The 6th International Conference on Telecommunication Systems, Services, and Applications 2011

978-1-4577-1442-9/11/$26.00 ©2011 IEEE 274