RE: Disman WGlast call ondraft-ietf-disman-remops-mib-v2-02.txt

It looks fine with one observation. The phrase:

 In insecure environments it is RECOMMENDED that the
   MIBs defined within this memo not be supported.

seems intended to apply only for the ping and traceroute MIB, not for the lookup MIB. 

In any case, this seems redundant with the generic recommendations that are part of the security boilerplate which say:

 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. 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of Juergen Quittek
> Sent: 08 July, 2004 3:31 AM
> To: Juergen Quittek; Randy Presuhn; [email protected]; 
> Romascanu, Dan (Dan)
> Subject: Re: [Disman] Disman WGlast call 
> ondraft-ietf-disman-remops-mib-v2-02.txt
> 
> 
> 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 protected]        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
> 
> 
> --On 02.07.2004 13:58 h +0200 Juergen Quittek wrote:
> 
> > Randy,
> >
> > Sorry, my last email slipped out of my mail editor
> > while I was typing with a wrong keyboard driver.
> >
> >
> > --On 01.07.2004 11:59 h -0700 Randy Presuhn wrote:
> >
> >> Hi -
> >>
> >>> From: "Romascanu, Dan (Dan)" <[email protected]>
> >>> To: "Randy Presuhn" <[email protected]>; 
> <[email protected]>
> >>> Cc: <[email protected]>
> >>> 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?
> >
> > Yes.  I am currently working on the issues raised by Eduardo.
> > Fixing the security consideration should not be a big problem.
> >
> >>> 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.
> >
> > 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.
> >
> > Thanks,
> >
> >     Juergen
> >
> >> Randy
> >>
> 
> 
> 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.
> 
> 
> 
>