11.4. Use of Reports (Utilisation des rapports)

11.4. Use of Reports (Utilisation des rapports)

Cette section décrit comment l'USM utilise le mécanisme de rapport (Report) SNMP pour communiquer des erreurs et d'autres informations.

Report PDU (PDU de rapport)

Le PDU de rapport (Report PDU), défini dans [RFC3416], est utilisé par l'USM pour retourner des informations sur les erreurs survenues pendant le traitement des messages. Les rapports sont particulièrement importants pour:

1. Découverte (Discovery) - retourner le snmpEngineID du moteur autorisé
2. Synchronisation temporelle (Time synchronization) - retourner les valeurs de temps actuelles du moteur
3. Notification d'erreur (Error notification) - indiquer des erreurs d'authentification, de confidentialité ou autres erreurs liées à la sécurité

USM Statistics (Statistiques USM)

L'USM maintient plusieurs compteurs qui suivent diverses conditions d'erreur. Ces compteurs sont définis dans le groupe usmStats du module MIB (section 5):

• usmStatsUnsupportedSecLevels - Messages avec des niveaux de sécurité non pris en charge
• usmStatsNotInTimeWindows - Messages en dehors de la fenêtre temporelle
• usmStatsUnknownUserNames - Messages avec des noms d'utilisateur inconnus
• usmStatsUnknownEngineIDs - Messages avec des ID de moteur inconnus
• usmStatsWrongDigests - Messages avec des résumés d'authentification incorrects
• usmStatsDecryptionErrors - Messages avec des erreurs de déchiffrement

Report Generation (Génération de rapport)

Lorsque l'USM détecte une erreur lors du traitement d'un message entrant, il PEUT (MAY) générer un Report-PDU contenant:

1. L'objet compteur de statistiques USM approprié
2. La valeur actuelle de ce compteur
3. Le msgID pertinent du message reçu (pour la correspondance)

Considérations importantes:

• Les rapports ne sont PAS toujours générés pour chaque erreur. La décision dépend du niveau de sécurité et du type d'erreur.
• Les rapports pour certaines erreurs (comme usmStatsNotInTimeWindows pour la découverte) sont utilisés de manière constructive.
• Les rapports NE DOIVENT PAS (MUST NOT) être envoyés en réponse à un autre rapport pour éviter les boucles infinies.

Security Levels for Reports (Niveaux de sécurité pour les rapports)

Les rapports sont envoyés avec des niveaux de sécurité variables selon l'erreur:

1. noAuthNoPriv - Utilisé pour:

   • Découverte (engineID inconnu)
   • Échecs de synchronisation temporelle
   • Noms d'utilisateur inconnus

2. Identique à la requête - Utilisé pour:

   • Échecs d'authentification (résumé incorrect)
   • Erreurs de déchiffrement
   • Erreurs hors fenêtre temporelle (après synchronisation)

Report Reception (Réception de rapport)

Lorsqu'un générateur de commandes ou un initiateur de notification reçoit un Report-PDU:

1. Réponse de découverte: Si le rapport contient usmStatsUnknownEngineIDs et que le varBind contient un engineID non nul, l'application a réussi à découvrir l'identité du moteur autorisé.

2. Réponse de synchronisation temporelle: Si le rapport contient usmStatsNotInTimeWindows, l'application devrait extraire msgAuthoritativeEngineBoots et msgAuthoritativeEngineTime des securityParameters et mettre à jour son cache local.

3. Indication d'erreur: Pour les autres types de rapports, l'application devrait traiter le rapport comme une indication que la demande originale a échoué pour la raison spécifiée.

Report Handling Best Practices (Meilleures pratiques de gestion des rapports)

1. Éviter les tempêtes de rapports: Les implémentations devraient limiter le débit ou supprimer la génération de rapports pour éviter la congestion du réseau.

2. Enregistrer les rapports: Les rapports liés à la sécurité devraient être enregistrés pour l'audit et l'analyse de sécurité.

3. Retour d'information utilisateur: Les applications devraient fournir un retour d'information clair aux utilisateurs lorsque les rapports indiquent des échecs d'authentification ou d'autorisation.

4. Erreurs de fenêtre temporelle: Après plusieurs rapports usmStatsNotInTimeWindows, les implémentations devraient suspecter un décalage d'horloge et peuvent nécessiter une intervention manuelle.

Privacy and Reports (Confidentialité et rapports)

Les rapports générés en réponse à des messages avec confidentialité peuvent nécessiter un traitement spécial:

• Si le déchiffrement échoue, le rapport devrait indiquer usmStatsDecryptionErrors.
• Le rapport lui-même devrait être envoyé avec le même niveau de sécurité que celui demandé dans le message original, si possible.
• Si le niveau de sécurité ne peut pas être déterminé (par exemple, en raison d'une corruption grave du message), le rapport devrait être envoyé avec noAuthNoPriv.