RE: Updating the MIB security guidelines

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zaterdag 28 december 2002 5:25
> To: mibs@ops.ietf.org
> Subject: Re: Updating the MIB security guidelines
> 
> 
> 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

or maybe even better:

     Some of the readable objects in this MIB module (that is all objects
     with a MAX-ACCESS other than not-accessible) 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.
> 
Seems to be inline with what I responded to Randy.
And it sounds as if we should have told the ADSL folk to include some
rate-limiting control objects?

Bert
> Or am I missing something?
> 
> Mike
> 
>