Internet DRAFT - draft-fan-meng-snmp-lock
draft-fan-meng-snmp-lock
Network Working Group W. Fan
Internet-Draft T. Meng
Intended status: Standards Track Huawei-Symantec Technologies
Expires: November 2, 2009 May 2009
A lock feature to SNMP
draft-fan-meng-snmp-lock-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 2, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Fan & Meng Expires November 2, 2009 [Page 1]
Internet-Draft A lock feature to SNMP May 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo is intended to provide a lock mechanism to SNMP for
protecting SET operations from being interrupted by any other network
management operations such as NETCONF <edit-config> or CLI writes.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular, it extends
LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for
managing SNMP locks. The lock acquisition and release can be
achieved through manipulating those objects.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. A large SET operation handling . . . . . . . . . . . . 3
1.1.2. Multiple SET operations handling as a transaction . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. MIB extension to LOCK-MIB . . . . . . . . . . . . . . . . . . 5
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7
6.1. Procedure of lock acquisition . . . . . . . . . . . . . . 7
6.2. Procedure of lock release . . . . . . . . . . . . . . . . 9
6.3. Procedure of lock validation . . . . . . . . . . . . . . . 9
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Relationship to other MIBs . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. MIB Security Considerations . . . . . . . . . . . . . . . 16
10. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Fan & Meng Expires November 2, 2009 [Page 2]
Internet-Draft A lock feature to SNMP May 2009
1. Introduction
Network devices may support multiple management protocols for
flexible operation and management. For example, a device may support
NETCONF [RFC4741] , SNMP, and proprietary CLI for configuration and
allow for multiple operators using different protocols configure it
at the same time. It is needed to protect operations from
intervention by the others for data consistency, regardless of which
NM protocol is used.
This memo is intended to provide a lock mechanism to SNMP for
protecting SET operations from being interrupted by any other network
management operations such as NETCONF <edit-config> or CLI writes.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it extends
LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for
managing SNMP locks. The lock acquisition and releasing can be
achieved through manipulating those objects.
1.1. Usage Scenarios
In the following we describe a few scenarios for SNMP locking.
Besides the two described here, there might be many other usage
scenarios possible.
1.1.1. A large SET operation handling
Now that SSH running over TCP as well as DTLS running over TCP and
SCTP is proposed or accepted as an optional transport mapping for
SNMP, people could write bigger messages, including SET messages. In
this case, SNMP agent may consume more time for processing the single
large SET operation, SNMP would like to use locks to prevent
conflicts during the processing as other NM interfaces might do.
Nevertheless, locks should only be used when the manager knows they
are sending an especially large SET except for the following cases,
not for the normal SETs that only carry a few varbinds and complete
in millisecond timeframes.
1.1.2. Multiple SET operations handling as a transaction
In some cases, we should treat multiple SET operations as a logic
transaction as a whole, whatever they are across multiple tables or
agents or even administrative domains.
SNMP offers RowStatus, which can maintain state over a sequence of
operations to a particular row in a table, but SNMP does not have a
mechanism for "locking" while an SNMP manager builds transaction
state across multiple tables or locking a configuration while a
Fan & Meng Expires November 2, 2009 [Page 3]
Internet-Draft A lock feature to SNMP May 2009
manager builds a transaction across multiple agents. all operations
within a transaction would be kept as atomic by using SNMP locking.
New technologies that can be managed using SNMP can be implemented on
devices that cross administrative domains. IEEE 802.1 provider
bridging, for example, might allow SETs to be done to a CPE device
from two different administrative domains, where who can change what
is determined using access controls. But in some cases, it could be
important when they can change what; it might be important that two
administrators not try to modify the same device at the same time
because this could cause misconfiguration. Real locks (not the
simple advisory locks commonly used in SNMP) might be used to prevent
conflicts in provisioning shared administration environments.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Conventions
Terms "SNMP manager" and "SNMP agent" have been defined in section
3.1.3.1 and 3.1.3.2 respectively in [RFC3411] .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview
This memo enable SNMP agent to lock a portion or all of configuration
data for a specific user. In particular, the protected area by a
lock is a set of object types (and instances) which are specified by
a family of view subtrees, per section 2.4.2, [RFC3415].
The SNMP agent MUST ensure that all the configuration resources
protected by a lock are not modified by other SNMP or non-SNMP users
(and sessions) such as NETCONF and the CLI.
Fan & Meng Expires November 2, 2009 [Page 4]
Internet-Draft A lock feature to SNMP May 2009
The duration of a lock begins when the lock is granted and lasts
until the corresponding unlock (whether forcibly or not) request
succeeds or the underlying session terminates or the system where the
agent resides reboots.
A SNMP user MAY have multiple part of the configuration data locked
via multiple lock requests.
The SNMP agent assigns a lock identifier to the lock when a lock
request has been processed (whether the lock is granted or not at
last).
5. MIB extension to LOCK-MIB
This section describes the MIB extension to LOCK-MIB for managing
SNMP locks.
LOCK-MIB is defined in [I-D.meng-fan-lock-mib] to monitor locks via
multiple NM interfaces. It consists of the lockTable and several
specific NM interface tables as well as several scalar variables.
The lockTable collects generic information for all locks being
managed by the device regardless of protocol and its structure is
like:
--lockObjects(1)
|
+--lockTable(3)
|
+--lockEntry(1) [lockIndex]
|
+--Unsigned32 lockIndex(1)
|
+--SnmpAdminString lockUserName(2)
|
+--SnmpAdminString lockNMInterface(3)
|
+--INTEGER lockType(4)
|
+--TimeTicks lockStartTime(5)
|
+--TimeTicks lockEndTime(6)
|
+--INTEGER lockState(7)
[I-D.meng-fan-lock-mib] has more details.
A specific NM interface lock table collects specific information with
regard to all locks via one specific protocol, for example,
Fan & Meng Expires November 2, 2009 [Page 5]
Internet-Draft A lock feature to SNMP May 2009
lockNetconfTable collects specific information of all locks via
NETCONF. Since LOCK-MIB allows for being extended by adding a new
specific NM interface lock table, we organize specific information of
all locks via SNMP into a specific NM interface lock table called
lockSnmpTable:
--lockObjects(1)
|
+--lockSnmpObjects(6)
|
+--TestAndIncr lockSnmpSpinLock(1)
|
+--lockSnmpTable(2)
|
+--lockSnmpEntry(1) [lockSnmpLockId]
|
+--Unsigned32 lockSnmpLockId(1)
|
+--SnmpAdminString lockSnmpViewTreeFamilyViewName(2)
|
+--OBJECT IDENTIFIER lockSnmpViewTreeFamilySubtree(3)
|
+--OCTET STRING lockSnmpViewTreeFamilyMask(4)
|
+--INTEGER lockSnmpViewTreeFamilyType(5)
|
+--Unsigned32 lockSnmpIndex(6)
|
+--RowStatus lockSnmpStatus(7)
The meaning of each Object Type is explained as below:
lockSnmpSpinLock is an advisory lock which is used to coordinate
multiple simultaneous SETs to lockSnmpTable.
lockSnmpLockId is an instance-identifier to differentiate multiple
entries in lockSnmpTable.
lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
lockSnmpViewTreeFamilyMask and lockSnmpViewTreeFamilyType are
jointly used to represent the protected area by a lock as a MIB
view. their semantics is specified in [RFC3415].
lockSnmpIndex connects a entry in lockSnmpTable to the
corresponding entry in lockTable.
lockSnmpStatus is used to indicate the status of the associated
entry, "notReady" means the lock request is pending, "active"
Fan & Meng Expires November 2, 2009 [Page 6]
Internet-Draft A lock feature to SNMP May 2009
means the lock takes effect.
The lockSnmpTable can be used to acquire or release a lock, and can
be combined with lockTable to monitor all SNMP locks.
6. Elements of Procedure
This section describes how to manipulate objects defined in section 5
in order to acquire and release a lock. It gives the procedure of
lock acquisition, lock release as well as lock validation.
6.1. Procedure of lock acquisition
SNMP manager can request a lock by trying to create an entry in
lockSnmpTable. Before that, we should retrieve the value of
lockSnmpSpinLock as the instance-identifier of the entry to be
created and calculate the value of lockSnmpViewTreeFamilySubtree and
lockSnmpViewTreeFamilyMask as well as specify the value of
lockSnmpViewTreeFamilyViewName and lockSnmpViewTreeFamilyType to
identify the intended protected area by the lock based on subsequent
SET(s) to be issued. Even though we create a entry successfully, its
status column won't be active until the lock is granted. Lock
request failure would destroy the associate entry. Whatever the lock
is granted or not, a entry collecting generic information about the
lock will be added to lockTable.
Manager Agent
(1)
<----------->
(2)
(3)
<------------>
(4)
(5)
(6)
(7)
<----------->
(1) the manager GET(lockSnmpSpinLock.0) and save in sValue. sValue
is used to be the instance-identifier of the entry to be created.
I.e., if an entry is created successfully, the value of the
lockSnmpLockId associated with the entry equals to sValue.
(2) the manager specifies the viewValue and typeValue, calculates
the subtreeValue and maskValue based on the SET operations to be
protected. Combination of them is used to identify the intended
protected area by the lock. How to get these values is out of the
scope of this document, and it is left to implementation-specific.
Fan & Meng Expires November 2, 2009 [Page 7]
Internet-Draft A lock feature to SNMP May 2009
(3) the manager SET(lockSnmpSpinLock.0=sValue,
lockSnmpViewTreeFamilyViewName=viewValue,
lockSnmpViewTreeFamilySubtree=subtreeValue,
lockSnmpVIewTreeFamilyMask=maskValue,
lockSnmpViewTreeFamilyViewType=typeValue)
(4) An entry is created with lockSnmpStatus="notReady" by the
agent.
(5) the agent processes the lock request based on criteria
mentioned later.
(6) After the lock request processing completes, an entry
representing the lock is added to lockTable with
lockState="ACTIVE" or lockState="FAILED" depending on the lock
request succeeded or not, if lockState=ACTIVE, then the value of
lockSnmpIndex is set to the value of the corresponding lockIndex
in lockTable and the value of status column is set to ACTIVE,
otherwise, the associated entry in lockSnmpTable is deleted.
(7) the manager GET(lockSnmpStatus). When the value of
lockSnmpStatus is "active", the lock is valid. Otherwise the lock
failed.
Granted locks protect all instances specified by the associated
family of view subtrees (i.e., combination of values of
lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
lockSnmpViewFamilyMask and lockSnmpViewFamilyType) from modification
by others, regardless of SNMP or non-SNMP operations.
A lock request MUST be handled atomically by the agent. The agent
either locks all requested parts of the configuration data or none.
If during the lock request processing one of the requested parts
cannot be locked, the agent MUST unlock all parts that have already
been locked during the lock request processing.
The agent MUST be able to grant multiple simultaneous locks to a
single user. If the protected area of the individual locks overlaps,
instances in the common area MUST be protected until all of the locks
are released.
With point (5) above, a lock request MUST fail if:
o Any part of the MIB to be protected is already locked by other
users, including SNMP users or any other non-SNMP management
method.
Fan & Meng Expires November 2, 2009 [Page 8]
Internet-Draft A lock feature to SNMP May 2009
o The agent implements access control model(s), and the locking user
does not have sufficient access rights. The exact handling of
access rights is outside the scope of this document, but it is
assumed that there is an access control system that MAY deny or
allow the lock request.
6.2. Procedure of lock release
Manager can try to delete an entry in lockSnmpTable in order to
release the associated active lock.
(1) the manager SET(lockSnmpStatus=destroy)
(2) the agent release the lock.
(3) the manager GET(lockState) to check if the lock has been
released or not.
Manager Agent
(1)
<----------->
(2)
(3)
<----------->
6.3. Procedure of lock validation
An active SNMP lock should protect locked managed object types (and
instances) from modification by other SNMP users or any other non-
SNMP methods. When the operations attempting to modify locked object
types (and instances) arrives, the server MUST fail them (with error
codes). A locked object MUST be treated as an unavailable resource.
For example, in a SNMPv3 message, the error code MUST be
resourceUnavailable.
According to section 4.2.5, [RFC3416], a SET operation is
conceptually processed as a two phase operation. Before actual
variable assignments, there are 12 validation steps for checking,
e.g., access rights, value types, etc. If any variable binding's
name specifies an already locked managed object types (or instance),
step (11) will be triggered, i.e., the value of the Response-PDU's
error-status field is set to "resourceUnavailable", and the value of
its error-index field is set to the index of the failed variable
binding.
Fan & Meng Expires November 2, 2009 [Page 9]
Internet-Draft A lock feature to SNMP May 2009
7. Definitions
LOCK-SNMP-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE, MODULE-IDENTITY,
mib-2, Unsigned32 FROM SNMPv2-SMI
TestAndIncr, RowStatus FROM SNMPv2-TC
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
lockSnmpMIB MODULE-IDENTITY
LAST-UPDATED "200905270000Z"-- 27 May 2009
ORGANIZATION "Operations and Management Area Working Group"
CONTACT-INFO
" Tony Meng
Postal: Huawei-Symantec Technologies
3rd Floor, Section D, Keshi Building
No.28, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085
China
Email: mengjian@huaweisymantec.com
Washam Fan
Postal: Huawei-Symantec Technologies
3rd Floor, Section D, Keshi Building
No.28, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085
China
Email: Washam.Fan@huaweisymantec.com
"
DESCRIPTION "The module defines management information for
managing SNMP locks for network management protocols.
Copyright (C) The IETF Trust (2009). This version
of this MIB module is part of RFC XXXX; see the RFC
itself for full legal notices."
-- RFC Ed.: replace XXXX with actual RFC number & remove this note
REVISION "200905270000Z"-- 27 May 2009
DESCRIPTION "Initial version, published as RFC XXXX."
::= { mib-2 xxx } --to be assigned by IANA
-- Administrative assignments *******************************
lockSnmpObjects OBJECT IDENTIFIER ::= { lockSnmpMIB 1 }
Fan & Meng Expires November 2, 2009 [Page 10]
Internet-Draft A lock feature to SNMP May 2009
lockSnmpConformance OBJECT IDENTIFIER ::= { lockSnmpMIB 2 }
lockSnmpSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow cooperating SNMP
Command Generator applications to coordinate their
use of the Set operation in creating SNMP locks.
When creating a new SNMP lock, it is important to
understand the potential interactions with other
uses of the lock. The lockSnmpSpinLock should be
retrieved. The lockSnmpLockId of the lock to be
created should be determined to be unique by the
SNMP Command Generator application by consulting
the lockSnmpSpinLock. Finally, the requested lock
may be created (Set), including the advisory lock.
If another SNMP Command Generator application has
altered the locks in the meantime, then the spin
lock's value will have changed, and so this creation
will fail because it will specify the wrong value for
the spin lock.
Since this is an advisory lock, the use of this lock
is not enforced.
"
::= { lockSnmpObjects 1 }
lockSnmpTable OBJECT-TYPE
SYNTAX SEQUENCE OF LockSnmpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table collects specific information of all locks
via SNMP. The information includes lock identifiers for
identifying all locks via SNMP, intended protected area
by the lock, etc.
Users can request a lock by creating a new entry
successfully. Combination of values of
lockSnmpViewTreeFamilyViewName,
lockSnmpViewTreeFamilySubtree,
lockSnmpViewTreeFamilyMask
and lockSnmpViewTreeFamilyType represents the intended
protected area by the lock.
Users can release an active lock by trying to destroy
Fan & Meng Expires November 2, 2009 [Page 11]
Internet-Draft A lock feature to SNMP May 2009
the associated entry.
Users can retrieve the information of a lock from
lockTable by referencing the value of snmpLockIndex
when the lock is active.
"
::= { lockSnmpObjects 2 }
lockSnmpEntry OBJECT-TYPE
SYNTAX LockSnmpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry represents a SNMP lock and includes all
specific information about the lock.
"
INDEX { lockSnmpLockId }
::= { lockSnmpTable 1 }
LockSnmpEntry ::= SEQUENCE
{
lockSnmpLockId Unsigned32,
lockSnmpViewTreeFamilyViewName SnmpAdminString,
lockSnmpViewTreeFamilySubtree OBJECT IDENTIFIER,
lockSnmpViewTreeFamilyMask OCTET STRING,
lockSnmpViewTreeFamilyType INTEGER,
lockSnmpIndex Unsigned32,
lockSnmpStatus RowStatus
}
lockSnmpLockId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Lock identifier to differentiate all SNMP locks.
The value should equal to the value of lockSnmpSpinLock
when creating the associated entry.
"
::= { lockSnmpEntry 1 }
lockSnmpViewTreeFamilyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The human readable name for a family of view subtrees.
"
::= { lockSnmpEntry 2 }
Fan & Meng Expires November 2, 2009 [Page 12]
Internet-Draft A lock feature to SNMP May 2009
lockSnmpViewTreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of lockSnmpViewTreeFamilyMask
defines a family of view subtrees.
"
::= { lockSnmpEntry 3 }
lockSnmpViewTreeFamilyMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The bit mask which, in combination with the
corresponding instance of
lockSnmpViewTreeFamilySubtree,
defines a family of view subtrees.
Readers can refer to [RFC3415] for details how to
define a family of view subtrees with the two values.
"
DEFVAL { ''H }
::= { lockSnmpEntry 4 }
lockSnmpViewTreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Indicates whether the corresponding instances of
lockSnmpViewTreeFamilySubtree and
lockSnmpViewTreeFamilyMask
define a family of view subtrees which is included in
or excluded from the MIB view.
"
DEFVAL { included }
::= { lockSnmpEntry 5 }
lockSnmpIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Lock identifier to differentiate all locks via
multiple NM interfaces. It connects the entry to
the corresponding entry in lockTable.
Users can retrieve the info of the lock from lockTable
by referencing the value.
Fan & Meng Expires November 2, 2009 [Page 13]
Internet-Draft A lock feature to SNMP May 2009
"
::= { lockSnmpEntry 6 }
lockSnmpStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION "With value 'notReady' means the lock request has been
submitted successfully but not yet processed.
With value 'active' means the lock is granted at last.
Failed and released lock will be deleted.
"
::= { lockSnmpEntry 7 }
-- Conformance Information *******************************************
lockSnmpCompliances OBJECT IDENTIFIER ::= { lockSnmpConformance 1 }
lockSnmpGroups OBJECT IDENTIFIER ::= { lockSnmpConformance 2 }
-- Compliance statements
lockSnmpCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for an entity who implements
this LOCK-SNMP-MIB."
MODULE -- this module
MANDATORY-GROUPS { lockSnmpGroup }
::= { lockSnmpCompliances 1 }
lockSnmpGroup OBJECT-GROUP
OBJECTS {
lockSnmpSpinLock,
lockSnmpViewTreeFamilyViewName,
lockSnmpViewTreeFamilySubtree,
lockSnmpViewTreeFamilyMask,
lockSnmpViewTreeFamilyType,
lockSnmpIndex,
lockSnmpStatus
}
STATUS current
DESCRIPTION "A collection of objects providing basic instrumentation
of an entity which supports SNMP lock."
::= { lockSnmpGroups 1 }
END
Fan & Meng Expires November 2, 2009 [Page 14]
Internet-Draft A lock feature to SNMP May 2009
8. Relationship to other MIBs
LOCK-MIB defined in [I-D.meng-fan-lock-mib] collects generic
information of all locks supported in the device, the memo extends
LOCK-MIB to collect specific information of all SNMP locks described
in this memo. LOCK-MIB and the extension done in this memo can be
used jointly to manage and control SNMP locks, per section 6.
When the extension is added to LOCK-MIB, statistics variables should
reflect SNMP locks defined in this memo as well as other NM interface
locks. When a SNMP lock becomes active, the value of lockActivelocks
should be incremented by 1, when a SNMP lock failure occurs, the
value of lockFailures should be incremented by 1, when an active SNMP
lock is released, the value of lockActivelocks should be reduced by
1.
SNMP-VIEW-BASED-ACM-MIB defined in [RFC3416] defines
vacmViewTreeFamilyTable to represent views. lockSnmpTable represents
views in the identical way which is used to identify protected areas
by locks.
9. Security Considerations
This document enable a SNMP agent to handle the lock acquisition,
lock release and lock validation. These work should be done in
accordance with Security Model and Access Control Model to manage and
control locks.
Before a manager can set lockSnmpTable, it should be authenticated
successfully. When a conceptual row is to be created in
lockSnmpTable, the agent should check if the authenticated manager
has appropriate privileges about all objects falling into the
intended locked area as well as other criteria if necessary.
A lock might prevent other users from configuring the system (which
might lead to DoS attack). The following mechanisms are in place to
prevent the misuse of this possibility:
Only an authenticated and authorized user should be allowed to
request a lock.
The lock is automatically released when a session (if it exists,
e.g., SSH transport mapping is used) is terminated regardless of
how the session ends. The reboot behavior leads to all the active
locks automatically released.
Implementations should allow an administrator to release an SNMP
lock via SNMP and through the native CLI console interface, to be
Fan & Meng Expires November 2, 2009 [Page 15]
Internet-Draft A lock feature to SNMP May 2009
able to prevent denial of service attacks.
Keeping track of the number of active locks using lockActivelocks
counter can uncover some bad behaviors. E.g. If the number of
active locks grows rapidly or there are locks lasting for a long
period of time, somebody might be trying to launch a denial of
service attack.
The SNMP agent may log lock requests in an audit trail.
LOCK-MIB doesn't allow for modifying specific NM interface lock
tables except for lockSnmpTable, which means a non SNMP lock can't be
released via manipulating managed objects defined in LOCK-MIB. Since
the access control system is different among different NM interfaces,
SNMP lock SHOULD NOT be released by non SNMP interfaces or methods.
lock release forcibly might lead to difficult recovery, as It is
impossible to rollback all successful SET(s) protected by the lock.
When a lock is grant in a SET processing procedure, it may cause The
SET processing in place failed. In that case, the agent SHOULD try
to undo all the assignments in the SET, the corresponding Response
PDU is returned with error-status with value "commitFailed" or
"undoFailed" (in the latter case. the undone failed).
9.1. MIB 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:
o lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
lockSnmpViewTreeFamilyMask, lockSnmpViewTreeFamilyType: these
objects are used to identify the scope of intended locked area.
If any object falling into this area is unauthorized to the
requesting user, the lock request will fail. If the SET operation
has altered in an unauthoritative way, the lock request probably
fails.
o lockSnmpStatus: this object indicates the state of the lock via
combining with the lockState column in lockTable. SET operations
attempting set lockSnmpStatus to 'notInService' will release the
lock or abort the lock request. SET operations attempting set
lockSnmpStatus to 'destroy' will delete the entry (and release an
active lock). So unauthorized SET operations will probably broken
Fan & Meng Expires November 2, 2009 [Page 16]
Internet-Draft A lock feature to SNMP May 2009
an active lock illegally.
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.
10. Acknowledges
This draft partially borrows from Balazs Lengyel and Martin
Bjorklund's [I-D.ietf-netconf-partial-lock]. Many thanks to David
Harrington for his guidance and feedback on this doc.
11. References
11.1. Normative References
[I-D.meng-fan-lock-mib] Meng, T. and W. Fan, "Definitions of
Managed Objects for lock via network
management protocols", April 2009.
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, EFC 2119,
March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D.,
Ed., and J. Schoenwaelder, Ed.,
"Structure of Management Information
Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D.,
Ed., and J. Schoenwaelder, Ed.,
Fan & Meng Expires November 2, 2009 [Page 17]
Internet-Draft A lock feature to SNMP May 2009
"Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J.
Schoenwaelder, "Conformance
Statements for SMIv2", STD 58,
RFC 2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B.
Wijnen, "An Architecture for
Describing Simple Network Management
Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3415] Wijnen, B., Presuhn , R., and K.
McCloghrie, "View-based Access
Control Model (VACM) for the Simple
Network Management Protocol (SNMP)",
RFC 3415, December 2002.
[RFC3416] Presuhn, R., "Version 2 of the
Protocol Operations for the Simple
Network Management Protocol (SNMP)",
STD 62, RFC 3416, December 2002.
11.2. Informative References
[I-D.ietf-netconf-partial-lock] Lengyel, B. and M. Bjorklund,
"Partial Lock RPC for NETCONF",
Feburary 2009.
[RFC3410] Case, J., Mundy, R., Partain, D.,
and B. Stewart, "Introduction and
Applicability Statements for
Internet-Standard Management
Framework", RFC 3410, December 2002.
[RFC4741] Enns, R., Ed., "NETCONF
Configuration Protocol", RFC 4741,
December 2006.
Fan & Meng Expires November 2, 2009 [Page 18]
Internet-Draft A lock feature to SNMP May 2009
Authors' Addresses
Washam Fan
Huawei-Symantec Technologies
3rd Floor, Section D, Keshi Building
No.28, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085
China
EMail: Washam.Fan@huaweisymantec.com
URI: http://www.huaweisymantec.com
Tony Meng
Huawei-Symantec Technologies
3rd Floor, Section D, Keshi Building
No.28, Xinxi Rd., Shangdi, Haidian Dist.
Beijing 100085
China
EMail: mengjian@huaweisymantec.com
URI: http://www.huaweisymantec.com
Fan & Meng Expires November 2, 2009 [Page 19]
