Do you have planned support SNMPv3 with TLS?

[ruslan-gennadievich]

Hi

Any plan to TLS?

[markabrahams]

I haven't made plans for any new library features beyond completing a half-finished AgentX subagent, which is the last feature left on my original list of improvements that I compiled in January (2020).

Having said that, TLS would be at or near the top of any subsequent feature list, and as such I'll keep this request open. I just don't have the bandwidth to look at it in the near term unfortunately.

Out of curiosity, what's your main driver for using TLS over USM?

[markabrahams]

I'm beginning to rethink the applicability/usefulness of SNMP/(D)TLS:
(1) I know of no-one who uses this.
(2) On researching tool support for SNMP/(D)TLS, I can't find anything outside of Net-SNMP and the odd library/toolkit that supports it.
(3) I've previously expressed concern with the additional overhead of the SNMPv3 discovery mechanism being a hindrance to the performance of SNMP in certain use cases. The certificate exchange inherent in SNMP over (D)TLS can only increase this overhead, which would further concern me.

Leaning towards removing this from the to-do list.

[markabrahams]

I went to get SNMP/TLS working under Net-SNMP - which I consider the gold standard in SNMP libraries / tools. More data points from that exercise:

1. Ubuntu doesn't have TLS enabled for Net-SNMP in the binaries that they ship. Had to download source and compile to enable configure options --with-security-modules=tsm --with-transports="DTLSUDP TLSTCP".
2. Net-SNMP's own walkthrough tutorial for SNMP/TLS has certificates that are 5 years expired and therefore don't work.
3. In the same tutorial, the example server to test your configuration against - test.net-snmp.org - is no longer running (or at least no longer listening to tlstcp on TCP port 10161).
4. Wireshark doesn't have an SNMP/TLS decoder.

Vital signs just aren't there - is SNMP/TLS dead in the water?

[ruslan-gennadievich]

Thanks for your research
I have some thinks about it:

1. Usually SNMP uses to get some info, and very rarely for apply some configuration. Therefore TLS rarely use. Nevertheless SNMP use for apply configuration impossible without TLS.

2. Net-SNMP support TLS, Yes you need build it froum source with above paramets.

3. Certificate in Net-SNMP need to renew just via openssl, use self sign certs.

4. Maybe it help with Wireshark:
   https://www.wireshark.org/docs/dfref/s/snmp.html
   https://wiki.wireshark.org/SNMP
   How decode TLS see in many article about web tls: https://resources.infosecinstitute.com/decrypting-ssl-tls-traffic-with-wireshark/
   https://www.wireshark.org/docs/dfref/s/snmp.html

[markabrahams]

Hi @ruslan-gennadievich - thanks for that. On those points:

1. It seems you've misunderstood what TLS brings to SNMP. Applying SNMP configuration is entirely possible without TLS. The SNMP protocol specifically describes a mechanism to change a device's management information by using SetRequest PDUs (see RFC 3416 for more details). The SNMP protocol can run on top of a variety of different SNMP transports (RFC 3417) and can use different authentication models (e.g. USM defined in RFC 3414). The more popular (than SNMP/TLS) SNMPv3 with USM has full access to all RFC 3416 protocol operations including SetRequests to write management information / configuration to devices. SNMP over TLS simply defines a different transport model (RFC 6353) and authentication model (RFC 5591) over which you run the same SNMP protocol operations defined in RFC 3416. So SNMP over TLS (using TSM) does not give you any additional configuration functionality that you don't already have for example in SNMP over UDP/IPv4 (using USM or even community-based "security").

2. & 3. Yes - you're correct - I've spent a few hours getting Net-SNMP clients and server working with SNMP/TLS. The point I was making was this: The fact that I had to spend a few hours getting it working, that it's not included in commonly distributed Net-SNMP packages, that the most-current examples are out-of-date, that documented test SNMP/TLS servers are not running, etc. all lend evidence to the fact that it's not in high demand. At all.

3. Wireshark supports TLS decoding. And SNMP decoding. But - annoyingly - not SNMP/TLS decoding. The method outlined in the article you posted relies on an application to write TLS key-exchange secrets to a file given in the SSLKEYLOGFILE environment variable. Unfortunately Net-SNMP doesn't do this. Further, the "Decode As..." Wireshark feature that allows you to decode various protocols running over a "TLS port" doesn't include SNMP as one of the protocols on the list. Another sign that there's a lack of people doing this.

So my question to you is: If your requirement for applying device configuration is able to be fulfilled using either SNMPv3/USM or SNMPv2c, do you have any requirement for SNMP/TLS at all?

[sean-lawless]

As a long time SNMP developer and user I recommend using the DH key change (net-snmp's 'snmpusm ... changekey' command) instead of TLS. It's available in nearly all net-snmp variants and adds PFS without TLS. This DH key change is defined/used in DOCSIS 3.0 and is in widespread use by most cable internet routers today. I think it would be a spectacular benefit if the community could leverage DH key change feature of net-snmp through nodeJs.

[markabrahams]

Hi @sean-lawless - yes this would be a great feature!

Just a note for any budding implementers out there, the USM DH key change feature is specified in RFC 2786. Adding to the management station side would be achieved by following the "Theory of Operation" in Section 2 of this RFC.

Adding to the agent side (I know you're not proposing this, but just for reference) would require first an implementation of the SNMP-USER-BASED-SM-MIB specified in RFC 3414, and then an implementation of the SNMP-USM-DH-OBJECTS-MIB DEFINITIONS specified in RFC 2786.