[marcosdumay]

> Devices don't identify themselves in any consistent way

SNMP standardized that before sysadmins everywhere decided it was devil's reincarnation and banned all of it that they could. When working on an equivalent standard, it may be useful to think about why your standard won't suffer the same fate from the same reasons.

[FooHentai]

>SNMP standardized that before sysadmins everywhere decided it was devil's reincarnation and banned all of it that they could.

Dunno what you mean. SNMP Write is certainly a hard sell to allow, but SNMP read has been a consistently useful element of monitoring strategy across many organisations I've worked for.

V3's still a tricksy, time-sucking devil to implement ubiquitously, though.

[marcosdumay]

Information gathering is entirely in the read part of the spec.

Things have been improving, but SNMP used to break at every network bridge, no matter if any part of it was external or had any kind of difference security requirements. It was completely reliable that if you got into an organization, you wouldn't be able to communicate with anything in a different network segment, even for status messages. This was one of the obstacles for IPv6 adoption, since it used to require status messages for setting datagram sizes (I think that changed).

It looked like every sysadmin on Earth would look at SNMP, say "I don't want an attacker to have status and infrastructure information of my network", and block it. As did all network security guides on the Web.

I once worked for a company that basically had a client software that transmitted the same information of SNMP-read over HTTP. When I would go at clients I often asked their sysadmins why SNMP was blocked, they would always say "security", then I would tell them that they were buying this that was exactly the same as SNMP, and they would just say it's different somehow...