Skip to main content

1. Introduction

1. Introduction​

1.1. Overview​

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time.

The major portions of the architecture are:

  • An SNMP engine which provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects.

  • One or more SNMP applications which use the services of the SNMP engine to perform specific management functions.

The architecture permits different message formats and security models to be used. It permits the evolution of security protocols without major disruption to SNMP implementations.

1.2. SNMP​

The SNMP is an application layer protocol for exchanging management information between management systems and agents. SNMP is widely used for managing network devices such as routers, switches, servers, and workstations.

The first version of SNMP, known as SNMPv1, was defined in RFCs 1155, 1157, and 1212. SNMPv1 uses a simple security model based on community strings.

The second version of SNMP, known as SNMPv2c, was defined in RFCs 1901-1908. SNMPv2c uses the same security model as SNMPv1, but adds new protocol operations and data types.

The third version of SNMP, known as SNMPv3, is defined in RFCs 3410-3418. SNMPv3 adds security and remote configuration capabilities to SNMPv2c. This document is part of the SNMPv3 framework.

1.3. Goals of this Architecture​

The main goals of this architecture are:

  1. Modularity: The architecture is designed to allow different message formats, security models, and access control models to be used independently.

  2. Evolution: The architecture allows new features to be added without requiring changes to existing implementations.

  3. Security: The architecture provides a framework for adding strong security to SNMP, including authentication, privacy, and access control.

  4. Coexistence: The architecture allows SNMPv1, SNMPv2c, and SNMPv3 to coexist in the same network.

  5. Simplicity: The architecture is designed to be as simple as possible while meeting the other goals.

1.4. Security Requirements of this Architecture​

The architecture provides facilities for the following security services:

  1. Data Integrity: Ensures that messages have not been altered or destroyed in an unauthorized manner. This is accomplished through the use of message authentication codes.

  2. Data Origin Authentication: Corroborates the source of a message. This is also accomplished through the use of message authentication codes.

  3. Message Replay Protection: Ensures that each message is unique, and cannot be replayed at a later time. This is accomplished through the use of time stamps and message identifiers.

  4. Data Confidentiality: Protects against disclosure of the message payload through encryption.

  5. Access Control: Restricts access to managed objects based on the identity of the user and the type of operation being performed.

The architecture also addresses the following security threats:

  • Masquerade: An unauthorized entity pretending to be an authorized entity.

  • Modification of Information: An unauthorized entity altering messages in transit.

  • Message Stream Modification: Reordering, delaying, or replaying messages.

  • Disclosure: Releasing message contents to an unauthorized entity.

  • Denial of Service: Preventing authorized users from accessing the management system.

The architecture does not address the following threats:

  • Traffic Analysis: Analysis of message patterns to infer information about the network.

  • **Denial of Service attacks that consume resources at the agent or manager.

1.5. Design Decisions​

The following design decisions were made in developing this architecture:

  1. Separation of PDU processing from message processing: The architecture separates the processing of protocol data units (PDUs) from the processing of messages. This allows different message formats to be used with the same PDU format.

  2. Multiple security models: The architecture allows multiple security models to coexist, allowing for the evolution of security protocols.

  3. Multiple access control models: The architecture allows multiple access control models to coexist, allowing for different access control policies.

  4. Separation of authentication and privacy: The architecture allows authentication and privacy to be used independently. This allows for authentication without privacy, which may be required in some environments.

  5. Use of abstract service interfaces: The architecture defines abstract service interfaces between the major components. This allows different implementations of each component to interoperate.

  6. Emphasis on remote configuration: The architecture emphasizes the ability to remotely configure security and access control parameters. This is essential for large-scale deployments.

  7. Backward compatibility: The architecture is designed to allow SNMPv1 and SNMPv2c messages to be processed by the same SNMP engine that processes SNMPv3 messages.

  8. Forward compatibility: The architecture is designed to allow new message formats and security models to be added in the future.

Last updated on