Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Jul 2004 18:41:59 +0300

I have some concerns with respect to the Security Considerations section. It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html), probably reflecting the style or the guidelines that were in place by the time RFC 2925 was published. However, I miss the clarity of the current text, and especially the enumeration of the security sensitive objects in the MIB modules, the explicit description of the risks associated with their mis-configuration or disclosure, and the explicit recommendation to deploy SNMPv3 and to enable cryptographic security.

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Randy Presuhn
> Sent: 17 June, 2004 9:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Disman] Disman WG last call 
> ondraft-ietf-disman-remops-mib-v2-02.txt
> 
> 
> Hi -
> 
> As disman WG chair, I'm announcing the start of a two-week 
> working group
> last call on the Remote Operations MIBs.  The latest version 
> is available at
> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m
> ib-v2-02.txt
> Our objective is to advance to Draft Standard.  Off-line I've received
> word that that we will have at least two implementation reports.  I'm
> fairly sure there are more out there, so please speak up if 
> you know of
> an implementation.
> 
> I'm CC:ing the ipcdn WG mailing list, since we've incorporated some
> additional conformance material to meet (I hope) their needs.  Please
> send any comments, including "I've read it and don't object" comments,
> to the disman WG mailing list at [email-masked].
> 
> The last call will end on Friday, July second, 2004.  If 
> anyone is committed
> to reviewing it but would need additional time, let me know 
> and I'll see what
> we can work out.
> 
> Randy
> 
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 Jul 2004 11:59:53 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 01, 2004 8:41 AM
> Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt
>

> I have some concerns with respect to the Security Considerations section.
> It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html),
> probably reflecting the style or the guidelines that were in place by the time
> RFC 2925 was published.

(As WG chair) Clearly, this must be fixed before we ask our AD to take
it to the IESG.

Juergen Q.: could you re-spin this before the i-d cutoff?

> However, I miss the clarity of the current text, and
> especially the enumeration of the security sensitive objects in the MIB modules,
> the explicit description of the risks associated with their mis-configuration or
> disclosure, and the explicit recommendation to deploy SNMPv3 and to enable
> cryptographic security.
...

(As technical contributor) I rather like the current text.  I'd like to see it retained
(except perhaps the first paragraph, which would become redundant) and
merged with the additional text required by the boilerplate.

Randy

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 02 Jul 2004 10:03:06 +0200

Rand

> merged with the additional text required by the boilerplate.

I will try to satisfy both sides: including the new boilerplate text and listing
vulnerable objects as well as keeping all but the first paragraphs of the current
version.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 02 Jul 2004 13:58:55 +0200

Randy,

Sorry, my last email slipped out of my mail editor
while I was typing with a wrong keyboard driver.

> Juergen Q.: could you re-spin this before the i-d cutoff?

Yes.  I am currently working on the issues raised by Eduardo.
Fixing the security consideration should not be a big problem.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 08 Jul 2004 02:31:12 +0200

Dan and Randy,

Below please find a new version of the Security Considerations.
Please have a look at it and tell me if it covers your concerns.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

> vulnerable objects as well as keeping all but the first paragraphs of the current

5.  Security Considerations

   There are a number of management objects defined in the three MIB
   modules 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:

   o  pingMaxConcurrentRequests
   o  traceRouteMaxConcurrentRequests
   o  lookupMaxConcurrentRequests
      The MIB modules limit their maximum numbers of concurrent requests
      by the values of these objects.  Unauthorized access to them may
      lead to an overload of the managed node and to a disruption of
      other functions of the managed node.

   o  pingCtlTable
   o  traceRouteCtlTable
   o  lookupCtlTable
      All objects in entries of these tables (except index objects) have
      a MAX-ACCESS clause of read-create.  Unauthorized access to these
      objects can disturb the measurements controlled by the tables.
      Also, the functions offered by the MIB modules can be misused for
      illegal data retrieval and for attacking other systems by floods
      of ping probes, traceorute probes or lookup requests,
      respectively.

   In general, both the ping and traceroute functions when used
   excessively are considered a form of system attack.  In the case of
   ping sending a system requests too often can negatively effect its
   performance or attempting to connect to what is supposed to be an
   unused port can be very unpredictable.  Excessive use of the
   traceroute capability can like ping negatively affect system
   performance.  In insecure environments it is RECOMMENDED that the
   MIBs defined within this memo not be supported.

   o  lookupPurgeTime
      Unauthorized access to this object can lead to results of lookup
      operations being deleted before they are read by a management
      system, if the object is set to 0 or small values close to 0.  If
      otherwise, the object is set to very high values, unauthorized
      access can lead to a high consumption of resources for storing
      lookup results.

   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.  However, the only information that might be
   disclosed is the configuration and results of measurements that are
   performed by implementations of the MIB modules.  This information
   can only be mis-used in conjunction with the mis-use of further
   information.

   To facilitate the provisioning of access control by a security
   administrator using the View-Based Access Control Model (VACM)
   defined in RFC 3415 [RFC3415] for tables in which multiple users may
   need to independently create or modify entries, the initial index is
   used as an "owner index".  Such an initial index has a syntax of
   SnmpAdminString, and can thus be trivially mapped to a securityName
   or groupName as defined in VACM, in accordance with a security
   policy.

   All entries in related tables belonging to a particular user will
   have the same value for this initial index.  For a given user's
   entries in a particular table, the object identifiers for the
   information in these entries will have the same subidentifiers
   (except for the "column" subidentifier) up to the end of the encoded
   owner index. To configure VACM to permit access to this portion of
   the table, one would create vacmViewTreeFamilyTable entries with the
   value of vacmViewTreeFamilySubtree including the owner index portion,
   and vacmViewTreeFamilyMask "wildcarding" the column subidentifier.
   More elaborate configurations are possible.  The VACM access control
   mechanism described above provides control.

   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 [RFC3410], 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.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 8 Jul 2004 09:50:15 -0700

Hi -

> From: "Juergen Quittek" <[email-masked]>
> To: "Juergen Quittek" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Sent: Wednesday, July 07, 2004 5:31 PM
> Subject: Re: [Disman] Disman WGlast call ondraft-ietf-disman-remops-mib-v2-02.txt
>

...

As technical contributor:
   This looks very good to me.  I'm happy.
   I'll reply to Dan's observations separately.

As WG chair:
   I'll have limited email access until Sunday.
   I'd like you to proceed as follows in my virtual absence.

   Since no other issues have surfaced, please submit the updated
   i-d at your earliest opportunity after coming to agreement on Dan's
   concerns about whether the lookup MIB should be included in the
   list of MIBs NOT RECOMMENDED for implementation in insecure
   environments.

   In light of the stability and lack of problems reported on this document,
   there will be a ONE WEEK WG last call, starting when
   the updated i-d appears.  If anyone *committed* to reviewing the
   document needs additional time, please contact me and we'll work
   something out.

Randy