Subject: mboned: Security Considerations update for draft-ietf-mboned-msdp-mib

From: Bill Fenner <[email-masked]>
Date: Fri, 22 Sep 2006 11:05:47 -0700 (PDT)

In AUTH48, the topic of security considerations for
draft-ietf-mboned-msdp-mib came up.  In response, I wrote the
following security considerations update, which I'd like the WG to
have a chance to review before making the change.  I'd like to hear
comments by Friday, September 29th.

Thanks,
  Bill

4.  Security Considerations

      There are a number of management objects defined in this MIB
      module with a MAX-ACCESS clause of read-write and/or read-create.
      Such objects may be considered sensitive or vulnerable in some
      network environments.  The support for SET operations in a non-
      secure environment without proper protection can have a negative
      effect on network operations.  These are the tables and objects
      and their sensitivity/vulnerability:

      msdpEnabled
         Obviously, by modifying msdpEnabled, an attacker could simply
         disable MSDP processing on the router.

      msdpCacheLifetime
         If allowed to modify msdpCacheLifetime, an attacker could set
         the value to a value lower than a peer's refresh interval,
         causing all state to time out and be refreshed.

      msdpRequestsPeer, msdpRequestsStatus
         If allowed to modify entries in the msdpRequestsTable, an
         attacker could cause this system to send MSDP Requests to an
         unknown system, or could simply remove the proper
         configuration.  Note that the msdpRequestsTable is deprecated,
         and the MSDP Request functionality is not in the published MSDP
         spec.

      msdpPeerTable objects
         The writable objects in the msdpPeerTable are:
         msdpPeerLocalAddress, msdpPeerConnectRetryInterval,
         msdpPeerHoldTimeConfigured, msdpPeerKeepAliveConfigured,
         msdpPeerDataTtl, msdpPeerProcessRequestsFrom, msdpPeerStatus,
         and msdpPeerEncapsulationType.  Of these, modifying
         msdpPeerIpAddress and msdpPeerStatus could cause a changed or
         deleted peer configuration.  Modifying any of the other values
         could cause subtle protocol misbehavior.

      msdpSACacheStatus
         This writable object can be used to remove valid values from
         the router's SA cache.

      msdpRPAddress
         Changing this object can cause a failure of the Peer-RPF rules
         for SA messages sourced by this router.

      msdpMeshGroupStatus
         This object can be used to change this router's idea of its
         mesh group membership and those of its peers.  Misconfiguration
         of mesh groups can cause subtle protocol misbehavior.

      Some of the readable objects in this MIB module (i.e., objects
      with a MAX-ACCESS other than not-accessible) may be considered
      sensitive or vulnerable in some network environments.  It is thus
      important to control even GET and/or NOTIFY access to these
      objects and possibly to even encrypt the values of these objects
      when sending them over the network via SNMP.  These are the tables
      and objects and their sensitivity/vulnerability:

      o The entire msdpPeerTable.  Peer information can result in
        discovering internal topology, which many want to keep secret.

      o msdpNumSACacheEntries.  The size of the SA Cache could reveal
        whether this system has MSDP entries for public and/or private
        groups.

      o The entire msdpSACacheTable.  The active sources and groups in a
        network could be private.

      o The entire msdpMeshGroupTable.  This information can also lead
        to internal topology information.

      SNMP versions prior to SNMPv3 did not include adequate security.
      Even if the network itself is secure (for example by using IPsec),
      even then, there is no control as to who on the secure network is
      allowed to access and GET/SET (read/change/create/delete) the
      objects in this MIB module.

      It is RECOMMENDED that implementers consider the security features
      as provided by the SNMPv3 framework (see [6], Section 8),
      including full support for the SNMPv3 cryptographic mechanisms
      (for authentication and privacy).

      Further, deployment of SNMP versions prior to SNMPv3 is NOT
      RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
      enable cryptographic security.  It is then a customer/operator
      responsibility to ensure that the SNMP entity giving access to an
      instance of this MIB module is properly configured to give access
      to the objects only to those principals (users) that have
      legitimate rights to indeed GET or SET (change/create/delete)
      them.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/