Implement SNMPv3 support

[jmbredal]

The underlying NET-SNMP backend supports SNMPv3. Implement support for this in NAV.

An attempt to break down this feature into multiple parts (which individually might need to be broken down, as well)

• Research which SNMPv3 configuration options NAV needs to support in a new management profile type #2692
• Implement an SNMPv3 management profile type #2693
• Add SNMPv3 session support to the synchronous libraries #2700
  • Test and update SeedDB netbox reachability functions for SNMPv3 session compatibilty #2704
  • Update SeedDB writeable profile connectivity verification to support SNMPv3 #2727
  • Test and update arnold backend script for SNMPv3 session compatibilty #2726
  • Test and update portadmin management handlers for SNMPv3 session compatibilty #2712
  • Refactor nav.Snmp.Snmp to use a dataclass for SNMPv3 configuration arguments
  • Add SNMPv3 support to snmptrapd #2755
• Change multi-SNMP profile behavior to allow write-enabled profiles also for reading when nothing else is available #2735
• Add SNMPv3 session support to the asynchronous libraries #2736
  • Remove remaining uses of Netbox.snmp_version #2522
  • Test and update the navoidverify and naventity commands for SNMPv3 support #2747
  • Implement SNMPv3 contexts as alternative to community indexing for retrieval of logical BRIDGE-MIB instances on Cisco switches #2811
  • Research how SNMPv3 contexts affect ipdevpoll's VRF-handling code
• Update the navsnmp command line program to support SNMPv3 profiles #2724

[jmbredal]

(by bzed)
Is anybody working on this? If not I'll see if I can implement it.

[jmbredal]

(by mbrekkevold)
Hi Bernd, not currently, no, but I'm delighted to hear someone is interested in working on it :)

We are planning to look at NETCONF support in 2015, which will also necessitate some of the same changes to NAV's data model for storing management credentials.

I'm not sure where or if we have documented our ideas for this, but we are thinking along the lines of a separate "management credentials" table or store, where named sets of unique credentials are stored. Each IP Device/Netbox would then have a relation to this table, so that adding a Netbox in SeedDB entails selecting a pre-stored set of credentials from a dropdown list.

We'll gladly answer any questions you might have (and I would recommend the nav-dev mailing list, or our #nav IRC channel on freenode).

[jmbredal]

(by bzed)
Unfortunately I did not yet find the time to look into snmp v3 and I doubt I will find the time soonish. Is the some plan when v3 will arive?

[jmbredal]

(by mbrekkevold)

Unfortunately I did not yet find the time to look into snmp v3 and I
doubt I will find the time soonish. Is the some plan when v3 will arive?

I'd forgotten all about this since I last heard from you.

We've already begun implementation of a "management credentials" store,
and the University of Linköping seems to be willing to pay us to fix
SNMPv3 support, so we may actually get there in 2016.

[b2cc]

@jmbredal @lunkwill42 : any news on SNMPv3 support? We would really appreciate if this could be implemented as some of our devices are exposed to the internet and we want to avoid sending plaintext credentials over unsecured lines. thanks for providing such awesome product!

[lunkwill42]

Hi, @b2cc . SNMPv3 has been on the backburner for a while now, because we want to prioritize NETCONF et.al. But, any initial support for NETCONF will be mainly for configuration purposes (such as PortAdmin) - though it will also require the same initial changes as for SNMPv3 support: A different way of storing management credentials for devices.

We will, however, not be able to complete any kind of support for NETCONF until we have relicensed NAV to either GPLv3 or Apache 2.0, which is a big upcoming task for us (since there are multiple copyright holders).

You're now subscribed to this issue, so we'll keep you posted.

[b2cc]

@lunkwill42 : ok I understand, thanks for the heads up!

[trantor]

Hello @lunkwill42 Any news on this? I still do not see SNMP v3 in the Management Profile section...

[lunkwill42]

Hello @lunkwill42 Any news on this? I still do not see SNMP v3 in the Management Profile section...

Indeed. No news, unfortunately. This is still not a priority for our customers, so it's still on the backburner. I've also never heard back from @pstolpe whether the University of Linköping is interested in pursuing this...

So as it stands: We have management profiles now, but no SNMP v3 support. A new profile type for SNMP v3 would be relatively easy to create. Then, the work would remain to update the two adapter modules (synchronous and asynchronous) NAV uses to adapt to NET-SNMP to be able to initialize SNMP v3 sessions using the config from such a profile.

[oddkl]

If it helps, we're a customer, and we want this feature!
So upvoted!

[thomases]

We're also a customer, and would very much like to see this implemented. Upvoted!

[pstolpe]

We still would like to see ANMP v3 implemented fully at Linköping University, but we have not currently got any budget to fund this. What is most interesting for us is SNMP v3 contexts to get arp etc from within VRF's in our vendor Alcatel Lucent Enterprise OmniSwitch platform. We have other platforms right now i.e. Fortinet that has a problematic SNMP implementation so part from this I'd like to see an API where we could feed ARP/ IPv6-neighbor data etc from other sources home-brew or other solutions to NAV. But that's another feature request.

[raskallen]

We are also a customer (although posting from my private git accout) and would like, or actually need, snmpv3 support. This is what stops us from using NAV. So hereby upvote from us. :)

[lunkwill42]

If you're a customer with Sikt, it helps to identify which institution you represent :)

SNMPv3 has previously been discussed, but not upvoted, by the NAV reference committee (UiO, UiA, NTNU, UiT and HiVolda). I'll make sure to add this issue to the agenda of our next scheduled meeting.

[eriksornes]

Hi, we would also like snmpv3 implemented. We have som remote equipment we would very much like to access more secure with snmpv3, if its possible. Also I think we are customers of Sikt of some sort.

[xloto]

Recomendation from an alert message on justiscert.no (The Norwegian justice sector's ICT security and response environment) today:

"Turn off all insecure/deprecated features (eg TLS v1.0 and v1.1, SMBv1, NTLMv1, FTP, Telnet, SNMP v1 and v2, POP, IMAP, NetBIOS, LLMNR, HTTP)"

Link to alert (in norwegian): https://justiscert.no/[justiscert-varsel]-[074-2023]-[tlpclear]-microsoft-adobe-og-sap-sarbarheter-for-oktober-2023

[lunkwill42]

Good news for everyone following this issue: Our team has now been told this is our highest priority for the upcoming sprint, as we have signed a deal to deliver network management services to a customer that has an absolute requirement for SNMPv3.

[pstolpe]

Great news indeed. Hope you will implement multiple snmpv3 context names per device to poll vrf data from the vendors that uses that. /P Den mån 30 okt. 2023 09:52Morten Brekkevold ***@***.***> skrev:

…

Good news for everyone following this issue: Our team has now been told this is our highest priority for the upcoming sprint, as we have signed a deal to deliver network management services to a customer that has an absolute requirement for SNMPv3. — Reply to this email directly, view it on GitHub <#1177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIGIETQUHVNNE7G7LBR3CC3YB5TD3AVCNFSM4C4WTWMKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGQ3TIMBTGMYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>