idnits 2.17.1 draft-fan-meng-snmp-lock-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.meng-fan-lock-mib]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 251 has weird spacing: '...nString lock...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2009) is 5454 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-meng-fan-lock-mib - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.meng-fan-lock-mib' -- No information found for draft-ietf-netconf-partial-lock - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Fan 3 Internet-Draft T. Meng 4 Intended status: Standards Track Huawei-Symantec Technologies 5 Expires: November 2, 2009 May 2009 7 A lock feature to SNMP 8 draft-fan-meng-snmp-lock-00 10 Status of This Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 2, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This memo is intended to provide a lock mechanism to SNMP for 57 protecting SET operations from being interrupted by any other network 58 management operations such as NETCONF or CLI writes. 59 This memo defines a portion of the Management Information Base (MIB) 60 for use with network management protocols. In particular, it extends 61 LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for 62 managing SNMP locks. The lock acquisition and release can be 63 achieved through manipulating those objects. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3 69 1.1.1. A large SET operation handling . . . . . . . . . . . . 3 70 1.1.2. Multiple SET operations handling as a transaction . . 3 71 2. The Internet-Standard Management Framework . . . . . . . . . . 4 72 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. MIB extension to LOCK-MIB . . . . . . . . . . . . . . . . . . 5 75 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Procedure of lock acquisition . . . . . . . . . . . . . . 7 77 6.2. Procedure of lock release . . . . . . . . . . . . . . . . 9 78 6.3. Procedure of lock validation . . . . . . . . . . . . . . . 9 79 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. Relationship to other MIBs . . . . . . . . . . . . . . . . . . 15 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9.1. MIB Security Considerations . . . . . . . . . . . . . . . 16 83 10. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 Network devices may support multiple management protocols for 91 flexible operation and management. For example, a device may support 92 NETCONF [RFC4741] , SNMP, and proprietary CLI for configuration and 93 allow for multiple operators using different protocols configure it 94 at the same time. It is needed to protect operations from 95 intervention by the others for data consistency, regardless of which 96 NM protocol is used. 98 This memo is intended to provide a lock mechanism to SNMP for 99 protecting SET operations from being interrupted by any other network 100 management operations such as NETCONF or CLI writes. 101 This memo defines a portion of the Management Information Base (MIB) 102 for use with network management protocols. In particular it extends 103 LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for 104 managing SNMP locks. The lock acquisition and releasing can be 105 achieved through manipulating those objects. 107 1.1. Usage Scenarios 109 In the following we describe a few scenarios for SNMP locking. 110 Besides the two described here, there might be many other usage 111 scenarios possible. 113 1.1.1. A large SET operation handling 115 Now that SSH running over TCP as well as DTLS running over TCP and 116 SCTP is proposed or accepted as an optional transport mapping for 117 SNMP, people could write bigger messages, including SET messages. In 118 this case, SNMP agent may consume more time for processing the single 119 large SET operation, SNMP would like to use locks to prevent 120 conflicts during the processing as other NM interfaces might do. 121 Nevertheless, locks should only be used when the manager knows they 122 are sending an especially large SET except for the following cases, 123 not for the normal SETs that only carry a few varbinds and complete 124 in millisecond timeframes. 126 1.1.2. Multiple SET operations handling as a transaction 128 In some cases, we should treat multiple SET operations as a logic 129 transaction as a whole, whatever they are across multiple tables or 130 agents or even administrative domains. 132 SNMP offers RowStatus, which can maintain state over a sequence of 133 operations to a particular row in a table, but SNMP does not have a 134 mechanism for "locking" while an SNMP manager builds transaction 135 state across multiple tables or locking a configuration while a 136 manager builds a transaction across multiple agents. all operations 137 within a transaction would be kept as atomic by using SNMP locking. 139 New technologies that can be managed using SNMP can be implemented on 140 devices that cross administrative domains. IEEE 802.1 provider 141 bridging, for example, might allow SETs to be done to a CPE device 142 from two different administrative domains, where who can change what 143 is determined using access controls. But in some cases, it could be 144 important when they can change what; it might be important that two 145 administrators not try to modify the same device at the same time 146 because this could cause misconfiguration. Real locks (not the 147 simple advisory locks commonly used in SNMP) might be used to prevent 148 conflicts in provisioning shared administration environments. 150 2. The Internet-Standard Management Framework 152 For a detailed overview of the documents that describe the current 153 Internet-Standard Management Framework, please refer to section 7 of 154 RFC 3410 [RFC3410]. 156 Managed objects are accessed via a virtual information store, termed 157 the Management Information Base or MIB. MIB objects are generally 158 accessed through the Simple Network Management Protocol (SNMP). 159 Objects in the MIB are defined using the mechanisms defined in the 160 Structure of Management Information (SMI). This memo specifies a MIB 161 module that is compliant to the SMIv2, which is described in STD 58, 162 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 163 [RFC2580]. 165 3. Conventions 167 Terms "SNMP manager" and "SNMP agent" have been defined in section 168 3.1.3.1 and 3.1.3.2 respectively in [RFC3411] . 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 4. Overview 176 This memo enable SNMP agent to lock a portion or all of configuration 177 data for a specific user. In particular, the protected area by a 178 lock is a set of object types (and instances) which are specified by 179 a family of view subtrees, per section 2.4.2, [RFC3415]. 181 The SNMP agent MUST ensure that all the configuration resources 182 protected by a lock are not modified by other SNMP or non-SNMP users 183 (and sessions) such as NETCONF and the CLI. 185 The duration of a lock begins when the lock is granted and lasts 186 until the corresponding unlock (whether forcibly or not) request 187 succeeds or the underlying session terminates or the system where the 188 agent resides reboots. 190 A SNMP user MAY have multiple part of the configuration data locked 191 via multiple lock requests. 193 The SNMP agent assigns a lock identifier to the lock when a lock 194 request has been processed (whether the lock is granted or not at 195 last). 197 5. MIB extension to LOCK-MIB 199 This section describes the MIB extension to LOCK-MIB for managing 200 SNMP locks. 202 LOCK-MIB is defined in [I-D.meng-fan-lock-mib] to monitor locks via 203 multiple NM interfaces. It consists of the lockTable and several 204 specific NM interface tables as well as several scalar variables. 205 The lockTable collects generic information for all locks being 206 managed by the device regardless of protocol and its structure is 207 like: 209 --lockObjects(1) 210 | 211 +--lockTable(3) 212 | 213 +--lockEntry(1) [lockIndex] 214 | 215 +--Unsigned32 lockIndex(1) 216 | 217 +--SnmpAdminString lockUserName(2) 218 | 219 +--SnmpAdminString lockNMInterface(3) 220 | 221 +--INTEGER lockType(4) 222 | 223 +--TimeTicks lockStartTime(5) 224 | 225 +--TimeTicks lockEndTime(6) 226 | 227 +--INTEGER lockState(7) 229 [I-D.meng-fan-lock-mib] has more details. 231 A specific NM interface lock table collects specific information with 232 regard to all locks via one specific protocol, for example, 233 lockNetconfTable collects specific information of all locks via 234 NETCONF. Since LOCK-MIB allows for being extended by adding a new 235 specific NM interface lock table, we organize specific information of 236 all locks via SNMP into a specific NM interface lock table called 237 lockSnmpTable: 239 --lockObjects(1) 240 | 241 +--lockSnmpObjects(6) 242 | 243 +--TestAndIncr lockSnmpSpinLock(1) 244 | 245 +--lockSnmpTable(2) 246 | 247 +--lockSnmpEntry(1) [lockSnmpLockId] 248 | 249 +--Unsigned32 lockSnmpLockId(1) 250 | 251 +--SnmpAdminString lockSnmpViewTreeFamilyViewName(2) 252 | 253 +--OBJECT IDENTIFIER lockSnmpViewTreeFamilySubtree(3) 254 | 255 +--OCTET STRING lockSnmpViewTreeFamilyMask(4) 256 | 257 +--INTEGER lockSnmpViewTreeFamilyType(5) 258 | 259 +--Unsigned32 lockSnmpIndex(6) 260 | 261 +--RowStatus lockSnmpStatus(7) 263 The meaning of each Object Type is explained as below: 265 lockSnmpSpinLock is an advisory lock which is used to coordinate 266 multiple simultaneous SETs to lockSnmpTable. 268 lockSnmpLockId is an instance-identifier to differentiate multiple 269 entries in lockSnmpTable. 271 lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree, 272 lockSnmpViewTreeFamilyMask and lockSnmpViewTreeFamilyType are 273 jointly used to represent the protected area by a lock as a MIB 274 view. their semantics is specified in [RFC3415]. 276 lockSnmpIndex connects a entry in lockSnmpTable to the 277 corresponding entry in lockTable. 279 lockSnmpStatus is used to indicate the status of the associated 280 entry, "notReady" means the lock request is pending, "active" 281 means the lock takes effect. 283 The lockSnmpTable can be used to acquire or release a lock, and can 284 be combined with lockTable to monitor all SNMP locks. 286 6. Elements of Procedure 288 This section describes how to manipulate objects defined in section 5 289 in order to acquire and release a lock. It gives the procedure of 290 lock acquisition, lock release as well as lock validation. 292 6.1. Procedure of lock acquisition 294 SNMP manager can request a lock by trying to create an entry in 295 lockSnmpTable. Before that, we should retrieve the value of 296 lockSnmpSpinLock as the instance-identifier of the entry to be 297 created and calculate the value of lockSnmpViewTreeFamilySubtree and 298 lockSnmpViewTreeFamilyMask as well as specify the value of 299 lockSnmpViewTreeFamilyViewName and lockSnmpViewTreeFamilyType to 300 identify the intended protected area by the lock based on subsequent 301 SET(s) to be issued. Even though we create a entry successfully, its 302 status column won't be active until the lock is granted. Lock 303 request failure would destroy the associate entry. Whatever the lock 304 is granted or not, a entry collecting generic information about the 305 lock will be added to lockTable. 307 Manager Agent 308 (1) 309 <-----------> 310 (2) 311 (3) 312 <------------> 313 (4) 314 (5) 315 (6) 316 (7) 317 <-----------> 319 (1) the manager GET(lockSnmpSpinLock.0) and save in sValue. sValue 320 is used to be the instance-identifier of the entry to be created. 321 I.e., if an entry is created successfully, the value of the 322 lockSnmpLockId associated with the entry equals to sValue. 324 (2) the manager specifies the viewValue and typeValue, calculates 325 the subtreeValue and maskValue based on the SET operations to be 326 protected. Combination of them is used to identify the intended 327 protected area by the lock. How to get these values is out of the 328 scope of this document, and it is left to implementation-specific. 330 (3) the manager SET(lockSnmpSpinLock.0=sValue, 331 lockSnmpViewTreeFamilyViewName=viewValue, 332 lockSnmpViewTreeFamilySubtree=subtreeValue, 333 lockSnmpVIewTreeFamilyMask=maskValue, 334 lockSnmpViewTreeFamilyViewType=typeValue) 336 (4) An entry is created with lockSnmpStatus="notReady" by the 337 agent. 339 (5) the agent processes the lock request based on criteria 340 mentioned later. 342 (6) After the lock request processing completes, an entry 343 representing the lock is added to lockTable with 344 lockState="ACTIVE" or lockState="FAILED" depending on the lock 345 request succeeded or not, if lockState=ACTIVE, then the value of 346 lockSnmpIndex is set to the value of the corresponding lockIndex 347 in lockTable and the value of status column is set to ACTIVE, 348 otherwise, the associated entry in lockSnmpTable is deleted. 350 (7) the manager GET(lockSnmpStatus). When the value of 351 lockSnmpStatus is "active", the lock is valid. Otherwise the lock 352 failed. 354 Granted locks protect all instances specified by the associated 355 family of view subtrees (i.e., combination of values of 356 lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree, 357 lockSnmpViewFamilyMask and lockSnmpViewFamilyType) from modification 358 by others, regardless of SNMP or non-SNMP operations. 360 A lock request MUST be handled atomically by the agent. The agent 361 either locks all requested parts of the configuration data or none. 362 If during the lock request processing one of the requested parts 363 cannot be locked, the agent MUST unlock all parts that have already 364 been locked during the lock request processing. 366 The agent MUST be able to grant multiple simultaneous locks to a 367 single user. If the protected area of the individual locks overlaps, 368 instances in the common area MUST be protected until all of the locks 369 are released. 371 With point (5) above, a lock request MUST fail if: 373 o Any part of the MIB to be protected is already locked by other 374 users, including SNMP users or any other non-SNMP management 375 method. 377 o The agent implements access control model(s), and the locking user 378 does not have sufficient access rights. The exact handling of 379 access rights is outside the scope of this document, but it is 380 assumed that there is an access control system that MAY deny or 381 allow the lock request. 383 6.2. Procedure of lock release 385 Manager can try to delete an entry in lockSnmpTable in order to 386 release the associated active lock. 388 (1) the manager SET(lockSnmpStatus=destroy) 390 (2) the agent release the lock. 392 (3) the manager GET(lockState) to check if the lock has been 393 released or not. 395 Manager Agent 396 (1) 397 <-----------> 398 (2) 399 (3) 400 <-----------> 402 6.3. Procedure of lock validation 404 An active SNMP lock should protect locked managed object types (and 405 instances) from modification by other SNMP users or any other non- 406 SNMP methods. When the operations attempting to modify locked object 407 types (and instances) arrives, the server MUST fail them (with error 408 codes). A locked object MUST be treated as an unavailable resource. 409 For example, in a SNMPv3 message, the error code MUST be 410 resourceUnavailable. 412 According to section 4.2.5, [RFC3416], a SET operation is 413 conceptually processed as a two phase operation. Before actual 414 variable assignments, there are 12 validation steps for checking, 415 e.g., access rights, value types, etc. If any variable binding's 416 name specifies an already locked managed object types (or instance), 417 step (11) will be triggered, i.e., the value of the Response-PDU's 418 error-status field is set to "resourceUnavailable", and the value of 419 its error-index field is set to the index of the failed variable 420 binding. 422 7. Definitions 424 LOCK-SNMP-MIB DEFINITIONS ::= BEGIN 426 IMPORTS 427 OBJECT-TYPE, MODULE-IDENTITY, 428 mib-2, Unsigned32 FROM SNMPv2-SMI 429 TestAndIncr, RowStatus FROM SNMPv2-TC 430 SnmpAdminString FROM SNMP-FRAMEWORK-MIB 431 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 433 lockSnmpMIB MODULE-IDENTITY 434 LAST-UPDATED "200905270000Z"-- 27 May 2009 435 ORGANIZATION "Operations and Management Area Working Group" 436 CONTACT-INFO 437 " Tony Meng 438 Postal: Huawei-Symantec Technologies 439 3rd Floor, Section D, Keshi Building 440 No.28, Xinxi Rd., Shangdi, Haidian Dist. 441 Beijing 100085 442 China 443 Email: mengjian@huaweisymantec.com 445 Washam Fan 446 Postal: Huawei-Symantec Technologies 447 3rd Floor, Section D, Keshi Building 448 No.28, Xinxi Rd., Shangdi, Haidian Dist. 449 Beijing 100085 450 China 451 Email: Washam.Fan@huaweisymantec.com 452 " 453 DESCRIPTION "The module defines management information for 454 managing SNMP locks for network management protocols. 456 Copyright (C) The IETF Trust (2009). This version 457 of this MIB module is part of RFC XXXX; see the RFC 458 itself for full legal notices." 460 -- RFC Ed.: replace XXXX with actual RFC number & remove this note 462 REVISION "200905270000Z"-- 27 May 2009 463 DESCRIPTION "Initial version, published as RFC XXXX." 465 ::= { mib-2 xxx } --to be assigned by IANA 467 -- Administrative assignments ******************************* 469 lockSnmpObjects OBJECT IDENTIFIER ::= { lockSnmpMIB 1 } 470 lockSnmpConformance OBJECT IDENTIFIER ::= { lockSnmpMIB 2 } 472 lockSnmpSpinLock OBJECT-TYPE 473 SYNTAX TestAndIncr 474 MAX-ACCESS read-write 475 STATUS current 476 DESCRIPTION "An advisory lock used to allow cooperating SNMP 477 Command Generator applications to coordinate their 478 use of the Set operation in creating SNMP locks. 480 When creating a new SNMP lock, it is important to 481 understand the potential interactions with other 482 uses of the lock. The lockSnmpSpinLock should be 483 retrieved. The lockSnmpLockId of the lock to be 484 created should be determined to be unique by the 485 SNMP Command Generator application by consulting 486 the lockSnmpSpinLock. Finally, the requested lock 487 may be created (Set), including the advisory lock. 489 If another SNMP Command Generator application has 490 altered the locks in the meantime, then the spin 491 lock's value will have changed, and so this creation 492 will fail because it will specify the wrong value for 493 the spin lock. 495 Since this is an advisory lock, the use of this lock 496 is not enforced. 497 " 498 ::= { lockSnmpObjects 1 } 500 lockSnmpTable OBJECT-TYPE 501 SYNTAX SEQUENCE OF LockSnmpEntry 502 MAX-ACCESS not-accessible 503 STATUS current 504 DESCRIPTION "This table collects specific information of all locks 505 via SNMP. The information includes lock identifiers for 506 identifying all locks via SNMP, intended protected area 507 by the lock, etc. 509 Users can request a lock by creating a new entry 510 successfully. Combination of values of 511 lockSnmpViewTreeFamilyViewName, 512 lockSnmpViewTreeFamilySubtree, 513 lockSnmpViewTreeFamilyMask 514 and lockSnmpViewTreeFamilyType represents the intended 515 protected area by the lock. 517 Users can release an active lock by trying to destroy 518 the associated entry. 520 Users can retrieve the information of a lock from 521 lockTable by referencing the value of snmpLockIndex 522 when the lock is active. 523 " 524 ::= { lockSnmpObjects 2 } 526 lockSnmpEntry OBJECT-TYPE 527 SYNTAX LockSnmpEntry 528 MAX-ACCESS not-accessible 529 STATUS current 530 DESCRIPTION "An entry represents a SNMP lock and includes all 531 specific information about the lock. 532 " 533 INDEX { lockSnmpLockId } 534 ::= { lockSnmpTable 1 } 536 LockSnmpEntry ::= SEQUENCE 537 { 538 lockSnmpLockId Unsigned32, 539 lockSnmpViewTreeFamilyViewName SnmpAdminString, 540 lockSnmpViewTreeFamilySubtree OBJECT IDENTIFIER, 541 lockSnmpViewTreeFamilyMask OCTET STRING, 542 lockSnmpViewTreeFamilyType INTEGER, 543 lockSnmpIndex Unsigned32, 544 lockSnmpStatus RowStatus 545 } 547 lockSnmpLockId OBJECT-TYPE 548 SYNTAX Unsigned32 549 MAX-ACCESS not-accessible 550 STATUS current 551 DESCRIPTION "Lock identifier to differentiate all SNMP locks. 552 The value should equal to the value of lockSnmpSpinLock 553 when creating the associated entry. 554 " 555 ::= { lockSnmpEntry 1 } 557 lockSnmpViewTreeFamilyViewName OBJECT-TYPE 558 SYNTAX SnmpAdminString (SIZE(0..32)) 559 MAX-ACCESS read-create 560 STATUS current 561 DESCRIPTION "The human readable name for a family of view subtrees. 562 " 563 ::= { lockSnmpEntry 2 } 565 lockSnmpViewTreeFamilySubtree OBJECT-TYPE 566 SYNTAX OBJECT IDENTIFIER 567 MAX-ACCESS read-create 568 STATUS current 569 DESCRIPTION "The MIB subtree which when combined with the 570 corresponding instance of lockSnmpViewTreeFamilyMask 571 defines a family of view subtrees. 572 " 573 ::= { lockSnmpEntry 3 } 575 lockSnmpViewTreeFamilyMask OBJECT-TYPE 576 SYNTAX OCTET STRING (SIZE (0..16)) 577 MAX-ACCESS read-create 578 STATUS current 579 DESCRIPTION "The bit mask which, in combination with the 580 corresponding instance of 581 lockSnmpViewTreeFamilySubtree, 582 defines a family of view subtrees. 584 Readers can refer to [RFC3415] for details how to 585 define a family of view subtrees with the two values. 586 " 587 DEFVAL { ''H } 588 ::= { lockSnmpEntry 4 } 590 lockSnmpViewTreeFamilyType OBJECT-TYPE 591 SYNTAX INTEGER { included(1), excluded(2) } 592 MAX-ACCESS read-create 593 STATUS current 594 DESCRIPTION "Indicates whether the corresponding instances of 595 lockSnmpViewTreeFamilySubtree and 596 lockSnmpViewTreeFamilyMask 597 define a family of view subtrees which is included in 598 or excluded from the MIB view. 599 " 600 DEFVAL { included } 601 ::= { lockSnmpEntry 5 } 603 lockSnmpIndex OBJECT-TYPE 604 SYNTAX Unsigned32 605 MAX-ACCESS read-only 606 STATUS current 607 DESCRIPTION "Lock identifier to differentiate all locks via 608 multiple NM interfaces. It connects the entry to 609 the corresponding entry in lockTable. 611 Users can retrieve the info of the lock from lockTable 612 by referencing the value. 614 " 615 ::= { lockSnmpEntry 6 } 617 lockSnmpStatus OBJECT-TYPE 618 SYNTAX RowStatus 619 MAX-ACCESS read-write 620 STATUS current 621 DESCRIPTION "With value 'notReady' means the lock request has been 622 submitted successfully but not yet processed. 623 With value 'active' means the lock is granted at last. 624 Failed and released lock will be deleted. 625 " 626 ::= { lockSnmpEntry 7 } 628 -- Conformance Information ******************************************* 630 lockSnmpCompliances OBJECT IDENTIFIER ::= { lockSnmpConformance 1 } 631 lockSnmpGroups OBJECT IDENTIFIER ::= { lockSnmpConformance 2 } 633 -- Compliance statements 635 lockSnmpCompliance MODULE-COMPLIANCE 636 STATUS current 637 DESCRIPTION "The compliance statement for an entity who implements 638 this LOCK-SNMP-MIB." 640 MODULE -- this module 641 MANDATORY-GROUPS { lockSnmpGroup } 643 ::= { lockSnmpCompliances 1 } 645 lockSnmpGroup OBJECT-GROUP 646 OBJECTS { 647 lockSnmpSpinLock, 648 lockSnmpViewTreeFamilyViewName, 649 lockSnmpViewTreeFamilySubtree, 650 lockSnmpViewTreeFamilyMask, 651 lockSnmpViewTreeFamilyType, 652 lockSnmpIndex, 653 lockSnmpStatus 654 } 655 STATUS current 656 DESCRIPTION "A collection of objects providing basic instrumentation 657 of an entity which supports SNMP lock." 658 ::= { lockSnmpGroups 1 } 660 END 661 8. Relationship to other MIBs 663 LOCK-MIB defined in [I-D.meng-fan-lock-mib] collects generic 664 information of all locks supported in the device, the memo extends 665 LOCK-MIB to collect specific information of all SNMP locks described 666 in this memo. LOCK-MIB and the extension done in this memo can be 667 used jointly to manage and control SNMP locks, per section 6. 669 When the extension is added to LOCK-MIB, statistics variables should 670 reflect SNMP locks defined in this memo as well as other NM interface 671 locks. When a SNMP lock becomes active, the value of lockActivelocks 672 should be incremented by 1, when a SNMP lock failure occurs, the 673 value of lockFailures should be incremented by 1, when an active SNMP 674 lock is released, the value of lockActivelocks should be reduced by 675 1. 677 SNMP-VIEW-BASED-ACM-MIB defined in [RFC3416] defines 678 vacmViewTreeFamilyTable to represent views. lockSnmpTable represents 679 views in the identical way which is used to identify protected areas 680 by locks. 682 9. Security Considerations 684 This document enable a SNMP agent to handle the lock acquisition, 685 lock release and lock validation. These work should be done in 686 accordance with Security Model and Access Control Model to manage and 687 control locks. 689 Before a manager can set lockSnmpTable, it should be authenticated 690 successfully. When a conceptual row is to be created in 691 lockSnmpTable, the agent should check if the authenticated manager 692 has appropriate privileges about all objects falling into the 693 intended locked area as well as other criteria if necessary. 695 A lock might prevent other users from configuring the system (which 696 might lead to DoS attack). The following mechanisms are in place to 697 prevent the misuse of this possibility: 699 Only an authenticated and authorized user should be allowed to 700 request a lock. 702 The lock is automatically released when a session (if it exists, 703 e.g., SSH transport mapping is used) is terminated regardless of 704 how the session ends. The reboot behavior leads to all the active 705 locks automatically released. 707 Implementations should allow an administrator to release an SNMP 708 lock via SNMP and through the native CLI console interface, to be 709 able to prevent denial of service attacks. 711 Keeping track of the number of active locks using lockActivelocks 712 counter can uncover some bad behaviors. E.g. If the number of 713 active locks grows rapidly or there are locks lasting for a long 714 period of time, somebody might be trying to launch a denial of 715 service attack. 717 The SNMP agent may log lock requests in an audit trail. 719 LOCK-MIB doesn't allow for modifying specific NM interface lock 720 tables except for lockSnmpTable, which means a non SNMP lock can't be 721 released via manipulating managed objects defined in LOCK-MIB. Since 722 the access control system is different among different NM interfaces, 723 SNMP lock SHOULD NOT be released by non SNMP interfaces or methods. 725 lock release forcibly might lead to difficult recovery, as It is 726 impossible to rollback all successful SET(s) protected by the lock. 727 When a lock is grant in a SET processing procedure, it may cause The 728 SET processing in place failed. In that case, the agent SHOULD try 729 to undo all the assignments in the SET, the corresponding Response 730 PDU is returned with error-status with value "commitFailed" or 731 "undoFailed" (in the latter case. the undone failed). 733 9.1. MIB Security Considerations 735 There are a number of management objects defined in this MIB module 736 with a MAX-ACCESS clause of read-write and/or read-create. Such 737 objects may be considered sensitive or vulnerable in some network 738 environments. The support for SET operations in a non-secure 739 environment without proper protection can have a negative effect on 740 network operations. These are the tables and objects and their 741 sensitivity/vulnerability: 743 o lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree, 744 lockSnmpViewTreeFamilyMask, lockSnmpViewTreeFamilyType: these 745 objects are used to identify the scope of intended locked area. 746 If any object falling into this area is unauthorized to the 747 requesting user, the lock request will fail. If the SET operation 748 has altered in an unauthoritative way, the lock request probably 749 fails. 751 o lockSnmpStatus: this object indicates the state of the lock via 752 combining with the lockState column in lockTable. SET operations 753 attempting set lockSnmpStatus to 'notInService' will release the 754 lock or abort the lock request. SET operations attempting set 755 lockSnmpStatus to 'destroy' will delete the entry (and release an 756 active lock). So unauthorized SET operations will probably broken 757 an active lock illegally. 759 SNMP versions prior to SNMPv3 did not include adequate security. 760 Even if the network itself is secure (for example by using IPsec), 761 even then, there is no control as to who on the secure network is 762 allowed to access and GET/SET (read/change/create/delete) the objects 763 in this MIB module. 765 It is RECOMMENDED that implementers consider the security features as 766 provided by the SNMPv3 framework (see [RFC3410], section 8), 767 including full support for the SNMPv3 cryptographic mechanisms (for 768 authentication and privacy). 770 Further, deployment of SNMP versions prior to SNMPv3 is NOT 771 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 772 enable cryptographic security. It is then a customer/operator 773 responsibility to ensure that the SNMP entity giving access to an 774 instance of this MIB module is properly configured to give access to 775 the objects only to those principals (users) that have legitimate 776 rights to indeed GET or SET (change/create/delete) them. 778 10. Acknowledges 780 This draft partially borrows from Balazs Lengyel and Martin 781 Bjorklund's [I-D.ietf-netconf-partial-lock]. Many thanks to David 782 Harrington for his guidance and feedback on this doc. 784 11. References 786 11.1. Normative References 788 [I-D.meng-fan-lock-mib] Meng, T. and W. Fan, "Definitions of 789 Managed Objects for lock via network 790 management protocols", April 2009. 792 [RFC2119] Bradner, S., "Key words for use in 793 RFCs to Indicate Requirement 794 Levels", BCP 14, EFC 2119, 795 March 1997. 797 [RFC2578] McCloghrie, K., Ed., Perkins, D., 798 Ed., and J. Schoenwaelder, Ed., 799 "Structure of Management Information 800 Version 2 (SMIv2)", STD 58, 801 RFC 2578, April 1999. 803 [RFC2579] McCloghrie, K., Ed., Perkins, D., 804 Ed., and J. Schoenwaelder, Ed., 805 "Textual Conventions for SMIv2", 806 STD 58, RFC 2579, April 1999. 808 [RFC2580] McCloghrie, K., Perkins, D., and J. 809 Schoenwaelder, "Conformance 810 Statements for SMIv2", STD 58, 811 RFC 2580, April 1999. 813 [RFC3411] Harrington, D., Presuhn, R., and B. 814 Wijnen, "An Architecture for 815 Describing Simple Network Management 816 Protocol (SNMP) Management 817 Frameworks", STD 62, RFC 3411, 818 December 2002. 820 [RFC3415] Wijnen, B., Presuhn , R., and K. 821 McCloghrie, "View-based Access 822 Control Model (VACM) for the Simple 823 Network Management Protocol (SNMP)", 824 RFC 3415, December 2002. 826 [RFC3416] Presuhn, R., "Version 2 of the 827 Protocol Operations for the Simple 828 Network Management Protocol (SNMP)", 829 STD 62, RFC 3416, December 2002. 831 11.2. Informative References 833 [I-D.ietf-netconf-partial-lock] Lengyel, B. and M. Bjorklund, 834 "Partial Lock RPC for NETCONF", 835 Feburary 2009. 837 [RFC3410] Case, J., Mundy, R., Partain, D., 838 and B. Stewart, "Introduction and 839 Applicability Statements for 840 Internet-Standard Management 841 Framework", RFC 3410, December 2002. 843 [RFC4741] Enns, R., Ed., "NETCONF 844 Configuration Protocol", RFC 4741, 845 December 2006. 847 Authors' Addresses 849 Washam Fan 850 Huawei-Symantec Technologies 851 3rd Floor, Section D, Keshi Building 852 No.28, Xinxi Rd., Shangdi, Haidian Dist. 853 Beijing 100085 854 China 856 EMail: Washam.Fan@huaweisymantec.com 857 URI: http://www.huaweisymantec.com 859 Tony Meng 860 Huawei-Symantec Technologies 861 3rd Floor, Section D, Keshi Building 862 No.28, Xinxi Rd., Shangdi, Haidian Dist. 863 Beijing 100085 864 China 866 EMail: mengjian@huaweisymantec.com 867 URI: http://www.huaweisymantec.com