Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-m ib-15.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 8 Oct 2003 16:09:09 -0400

Hi

While I understand how the ARC MIB could be used to cause the problems that
the IESG was concerned with, I don't really see where the Alarm MIB poses
any more risk than 'normal' notifications. Ok. Let me put on my imagination
hat: if a manager somehow sets up 323432 alarm models that alarm on the same
internal stimulus and use the Alarm MIB notifications and then makes that
internal stimulus happen, then 323432 notifications will get sent out on the
wire. Is this what we are trying to warn people against? 

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:58 PM
To: Disman (E-mail)
Subject: Re: [Disman] Security considerations in
draft-ietf-disman-alarm-mib-15.txt

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, October 08, 2003 12:48 PM
> Subject: RE: [Disman] Security considerations in 
> draft-ietf-disman-alarm-mib-15.txt
..
> The following is the proposed resolution to Randy-75-2. Assuming no 
> objection, this item will is closed with no changes to the draft.

I object, both as WG chair and as a technical contributor.

> Assuming you referring to the following text:
>
> "  Setting these objects may have disruptive effects on network
>    operation that range from omission of alarm notifications to
>    flooding of unwanted alarm notifications from the network.
>    The consequence of suppressing or deferring the reporting
>    of an alarm can prevent the timely delivery of important
>    diagnostic information, including information that can help
>    identify an attack."
>
> This is not relevant in the case of the Alarm MIB since we neither 
> suppress or defer notifications. We have text about throttling in the 
> 'normal' places within the draft.

Technically:
Even with the throttling language that's there, this MIB can be used to
cause flooding, either due to an exessive number of resources going into
alarm (throttling is in part per resource type), oscillating (throttling is
on consecutive notifications), or distributed DoS (multiple systems
configured).

As Chair:
Given the IESG's comments on the ARC MIB, which show that they are well
aware of these issues, I believe we need to reconsider.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 13:34:35 -0700

Hi -

> Sent: Wednesday, October 08, 2003 1:09 PM
> Subject: RE: [Disman] Security considerations in draft-ietf-disman-alarm-mib-15.txt
...
> wire. Is this what we are trying to warn people against?
...

That's getting into the spirit.  Particularly if the manager is a bad guy and has
those 323432 notifications sent to some other system as (part of) a DDoS
attack.  A really obnoxious one would be to set up a two-entry alarm model
to form a feedback loop: seeing any alarmActiveState triggers an alarmClearState,
which in turn triggers an alarmActiveState.  As soon as some other alarm
(innocently) becomes active, and endless cascade starts.  It can't be turned off
because of the way alarmModelRowStatus works.  Because it's an oscillation,
the throttle won't slow it down.  Resetting the box wouldn't stop it; the only
hope would be to nip it in the bud using RFC 3413.  Meanwhile, whatever
manager(s) were identified as targets would be drowning in notifications.

That's why these objects are sensitive and should be protected by an
appropriate security policy.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 13:34:35 -0700

Hi -

...
...

Randy