Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt

From: [email-masked]
Date: Mon, 19 Jul 2004 15:20:19 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Distributed Management Working Group of the IETF.

	Title		: Definitions of Managed Objects for Remote 
			  Ping, Traceroute, and Lookup Operations
	Author(s)	: J. Quittek, K. White
	Filename	: draft-ietf-disman-remops-mib-v2-03.txt
	Pages		: 89
	Date		: 2004-7-19
	
This memo defines Management Information Bases (MIBs) for performing
remote ping, traceroute and lookup operations at a remote host.  When
managing a network it is useful to be able to initiate and retrieve
the results of ping or traceroute operations when performed at a
remote host.  A Lookup capability is defined in order to enable
resolving of either an IP address to an DNS name or an DNS name to an
IP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing
remote ping or traceroute operations.  The purpose of this memo is to
define a standards-based solution to enable interoperability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-disman-remops-mib-v2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 20 Jul 2004 12:28:37 +0200

Dear all,

Below please find the list of changes from version -02 to version -03.

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.netlab.nec.de

> 	Filename	: draft-ietf-disman-remops-mib-v2-03.txt

=======================================
changes from version -02 to version -03
=======================================

========================================================================
23. new Internet draft boilerplates
========================================================================
Problem Description:
------------------------------------------------------------------------
The boilerplates for Internet drafts have changed. the ones used so far
are outdated.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Update boilerplate sections.
========================================================================
Status: solution committed
========================================================================

========================================================================
24. DESCRIPTIONs of pingCtlTrapProbe/TestFailureFilter unclear
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clauses of objects pingCtlTrapProbeFailureFilter and
pingCtlTrapTestFailureFilter have some ambiguity
========================================================================
Suggested solution:
------------------------------------------------------------------------
in DESCRITION clause of pingCtlTrapProbeFailureFilter replace OLD
            Setting pingCtlTrapGeneration
            to probeFailure(0) implies that a pingProbeFailed
            NOTIFICATION is generated only when the number of
            successive probe failures as indicated by the
            value of pingCtlTrapPrbefailureFilter fail within
            a given ping test."
with NEW
            Setting BIT probeFailure(0) of object
            pingCtlTrapGeneration to '1' implies that a
            pingProbeFailed NOTIFICATION is generated only when
            a number of consecutive ping probes equal to the
            value of pingCtlTrapProbeFailureFilter fail within
            a given ping test.  After triggering the notification,
            the probe failure counter is reset to zero."

in DESCRITION clause of pingCtlTrapTestFailureFilter replace OLD
            Setting pingCtlTrapGeneration to testFailure(1)
            implies that a pingTestFailed NOTIFICATION is
            generated only when the number of ping failures
            within a test exceed the value of
            pingCtlTrapTestFailureFilter."
with new
            Setting BIT testFailure(1) of object
            pingCtlTrapGeneration to '1' implies that a
            pingTestFailed NOTIFICATION is generated only when
            a number of consecutive ping tests equal to the
            value of pingCtlTrapProbeFailureFilter fail.
            After triggering the notification the test failure,
            counter is reset to zero."
========================================================================
Status: solution committed
========================================================================

========================================================================
25. wrong DEFVAL for pingCtlSourceAddressType,
    traceRouteCtlTargetAddressType, and lookupCtlTargetAddressType
========================================================================
Problem Description:
------------------------------------------------------------------------
Object pingCtlSourceAddressType with a SYNTAX clause of InetAddressType
has a DEFVAL of  { ipv4 }.  this does not comply with RFC 3291.
The same applies to objects traceRouteCtlTargetAddressType and
lookupCtlTargetAddressType.
========================================================================
Suggested solution:
------------------------------------------------------------------------
for pingCtlSourceAddressType, traceRouteCtlTargetAddressType and
lookupCtlTargetAddressType:

replace OLD
        DEFVAL { ipv4 }
with NEW
        DEFVAL { unknown }
========================================================================
Status: solution committed
========================================================================

========================================================================
26. Name and number conflicts in compliancy sections
========================================================================
Problem Description:
------------------------------------------------------------------------
Some object groups and the compliancy statements have changed compared
to RFC 2925, but still use the same names and OIDs.
========================================================================
Suggested solution:
------------------------------------------------------------------------
rename OLD pingGroup to NEW pingMinimumGroup
rename OLD pingCompliance to NEW pingFullCompliance

rename OLD traceRouteGroup to NEW traceRouteMinimumGroup
rename OLD traceRouteCompliance to NEW traceRouteFullCompliance

remove all OID conflicts with RFC 2925
========================================================================
Status: solution committed
========================================================================

========================================================================
27. read-only RowStatus conflicts with RowStatus TC
========================================================================
Problem Description:
------------------------------------------------------------------------
pingCtlRowStatus and traceRouteCtlRowStatus have MIN-ACCES of read-only
in pingMinimumCompliancy and traceRouteMinimumCompliancy, respectively.
According to the RowStatus TC this implies that the row status can never
have a transition to 'active'.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Make the implementation of pingCtlRowStatus and traceRouteCtlRowStatus
optional in pingMinimumCompliancy and traceRouteMinimumCompliancy:

add NEW
     pingCtlRowStatusGroup OBJECT-GROUP
       OBJECTS {
                 pingCtlRowStatus
               }
       STATUS  current
       DESCRIPTION
           "The RowStatus object of the pingCtlTable."
       ::= { pingGroups 5 }

in pingMinimumCompliancy replace OLD
            OBJECT pingCtlRowStatus
            MIN-ACCESS  read-only
            DESCRIPTION
                "Write access is not required.  If write access is
                not supported then at least one entry in the
                pingCtlTable MUST be established already when the SNMP
                agent starts offering access to the PING-MIB module.
                If in such a case only a single entry is offered, then
                it is RECOMMENDED that this entry uses strings with a
                length of 0 for both of its two index objects."
with NEW
            GROUP pingCtlRowStatusGroup
            DESCRIPTION
                "A compliant implementation does not have to implement
                the pingCtlRowStatusGroup."

add NEW
     traceRouteCtlRowStatusGroup OBJECT-GROUP
       OBJECTS {
                 traceRouteCtlRowStatus
              }
       STATUS  current
       DESCRIPTION
           "The RowStatus object of the traceRouteCtlTable."
       ::= { traceRouteGroups 6 }

in traceRouteMinimumCompliancy remove OLD
            OBJECT traceRouteCtlRowStatus
            MIN-ACCESS  read-only
            DESCRIPTION
                "Write access is not required.  If write access is
                not supported then at least one entry in the
                pingCtlTable MUST be established already when the SNMP
                agent starts offering access to the TRACEROUTE-MIB
                module.  If in such a case only a single entry is
                offered, then it is RECOMMENDED that this entry uses
                strings with a length of 0 for both of its two index
                objects."
========================================================================
Status: solution committed
========================================================================

========================================================================
28. Security consideration do not match boilerplate
========================================================================
Problem Description:
------------------------------------------------------------------------
The section on security considerations does not match the boilerplate
for MIB security considerations.
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace OLD

5.  Security Considerations

   Certain management information in the MIBs defined by this document
   may be considered sensitive in some network environments.  Therefore,
   authentication of received SNMP requests and controlled access to
   management information SHOULD be employed in such environments.  The
   method for this authentication is a function of the SNMP
   Administrative Framework, and has not been expanded by this MIB.

   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.

   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.

with NEW

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.
========================================================================
Status: solution committed
========================================================================

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 20 Jul 2004 12:35:04 +0200

Dear all,

When editing the last version, I made a few mistakes and failed
to apply three changes, that you will find listed at the end of
this message.

Since we are entering a short WG last call on this document
soon, please include three suggested changes below in your
review.

Thanks,

    Juergen

> Below please find the list of changes from version -02 to version -03.
 [...]

================================
suggested changes to version -03
================================

========================================================================
29. Bad numbering of objects in DISMAN-TRACEROUTE-MIB
========================================================================
Problem Description:
------------------------------------------------------------------------
OID { traceRouteGroups 6 } is assigned twice,
to traceRouteCtlRowStatusGroup and to traceRouteHistoryGroup
========================================================================
Suggested solution:
------------------------------------------------------------------------
replcace for traceRouteHistoryGroup OLD
   ::= { traceRouteGroups 6 }
with NEW
   ::= { traceRouteGroups 7 }
========================================================================
Status: solution suggested
========================================================================

========================================================================
30. traceRouteMinimumCompliancy does not cover
    traceRouteCtlRowStatusGroup
========================================================================
Problem Description:
------------------------------------------------------------------------
The traceRouteMinimumCompliancy statement does not cover the new
traceRouteCtlRowStatusGroup.
========================================================================
Suggested solution:
------------------------------------------------------------------------
add to traceRouteMinimumCompliancy:
            GROUP traceRouteCtlRowStatusGroup
            DESCRIPTION
                "A compliant implementation does not have to implement
                the traceRouteCtlRowStatusGroup."
========================================================================
Status: solution suggested
========================================================================

========================================================================
31. Coverage of excessive lookup in security considerations
========================================================================
Problem Description:
------------------------------------------------------------------------
The Security considerations do not describe the threat of excessively
using the lookup service.

raised by Dan Romascanu
========================================================================
Suggested solution:
------------------------------------------------------------------------
In Secton 5. Security Considerations replace OLD
   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.
with NEW
   In general, all three, the ping, traceroute and lookup 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.  The same applies to excessive use of the lookup
   service, particularly, if the lookup cannot be resolved locally.  In
   insecure environments it is RECOMMENDED that the MIBs defined within
   this memo not be supported.
========================================================================
Status: solution suggested
========================================================================

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 20 Jul 2004 19:26:14 -0700

Hi -

> From: "Juergen Quittek" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 20, 2004 3:35 AM
> Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt
...
> soon, please include three suggested changes below in your
...

Thanks, Juergen.  Since the IESG doesn't like documents with
errata sheets (I wonder why?  :-) we'll need to spin a new draft
before we hand it off to our AD.  However, unless some other
issue surfaces in the meantime, I will *NOT* issue a WG last
call on that revision, and instead hand it off directly to our AD.
If anyone objects to proceeding in this manner, please speak
up now.

Randy Presuhn
disman WG chair

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 21 Jul 2004 09:30:15 +0200

Randy,

--On 20.07.2004 19:26 Uhr -0700 Randy Presuhn wrote:

> before we hand it off to our AD.

Yes, of course.  I just handed in the errata in order
to simplify the last call procedure.

> However, unless some other

If anybody wants to preview the fixed version (to be submitted
after the IETF meeting), please have a look at

    ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-04.txt

Thanks,

    Juergen

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 21 Jul 2004 09:00:27 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 21, 2004 12:30 AM
> Subject: Re: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt
...
...

Thanks!

As always, I'd like to hear from anyone who has read the draft,
even if it's only to say "no objection".

Randy