The Ironic SNMP driver does not leverage the security features that SNMPv3 offers. Supporting them would improve the security of the management network whenever SNMP is used for power management.
Since the underlying library (pysnmp) does all the SNMPv3 heavy lifting, at the level of the Ironic SNMP driver it is merely a matter of adding additional configuration parameters to utilize all the SNMPv3 security features. Then the operator could configure SNMP driver to use either SNMP v1, v2c or v3 by way of setting the `snmp_version` option (which is already present).
SNMPv3-related options to be introduced would be:
* snmp_usm_user: user name (string)
* snmp_usm_auth_protocol: tokens like md5, sha
* snmp_usm_auth_key: ascii string
* snmp_usm_priv_protocol: tokens like des, aes
* snmp_usm_priv_key: ascii string
* snmp_context_name: SNMP context (string) to address possibly many instances of the same MIB behind a single SNMP agent
Implementation-wise, we would not need to fork Ironic SNMP driver or introduce new hardware type or migrate existing SNMPv1/v2c configuration by way of adding SNMPv3 support to the SNMP driver.
The same applies to the VirtualPDU tool -- we will need to teach it picking up the options above [1], no backward incompatible changes anticipated.
The proposed change would introduce the indirect dependency on the `pycryptodomex` package which pysnmp (4.4.1+) uses for the low-level crypto operations.
1. https://github.com/openstack/virtualpdu/blob/master/virtualpdu/main.py#L51
Do we need a spec for this? I'd be fine if the additional config parameters were described here and they aren't controversial :)
wrt 'pycryptodome', I see this note [1], but I don't think we are using pycrypto? (someone should verify of course)
[1] https:/