[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Sat, 8, Dec 2005 C.M. Heard wrote:
| On Sat, 28 Dec 2002 Bert Wijnen wrote:
| > > 2) DoS attacks (as described in some of the ADSL MIBs'
| > > security considerations sections) based on the
| > > conditions under which notifications are generated.
| > > | > Mmm... I wonder... in the end it depends on
| > - having proper access control to those objects that control/limit
| > the sending of notifications (for example access to the tables in
| > RFC3413).
| > - ensuring that no notification flooding will take place.
| > That I guess depends on proper mib design and the MIB doctors should
| > be looking for such issues. I don't think it is OK to just say that
| > DoS attacks are possible. Better to build in controls to prevent it.
| | There is now text in 4.7 to the effect that notifications which can
| be generated by rapidly changing external conditions SHOULD have a
| rate-limiting mechanism in order to avoid overwhelming the network
| with floods of notifications. RFC 2108/RFC 2737 are cited as examples.

The "text in 4.7" referred to above is this:

  In many cases notifications will be triggered by external events, and
  sometimes it will be possible for those external events to occur at a
  sufficiently rapid rate that sending a notification for each
  occurrence would overwhelm the network.  In such cases a mechanism
  MUST be provided for limiting the rate at which the notification can
  be generated.  A common technique is to require that the notification
  generator use throttling -- that is, to require that it generate no
  more than one notification for each event source in any given time
  interval of duration T.  The throttling period T MAY be configurable,
  in which case it is specified in a MIB object, or it MAY be fixed, in
  which case it is specified in the notification definition.  Examples
  of the fixed time interval technique can be found in the SNMP-
  REPEATER-MIB [RFC2108] and in the ENTITY-MIB [RFC2737bis].

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.  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.
  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 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, thanks for your help.

- Clay


-- Paradyne Mail --


_______________________________________________
Adslmib mailing list
Adslmib at ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib