[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Comments on BCP-09
On Mon, Aug 05, 2002 at 05:43:47PM -0700, David T. Perkins wrote:
>9) the problems with the description of authentication notification.
> First, it is specified to be in RFC 1215, and implied to be used
> in only SNMPv1. The current definition of the authentication
> notification is found in RFC 1907. And it is generated when
> SNMPv1, SNMPv2, and SNMPv3 (with USM) result in authentication
Ok we should fix that.
> Now, it is the case that the notification was not well
> designed, and in some deployments due to improper agent design,
> and/or poor choice of security configurations, that its generation
> should be turned off.
Even with proper agent design, and reasonable security
configurations this notification is flawed.
> This section should explain each of these
> factors instead of repeating the herd mentality of "always
> turn off generation".
Sorry there isn't a reasonable network left in existance
where turning it on makes sense to me unless you can turn
back time to say 1980.
> If the notification is not turned on,
> then the objects snmpInBadCommunyUses, usmStatsUnknownUserNames,
> usmStatsNotInTimeWindows, and usmStatsWrongDigests must be
> monitored to determine authentication failures.
Yes, we should add that one should poll these objects instead.
The notification authenticationFailure is flawed for the simple
reason it is sent *ONCE* per invalid pdu. Since most networks are
designed with n notification senders and m notification
receivers, n tends to be much bigger than m. notification senders
are often optimized to send packets faster than general purpose
systems hosting notification receivers.
Hence if one wishes to bowl over a network management system,
one simply starts sending improper authenticated packets with spoofed
source addresses. If a firewall is in the way, then first
compromise some host on the inside and repeat.