Network Operations and Control Wiki
Register
Advertisement

Paper: On the Impact of Security Protocols on the Performance of SNMP
The content of this wiki page was adapted from the paper above. All credit goes to original authors.

Background: Know: SNMP security, Recognize: SNMP and UDP, SNMP fragmentation

The paper [1] describes how SSH, TLS, and DTLS can be used to take advantage of already deployed key management infrastructures and hence reduce the operating expenses associated with securing SNMP. The performance between the various options to secure SNMP are discussed before concluding guidelines for choosing solutions.

SNMP Architecture[]

The SNMP architecture defined in [2] and [3] allows for the addition of future protocol extensions such as additional security models or transports.

Structure of an SNMP entity according to the SNMPv3 architecture

SNMP Engine[]

The SNMP engine consists of a dispatcher and several subsystems. Each subsystem can contain multiple models implementing the services. Abstract Service Interfaces (ASIs) are used between the communicating subsystems.

  • Dispatcher
The dispatcher organises the data flow coming from transports, going up to applications and back to the network through the engine.
  • Message Processing subsystem
Different versions of SNMP messages, e.g., SNMPv1, SNMPv2c, and SNMPv3, are to be dispatched to their own message processing models.
  • Security subsystem
The SNMPv3 message processing model uses the User-based Security Model (USM) [4] while the SNMPv1 and SNMPv2c message processing models use the Community-based Security Model (CSM) [5] to provide security services on a per SNMP message basis, so called message-based security. To address the limitations of the original message-based architecture design, the Transport Security Model (TSM) [6] was introduced to interact with session-based secure transports through a shared cache.
  • Access Control subsystem
The View-based Access Control Model (VACM) is available in SNMPv3 to provide the access control mechanism.
  • Transport subsystem
The transport subsystem, which was not part of the original SNMP architecture, has been defined by the Integrated Security Model for SNMP (ISMS) working group of the Internet Engineering Task Force (IETF) to allow multiple transport protocols to be "plugged into" an SNMP engine. [1] The SSH Transport Model (SSHTM) [7] and the (D)TLS Transport Model (TLSTM) [8] provide security services on a per session basis, so called session-based security.

Message-based Security[]

  • Community-based Security Model
The CSM used by SNMPv1 and SNMPv2c are not secure as the community strings are trasmitted in plain text across the network.
  • User-based Security Model
The USM used by SNMPv3 provides three levels of security:
  • noAuthNoPriv (nn): no authentication, no encryption
  • authNoPriv (an): message authentication, message integrity, timeliness checking, but no encryption
  • authPriv (ap): security services plus encryption of the payload of SNMP messages
The time-sequence diagram below shows IP packets exchanged when executing a SNMP GET operation of SNMPv2c and SNMPv3/USM over UDP and TCP, including the typical TCP connection establishment and teardown exchange. The GET/REPORT exchange is usually used for the engine discovery and the USM clock synchronisation.
IP packets exchanged by executing a single SNMP GET operation

Session-based Security[]

  • Transport Security Model
The Transport Security Model (TSM) implements the ASIs of the security subsystem to provide the security information to the rest of the SNMP engine via the shared cache. From a performance perspective, the TSM processing costs are negligible since it only passes existing information while the actual translation of transport-specific and SNMP-specific security parameters happens within a secure transport model. [1]
  • SSH Transport Model
The Secure Shell (SSH) protocol [9] provides secure network services over an insecure network. It is composed of three layers:
  • The Transport layer uses public-key cryptography to authenticate the server, handles key exchanges, and setups a secure connection over a reliable data stream.
  • The User Authentication layer supports a number of methods to authenticate the client.
  • The Connection layer allows a single connection to host multiple channels simultaneously.
  • TLS Transport Model (for TLS)
The Transport Layer Security (TLS) protocol [10] is widely used to secure application layer protocols. It is composed of two layers:
  • The Record layer can be implemented on top of transport layer protocols to provide security services by encapsulating the application layer protocols.
  • The Handshake layer allows the server and client to authenticate each other and negotiate various parameters to establish a secure connection.
The TLS session resumption mechanism uses the security parameters cached during the previous session to bypass expensive key exchange procedure when resuming the session, consequently saving the server load and more importantly round trip time. Note that while TLS supports multiple authentication methods, TLSTM requires the use of X.509 certificates.
  • TLS Transport Model (for DTLS)
The Datagram Transport Layer Security (DTLS) protocol [11] is based on TLS but provides secure communication over unreliable datagram transports. It is composed of two layers similar to TLS:
  • The DTLS Record layer adds an explicit sequence number to allow the recipient to verify the TLS MAC for Anti-replay and message reordering protections.
  • The DTLS Handshake layer assigns a sequence number to each handshake message, as TLS messages are required to be transmitted and received in a defined order. Each handshake message may be fragmented over several records if the given datagram is small. The stateless cookie exchange is added to the initial handshake to prevent denial of service attacks.
The time-sequence diagram shows SSHTM has the longest process among all models since it needs three phases to establish the connection. In the scenario, the authentication requires several trips to discover available authentication mechanisms and try them in sequence. As for the TLSTM with and without session resumption, the diagram shows minor differences. However there is a significant difference in terms of CPU cycles needed and the resulting latency, as will be shown in the later measurement. DTLSTM requires less packets than TLSTM due to its transport being UDP.
IP packets exchanged by executing a single SNMP GET operation

Performance Evaluation[]

The performance reports were based on the prototype implementation of SNMP over SSH/TLS/DTLS developed as an extension of the Net-SNMP SNMP implementation. The libssh library was used for the SSH protocol, and the OpenSSL library was used for the TLS/DTLS protocols.

Machines used
Name CPUs RAM Ethernet
meat (fast) 2 Xeon 3 GHz 2GB 1 Gbps
veggie 2 Xeon 3 GHz 1GB 1 Gbps
turtle (slow) 1 Ultra Sparc IIi 128 MB 100 Mbps
Security features configured
Protocol Authentication Encryption Compression
USM/ap HMAC-MD5 AES-128 -
SSH HMAC-MD5 AES-128 null
TLS HMAC-MD5 AES-128 null

Session Establishment[]

The table below shows the latency measurement of performing SNMP GET operations on the scalar sysDescr.0 using different versions of SNMP with agents on a fast machine and a slow machine.
Performance of a single SNMP GET request
  1. TCP has connection setup and teardown overhead resulting in a larger number of round trips and hence the higher latency. Otherwise the performance of SNMPv1 and SNMPv2c is similar.
  2. The USM discovery exchange makes SNMPv3/USM/nn more expensive than SNMPv1/SNMPv2c. However the overhead for enabling the authentication and privacy in USM is relatively small.
  3. The session establishment involves cryptographic operations, resulting in significant delays, especially noticeable on the slow machine. SSH has higher delay and bandwidth usage due to more messages required than TLS/DTLS.
  4. With session resumption, TLSsr is close to USM in terms of bandwidth consumed and packets exchanged while the session key verification overhead contributes the higher latency.

Latency without Packet Loss[]

In this and the following sections, the performance is measured by walking the ifTable.
Walking the iftable 1

Latency for USM on slow (upper three curves) machine and a fast machine

  • USM/ap incurs largest delay followed by USM/an and USM/nn. However the difference is relatively small even on a slow machine, indicating little benefit in removing auth/priv.
Walking the iftable 2

Latency for protocols using auth/priv on a fast machine

  • The delays of these protocols are similar. The minor differences are mainly due to variations caused by the OS at that time.
  • Same results are observed on a slow machine, indicating the difference of protocols do not have much impact on delays if using similar hash functions and encryption transformations. [1]
Walking the iftable 4

Latency over UDP & TCP on a slow machine

  • The delays almost have no difference between UDP and TCP.
  • The result is the same on a fast machine, as what may be expected in a fast reliable network.

Bandwidth Usage[]

Snmpwalk iftable

Bandwidth consumed by USM, SNMPv2c/UDP and SNMPv2c/TCP

  • The upper three curves show the bandwidth used by USM/ap, USM/an and USM/nn, respectively, confiming the increase in message sizes due to security parameters carried.
  • The lower two curves indicate the usages for SNMPv2/TCP and SNMPv2/UDP respectively, showing that TCP costs more bandwidth than UDP as expected due to its bigger headers.
  • One interesting observation is that the overhead incurred by securing USM with HMAC-MD5 and AES-128 and the one caused by moving from UDP to TCP are about the same.
Snmp iftable 2

Bandwidth consumed by USM, TSM/SSH, TSM/TLS and TSM/DTLS

  • The curves from top to bottom represent the bandwidth used by TSM/TLS, TSM/SSH, USM, and TSM/DTLS, respectively, showing that USM and DTLS benefit from shorter UDP headers.
  • TLS consumes most bandwidth followed by SSH, indicating its less efficiency in message encodings.
  • SSH is close to USM though they are running on different protocols.
Table 3

Packet sizes for all security model/transport/security level combinations by sending 2310 GetNext requests

  • The table confirms TCP header overhead as the dominating packet sizes for TCP are larger than UDP.
  • SSH is more compact than TLS and USM/TCP/ap.
  • The result indicates that Piggybacking of ACKs works well for TCP-based transports as most of the packets are within dominating size range, i.e., only very few small ACKs and handshakes packets are left. [1]

Latency with Packet Loss[]

Table iv

Latency comparison of SNMP GetNext walks ifTable under packet loss

  • The table compares the lantency of different protocols suffering from 1% packet loss with the SNMP retransmission timeout set to 10ms and 100ms.
  • TCP's retransmission algorithm clearly performs better than the non-adaptive retransmission strategy used by NET-SNMP, i.e., linear backoff with a fixed retransmission timeout.

Impact of Bulk Retrieval[]

Figure 10

Latency for TMS/SSH performing SNMP GetBulk walks ifTable with different max-repetitions parameters

  • A GetBulk walk with r = 1 is similar to a GetNext walk. As the max-repetitions parameter increases, the number of interaction needed reduces and the overall latency improves.
  • The table below provides the latency comparison of USM, SSH, TLS and DTLS retrieving 2310 objects, showing similar figures.
  • While in the best case r reduces the number of interactions to 1/r, the same factor of the latency improvement is not seen, due to the larger response messages and the fact that startup costs are not affected by the usage of GetBulk.
Table v

Latency comparison of SNMP GetBulk walks ifTable with different max-repetitions parameters

Key Findings[]

  • The session resumption feature of TLS reduces the session reestablishment costs significantly. The resumption mechanism for SSH has yet to be standardised.
  • The difference between USM, SSH, TLS and DTLS in terms of latency is small after the session is established.
  • The non-adaptive SNMP retransmission algorithm is outperformed by TCP algorithms in packet loss networks.
  • The usage of GetBulk dramatically reduces the number of requests sent over the network, resulting in much better overall performance.

Guidelines for Choosing Suitable Solutions[]

SNMPv3/TSM/SSH[]

SSHTM
  • It integrates well with CLI management interfaces. [7]
  • It allows for integration with AAA servers using RADIUS [12] or Diameter [13].
  • The SSH user identity can be easily mapped to securityName for VACM.
  • SSH is efficient in encoding messages.
  • con: SSH incurs large session establishment overhead and is lack of session resumption mechanisms.
TCP
  • TCP supports large SNMP messages better than UDP does.
  • TCP retransmission algorithms work well in networks with low loss rates.
  • con: TCP retransmission algorithms might not be problematic if the packet loss rate is high enough to cause retransmission timeouts, which may eventually leand to the throughput degradation.

SNMPv3/TSM/SSH is a good choice where networks are reliable, long-lived sessions are possible, and AAA integration is required.

SNMPv3/TSM/TLS[]

TLSTM
  • The session resumption feature reduces the load.
  • TLS has less session startup overhead than SSH.
  • con: TLS is less efficient in encoding messages than SSH.
  • con: The derivation of securityName is complicated.
  • con: It is lack of good AAA integration. [1]
  • con: A X.509 public key infrastructure must be in place.
TCP
  • SNMPv3/TSM/TLS shares the same pros and cons of using TCP as mentioned earlier in SNMPv3/TSM/SSH.

SNMPv3/TSM/TLS is a good choice where networks are fairly reliable with an already deployed X.509 public key infrastructure.

SNMPv3/TSM/DTLS[]

(D)TLSTM
  • It shares most of the pros and cons of TLSTM.
UDP
  • DTLS has smaller framing overhead than TLS since there is no TCP header.
  • Applications have control over retransmissions, although application retransmission timers are to be coordinated with DTLS retransmission timers. [1]

SNMPv3/TSM/DTLS is a good choice where application retransmission mechanisms can work well in less reliable networks, with an already deployed X.509 public key infrastructure.

SNMPv3/USM/UDP[]

USM
  • A separate key management infrastructure ensures the availability of security functions regardless of the presence of other infrastructures.
  • con: Deploying a new key management infrastructure is expensive.
  • con: It is lack of AAA integration.
UDP
  • It works efficiently if SNMP interactions are sporadic. [1]
  • Applications can have full control over retransmissions.
  • con: It would suffer from IP fragmentation for bulk data transfers.

SNMPv3/USM/UDP is a good choice where the number of SNMP interactions is relatively small, applications can benefit from full controls over retransmissions, and only a limited number of users require SNMP access.

See also[]

References[]

  1. 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 J. Schonwalder and V. Marinov, "On the Impact of Security Protocols on the Performance of SNMP", ;presented at IEEE Transactions on Network and Service Management, 2011, pp.52-64.
  2. Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
  3. Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
  4. Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
  5. Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
  6. Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
  7. 7.0 7.1 Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
  8. Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011.
  9. Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
  10. Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  11. Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
  12. Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  13. Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Advertisement