RE: Problems with notifications

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

When a notification originator has a notification to send out,
it uses the value of snmpNotifyTag from table snmpNotifyTable
to select entries in table snmpTargetAddrTable that contain
the tag in the tag list value of snmpTargetAddrTagList. Each
entry in the address table points to an entry in table
snmpTargetParamsTable. The values from the address and
parms table specify the transport address, timeout,
retries, message processing model, security model,
security name, and security level; and the notification
table specifies whether to send a trap or inform.

If a trap is to be sent with USM, then the authEngineID is
that of the notification originator (which is typically
an "agent") and is known. That engineID and security
name from the parms table is used to lookup the entry
in table usmUserTable. Now all info is available to
be able to send the trap. (Of course, the notification
filters and VACM has to allow the trap to be sent.)


If an inform is to be sent with USM, then the authEngineID
is that of the receiver. However, there is no standard table
in the SNMPv3 frameworks specification that specifies a mapping
between a transport address in table snmpTargetAddrTable and
an SNMPengineID. So, either engineID (and engine boots and time)
discovery must be done before sending each inform,
or a secret table of cached transport address to
engine ID, boots, and time must be maintained. The
engineID discovery is not secure, since you have
to know both engineID and security name to select
an entry in table usmUserTable, and you don't yet
know the engineID of the notification receiver.
Thus, a dummy noAuth/noPriv inform must be sent to
discover the engineID (and boots and time). With
the discovered engineID and the security name from
the parm table, now table usmUserTable can be accessed.
But to send an inform, the engineBoots and engineTime
must be available, and it is retrieved from the
"remote engineID" table. In summary, to use informs,
there must be a table that maps between transport
address and engineID, and another table that is
indexed by "remote engine ID" that provides boots
and time. (If one is really paranoid and doesn't
want to every do noAuth/noPriv engineID, boots, and
time discovery, then things are a little bit
trickier.)  

Hope this is clear and helps.

On Mon, 10 Jan 2005, Wijnen, Bert (Bert) wrote:
> Can you calrify point 4) ??
> 
> Bert
> 
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> > Behalf Of David T. Perkins
> > Sent: Sunday, January 09, 2005 03:59
> > To: C. M. Heard
> > Cc: Mark Ellison; Mreview (E-mail)
> > Subject: Re: [Fwd: Re: [RMONMIB] I-D
> > ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]
> > 
> > 
> > HI,
> > 
> > It seems like I've been waging a one person battle
> > on the misuse of "accessible-for-notify". I guess
> > I just need to write an informational RFC and then
> > just move on. In general, I believe that MIB designers
> > are trying to create new control (signalling) protocols
> > out of SNMP. There are many problems with notifications
> > in SNMP, including:
> >  1) flow control
> >  2) lack of concern and coping with  dropped or
> >      suppressed notifications
> >  3) different "authEngineID" values for traps
> >      and informs when using USM
> >  4) "missing" objects for USM engine boots and time
> >      for "remote" engines
> >  5) lack of a usable log (RFC 3014 doesn't cut it)
> >  etc
> > 
> > Regards,
> > /david t. perkins

Regards,
/david t. perkins