Re: snmpconf Comments on BCP-09

[Michael MacFaden <mrm@xxxxxxxxxxxxxxxxx>]

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
>   failures. 

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. 

Mike