Hashed SNMP Community String

This chapter describes the hashed SNMP community string feature based on the device's IP address.

This functionality enhances device communication by generating unique hashed community strings based on their IP addresses. The hashed SNMP community implementation supports the replacement of SNMP community in the following TLVs:

  • TLV 53.1 (SNMPv1v2c Community Name)

  • TLV11 Coexistence mode (snmpCommunityName)

  • TLV11 NmAccessMode (docsDevNmAccessCommunity)

This feature is applicable for DOCSIS cable modem and MTA/PacketCable devices.

Configuring Hashed SNMP Community String

The Hashed SNMP Community String Based on Device IP Address chapter of DPE CLI Guide, describes the commands that you can use to configure the Prime Cable Provisioning hashed SNMP community string based on device IP address parameters.

Understanding Hashed SNMP Community String Feature

The CNR-EP shares IP address details of the device with DPE during the initial device boot process. When the device requests for configuration file via a TFTP request to the DPE, the DPE verifies feature enablement. If enabled, the DPE replaces the existing SNMP community strings set by the RDU with the hashed SNMP community strings in the binary config file (The configuration file generated by the RDU contains the plain SNMP community string, which should be the value configured by the user via the DPE CLI).

The hashed SNMP community string is based on the device IP address, and is encrypted based on the DPE CLI configuration.

This feature MUST be enabled on all DPEs within a PG.

Provisioning Workflow With Hashed SNMP Community String

Procedure

Step 1

Device sends DHCP Discover request to locate DHCP servers (CNR).

Step 2

DHCP server queries the DPE for the device configuration.

Step 3

If DPE doesn’t have config for the MAC, the packet is dropped by CNR.

Step 4

CNR requests RDU to build new configuration for the device MAC.

Step 5

RDU builds configuration and sends to DPE to be cached.

Step 6

CM times out and retries it's request for IP address.

Step 7

CNR again queries the DPE for the device configuration.

Step 8

DPE sends configuration for CM back to the CNR and CNR sends DHCP Offer message back to CM with DHCP options.

Step 9

CM sends the DHCP Request with required parameter list.

Step 10

CNR issues CM appropriate IP address along with other DHCP options.

Step 11

After the DORA completion, CNR sends the CM IP to DPE.

Step 12

CM requests the current time from DPE and DPE responds with the current time (ToD).

Step 13

CM requests configuration for file in DHCP offer (TFTP request).

Step 14

DPE checks if the hashed SNMP community string feature is enabled.

Step 15

If enabled, DPE replaces the SNMP community strings with hashed SNMP community strings.

Step 16

DPE responds via TFTP with the appropriate configuration.

Step 17

CM acknowledges DPE on TFTP completion and CM will now obtain it's IP address.

Reset Workflow With Hashed SNMP Community String

When a user performs a device reset, the RDU uses the SNMP read and write community value configured via the RDU Admin UI (or which may be in any one of the following hierarchy levels: device, DHCP Criteria, COS or system defaults level) to perform the device reset operation. The RDU sends this community string to the DPE along with the device IP address to perform the device reset.

If the hashed SNMP feature is enabled, then the DPE verifies if the SNMP community string values received from RDU are the same as the values configured in the DPE CLI. If a match is found, the DPE replaces the SNMP community string values with the hashed SNMP community string (computed based on the device IP address) for the device reset operation. If the values differ, the SNMP community string values passed from RDU is used for device reset operation.

Procedure

Step 1

When a device reset is initiated from RDU, RDU performs a lease query to CNR.

Step 2

CNR responds to RDU with the IP address of the device.

Step 3

RDU issues a reset request for the device IP with the SNMP community strings to DPE.

Step 4

DPE ensures that the hashed SNMP community string feature is actively enabled.

Step 5

If enabled, DPE sends reset request to the device with the hashed SNMP community string.

Note: PCP users should perform device reset only via the DPE if this feature is enabled.

Hashed SNMP Community String feature workflow

This section provides a comprehensive overview of the feature's overall operations, followed by the workflows for each of the individual TLVs mentioned above.

Procedure

Step 1

CM requests for configuration file.

Step 2

DPE verifies for hashed SNMP read community string feature enablement and checks if the read community string provided on the CLI matches the one present in the configuration file.

  • If yes, the DPE computes the new hashed read community string and proceeds to the TLV53 SNMP read community, TLV11 Co-existence Mode SNMP Read Community and TLV11 NmAccess Mode SNMP Read Community workflows sequentially.

  • If no, it emits a trace log and exits without replacement.

Step 3

DPE verifies for hashed SNMP write community string feature enablement and checks if the write community string provided on the CLI matches the one present in the configuration file.

  • If yes, the DPE computes the new hashed write community string and proceeds to the TLV53 SNMP write community, TLV11 Co-existence Mode SNMP write Community and TLV11 NmAccess Mode SNMP write Community workflows sequentially.

  • If no, it emits a trace log and exits without replacement.

Step 4

The resultant configuration file is finally delivered to the CM.

TLV53 SNMP Read Community Workflow

This section outlines the steps and decisions involved in processing TLV 53 SNMP read community.

For replacement of TLV 53 SNMP read community names with IP-specific hashed strings, the following TLVs contained within TLV 53 entries are considered:

  • 53.1 SNMPv1v2c Community Name

  • 53.2 SNMPv1v2c Transport Address Access

    • 53.2.1 SNMPv1v2c Transport Address

    • 53.2.2 SNMPv1v2c Transport Address Mask

  • 53.3 SNMPv1v2c Access View Type

Procedure

Step 1

Check if the read community string provided on the CLI matches the one present in the TLV 53.1 in the configuration file.

Step 2

If yes and if there are any TLV 53.2 sub-options(one or multiple instances of 53.2.1 and 53.2.2) associated with this TLV53, iterate through them.

Step 3

To find the access type of this TLV 53, check for the presence of TLV 53.3.

  • If present and 53.3 is not of read access type, emit trace log "Read community is configured with OTHER access type" and exit without read community string replacement.

  • Else, default to read access type and proceed with replacement if the new hashed read community length is between 1-32 and TLV 53 length after replacement with new hashed read community is between 1-255.

TLV11 Coexistence Mode SNMP Read Community Workflow

This section details the mechanics of the replacement of snmpCommunityName in TLV 11 coexistence mode.

For replacement of TLV 11 coexistence SNMP Community names with IP-specific hashed strings, the following MIB object types contained within TLV 11 entries are considered:

  • snmpCommunityName

  • snmpCommunitySecurityName

  • vacmGroupName

  • vacmAccessWriteViewName

Procedure

Step 1

Check if the read community string provided on the CLI matches the one present in the TLV 11 snmpCommunityName in the configuration file.

Step 2

To evaluate if the TLV 11 containing snmpCommunityName should be considered read-only or read-write for community string replacement:

  1. Determine the value of snmpCommunitySecurityName that is in the same snmpCommunityEntry as the snmpCommunityName being evaluated. This will be the snmpCommunitySecurityName that has the same index as snmpCommunityName.

  2. Determine the list of all values of vacmGroupName where the vacmSecurityName portion of the index matches the value of snmpCommunitySecurityName determined in the prior step.

    • Find all vacmAccessWriteViewName objects where the groupName index value has a match in the list of all values of vacmGroupName determined in the prior step. If one or more non-empty vacmAccessWriteViewName is found, snmpCommunityName is considered read-write. Emit trace log "config file contains read community with vacmAccessWriteViewName config" and exit without read community string replacement.

    • If no matching vacmGroupName or vacmAccessWriteViewName is found, default to read-only access and proceed to replace with new hashed read community string.

TLV11 NmAccess Mode SNMP Read Community Workflow

Replacement process for docsDevNmAccessCommunity in TLV 11 NmAccess mode is explained here.

For replacement of TLV 11 NmAccess mode SNMP Community names with IP-specific hashed strings, the following MIB object types contained within TLV 11 entries are considered:

  • docsDevNmAccessCommunity

  • docsDevNmAccessStatus

Procedure

Step 1

Determine the list of all TLV 11 NmAccess (docsDevNmAccessStatus) read access type instances.

Step 2

For each read instance, check if the docsDevNmAccessCommunity present in the configuration file matches the read community string provided on the CLI.

  • If yes, replace with the new hashed read community string.

  • If no, emit trace log "No eligible read community instances found" and exit without read community string replacement.

TLV53 SNMP Write Community Workflow

This section outlines the steps and decisions involved in processing TLV 53 SNMP write community.

For replacement of TLV 53 SNMP write community names with IP-specific hashed strings, the following TLVs contained within TLV 53 entries are considered:

  • 53.1 SNMPv1v2c Community Name

  • 53.2 SNMPv1v2c Transport Address Access

    • 53.2.1 SNMPv1v2c Transport Address

    • 53.2.2 SNMPv1v2c Transport Address Mask

  • 53.3 SNMPv1v2c Access View Type

Procedure

Step 1

Check if the write community string provided on the CLI matches the one present in the TLV 53.1 in the configuration file.

Step 2

If yes and if there are any TLV 53.2 sub-options(one or multiple instances of 53.2.1 and 53.2.2) associated with this TLV53, iterate through them.

Step 3

To find the access type of this TLV 53, check for the presence of TLV 53.3.

  • If 53.3 is of write access type, proceed with replacement if the new hashed write community length is between 1-32 and TLV 53 length after replacement with new hashed write community is between 1-255.

  • Else, emit trace log "Write community is configured with OTHER access type" and exit without write community string replacement.

TLV11 Co-existence Write Workflow

This section details the mechanics of the replacement of snmpCommunityName in TLV 11 coexistence mode.

For replacement of TLV 11 coexistence SNMP Community names with IP-specific hashed strings, the following MIB object types contained within TLV 11 entries are considered:

  • snmpCommunityName

  • snmpCommunitySecurityName

  • vacmGroupName

  • vacmAccessWriteViewName

Procedure

Step 1

Check if the write community string provided on the CLI matches the one present in the TLV 11 snmpCommunityName in the configuration file.

Step 2

To evaluate if the TLV 11 containing snmpCommunityName should be considered read-only or read-write for community string replacement:

  1. Determine the value of snmpCommunitySecurityName that is in the same snmpCommunityEntry as the snmpCommunityName being evaluated. This will be the snmpCommunitySecurityName that has the same index as snmpCommunityName.

  2. Determine the list of all values of vacmGroupName where the vacmSecurityName portion of the index matches the value of snmpCommunitySecurityName determined in the prior step.

    • Find all vacmAccessWriteViewName objects where the groupName index value has a match in the list of all values of vacmGroupName determined in the prior step. If one or more non-empty vacmAccessWriteViewName is found, snmpCommunityName is considered read-write. Proceed to replace with new hashed write community string.

    • If no matching vacmGroupName or vacmAccessWriteViewName is found, emit trace log "config file contains write community with NO vacmGroupName/vacmAccessWriteViewName config." and exit without write community string replacement.

TLV11 NmAccess Write Workflow

Replacement process for docsDevNmAccessCommunity in TLV 11 NmAccess mode is explained here.

For replacement of TLV 11 NmAccess mode SNMP Community names with IP-specific hashed strings, the following MIB object types contained within TLV 11 entries are considered:

  • docsDevNmAccessCommunity

  • docsDevNmAccessStatus

Procedure

Step 1

Determine the list of all TLV 11 NmAccess (docsDevNmAccessStatus) write access type instances.

Step 2

For each write instance, check if the docsDevNmAccessCommunity present in the configuration file matches the write community string provided on the CLI.

  • If yes, replace with the new hashed write community string.

  • If no, emit trace log "No eligible write community instances found" and exit without write community string replacement.

Generating Hashed SNMP Community String

The process of generating hashed SNMP community strings, for both read and write access, involves the following steps (see, Hashed SNMP Community String Based on Device IP Address chapter of DPE CLI Guide for details on the configuration parameters used for this formulation) :

Procedure

Step 1

The format configured is a character string, with a special designation indicating where the IP address is to be inserted within the string. The IP address (either v4 or v6) of the device is converted to bytes, and inserted into the configured format. This is used as the data input to the configured hash function.

Step 2

The configured secret key is used as the key input to the configured hash function.

Step 3

The output of the hash function is encoded as base64. If a length for the hashed community string has not been configured, the entire base64 encoding is used as the hashed SNMP community string. If a length for the hashed community string has been configured, the base64 encoding is truncated to this configured length, and this is used as the hashed SNMP community string.