Security Considerations for our MIBs

["R.E. (Robert) Moore (254-4436)" <[e-mail]>]

Currently only one thing stands in the way of the APPN MIB's going
forward to the IESG:  a nontrivial Security Considerations section.  Both
Randy and Deirdre have indicated that we can't slip by under a
grandfather clause here.  So in the absence of contributions from anyone
else, I decided to take a shot at some Security Considerations sections
for all three of our current MIBs.  The format is the same in all three
cases:  a generic paragraph saying, in effect, SNMP security is global,
not different for each MIB, followed by a quick mention of any particular
objects in the MIB that are especially sensitive.  The generic part is
based on the material from the IETF that I forwarded to you earlier.

I'm certainly open to suggestions for improvements, both in the generic
text and in the MIB-specific parts.  We can wait until next week to fine-
tune the sections for the DLUR and HPR MIBs.  It would be nice, however,
if we could reach agreement on the APPN MIB's Security Considerations by
tomorrow, so that BobC (Yes!  Finally we have a change that hits his part
of a document harder than it does mine:-)) can pull in the text and
generate a new Internet-Draft.  We could get this draft posted before the
IETF 38 blackout, and still have a chance for Deirdre to take the MIB to
the IESG before we move to our new area.

So take a quick look at this material, and send your responses back to
the mailing lists.

Thanks,
Bob Moore
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Proposed "Security Considerations" Section (APPN MIB):

In most cases, MIBs are not themselves security risks; if SNMP security
is operating as intended, the use of a MIB to view information about a
system, or to change some parameter at the system, is a tool, not a
threat.

None of the read-only objects in the APPN MIB reports a password, user
data, or anything else that is particularly sensitive.  Some enterprises
view their network configuration itself, as well as information about
network usage and performance, as corporate assets; such enterprises may
wish to restrict SNMP access to most of the objects in the MIB.

Four of the read-write objects in the MIB can affect network operations;
it is recommended that SNMP access to these objects be restricted.  The
four objects are:

  -  appnNodeNnSafeStoreFreq:  Setting this object to 0, or to a very
     large value, effectively turns off safe storing of topology data.

  -  appnPortCommand, appnLsCommand:  These two objects allow an APPN
     port or link station to be activated, deactivated, or recycled via
     an SNMP operation.  The latter two operations may disrupt current
     users of the network.

  -  appnIsInSessState:  Setting this object to 'inactive' causes an
     active SNA session to be deactivated.

Other read-write objects control the gathering of network management
data; controlling access to these objects is less critical.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Proposed "Security Considerations" Section (DLUR MIB):

In most cases, MIBs are not themselves security risks; if SNMP security
is operating as intended, the use of a MIB to view information about a
system, or to change some parameter at the system, is a tool, not a
threat.

None of the read-only objects in the DLUR MIB reports a password, user
data, or anything else that is particularly sensitive.  Some enterprises
view their network configuration itself, as well as information about
network usage and performance, as corporate assets; such enterprises may
wish to restrict SNMP access to most of the objects in the MIB.

There are no read-write objects in the DLUR MIB.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Proposed "Security Considerations" Section (HPR MIB):

In most cases, MIBs are not themselves security risks; if SNMP security
is operating as intended, the use of a MIB to view information about a
system, or to change some parameter at the system, is a tool, not a
threat.

None of the read-only objects in the HPR MIB reports a password, user
data, or anything else that is particularly sensitive.  Some enterprises
view their network configuration itself, as well as information about
network usage and performance, as corporate assets; such enterprises may
wish to restrict SNMP access to most of the objects in the MIB.

One read-write object in the MIB can affect network operations:

  -  hprRtpPathSwitchTrigger:  Setting this object to 'switchPathNow'
     triggers an immediate path switch attempt.  An HPR path switch does
     not itself disrupt the SNA sessions using the RTP connection
     undergoing the path switch.  However, frequent path switches for
     many RTP connections can have an adverse impact on overall network
     performance.

It is recommended that SNMP access to this object be restricted.

Other read-write objects control the gathering of network management
data; controlling access to these objects is less critical.