[Wes - if you're around, we could probably
do with your input on this one! ]
On Tue, 2005-08-23 at 16:33 -0700, David T. Perkins wrote:
> Now, on NET-SNMP, what I find most troubling is the
> inconsistent behavior between SNMPv1(and v2c), and
> SNMPv3/USM, and between TRAPs and INFORMs.
Agreed.
The current situation is clearly not sensible,
and should be improved.
> I would hope for the following changes for USM:
> 1) with no users configured, you should be able to recieve
> both noAuthNoPriv TRAPs and INFORMs
I'd support that.
It would be consistent with the handling of community-based
notifications, and also the generation of SNMPv3 noAuth
requests.
(see snmpusm.c:usm_generate_out_msg())
> 2) on authNoPriv TRAPs and INFORMs, if there is a
> problem ... then I believe that the notification
> should still be outputted
I disagree.
That would be inconsistent with the handling of errors with
other PDU types, and the processing of community-based traps.
(e.g RFC 1157, section 4.1)
It might well be sensible to log an indication that there
was an erroneous message received (rather than just failing
silently), but I wouldn't suggest any more processing than
that. It certainly shouldn't be merged with the main trap
handler processing.
> 3) on authPriv and a failure, an output should still
> be done, but with an error indication that the
> message content is not available.
Again, this feels similar to the failed authenticated request
case. Logging an error would be sensible, but nothing more.
>From the other list of suggestions:
> 1) not require entries for noAuthNoPriv
Agreed
> 2) print what protocol of each trap or inform
> 3) print security level (unsecured (noAuthNoPriv),
> authenticated(authNoPriv), or encrypted(authPriv)
I don't think we should change the existing (external)
'traphandle' API. We've documented the input format
that such scripts should expect for too long now.
However the internal Netsnmp_Trap_Handler routine does
receive the incoming PDU (complete with version and
administrative settings) as one of the parameters.
So this information is already available to C-based
trap handlers.
There probably isn't a simple way to make use of this
as yet (other than adding code to 'snmptrapd_handlers.c'),
but the basic framework is in place.
Either extending the build environment to support a
"trapd module" mechanism (similar to the existing agent
MIB module setup), or a new "trap2handle" directive
(with an extended input format). Or both!
> 4) print and indication as to the status (success, noSuchUser,
> engineID/EngineClock discovery, outOfTimeWindow, authFail,
> decryptionFail, etc)
Reporting errors feels different from processing successful
incoming requests. I can see a case for having a separate
"error handler" mechanism, but this should probably be
considered as part of the main SNMP library, rather than
something exclusively for snmptrapd.
I *still* feel that we need to address the non-scalability
of engine IDs wrt SNMPv3 traps. Both GET*/SET requests
and inform notifications Just Work (discovering engineIDs
automatically). That's not possible for unacknowledged
traps, but we ought to be able to come up with a simpler
mechanism, but staying within the existing (possibly broken)
USM framework.
Hence my suggestion of "wildcard" user matching.
Dave
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
