Presentation is loading. Please wait.

Presentation is loading. Please wait.

SNMPv3 * * Mani Subramanian “Network Management: Principles and practice”, Addison-Wesley, 2000.

Similar presentations


Presentation on theme: "SNMPv3 * * Mani Subramanian “Network Management: Principles and practice”, Addison-Wesley, 2000."— Presentation transcript:

1 SNMPv3 * * Mani Subramanian “Network Management: Principles and practice”, Addison-Wesley, 2000.

2 SNMPv3  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  View-based Access Control Model (VCAM)

3 Background  SGMP: monitor gateways  SNMP: simple but powerful facilities to monitor and control NEs o SMI o MIB o Protocol  SNMP deficiencies:  Difficulties in monitoring networks as opposed to nodes on networks,  RMON  Lack of security facilities, S-SNMP  SNMPv2 SNMPv2  SNMPv2 Working Group: charged with all non security aspects oSMI, MIB, Protocol, Conformance issues, compatibility issues  SNMPv2 Security WG oBased on S-SNMP, many unresolved issues  SNMPv2 was finally issued w/out security features and security work and previous efforts resulted in creating a new standard, SNMPv3

4 Design Requirements  Address the need for secure support (especially those required by set- request operations)  Define and architecture that allows for longevity for SNMP  Allow different portions of the architecture to move at different speeds towards standard status  Allow for future extensions (Modular Implementation)  Keep SNMP simple  Allow for minimal implementations  Support also more complex features, which are required in large networks  Re-use existing specifications, whenever possible

5 Security Threats Modification of Information  an entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object Masquerade  management operations not authorized for some entity may be attempted by assuming the identity of another entity that has the appropriate authorizations Management Entity A Management Entity B Modification of information Masquerade Message stream modification Disclosure

6 Security Threats Message Stream Modification  SNMP is typically based upon a connectionless transport service. Messages may be maliciously re- ordered, delayed or replayed, in order to effect unauthorized management operations. o For example, a message to reboot a system could be copied and replayed later Disclosure  Eavesdropping or intercepting on the exchanges between SNMP engines Management Entity A Management Entity B Modification of information Masquerade Message stream modification Disclosure

7 Security Threats SNMPv3 is not intended to secure against these two threats: Denial of Service:  An attacker may prevent exchanges between manager and agent  DOS are indistinguishable from network element failures  DOS may disrupt all services (not just those pertaining to NM) Traffic Analysis:  An attacker may observe the general pattern of traffic between managers and agents Management Entity A Management Entity B Modification of information Masquerade Message stream modification Disclosure

8 SNMPv3  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  View-based Access Control Model (VCAM)

9 SNMP Architecture  Distributed, interacting collection of SNMP entities  SNMP entity implements a portion of the SNMP capability:  It acts either as an agent or manager or both  A collection of modules interacting with each other to provide services

10 SNMP Architecture Advantages:  The role of SNMP entity is determined by the modules implemented in that entity o Certain set of modules are required for agent, while a different set is required for a manager  Security subsystem provides services such as authentication and privacy of messages o Multiple security models can coexist  Set of authorization services an application can use for checking access rights o Access Control

11 SNMP Architecture-Manager NOTIFICATION RECEIVER COMMAND GENERATOR PDU DISPATCHER USER BASED SECURITY MODEL OTHER SECURITY MODEL SECURITY SUBSYSTEM SNMPv1 SNMPv2C SNMPv3 OTHER MESSAGE PROCESSING SUBSYSTEM MESSAGE DISPATCHER TRANSPORT MAPPINGS NOTIFICATION ORIGINATOR SECURITY MODEL COMMUNITY BASED

12 SNMPv3 Architecture-Manager  Command Generator Application o Monitor and manipulate management data at remote agents o Make use of SNMPv1,v2 PDUs: Get, GetNext, GetBulk, etc.  Notification Originator Application  Initiates messages, such as InformRequest PDU  Notification Receiver Application o Receive messages from other managers or agents o InformRequest, SNMPv1- and SNMPv2-Traps, etc…  These applications make use of the services provided by the SNMP engine: o Get Outgoing PDUs, process them and generates SNMP messages for transmission over the transport layer o Accept incoming SNMP messages, process them, and extracts PDUs and passes them to appropriate SNMP application

13 SNMPv3 Architecture-Manager  One dispatcher in an SNMP engine o Accepts PDUs from applications o Handles multiple version messages (SNMPv1, v2, v3) o Interfaces with application modules, network, and message processing models  Three components for three functions  Transport mapper delivers messages over the transport protocol  Routes messages between network and appropriate module of MPS  PDU dispatcher handles messages between application and MPS SNMP Engine (identified by snmpEngineID) Dispatcher Message Processing Subsystem Security Subsystem

14 SNMPv3 Architecture-Manager  Accepts outgoing PDUs from Dispatcher, attach appropriate header, and return message to Dispatcher  Accepts incoming messages, process each message header, and return the enclosed PDU to the Dispatcher  Contains one or more Message Processing Models, each for each SNMP version  SNMP version identified in the header SNMP Engine (identified by snmpEngineID) Message Processing Subsystem Security Subsystem Dispatcher

15 SNMPv3 Architecture-Manager  Security subsystems perform authentication and encryption functions for each outgoing/incoming message  Outgoing PDUs may be encrypted and authentication codes generated and appended to the message header o The message is then returned to the MPS  Incoming messages are passed to the security subsystem o Message decryption o Messages authenticated SNMP Engine (identified by snmpEngineID) Security Subsystem Dispatcher Message Processing Subsystem

16 SNMPv3 Architecture-Agent PDU DISPATCHER SNMPv1 SNMPv2C SNMPv3 OTHER MESSAGE PROCESSING SUBSYSTEM MESSAGE DISPATCHER TRANSPORT MAPPINGS MANAGEMENT INFORMATION BASE VIEW BASED ACCESS CONTROL ACCESS CONTROL SUBSYSTEM NOTIFICATION ORIGINATOR COMMAND RESPONDER USER BASED SECURITY MODEL OTHER SECURITY MODEL SECURITY SUBSYSTEM Proxy Forwarder Applications COMMUNITY BASED SECURITY MODEL

17 SNMPv3 Architecture-Agent  Command Responder Application o Provides access to management data o Responds to incoming requests by retrieving and/or setting managed objects and issuing Response PDU  Notification Originator Application o e.g., SNMPv1, v2 Trap PDU  Proxy Forwarder Application o Forwards messages between entities  Access Control Subsystem o Provides authorization services to “control access” to the MIB for reading and setting management objects o Who can access o What can be accessed

18 Terminology SNMP Engine ID snmpEngineID -- associated with each SNMP entity Principal principal -- person or group or application requesting services Security Name securityName -- human readable name Context Engine ID contextEngineID -- each entity has a unique context ID (identical to snmpEngineID) Context Name contextName -- a context associated with a managed object (for access control) An SNMP agent can monitor more than one network element (context) Example: SNMP Engine IDIP address Principal John Smith Security Name Administrator

19 snmpEngineID

20 Abstract Service Interfaces  Abstract service interface is a conceptual interface between modules, independent of implementation  Defines a set of primitives o A primitive specifies the function to be performed (e.g., procedure call)  Primitives associated with receiving entities o An interface defined used primitive and parameters is referred to as “abstract service interface”  e.g., Dispatcher primitives: o Handle messages to and from applications o registering and un-registering of application modules o transmitting to and receiving messages from network  IN and OUT parameters  Status information / result

21 Dispatcher Primitives sendPdu  Used by a command generator to send SNMP request or notification PDU to another SNMP entity  When successfully preparing the message by the Dispatcher:  a sendPduHandle (unique identifier) is returned (to track any response, if any is expected)  The application also provides transport domain/address for the PDU as well as message processing model, security model, principal, level of security, the context for this PDU, and the PDU itself Command Generator Dispatcher Abstract Service Interface sendPdu Abstract Service Interface prepareOutgoingMessage Message Processing Model sendPduHandle/ Error Indication

22 Dispatcher Primitives processResponsePdu  Used by Dispatcher to pass an incoming response PDU to an application  The application checks whether it is matched with a preceding request or notification PDU by checking the sendPduHandle:  Success or failure Command Generator Dispatcher sendPdu Abstract Service Interface prepareOutgoingMessage Message Processing Model sendPduHandle/ errorIndication processResponsePdu

23 Dispatcher Primitives processPdu  Used by Dispatcher to pass an incoming request or notification PDU to an application  Security related information is required to generate a matching response message  The security subsystem will check whether access is allowed and a response will be generated accordingly returnResponsePdu  Used by command responder to return an SNMP response in response to an incoming request or notification Command Generator Dispatcher sendPdu Abstract Service Interface prepareOutgoingMessage Message Processing Model sendPduHandle/ errorIndication processPdu

24 Message Processing Subsystem Primitives prepareOutgoingMessage  Prepare a message for an outgoing SNMP request or notification PDU  The IN parameter is a PDU and OUT parameter is the message  Success or failure is returned prepareResponseMessage  Request the preparation of a message containing an outgoing SNMP response PDU, in response to an incoming request or notification PDU Command Generator Dispatcher sendPdu Abstract Service Interface prepareOutgoingMessage Message Processing Model sendPduHandle/ errorIndication

25 Security Subsystem Primitives generateRequestMessage  Generate a “message” containing an outgoing SNMP request or notification PDU  Returns to the MPS a message (with possibly authentication and encryption) and associated security parameters processIncomingMessage  Provide security function for incoming messages  Return success or failure indicating the result of the security check  If successful, a PDU is returned to the MPS generateResponseMessage  Generate a message containing outgoing SNMP response PDU in response to incoming request or notification  Returns to the MPS a message (with some authentication and encryption applied) and associated security parameters

26 SNMPv3  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  View-based Access Control Model (VCAM)

27 Command Generator  Command Generator: 1)-Examine parameters from the received PDU and match/compare them with a cached copy ( security model/level/name, contextName, etc.). If not math, message is discarded 2)-Check the received PDU (check request-id, etc. ) 3)- if all OK, then take action

28 Command Responder  Command Responder: 1)-examines content of request PDU. Check whether object has already registered with the responder 2)- isAccessAllowed is invoked (to determine whether object can be accessed by the principal making the request)  check the security level 3)- if access permitted, prepare a response.

29 Scenario Diagrams

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45 SNMPv3  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  View-based Access Control Model (VCAM)

46 Message Format Version Global/ Header Data Security Parameters Plaintext / Encrypted scopedPDU Data Message ID Message Max. Size Message Flag Message Security Model Header Data Context Engine ID Context Name Data scopedPDU Authoritative Engine ID Authoritative Engine Boots Authoritative Engine Time User Name Authentication Parameters Privacy Parameters Security Parameters Whole Message 1 SNMPv1 2 SNMPv2 3 SNMPv3 reportableFlag privFlag authFlag Time synch. between entities to avoid message replay and achieve timeliness

47 Message Format

48 SNMPv3  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  View-based Access Control Model (VCAM)

49 Security Model Goals  Verification that each received SNMP message has not been modified during its transmission through the network o Data Integrity (Authentication)  Verification of the identity of the user on whose behalf a received SNMP message claims to have been generated. o Authentication  Detection of received SNMP messages, which request or contain management information, whose time of generation was not recent o Message redirection/re-ordering/delay/replay  Ensure that the contents of each received SNMP message are protected from disclosure o Data encryption/decryption

50 Security Model  The Security model authenticates and forwards incoming and outgoing messages to the MPM  3 different modules o Authentication module o Privacy module o Timeliness module Security Subsystem Message Processing Model Authentication Module Privacy Module Timeliness Module Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

51 Authentication Module  Data integrity o message authentication at sender and validation at receiver o Ensure that a message is not modified by an unauthorized intruder o Authentication protocols: HMAC-MD5-96 / HMAC-SHA-96  Data origin authentication o Check the identity of a user on whose behalf a message is sent authoritative o Append to the message a unique Identifier associated with authoritative SNMP engine Security Subsystem Message Processing Model Authentication Module Privacy Module Timeliness Module Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

52 Privacy Module  Data confidentiality ensures that data is not made available to unauthorized users or entities  Encryption is applied at the sender and decryption at receiver (CBC-DES) Security Subsystem Message Processing Model Authentication Module Privacy Module Timeliness Module Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

53 Timeliness Module  Prevent message redirection, delay and replay  Configure a receiver window for accepting message (e.g., 150 s for SNMPv3)  Three objects: snmpEngineIP, snmpEngineBoots, snmpEngineTime Security Subsystem Message Processing Model Authentication Module Privacy Module Timeliness Module Data Integrity Data Origin Authentication Data Confidentiality Message Timeliness & Limited Replay Protection

54 Authoritative vs. non-authoritative engine  Responsibility of Authoritative engine o Unique SNMP engine ID o Time-stamp (a clock maintained by the authoritative engine)  Non-authoritative engine should keep a table of the time-stamp and authoritative engine ID o Synchronize its clock with regard to that of the authoritative engine Non-Authoritative Engine (NMS) Non-Authoritative Engine (NMS) Authoritative Engine (Agent)

55 User-based Security Model (USM)  USM primitives across abstract service interfaces o Authentication service primitives o authenticateOutgoingMsg o authenticateIncomingMsg o Privacy Services o encryptData // outgoing PDU o decryptData // incoming PDU

56 User-based Security Model (USM) Security Subsystem Privacy Module scopedPDU Encryption key User-based Security Model Encrypted scopedPDU Privacy parameters Authentication Module Whole Message Authentication key Authenticated Whole Message Privacy and Authentication Service for Outgoing Message Message Processing Model MPM Information Header data Security data scopedPDU (Authenticated/encrypted) whole message Whole message length Security Parameters

57 User-based Security Model (USM) Security Subsystem Privacy Module scopedPDU Encryption key User-based Security Model Encrypted scopedPDU Privacy parameters Authentication Module Whole Message Authentication key Authenticated Whole Message Message Processing Model MPM Information Header data Security data scopedPDU (Authenticated/encrypted) whole message Whole message length Security Parameters  USM invokes privacy module w/ encryption key and scopedPDU  Privacy module returns privacy parameters and encrypted scopedPDU  USM then invokes the authentication module w/authentication key and whole message and receives authenticated whole message

58 User-based Security Model (USM)  Processing secure incoming message reverse of secure outgoing message  Authentication validation done first by the authentication module  Decryption of the message done then by the privacy module Security Subsystem User-based Security Model Message Processing Model MPM Information Header data Security parameters whole message (Decrypted) scopedPDU Privacy Module Decrypt key Decrypted scopedPDU Privacy parameters Authentication Module Whole Message (as received from network) Authentication key Authenticated Whole Message Authentication parameters Encrypted PDU

59 User-based Security Model (USM)  msgUserName: user or a principal on whose behalf the message is being exchanged  msgAuthenticationParameters: defined by authentication protocol  msgPrivacyParameters: type of privacy protocol used

60 SNMPv3-Next!  Background and security threats  SNMPv3 Architecture  SNMPv3 Applications  Message Format  User-based Security Model (USM)  USM Timeliness Mechanism  Cryptographic Functions  USM Message Processing  Discovery  Key Management  View-based Access Control Model (VCAM)

61 USM Timeliness Mechanism Management of authoritative clocks  All authoritative engines must maintain two objects: o snmpEngineBoots o snmpEngineTime  Initially, both are set to 0  snmpEngineTime is incremented once per second  snmpEngineBoots is incremented if the system has rebooted or if snmpEngineTime reaches its maximum value (2 31 -1) o if an authoritative engine does not know its latest snmpEngineBoots  snmpEngineBoots = 2 31 -1 o variable latched at its maximum  needs to be manually reconfigured and new snmpEngineID is assigned

62 USM Timeliness Mechanism Synchronization  A non-authoritative engine must remain loosely synchronized with each authoritative engine with which it communicates  A non-authoritative engine keeps a local copy of 3 variables for each authoritative engine: o snmpEngineBoots : o Most recent value from authoritative engine o snmpEngineTime : o Synchronized to the authoritative engine. Between synch events, it is incremented once per second to maintain loose synch o latestReceivedEngineTime : o Highest value of msgAuthoritativeEngineTime. oIt protects against a replay message attack o These values are stored in a cache indexed by snmpEngineID

63 USM Timeliness Mechanism Synchronization (cont’d) If message is authentic  non auth. updates its local variables according to this rule: (msgAuthoritativeEngineBoots > snmpEngineBoots) OR [(msgAuthoritativeEngineBoots = snmpEngineBoots) AND (msgAuthoritativeEngineTime > latestReceivedEngineTime)] authoritative non-authoritative msgAuthoritativeEngineBoots, msgAthoritativeEngineTime, msgAthoritativeEngineID If two messages arrive out of order or a replay attack is underway!

64 USM Timeliness Mechanism Synchronization (cont’d)  If an update is called for, then snmpEngineBoots := msgAuthoritativeEngineBoots snmpEngineTime := msgAuthoritativeEngineTime latestReceivedEngineTime := msgAuthoritativeEngineTime  If ( msgAuthoritativeEngineBoots < snmpEngineBoots ) then no update occurs [Message not authentic  to be discarded]  If [(msgAuthoritativeEngineBoots = snmpEngineBoots) AND (msgAuthoritativeEngineTime < latestReceivedEngineTime)] then no update occurs [Message may be authentic but may be misordered  Update of snmpEngineTime is not warranted]

65 USM Timeliness Mechanism Timeliness checking by authoritative receiver  Ensure that messages are received within a reasonable time window (avoid delays and replays)  Too small time window  authentic messages may be considered as unauthentic  Too large  increase vulnerability for attacks  Incoming message is considered outside the time window if the following is true : snmpEngineBoots = (2 31 -1) OR msgAuthoritativeEngineBoots  snmpEngineBoots OR The value of msgAuthoritativeEngineTime differs from that of snmpEngineTime by more than ± 150 seconds.  message is considered not authentic (discarded and error message returned)

66 USM Timeliness Mechanism Timeliness checking by non-authoritative receiver  Incoming message is considered outside the time window if the following is true: snmpEngineBoots = (2 31 -1) OR msgAuthoritativeEngineBoots < snmpEngineBoots OR [(msgAuthoritativeEngineBoots = snmpEngineBoots) AND msgAuthoritativeEngineTime < snmpEngineTime – 150 ]

67 Cryptographic Functions-Authentication 2 functions defined by USM  authentication: authKey  encryption: privKey  authKey and privKey are derived from the password and are not accessible via SNMP 1- Authentication  Two authentication protocols o HMAC-MD5-96 (Message Digest) o HMAC-SHA1-96 (Secure Hash Algorithm)  HMAC: message authentication code generation from authKey  A 96-bit MAC code generated and inserted in msgAuthenticationParameters field of the message  MD-5 (16-octet) and SHA1 (20-octet) are the underlying hash functions

68 Cryptographic Functions-Authentication Procedure: 1. Derive extendedAuthKey : Supplement authKey with 0s to get 64-byte string 2. Define ipad, opad, K1, and K2 : ipad = 0x36 (00110110) repeated 64 times opad = 0x5c (01011100) repeated 64 times K1 = extendedAuthKey XOR ipad K2 = extendedAuthKey XOR opad 3. Derive HMAC by hashing algorithm used HMAC = H (K2, H (K1, wholeMsg))  Depending on whether MD-5 or SHA-1 is used, the algorithm produces a 16 (MD-5) or 20 (SHA-1)-octet length output which is truncated to produce a 12-octet MAC

69 Cryptographic Functions-Authentication

70 To authenticate sender receiver

71 Cryptographic Functions-Encryption 2- Encryption and decryption of scoped PDU (context engine ID, context name, and PDU)  CBC - DES (Cipher Block Chaining - Data Encryption Standard) symmetric protocol o 16 octet privKey (derived from password, similar to authKey ) is used as input to encryption protocol o First 8 octets of privKey are used as DES key (only 56 bits  LSB of each octet is ignored)

72 Cryptographic Functions-Encryption  CBC Mode o Last 8-octet of privKey used as pre- initialization vector ( pre-IV ) o Generate salt value (8 octets):  Initialization vector: IV = salt XOR pre-IV o Transmit salt in msgPrivacyParameters so that receiver can recover the IV Local value: 4-octet integer, implementation dependent, modified after each use.

73 Cryptographic Functions-Encryption k IV P1P1 C1C1 k P2P2 C2C2 k PnPn CnCn DES Encrypt DES Encrypt DES Encrypt C n-1 Data is divided into blocks of 64 bits each. K is shared between sender and receiver Encryption

74 Cryptographic Functions-Encryption k IV P1P1 C1C1 k P2P2 C2C2 k PnPn CnCn DES Decrypt DES Decrypt DES Decrypt C n-1 IV at the receiver is generated from the salt that is transmitted in the message Decryption

75 USM Message Processing Retrieve user information Privacy Required? msgPrivacyParamters  NULL Authent. Required? msgAuthent.Paramters  NULL Encrypt scopedPDU set msgPrivacyParamters YES NO Compute MAC set msgAuthent.Paramters YES Message Transmission Security name of principal Auth. snmpEngineID Determine security level … NO

76 USM Message Processing Retrieve msg parameters Authent. Required? Privacy Required? Encrypt scopedPDU set msgPrivacyParamters YES NO YES Message reception Compute MAC msgAuthent.Paramters Determine if msg is within time window Decrypt scopedPDU NO security level Security model Security name…. Time synch. Timeliness check

77 Discovery  The non-authoritative engine sends a Request message: securityLevel = noAuthnoPriv msgUserName = “initial” msgAuthoritativeEngineID = null varBindList = null  The authoritative engine respond with : msgAuthoritativeEngineID = snmpEngineID (its own)  If authenticated communication is required o The non-authoritative engine establishes time synchronization with the authoritative engine o Authoritative engine sends an Report message with its current values: msgAuthoritativeEngineBoots = snmpEngineBoots msgAuthoritativeEngineTime = snmpEngineTime

78 Key Management  Authentication and privacy keys are required  A principal (i.e., NMS) should deploy or use only one auth. key and one priv. key.  Keys are stored for the user’s password  Password: human readable, not easy guessed  Keys are not accessible via SNMP and are not stored in the MIB Password to key generation 1)- Repeat the psswd to generate 2 20 bytes  digest0 2)- digest1 = Hash (digest0) digest1 is 16-octet (MD-5) or 20-octet (SHA-1)  authKey is digest1 NOTE :: A single password can be used ( authKey and privKey are the same) or 2 passwords for 2 different keys

79 Key Localization  A localized key is a secret key shared between a user and one authoritative SNMP Engine  Hence, a user can communicate with many agents but maintains only one key (i.e., only one password) User 1 User 2 ( authKey1_1, privKey1_1 ) ( authKey1_2, privKey1_2 ) Agent 1 User 1 User 4 ( authKey2_1, privKey2_1 ) ( authKey2_4, privKey2_4 ) Agent 2 If compromised, other keys are not! If this agent compromised, only its keys are compromised. Other agents are safe.

80 Generating localized Keys password Take Hash of expanded password string Take Hash of user key and Remote Engine ID Take Hash of user key and Remote Engine ID Take Hash of user key and Remote Engine ID User Key ( digest1 ) Localized Key digest2 Localized key Localized key Localized keys are initially configured in a secure way ( could be manual!)

81 Key Update To enhance security, Keys are to be updated from time to time: keyOld  keyNew Requestor: 1)- Generate random 2)- Compute: digest = Hash ( keyOld || random ) 3)- delta = digest XOR keyNew 4)- protocolKeyChange = ( random || delta)  Send a message setRequest ( protocolKeyChange ) Receiver: 1)- compute digest = Hash( keyOld || random) 2)- compute keyNew = digest XOR delta NOTE: digest XOR delta = digest XOR (digest XOR keyNew) = keyNew Since an attacker does not know keyOld, the update of the key is safe

82 Access Control  Agent can validate sending sources and their access privilege for command requests.  Step following Authentication  Maintain a local database contains access rights and policies MIB VIEWAllowed Operations Allowed managersRequired Level of Security Interface Table SETJohnAuthentication, Encryption Interface Table GET/GETNEXTJohn, PaulAuthentication Systems Group GET/GETNEXTGeorgesNone

83 Access Control (read, write, or send notification)


Download ppt "SNMPv3 * * Mani Subramanian “Network Management: Principles and practice”, Addison-Wesley, 2000."

Similar presentations


Ads by Google