-
Notifications
You must be signed in to change notification settings - Fork 118
Add basic SNMPv3 configuration and user handling #611
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: development
Are you sure you want to change the base?
Conversation
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"/>). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
kieran242
left a comment
There was a problem hiding this 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> |
There was a problem hiding this comment.
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"/>). |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
|
Propose to remove version from method names to ease any potential future support for v4. |
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.
|
Rebased to current development branch. Some open questions to be adressed later:
|
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.