[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Comments on BCP-09
It's surprising that there is so much agreement in the below. One
would think that we work together or something.
At 06:52 PM 8/5/2002 -0700, Michael MacFaden wrote:
>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.
Warning! Time-space continuum violation.
>> 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.
Sometimes when we agree with the resulting action, there is a
disagreement with the reason. Why, because learning a lesson
is more important than a single solution. So, the problem, AGAIN,
with the BCP is the repeated reason (which is incorrect).
So, Mike, do you want to describe the dampening algorithm that
should be used, or do you want me to describe it?
/david t. perkins