Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt
Juergen Quittek <[email protected]>
| Newsgroups | gmane.ietf.disman |
|---|---|
| Message-ID | <2147483647.1090326517@[10.1.1.171]> |
Dear all,
Below please find the list of changes from version -02 to version -03.
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.netlab.nec.de
--On 19.07.2004 15:20 h -0400 [email protected] wrote:
> 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
=======================================
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
========================================================================