Transport Data Security in Network Management Systems Nisha P Kurur1 , Ishpal Singh Gill1 , N. Usha Rani2 , Timothy A. Gonsalves1 1 Department

of Computer Science and Engineering, Indian Institute of Technology Madras, Chennai, India {nisha,ishpal,tag}@lantana.tenet.res.in

Abstract— In today’s increasingly networked world, it is common for a Network Management System (NMS) to be used to automate and simplify different network administration tasks. The NMS has to retrieve information from the network elements (NEs). This data needs to be authentic, untampered and confidential. The focus of this paper is a secure transport mechanism for network management, which can be easily used to manage heterogeneous telecom networks. A survey of NEs based on their support for security was conducted which resulted in a classification of NEs into four groups. The transit security for each group is handled in a distinct manner such that the mechanism causes minimum overhead and provides maximum efficiency. We propose user-space VPN based encrypted tunnels for NEs with poor transit security mechanisms. We discuss a secure key exchange protocol, which has been overlaid on an existing user-space VPN software, enhancing the key exchange security. NEs that support secure transit mechanisms can reuse them for management traffic security.

I. I NTRODUCTION The rapid growth of Internet and other networked applications resulted in a need for NMS to automate and simplify different network administration tasks [1]. The use of NMS reduces the operational costs and enhances performance, thus benefiting the organization as well as its customers. By introducing an NMS for managing a heterogeneous network, additional information pertaining to the management activities flow through the network. It is very important that this sensitive information about the network, used for management operations, should not be revealed to any unauthorized sources. In addition, the NMS stores sensitive data regarding the managed network which should be safe-guarded against inappropriate access. Thus, securing an NMS is very important. This NMS security can be considered in three specific dimensions - secure transport, access control and secure storage. In most networks, the management and subscriber traffic share the same data links, making the management traffic vulnerable to security threats. The data collection from devices and configuration of devices may be done using any standard protocol like SNMP or FTP or some proprietary protocol supported by that particular device. Some of these protocols do not support any security mechanisms and thus the data traverses through the network in unencrypted format. This provide hackers good opportunities to threaten the devices. If a single

2 NMSWorks

Software Pvt. Ltd., Chennai, India [email protected]

router in the network gets compromised, the hacker could route all the traffic to an unauthorized destination, creating a major security breach. Hence, every other security measure taken becomes useless, once the network becomes compromised. NMS also allows configuration management which allows to change the configurations of managed elements remotely. If misconfigured due to tampering of data in transit, then there can be serious issues like hacking the device and controlling the flow of traffic through it. So it is essential that the data in transit should adhere to the three fundamentals of security confidentiality, integrity and authenticity (CIA). In this paper, we propose and explain the design and implementation of a secure transport mechanism for NMS data in transit [2]. We consider the heterogeneity typical of most telecom networks. The rest of the paper is organized as follows. In Section II, the various existing techniques for securing management traffic are discussed. In Section III, we present our classification of NEs based on the security mechanisms supported. User space tunnels are explained in Section IV while the design and implementation of this secure mechanism is dealt in Section V. Section VI gives the performance evaluation and inferences of various experiments conducted. We conclude in Section VII. II. R ELATED W ORK The most commonly used protocol for network management is SNMP (v1, v2c, v3). Only SNMPv3 has good security. However, it requires higher CPU power and hence is expensive to implement on an embedded device [3]. Moreover, SNMP is mainly used only for performance and fault management. It is difficult to achieve configuration management through SNMP as bulk configuration is inefficient using this protocol [4], [5]. Several techniques have been considered for performing these functions, out of which some have poor security. Another method of protecting management transit data is by means of encrypted tunnels which enable protocol independent security. There are three tunneling mechanisms - MPLS, kernel space and user space [6]. MPLS cannot be considered as it assumes a trusted network, which is not the case as we consider a heterogeneous network. In practice, IPSec is commonly used for the establishment of these secure tunnels

TABLE I

as many high end NEs support this tunneling mechanism. However, as we consider a heterogeneous network, there can be elements that do not support IPSec. Also, IPSec has a few disadvantages which are explained in Section IV.

IPS EC VS O PEN VPN Function IPSec Configuration hard Client authentication must Handshake time slow Pre-shared key yes Interoperability problems yes TCP application support yes UDP application support yes Throughput rate high Compression support yes Configuration of support for NAT difficult

III. H ETEROGENEOUS N ETWORKS The challenge is to provide a security mechanism for NMS traffic in heterogeneous networks. A heterogeneous network consists of various NEs, the diversity may be in the supported protocols, technologies etc. To secure data in transit, the NE needs to support security mechanisms. As part of the study to know the various secure protocols supported by heterogeneous NEs, a survey was conducted. This was done as part of the initial study since it was important to know about heterogeneous network elements and various security mechanisms supported by them. As result of the survey, it was found that there were no classifications of network elements based on the secure protocols supported. Hence, we propose a division of network elements into four classes, based on their support for security, as given below: Class 1: NEs that support very weak security with access control credentials and data passing through the network as plain text. Protocols used by such NEs include telnet, SNMPv1 or v2c. Access control is done by user namepassword pairs/community strings. Examples for such NEs are routers that connects a LAN to ISP, metro Ethernet switches, and many legacy systems which still form a part of modern networks. Class 2: NEs that support secure protocols either for configuration or for management but not for both. This class can be further subdivided into two - one which supports secure configuration only and other which supports secure management only. Class 2(a) Many devices use SSH or any other secure protocol for configuration and SNMPv1 or v2c for management. Here configuration is done securely but the insecurity problem exists for the management protocol as SNMPv1 and v2c are not secure. Examples for this type of NEs include SAN switches by various vendors. Class 2(b) The other extreme is to use SNMPv3 for management and telnet or other weakly secure protocols for configuration. Examples for this type are Nortel switches. Class 3: NEs that support secure protocols for both configuration and management. Protocols are SSH or SNMPv3 or any proprietary secure protocol. High end switches and routers manufactured by Cisco, 3Com etc come under this category. Class 4: NEs that support protocol independent security by establishing tunnels from the source to destination. Here the tunnels are setup using IPSec, or other secure tunnel establishment techniques. IPSec is supported by backbone routers that are involved in VPN setup. IV. U SER - SPACE T UNNELS - O PEN VPN To achieve transit security it is better to consider an option where the security is provided independent of the traffic type or protocols. As part of this, we studied various tunneling

OpenVPN easy option fast yes no yes yes high yes easy

mechanisms and found out that SSL VPNs are more suited for our requirements. We also conducted a study of SSL VPNs that are commonly used like OpenVPN, CIPE etc. OpenVPN was chosen for our implementation as it runs at application layer and hence reduces the security risk due to kernel-coupling [7], [8]. Kernel space VPNs, like IPSec, are used for setting up encrypted tunnels. However, there are a few disadvantages which are as given below [9]. •

•

•

•

IPsec has many possible configurations, some of which produce insecure architectures. Also it is difficult to use effectively due to its complexity. The nature of IPsec requires it to be tightly coupled with the OS kernel. If the code can interfere with kernel space, its failure is usually catastrophic for the entire system. Every compromise of a kernel-coupled component equals instant root access. Though IPsec is more flexible, as it can be used for protecting both TCP and UDP-based protocols, there is an increase of complexity and processing overhead, as it cannot rely on TCP to manage reliability and fragmentation. IPSec adds extra bytes to the original packet which creates more bandwidth overheads. Also the initial handshake takes a long time in IPSec and a retransmit timer should be maintained. Apart from these issues, IPSec is bound to specific ports [10].

In this paper we propose the use of user-space encrypted tunnels for security of NMS data in transit [11]. These tunnels provide security at the transport or higher layers and thus provide end-to-end security. Moreover, they are not kernel dependent, simple to use and configure, and give comparable performance with respect to its counterpart, kernel space VPN. There are several user space VPNs available, and of these, we chose OpenVPN. OpenVPN is an open source, user space tunneling package, that uses the OpenSSL library to provide encryption of both the data and control channels [12]. Usage of common network protocols (TCP and UDP) makes it a desirable one. It also has the ability to work through most proxy servers, and is good at working through NAT and getting out through firewalls. Last but not the least, a single process can manage multiple simultaneous tunnels. The comparison with IPSec is given in Table I.

Security Gateway

NMS Server

Tunnel Establishment Secure Key Exchange Protocol

Key Exchange Server Server

Client

symmetric key

Client

symmetric key

OpenVPN tunnel OpenSSL

OpenVPN

Server

Client OpenVPN

OpenSSL

Tunnel Management Telnet server

Fig. 1.

cmd status

Tunnel Mgmt Process

Tunnel Management Protocol Server

Client

Tunnel Mgmt Listener

Securing management traffic

OpenVPN has two modes of operation depending on the key for encryption 1) Static key mode - A pre-shared secret key exists at both ends of the VPN tunnel. With this key, the selected symmetric encryption algorithm is used to encrypt all traffic. 2) TLS mode - The secret key is exchanged using the Diffie-Hellman protocol (DH) [13] with all messages being digitally signed by both ends. This secret key is then used for tunnel encryption. V. S ECURE

TRANSPORT MECHANISM

A. Design From the above classification of NEs, it is clear that there cannot be a unique method to secure data in transit because different NEs support different levels of security. To achieve the maximum security available for a given heterogeneous network, it would be better to make use of existing secure mechanisms and provide protection only for those elements that are in need. So the proposal is to make use of the security mechanisms already available with class 3 and class 4 elements and to promote the concept of user space VPNs to provide security for data in transit for class 1 and class 2 elements. It is evident that class 1 and class 2 elements do not support any security primitives. Hence we place these elements in a subnet with a security gateway guarding the subnet (Fig. 1) . The data is secured, with the aid of user space VPN software, while it traverses the public network. The security gateway also serves as the entry point for the NMS traffic into this protected subnet. This architecture not only solves the problem of managing a heterogeneous network, but also has the advantage of being independent of traffic type. Another issue that needs to be addressed is secure access to the NMS by clients. The administrator should be able to login to the NMS from anywhere in case of urgency. So the access to the NMS should not be restricted only within the secure subnet. To achieve this, a secure web server that uses https protocol is provided for remote login users. This secures the data flow between remote client locations and the NMS server.

Fig. 2.

Proposed Design for secure transport

B. Implementation OpenVPN in TLS mode uses DH protocol for key exchange. We implement a new secure hybrid secret key exchange mechanism which is considered to be more secure than DH [14]. Additional to this implementation, we have developed a full fledged PKI solution with a key server. The details are discussed below. The new secure secret key exchange mechanism is based on the RSA-KEM [15] and RSA-PSS [16] schemes which are considered to be more secure than DH as per NESSIE consortium [17]. This exchange mechanism is overlaid on the static key mode of the OpenVPN. Thus, we define a hybrid mode for OpenVPN, where the default static mode is enhanced to provide the features like dynamic key exchange, tunnel management, which are only present in the default TLS mode. The enhancements are implemented in such a way that they are generic and can be reused for any user-space VPNs. This can further be used to improve VPN solutions that do not support on-the-fly key exchange mechanisms. The PKI (Public Key Infrastructure) implementation includes a public/private key pair generator and a Certificate Authority (CA) which certifies and generates digital certificates. Moreover, a multi-threaded key exchange server to exchange symmetric keys with utmost security has been developed. This server uses a newly designed protocol, namely Secure Key Exchange (SKE) protocol, based on RSA-PSS digital signature scheme and RSA-KEM hybrid key exchange scheme. Additional to these features, a tunnel management protocol has been developed for managing the encrypted tunnels (Fig. 2). C. Protocols 1) Secure Key Exchange Protocol - SKE Protocol: The key exchange is done when any security gateway (client) connects to the NMS (Fig. 2). The NMS server listens at a specific port to which the client sends a key request. Both the ends first authenticate each other through exchange and verification of digital certificates. Thereafter, in response to a ”Key Request” from the client, the server uses the RSA-KEM scheme to generate and send the key across. All the exchange messages are digitally signed using the RSA-PSS scheme thus guarding against man-in-the-middle attack (Fig. 3).

Client (Proxy NMS)

Server (NMS Server)

Mgmt Process (NMS Server)

Listens on port 10001. Interpret mgmt commands.

Telnet server on port 10000.

ation

Key Exchange Initi

Mgmt Listener (Proxy NMS)

Issue telnet command.

te

Send Client certifica

shutdown

Client certificate verification

OpenVPN client instance successfully terminated.

Send Server certifica

te

OK Server certificate verification ned)

Key Request (sig

Server OpenVPN instance shutdown. restart

RSA−KEM key generation Cipher text with key

New OpenVPN client instance started.

(signed)

OK RSA−KEM key extraction

Display status and close socket.

ned)

Key Received (sig

Fig. 4.

Fig. 3.

Secure Key Exchange protocol

The exchanged key is used as the seed to a key scheduler algorithm that generates 16 different keys. (Internally uses the AES key scheduling algorithm). This algorithm is run on both sides and the keys are written into a key file which is used for tunnel encryption. This step in the protocol is specific to OpenVPN as its key file contains 16 different keys, each used for a specific crypto functionality. The overheads due to this key exchange are minimal and come in play only once when the tunnel is initially established. Thereafter, all the NMS traffic flows with complete security through this tunnel with no overheads of key exchange or certification. The digital certificate exchange can be totally avoided in case the NMS server itself is assumed to be the CA, since the main aim of this exchange is to authenticate the public key of the other party. 2) Tunnel Management Protocol: When a client comes up initially, a client management listener is also started that listens to the management requests coming from the server. Tunnel management is done from the NMS server by using the telnet protocol locally (Fig. 2). This means that the tunnel management can only be done from the NMS server by connecting to a specific port. Also using telnet from remote machines to the NMS server is not allowed. Thus to do the tunnel management, the administrator has to personally come to the NMS server and execute these commands. Thus the commands given in the telnet prompt is within the same machine (i.e NMS server) and creates no security issues. On providing the management command at the telnet prompt, the server sends appropriate requests to the client management listener and thus coordinates various administrative functionalities provided for tunnel management. This protocol was developed mainly to enhance the static mode OpenVPN with the same features as provided by the TLS mode (Fig. 4). In this protocol, the VPN client has a management process listening for the commands from the VPN server. These commands enable a single window tunnel

Tunnel Management protocol - newkey command

management for multiple clients. The commands supported are : 1) status - current status of the tunnels. i.e., how many VPN tunnels are connected to the NMS server, what are the client’s real and virtual IPs, port number to which they are connected etc. 2) shutdown hclientIP i - shutdown the VPN client. 3) restart hclientIP i - restart the VPN client. 4) newkey hclientIP i - generate and exchange a new key with the VPN client. 5) quit - quit the management console. newkey command:(Fig. 4) When a newkey command is given at the management prompt, the server sends a request to the client management listener to shutdown the client instance of the OpenVPN. Once the client instance is successfully shutdown, the client management listener sends an OK message to the server. As soon as the server receives the OK message, the server shuts down the OpenVPN server instance for that particular client and on successful completion sends a client restart message. The client receives the message and restarts the client. Whenever the client starts, first a new key is exchanged using the SKE protocol, thereby successfully completing the newkey command. In short, the newkey command comprises of both the commands - shutdown and restart. VI. P ERFORMANCE E VALUATION AND A NALYSIS Performance evaluation is done by measurement. The parameters of interest are CPU utilization and time taken for key exchange. The aim of this evaluation is to estimate the overheads caused (if any) due to our implementation when compared with default key exchange of OpenVPN. A. Environment Server - AMD Sempron 1.6 GHz processor, 512 MB RAM, 100 Mbps Ethernet card Client - AMD Athlon 2.1 GHz processor, 512 MB RAM, 100 Mbps Ethernet card Link - 2Mbps link connecting two different LANs.

TABLE II K EY E XCHANGE TIME COMPARISON Key Exchange mechanism OpenVPN-DH OpenVPN-SKE No Encryption OpenVPN-DH OpenVPN-SKE

4

Time taken local (sec) 0.126 0.137 No Encryption OpenVPN-DH OpenVPN-SKE

6000 Time taken (in minutes)

% CPU Utilization

5

Time taken remote (sec) 0.157 0.226

3 2 1

5000 4000 3000 2000 1000

0 10 107

495

1100

0 10

19

File size (in MB)

(a) % CPU utilization

Fig. 5.

107 495 1100 File size (in MB)

(b) Time taken for file transfer

Server side measurements

B. Experiments Experiment 1 - Key exchange performance: This experiment was conducted in both the ways - server and client on same machine as well as on different machines. The former setup was used to evaluate the performance of the key exchange without network overheads while the latter gives a normal setup. The experiment was repeated 10 times and the average values were calculated. The comparison between the OpenVPN with DH key exchange and the OpenVPN with SKE is shown in Table II. The times are seen to be very small. The time for key exchange can be further reduced if the digital certificates are exchanged only when they expire. Normally, the validity of the certificate is 6-12 months. Experiment 2 - File transfer performance: The measurements were carried out with file transfers of various sizes (10MB, 19MB, 107MB, 495MB and 1100 MB) through the VPN tunnel. The aim was to calculate the CPU utilization and the time taken for file transfer and estimate whether overheads are caused. The file transfer was conducted 10 times for each file size and the average values were calculated. It is clear that the CPU utilization is not increased considerably (Fig. 5(a)). This means that the CPU utilized is almost the same for OpenVPNDH and OpenVPN-SKE. Similarly, time taken for file transfers through OpenVPN-DH and OpenVPN-SKE are almost the same (Fig. 5(b)). VII. C ONCLUSIONS

AND

F UTURE

WORK

In this paper we have discussed various mechanisms for securing the transport data in an NMS. We have proposed the use of SSL VPNs for those NEs where no security mechanism is implemented. Also, as part of the implementation for making the SSL VPN key exchange secure, a new protocol namely Secure Key Exchange (SKE) has been designed and implemented. The SKE and Tunnel Management protocols designed for the VPN solution are generic and can be integrated wherever a secure key exchange and tunnel management protocols are required. The results of the performance measurements for the applications using these primitives have been very promising. For example, the OpenVPN using RSA-KEM

hybrid scheme show that it provides stronger security at a comparable efficiency to the existing OpenVPN package. The idea of implementing the SKE server as separate process was to enable the key exchange part independent of the VPN solution, i.e. the proposed method can be used along with any user space VPN solution with minor modifications. The key exchange server runs as an overlaid process on the OpenVPN which adds overheads on the VPN server since each client connection is handled by a separate instance. This can be improved by making the key exchange an integral process of the OpenVPN. However, this is related to software customization. The current design allows key management only from the server side using the tunnel management protocol (newkey command). This can be improved to enable key management from either side. The key management can also be automated instead of the present manual mechanism. R EFERENCES [1] Mani Subramaniam, Network Management - Principles and Practices, Addison-Wesley, 2000. [2] Nisha P Kurur, N Usha Rani, and Timothy A Gonsalves, “Securing Network Management Systems,” Tech. Rep., DON Lab, Computer Science Dept., Indian Institute of Technology Madras, 2006. [3] T. SenthilNathan, “Analysis and Design of an Embedded Management agent,” M.S. thesis, Computer Science Dept., Indian Institute of Technology, Madras, 2006. [4] L Sanchez, K McCloghrie, and J Saperia, “RFC 3139 - Requirements for Configuration Management of IP-based Networks,” June 2001. [5] J Schoenwaelder, “RFC 3535 - Overview of the 2002 IAB Network Management Workshop,” May 2003. [6] Jon C Snader, VPNs Illustrated: Tunnels, VPNs, and IPsec, AddisonWesley, Oct. 2005. [7] Charlie Hosner, “OpenVPN and the SSL VPN Revolution,” http://www.sans.org/rr/whitepapers/vpns/1459.php, Aug. 2004. [8] Matthew D Wilson, “VPN HOWTO,” http://www.tldp.org/HOWTO/ VPN-HOWTO, Dec. 1999. [9] Charlie Hosner, “SSL VPNs and OpenVPN: A lot of lies and a shred of truth,” http://software.newsforge.com/article.pl?sid=05/09/22/164231 &from=rss, Sept. 2005. [10] AbdelNasir Alshamsi and Takamichi Saito, “A Technical Comparison of IPSec and SSL,” in Proc. of 19th Intl. Conf. on Advanced Information Networking and Applications (AINA’05), Mar. 2005, vol. 2, pp. 392–395. [11] James Yonan, “VPN Solutions,” http://openvpn.net/papers, 2003. [12] Vinayak Hegde, “Encryption using OpenSSL’s crypto libraries,” Linux Gazette Mag., vol. 87, 2003. [13] W Diffie and M E Hellman, “New directions in cryptography,” in IEEE Trans. on Information Theory 22, 1976, pp. 644–654. [14] Ishpal Singh Gill, “An Encryption Schema for Army Networks,” Tech. Rep., (MTech), DON Lab, Computer Science Dept., Indian Institute of Technology Madras, 2006. [15] A. W. Dent, “ACE-KEM and the general KEM-DEM structure,” NESSIE Internal report, 2002. [16] J. Jonsson, “Security proof for the RSA-PSS signature scheme,” in Proc. of 2nd NESSIE Workshop, 2001. [17] NESSIE, “The New European Schemes for Signature, Integrity, and Encryption,” http://www.cryptonessie.org, Feb. 2000.