Knowledge Search


×
 

Configuration and working of SNMPv3 polling on ScreenOS

  [KB22675] Show Article Properties


Summary:
This article provides information on how to configure the SNMPv3 agent on ScreenOS for SNMPv3 polling.
Symptoms:
How to configure SNMPv3 agent on ScreenOS for SNMPv3 polling and understand how SNMPv3 polling works.
Solution:

SNMP V3 overview on Screen OS

The SNMPv3 architecture introduces the User-based Security Model (USM) for message security. View-based Access Control Model (VACM) is used for access control.
The architecture supports the concurrent use of different security, access control, and message processing models. The SNMPv3 on ScreenOS supports the following:
  • SNMPv1 and SNMPv2 polling and traps, which use the community based security model.
  • SNMPv3, which uses the User Security model.
  • SNMPv3 traps.
  • View Access Control Model for access control.
 

How to Configure the SNMPv3 Agent:

  1. Configure the SNMP Engine ID:
    • Via the WebGUI,  go to Configuration > Report Settings > SNMPv3.  Enter a Local-engine ID, and then click Apply:


    • Via the CLI, enter:  set snmpv3 local-engine id FWNetscreen

    The Local engine ID configuration is optional. A local-engine ID is to identify a SNMP entity. By default, the serial number of the device is assigned as the value of the local engine ID.

    Each SNMP Engine maintains the following objects:
     
    • snmpEngineID (local engine ID) which uniquely and unambiguously identifies an SNMP Application or SNMP Engine
    • snmpBoots (Engine Boots) which is a count of the number of times the SNMP engine has re-booted/re-initialized since SNMP Engine ID was last configured
    • snmpEngineTime, which is the number of seconds since the SNMP Engine Boots counter was last incremented.

    These parameters ensure Replay-Protection. For protection against message replay, delay, and redirection, one of the SNMP engines involved in each communication is designated to be the authoritative SNMP engine.

    When an SNMP message contains a payload, which expects a response (for example: get Request), then the receiver of such messages is authoritative. When an SNMP message contains a payload, which does not expect a response (for example: Traps), then the sender of such a message is authoritative.

  2. Configure the USM User
    • Via the WebGUI, go to Configuration > Report Settings > SNMPv3 > USM User > New User. Enter a User Name, select Authentication Type, Privacy Protocol, and passwords. Then, click OK:




       
    • Via the CLI, enter:
      set snmpv3 user netscreen auth md5 auth-pass netscreen priv des priv-pass netscreen
      set snmpv3 user firewall auth sha auth-pass netscreen priv none

    Management operations that use this Security Model make use of a defined set of user identities. For any user, on whose behalf management operations are authorized at a particular SNMP engine, that SNMP engine must have knowledge of that user.

    An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that engine, including knowledge of the applicable attributes of that user.
    • UserName: A string representing the name of the user.

    • Authentication Parameters: This consists of the following:
      • Authentication Type: This specifies the protocol to be used for authentication of SNMP messages. The following protocols are supported:
        • HMAC-MD5-96 authentication protocol
        • HMAC-SHA-96 authentication protocol
      • Authentication Password: This indicates the authkey or the authentication password for the USM user

    • Encryption Parameters: This consists of the following:
      • Privacy Protocol: This specifies the protocol to be used for encryption of of SNMP messages. The DES protocol is supported.
      • Privacy Password: This indicates the encryption key or the encryption password for the USM user

    A device can support up to 32 users.

  3. Configure the community string for the SNMPv1/v2 protocol
    • Via the WebGUI go to Configuration > Report Settings > SNMPv3 > Community > New Community.  Enter the Community name and tag; and then click OK:

    • Via the CLI:
      set snmpv3 community public tag public
      set snmpv3 community juniper tag juniper
    These parameters are used in SNMPV1 and SNMPV2c communication, which use the community string to achieve security. Each community has a tag. When an SNMPv1 or SNMPv2 request is received, the system checks whether the source is a valid target with the assigned tag of the community.

 How to Configure SNMP View Access Control Model (VACM):

  1. Configure the view:
    Each view is tagged with an object identifier and mask values.   Note, a device can support up to 32 VACM views.
    • Via the WebGUI:
      1. Go to Configuration > Report Settings > SNMPv3 > VACM > New View
      2. Enter the View Name; and then click OK
        Example: View Name: test-view
      3. Go to Configuration > Report Settings > SNMPv3 >VACM > View DatabAse Edit.
      4. Type the following settings, and then click Add:




    • Via the CLI:
      set snmpv3 view all-mibs.1 mask ff type include
      set snmpv3 view onlu-netscreen-mibs oid .1.3.6.1.4.1.3224.1.1 mask fe type include

    Subtree OID: Object identifier. The format of OID is x.x.x.x.x.x.x.x
    Subtree Mask: Mask value. The format of the mask is FF. The length of the subtree mask is less than or equal to 16. Each bit masks an OID.

    For example:
    Subtree OID: oid .1.3.6.1.4.1.3224.1.1
    Subtree Mask: 1 1 1 1 1 1 1 0 (FE)

    In this example, to meet the VACM requirements, the first seven OIDs is in the 1.3.6.1.4.1.3224 subtree. This implies that all MIB objects start with the 1.3.6.1.4.1.3224 OID, that is subtree with the 1.3.6.1.4.1.3224 root.

  2. Configure the access group:
    For each access group, you can define the security model, security level, and privilege access for the view configured in the above step. A device can support up to 32 VACM access groups.
    • Via the WebGUI:  go to Configuration > Report Settings > SNMPv3 >VACM > New Access Group. Enter the following settings; and then click OK:



    • Via the CLI:
      set snmpv3 access group snmpv3 sec-model usm sec-level priv read all-mibs write all-mibs notify all-mibs -->snmpv3 usm
      set snmpv3 access group snmpv3-only-auth sec-model usm sec-level auth read all-mibs write all-mibs notify all-mibs --> snmpv3 usm
      set snmpv3 access group snmpv1-group-public sec-model v1 sec-level none read  only-netscreen-mibs write only-netscreen-mibs notify only-netscreen-mibs -->snmpv1
      set snmpv3 access group snmpv2-group-juniper sec-model v2c sec-level none read  only-netscreen-mibs write only-netscreen-mibs notify only-netscreen-mibs -->snmpv2c

    Parameters of an access group:

    • Group Name: Name of the Access Group.
    • Security Model: SNMP V1, SNMP V2C, or USM (which is used in SNMP V3).
    • Security Level:
      • PRIV - Encrypt and Authenticate SNMP message.
      • AUTH - Only Authenticate SNMP messages.
      • None: By default, the security level is none If security Model selected is USM, then you get the option to select the security level as PRIV or AUTH
    • Read View: Select this view for MIB objects that have the read permission. The OIDs that belong to this view are able to be read by the users By default, this is set to none.
    • Write View: Select this view for MIB objects that have the write permission. The OIDs that belong to this view are able to be written/modified by the users. By default, this is set to none.
    • Notify View: Select this view, for which traps/notification can be sent. The OIDs that belong to this group indicate the list of traps that the SNMP agent(firewall) can send to the SNMP manager. By default, it is set to is none.
  3. Configure the group mapping:
    You can bind access groups (by using USM/V1/V2c security module and read/write/notify views) with different USM users (if the USM model is being used) and different community strings (if the V1 or V2C security model is being used).
    • Via the WebGUI: Go to Configuration > Report Settings > SNMPv3 > VACM > New Sec-to-group > Mapping,  type the following settings, and then click OK:



    • Via the CLI:
      set snmpv3 group-mapping sec-model v1 community public group snmpv1-group-public
      set snmpv3 group-mapping sec-model usm user netscreen group snmpv3
      set snmpv3 access group snmpv2-group-juniper sec-model v2c sec-level none read  only-netscreen-mibs write only-netscreen-mibs notify only-netscreen-mibs

SNMPV3 Polling Explained


Discovery of Engine ID:



Authoritative SNMP engine:

One of the SNMP copies is involved in network communication designated to be the allowed SNMP engine to protect against message replay, delay, and redirection. The security keys used for authenticating and encrypting SNMPv3 packets are generated as a function of the authoritative SNMP engine's engine ID and user passwords.

When an SNMP message expects a response (for example: get exact, get next, set request), the receiver of these messages is authoritative. When an SNMP message does not expect a response, the sender is authoritative. In this case of polling, the SNMP Manager is the non-authoritative SNMP engine and the SNMP Agent is the authoritative SNMP engine.


SNMP EngineID discovery phase:

The USM requires that the snmpEngineID, snmpEngineBoots, and snmpEngineTime of the authoritative engine be placed in the msgSecurityParameters. This requires the non-authoritative engine (that is, manager) to know these values for the authoritative engine (that is, agent); before a GET, NEXT, or SET operation can be completed.

The discovery transaction is initiated by the manager that sends a SNMPv3 packet with the msgAuthoritativeEngineID, which contains a bogus value. When the agent receives a packet, in which the msgAuthoritativeEngineID is different from its own, the packet is discarded and a discovery packet (report PDU) is returned to the manager. The returned discovery packet contains the correct snmpEngineID, snmpEngineboots and snmpEngineTimes, which must be used by the manager.

 

SNMP Polling:

After the SNMPEngine ID is known to both the SNMP agent and SNMP Manager, then depending on the SNMP Access Group Security Level, the SNMP messages are encrypted and authenticated. The encryption key is generated as a function of SNMPEngineId and locally configured SNMP Encryption password, which is pre-shared on both ends.

Similarly, the authentication key is generated as a function of SNMPEngineId and locally configured SNMP authentication password, which is pre-shared on both ends.The message is then encrypted by using the encryption key, encryption algorithm, authentication key, and authentication alogorithm.The OID value pair is then sent in the variable binding section of the SNMP message to the SNMP agent and the SNMP agent returns the value of the polled OID.

Modification History:
2019-06-15: Content reviewed for accuracy.  Minor formatting changes.
Related Links: