Re: Updating the MIB security guidelines

["C. M. Heard" <heard@pobox.com>]

On Fri, 27 Dec 2002, Randy Presuhn wrote:
> I think there should also be some mention of accessible-for-notify
> objects and of notification types.
> 
>    1) sensitivity of notifications and their payloads

To address this comment it should suffice to re-word the third section
along the following lines:

-- for all MIBs you must evaluate

   Some of the readable objects in this MIB module (including objects
   with a MAX-ACCESS clause of accessible-for-notify) may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control even GET and/or NOTIFY access to these objects
   and possibly to even encrypt the values of these objects when
   sending them over the network via SNMP.  These are the tables and
   objects and their sensitivity/vulnerability:

    <list the tables and objects and state why they are sensitive>

>    2) DoS attacks (as described in some of the ADSL MIBs'
>       security considerations sections) based on the
>       conditions under which notifications are generated.

I'm not so sure that the example you cite is a good one to emulate.

Here is the relevant part of the Security Considerations section
from the ADSL MIB (RFC 2662):

   3) ADSL layer connectivity from the ATU-R will permit the subscriber
   to manipulate both the ADSL link directly and the AOC/EOC channels
   for their own loop.  For example,  unchecked or unfiltered
   fluctuations initiated by the subscriber could generate sufficient
   traps to potentially overwhelm either the management interface to the
   network or the element manager.  Other attacks affecting the ATU-R
   portions of the MIB may also be possible.

It was my understanding that accepted practice is to specify that
notification that can be generated by rapidly fluctuating external
conditions must be rate limited so as to avoid overwhelming the
network.  See, for example, draft-ietf-atommib-atm2-18.txt, where
the notification atmIntfPvcFailuresTrap is rate-limited by the object
atmIntfPvcNotificationInterval.

It seems to me that the need to have a warning in the security section
about the possibility of DoS attacks from notification floods is
indicative of a design flaw in the MIB module, i.e., lack of a rate
limiting mechanism for the notifications in question.

Or am I missing something?

Mike