Re: MIB Doctor Review of draft-ietf-adslmib-gshdslbis-07.txt

On Wed, 19 Jan 2005, Clay Sikes wrote:
> >On Sat, 8, Dec 2005 C.M. Heard wrote:
...
> >If I correctly understood what I read in the MIB module (and it is
> >certainly possible that I did not), then it would appear that the
> >notifications that could be flooded in case of fluctuations
> >initiated by the subscriber are hdsl2ShdslLoopAttenCrossing and
> >hdsl2ShdslSNRMarginCrossing, which are controlled by the writeable
> >objects hdsl2ShdslEndpointThreshLoopAttenuation and
> >hdsl2ShdslEndpointThreshSNRMargin.  At the very least the user
> >should be warned that incorrect configuration of these objects could
> >lead to that exposure (cf. (a) above).  You may also want to
> >consider adding a throttling mechanism to those notifications.  As
> >far as I could tell, the other notifications are already
> >rate-controlled.
> >
> >  
> >
> Hi Mike,
> 
> I really appreciate the time you spent looking over the draft.  I'm 
> starting to rework the draft as I can find some time.
> 
> I do have a question on the above issue.  Would the following be a solution:
> 
>    1. In the description text for each notification, add some text that
>       the agent must throttle the generation of consecutive
>       notifications of a specific notification object.  State that there
>       is to be at least a five-second gap between notifications of this
>       type.  This seems to be how RFC 2108 and RFC 2737 handled the
>       potential notification flooding situation.

That would be fine.  But note that there is nothing obligatory about
the five-second interval used in RFC 2108 ... if a shorter or longer
"dead time" interval would be more appropriate for this technology,
then that should be specified.  Also, some of the notifications
are by design limited to being generated once every 15 minutes
(hdsl2ShdslPerfESThresh is one such, or so it says in the
DESCRIPTION clause of hdsl2ShdslEndpointThreshES), and there is no
need for any change to those.

>       I'm not sure if I
>       should state when notification are throttled, they are dropped,
>       like was stated in RFC 2108, or should there be some sort of
>       queuing mechanism such as RFC 2737.  Perhaps you or someone will
>       have a preference on this.

This is an issue for the WG to agree on.  The simplest procedure
would probably be to drop notifications that are throttled in this
manner, as is done in RFC 2108.  Since the addition of throttling is
not entirely backward compatible -- will require some change to an
agent that is not already doing it -- it is probably a good idea to
specify the simplest mechanism that will do the job.

>    2. As part of the rework of Security Considerations section to bring
>       it in compliance with the Security Guidelines for IETF MIB
>       Modules, I'll add some text stating that notification flooding can
>       occur and that the agent, should or must, throttle each specific
>       notification such that three is at least a five-second gap.

The security threat is not from devices that do the throttling, but
rather from devices that do not.  So, my suggestion would be to state
that the previous version of the specification did not specifically
require throttling for certain notifications, and that devices
implemented to that version of the specification might generate
notifications at an uncontrolled rate.  Be as specific as possible in
saying under what circumstances this could happen.

> The other option would be to add object(s) to configure the throttling 
> mechanism.  I'm not sure this is the best approach because the 
> notification flooding issue exists with lots of other physical 
> interfaces such as ADSL and T1/E1.

Again, this is an issue for the WG to agree on.  Probably simpler is
better at this point.  (Note, however, that if such objects were added
it would probably be necessary to add some cautionary notes in the
Security Considerations section stating that a notification flood
could occur in the event of misconfiguration by an unauthorized party.)

Hope that helps.  Bert, pls speak up if you disagree with my advice.

Mike