RE: Security Considerations for writeable objects (was: RE: Pls r eview documents on IESG Agenda for December 1, 200)5

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

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of C. M. Heard
> Sent: Sunday, November 27, 2005 16:59
> To: Mreview (E-mail)
> Subject: Re: Security Considerations for writeable objects 
> (was: RE: Pls
> review documents on IESG Agenda for December 1, 200)5
> 
> 
> On Sun, 27 Nov 2005, Andy Bierman wrote:
> >Romascanu, Dan (Dan) wrote:
> >>[C. M. Heard wrote:]
> >>>>  o draft-ietf-isis-wg-mib-24.txt
> >>>>    Management Information Base for IS-IS (Proposed 
> Standard) - 20 of 22 
> >>>>    Token: Alex Zinin
> >>>>
> >>>I did the MIB Doctor review for this doc and I am satisfied 
> >>>with it.  I see come comments from a GenArt in the tracker.  
> >>>I agree with those on Section 2 and disagree with those on 
> >>>Section 7.  The reason I disagree is that complying with the 
> >>>comment would require listing all writeable objects in the 
> >>>MIB module, and it should be sufficient to say "all writeable 
> >>>attributes have the potential to disrupt network operations 
> >>>if improperly modified" as the doc now does.
> >>
> >>I am a little surprised by this comment from Mike, and I 
> think that I
> >>would disagree. 
> >>
> >>We are telling explicitly MIB writers at
> >>http://www.ops.ietf.org/mib-security.html:
> >>
> >>-- if you have any read-write and/or read-create objects, please
> >>-- describe their specific sensitivity or vulnerability.
> >>-- RFC 2669 has a very good example.
> >>
> >>I am opposed to replace this by another blanket generic 
> text. Different
> >>objects bear different threats in disrupting network operations if
> >>improperly modified, and I believe that it is important for the MIB
> >>documents to specifically and explicitly list those. 
> >
> >Me too!
> >I have often wondered if we could have some sort of coherent security
> >threat ranking guidelines, but it's too subjective (like the Fujita
> >Scale for MIB objects :-)
> >A knob that tells RMON how often to garbage collect useless 
> data is hardly
> >going to impact the network in the same manner as the knob 
> that disables
> >BGP.
> >
> >The problem with blanket boilerplate text is that sooner or 
> later everybody
> >knows it doesn't really apply, and they ignore ALL the text, 
> even when
> >you're telling them about the BGP knob.
> 
> I was defending the decision ***IN THIS CASE*** to say "all writeable
> attributes have the potential to disrupt network operations 
> if improperly
> modified and may require protection against unauthorized 
> write access."
> 
> I have just re-read the MIB module, and I don't see any obviously
> innocuous read-write or read-create objects.  I can't see any clear
> reason to set a different security policy for some of the writeable
> objects as opposed to others.  And if that is the case, I can't see
> any reason to list all 64 writeable objects.
> 

So, I suspect that there will be NO DISCUSS coming on this.
We can see.

If we (as collective set of MIB doctors) believe that it might help, we
could suggest some text aka "All 64 writable object have similar security
and privacy considerations, ..." The idea being that the authors (and
reviewers) in fact did consider ALL writable objects.

But does this text:

   network operations.  Since the MIB controls a device which routes
   packets, all writeable attributes have the potential to disrupt
   network operations if improperly modified and may require protection
   against unauthorized write access.

not already say so?

Bert

> The undercurrent with the GenArt comments, as well as Dan's 
> and Andy's,
> seems to be that every MIB module with writeable objects has some that
> are relativley innocuous and some that are not.  I don't think that is
> true ***IN THIS CASE***.  Maybe I am wrong about that, though.
> 
> In any case, the issue is whether a DISCUSS is going to be put on
> the document during IESG review.  I do believe that if that is done,
> the burden of proof is is on the party making the complaint to say
> explicitly why the current text is not good enough, e.g., by saying
> which objects should get different security policy treatment.
> 
> Mike
> 
>