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 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 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]