1. Introduction

1. Introduction

1.1. Overview

Ce document décrit une architecture pour décrire les cadres de gestion SNMP. L'architecture est conçue pour être modulaire afin de permettre l'évolution des normes de protocole SNMP au fil du temps.

Les principales parties de l'architecture sont:

• Un moteur SNMP qui fournit des services pour envoyer et recevoir des messages, authentifier et chiffrer des messages, et contrôler l'accès aux objets gérés.

• Une ou plusieurs applications SNMP qui utilisent les services du moteur SNMP pour exécuter des fonctions de gestion spécifiques.

L'architecture permet d'utiliser différents formats de messages et modèles de sécurité. Elle permet l'évolution des protocoles de sécurité sans perturbation majeure des implémentations SNMP.

1.2. SNMP

SNMP est un protocole de couche application pour échanger des informations de gestion entre les systèmes de gestion et les agents. SNMP est largement utilisé pour gérer les périphériques réseau tels que les routeurs, les commutateurs, les serveurs et les stations de travail.

La première version de SNMP, connue sous le nom de SNMPv1, a été définie dans les RFC 1155, 1157 et 1212. SNMPv1 utilise un modèle de sécurité simple basé sur les chaînes de communauté.

La deuxième version de SNMP, connue sous le nom de SNMPv2c, a été définie dans les RFC 1901-1908. SNMPv2c utilise le même modèle de sécurité que SNMPv1, mais ajoute de nouvelles opérations de protocole et types de données.

La troisième version de SNMP, connue sous le nom de SNMPv3, est définie dans les RFC 3410-3418. SNMPv3 ajoute des capacités de sécurité et de configuration à distance à SNMPv2c. Ce document fait partie du cadre SNMPv3.

1.3. Goals of this Architecture

Les principaux objectifs de cette architecture sont:

1. Modularité: L'architecture est conçue pour permettre d'utiliser différents formats de messages, modèles de sécurité et modèles de contrôle d'accès de manière indépendante.

2. Évolution: L'architecture permet d'ajouter de nouvelles fonctionnalités sans nécessiter de modifications aux implémentations existantes.

3. Sécurité: L'architecture fournit un cadre pour ajouter une sécurité forte à SNMP, y compris l'authentification, la confidentialité et le contrôle d'accès.

4. Coexistence: L'architecture permet à SNMPv1, SNMPv2c et SNMPv3 de coexister dans le même réseau.

5. Simplicité: L'architecture est conçue pour être aussi simple que possible tout en répondant aux autres objectifs.

1.4. Security Requirements of this Architecture

L'architecture fournit des facilités pour les services de sécurité suivants:

1. Intégrité des données: Garantit que les messages n'ont pas été altérés ou détruits de manière non autorisée. Ceci est accompli par l'utilisation de codes d'authentification de message.

2. Authentification de l'origine des données: Corrobore la source d'un message. Ceci est également accompli par l'utilisation de codes d'authentification de message.

3. Protection contre la relecture des messages: Garantit que chaque message est unique et ne peut pas être rejoué ultérieurement. Ceci est accompli par l'utilisation d'horodatages et d'identificateurs de message.

4. Confidentialité des données: Protège contre la divulgation de la charge utile du message par chiffrement.

5. Contrôle d'accès: Restreint l'accès aux objets gérés en fonction de l'identité de l'utilisateur et du type d'opération effectuée.

L'architecture traite également les menaces de sécurité suivantes:

• Mascarade: Une entité non autorisée se faisant passer pour une entité autorisée.

• Modification des informations: Une entité non autorisée altérant les messages en transit.

• Modification du flux de messages: Réorganisation, retard ou relecture de messages.

• Divulgation: Libération du contenu des messages à une entité non autorisée.

• Déni de service: Empêcher les utilisateurs autorisés d'accéder au système de gestion.

L'architecture ne traite pas les menaces suivantes:

• Analyse du trafic: Analyse des modèles de messages pour déduire des informations sur le réseau.

• **Attaques par déni de service qui consomment des ressources au niveau de l'agent ou du gestionnaire.

1.5. Design Decisions

Les décisions de conception suivantes ont été prises lors du développement de cette architecture:

1. Séparation du traitement PDU du traitement des messages: L'architecture sépare le traitement des unités de données de protocole (PDU) du traitement des messages. Cela permet d'utiliser différents formats de messages avec le même format PDU.

2. Modèles de sécurité multiples: L'architecture permet à plusieurs modèles de sécurité de coexister, permettant l'évolution des protocoles de sécurité.

3. Modèles de contrôle d'accès multiples: L'architecture permet à plusieurs modèles de contrôle d'accès de coexister, permettant différentes politiques de contrôle d'accès.

4. Séparation de l'authentification et de la confidentialité: L'architecture permet d'utiliser l'authentification et la confidentialité de manière indépendante. Cela permet l'authentification sans confidentialité, ce qui peut être requis dans certains environnements.

5. Utilisation d'interfaces de service abstraites: L'architecture définit des interfaces de service abstraites entre les composants principaux. Cela permet à différentes implémentations de chaque composant d'interopérer.

6. Accent sur la configuration à distance: L'architecture met l'accent sur la capacité de configurer à distance les paramètres de sécurité et de contrôle d'accès. Ceci est essentiel pour les déploiements à grande échelle.

7. Compatibilité ascendante: L'architecture est conçue pour permettre au même moteur SNMP qui traite les messages SNMPv3 de traiter les messages SNMPv1 et SNMPv2c.

8. Compatibilité future: L'architecture est conçue pour permettre l'ajout de nouveaux formats de messages et modèles de sécurité à l'avenir.