Skip to content

Conversation

@ubkr
Copy link

@ubkr ubkr commented Jul 18, 2025

Adds basic SNMPv3 configuration to enable SNMPv3 on the device and configure parameters such as the listening port, EngineID, initial user and set its associated secrets.

doc/Core.xml Outdated
<section xml:id="s.snmpv3_extension">
<title>SNMPv3 Device Management Extension (Optional)</title>
<para>
This section defines an optional extension to the Device Management Service for supporting Simple Network Management Protocol version 3 (SNMPv3) as specified in <xref linkend="RFC3410"/> and related standards. Devices supporting this extension <emphasis role="bold">shall</emphasis> indicate this capability via the <literal>SNMPv3</literal> flag in the <literal>DeviceServiceCapabilities</literal> (see Section <xref linkend="_Ref468447902"/>).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where SNMPv3 capability flag is added in DeviceServiceCapabilities in the PR?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No.. I forgot to add that, but I've added it now to the Network category

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ubkr @venki5685 there is an error in the table and the "SNMPv3" is not rendering properly in the table noted in my review comment. Looks to be missing a row section.

Copy link
Contributor

@kieran242 kieran242 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ubkr raised a few points and noted some of the Privacy protocols should be prob updated into the new Security Baseline document.

doc/Core.xml Outdated
</row>
<row>
<entry>
<para>SNMPv3</para>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error here needs correction. Misalignment between the "SNMPv3" and definition "Indication if the device supports SNMPv3..." and description.

doc/Core.xml Outdated
<section xml:id="s.snmpv3_extension">
<title>SNMPv3 Device Management Extension (Optional)</title>
<para>
This section defines an optional extension to the Device Management Service for supporting Simple Network Management Protocol version 3 (SNMPv3) as specified in <xref linkend="RFC3410"/> and related standards. Devices supporting this extension <emphasis role="bold">shall</emphasis> indicate this capability via the <literal>SNMPv3</literal> flag in the <literal>DeviceServiceCapabilities</literal> (see Section <xref linkend="_Ref468447902"/>).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ubkr @venki5685 there is an error in the table and the "SNMPv3" is not rendering properly in the table noted in my review comment. Looks to be missing a row section.

doc/Core.xml Outdated
<para role="text">The requested <literal>PrivacyProtocol</literal> is not supported by the Device.</para>
<para role="param">env:Sender - ter:InvalidArgVal - ter:SNMPUnsupportedSecurityLevel</para>
<para role="text">The combination of protocols for the specified <literal>SecurityLevel</literal> is not supported, or a required protocol was not specified.</para>
<para role="param">env:Receiver - ter:ActionNotSupported - ter:MaxSNMPUsersExceeded</para>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does a device user know the "MaxSNMPUsersExceeded" where has it been defined ?

Keys for authentication and privacy <emphasis role="bold">shall</emphasis> be provided by the Client as base64-encoded binary data using the <literal>tt:BinaryData</literal> type. The Device <emphasis role="bold">shall</emphasis> delocalize these keys using its EngineID as per SNMPv3 USM specifications (<xref linkend="RFC3414"/> Appendix A) before storing them internally.
</para>
<section xml:id="s.snmpv3_auth_protocols">
<title>Authentication Protocols</title>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HansBusch are these needed to be included in the new security baseline specification? #571

doc/Core.xml Outdated
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">AES-128-CFB:</emphasis> As specified in <xref linkend="RFC3826"/> (OID: <literal>usmAesCfb128Protocol</literal>). This protocol is <emphasis role="bold">REQUIRED</emphasis>. The privacy key length is 16 octets.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HansBusch do we need to also support these protocols "AES-128-CFB" in the Security Baseline doc? #571

@HansBusch
Copy link
Member

Propose to remove version from method names to ease any potential future support for v4.
Suggest to move schema types to device.wsdl.

ubkr and others added 10 commits December 4, 2025 10:27
Adds SNMPv3 configuration, user handling and control.
- Remove AddSNMPUser, DeleteSNMPUser, and GetSNMPUsers operations
- Enhance SetSNMPConfiguration to support initial user creation
- Remove SNMPUser and SNMPUserConfiguration complex types
- Retain security level, authentication, and privacy protocol types
- Update capability descriptions for service config + initial user setup
- Maintain GetSNMPConfiguration and SetSNMPConfiguration operations
- Remove xml:id attributes from SNMPv3 RFC entries (RFC 3410, 3411, 3414, 3826, 7860)
- Replace <xref linkend='RFCxxxx'/> with [RFC xxxx] bracket notation throughout SNMPv3 section
- Maintain datatracker.ietf.org URLs for modern RFC access
- Align SNMPv3 references with existing document RFC citation style
Rename privacy protocol enumerations from AES_*_CFB to CFB_AES_* to match
RFC 3826 naming convention (cipher mode first). Update OID references from
usmAesCfb*Protocol to usmAesCfb*PrivProtocol (correct "Priv" suffix).
Remove redundant SNMPv1/v2c statement.

The CFB_AES_128 pattern better represents cipher mode (CFB) followed by
algorithm (AES) and key size, consistent with RFC 3826 specifications.
Standardize terminology from "SNMPv3" to "SNMP" throughout specification
while clarifying that only SNMPv3 protocol version is supported. Update
section IDs, operation references, and capability flags for consistency.
Flatten SetSNMPConfiguration request structure to accept individual
parameters rather than nested types.
@ubkr
Copy link
Author

ubkr commented Dec 4, 2025

Rebased to current development branch.

Some open questions to be adressed later:

  • Which MIBs should be mandatory or recommended?
  • Are the mentioned hash and encryption algoritms still valid in todays environment and are there others used by the industry and in IT envs?

@ubkr ubkr marked this pull request as ready for review December 4, 2025 09:34
@ocampana-videotec ocampana-videotec added this to the 26.06 milestone Dec 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants