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

["C. M. Heard" <heard@pobox.com>]

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.

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