Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 1 Oct 2003 10:33:40 -0400

The replacement text is fine to me.
Thanks.

Regards,
Kam

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Wednesday, October 01, 2003 10:10 AM
> To: Disman (E-mail) (E-mail)
> Subject: RE: [Disman] FW: draft-ietf-disman-conditionmib
> 
> 
> In further discussions between Russ and me, the proposal now
> is to replace this text on page 13:
> 
>    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 netowrk.
> 
> with this 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.
> 
> Any objection fropm author/editor and or WG members?
> 
> We can make the change via an RFC-Editor note, so no need
> to respin the doc.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: woensdag 1 oktober 2003 10:46
> > To: Disman (E-mail) (E-mail)
> > Subject: [Disman] FW: draft-ietf-disman-conditionmib
> > 
> > 
> > FYI
> > 
> > Thanks,
> > Bert 
> > 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: woensdag 1 oktober 2003 10:37
> > To: 'Russ Housley'; [email-masked]
> > Subject: RE: draft-ietf-disman-conditionmib
> > 
> > 
> > Russ writes:
> > > 
> > > The ability to remotely shut off alarms seems to have a 
> > slightly different 
> > > security consideration that the usual MIB document, yet 
> > this document has 
> > > the typical boilerplate.
> > 
> > But... it is not JUST Boilerplate !!!
> > I did (and normally always do) ask them to be specific and explain
> > what the vulnerabilities are and I think they did. They have in the
> > security section:
> > 
> >   network operations.  These are the tables and objects and their
> >   sensitivity/vulnerability:
> > 
> >      arcTITimeInterval,
> >      arcCDTimeInterval,
> >      arcState,
> >      arcNalmTimeRemaining,
> >      arcRowStatus,
> >      arcStorageType.
> > 
> >   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 netowrk.
> > 
> > Maybe you do not find that detailed/speciifc enough?
> > But I am not sure we want them to go into detail about specific
> > alarms, cause this table is a generic table.
> > 
> > > I do not feel strong enough to register a  DISCUSS, but there is
> > > something unsettling.  Part of the  reason that I do not
> > > want to register a DISCUSS is because the alarms 
> themselves are not 
> > > described in this document.  The context of the alarms 
> needs to be 
> > > understood to determine the security consequences of masking them.
> > >
> > Well... they reference the ITU documents where these ARE described.
> > We do not want them to repat that description, do we?
> > 
> > Hope this makes you feel better letting it pass.
> > 
> > Bert 
> > > Russ
> > > 
> > > 
> > 
>