idnits 2.17.1 draft-quittek-midcom-snmp-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([NAT-MIB], [MDC-REQ], [MDC-FRM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 184 has weird spacing: '... using manag...' == Line 386 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8191 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) == Missing Reference: 'NAT-MIB' is mentioned on line 137, but not defined == Missing Reference: 'GFW-MIB' is mentioned on line 148, but not defined == Unused Reference: 'RFC3095' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 350, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-requirements (ref. 'MDC-REQ') ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-framework (ref. 'MDC-FRM') ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'JFW-MIB' Summary: 19 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-quittek-midcom-snmp-eval-00.txt NEC Europe Ltd. 3 Expires: October 2002 November 2001 5 Using SNMP as Midcom Protocol 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this document is unlimited. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This memo evaluates the Simple Network Management Protocol (SNMP) as 37 a candidate for realizing a Midcom protocol. The properties and 38 capabilities of the SNMP management framework are compared to the 39 Midcom requirements [MDC-REQ] and to the Midcom framework and 40 architecture [MDC-FRM]. It is shown that SNMP matches almost all 41 Midcom requirements and that with the already existing support for 42 NATs [NAT-MIB] only little additional effort is required for creating 43 a Midcom protocol solution based on the SNMP management framework. 45 Table of Contents 47 1 Introduction ................................................. 2 48 2 The SNMP Management Framework ................................ 2 49 2.1 Overview ................................................... 2 50 2.2 General Applicability ...................................... 3 51 2.3 Existing Support for NAT and Firewall Control .............. 3 52 3 Architectural Differences .................................... 3 53 4 Matching Midcom Requirements ................................. 4 54 4.1 Midcom Requirements Met by SNMP ............................ 4 55 4.2 Midcom Requirements Partially Met by SNMP .................. 5 56 4.3 Midcom Requirements Not Met by SNMP ........................ 5 57 5 Summary of the Evaluation .................................... 6 58 6 Security Considerations ...................................... 6 59 7 References ................................................... 6 60 8 Author's Address ............................................. 8 61 9 Full Copyright Statement ..................................... 9 63 1. Introduction 65 This memo evaluates the Simple Network Management Protocol (SNMP) as 66 a candidate for realizing a Midcom protocol. First the SNMP 67 management framework is introduced in section 2. Then major 68 differences to the Midcom architecture and framework [MDC-FRM] are 69 outlined in Section 3. The properties and capabilities of the SNMP 70 management framework are compared to the Midcom requirements [MDC- 71 REQ] item by item in Section 4. Section 5 summarizes the evaluation. 73 2. The SNMP Management Framework 75 This section gives an overview of the SNMP Management Framework and 76 discusses some of its properties and it discusses specific advantages 77 of SNMP and already existing support for NAT and firewall control. 79 2.1. Overview 81 The SNMP Management Framework presently consists of five major 82 components: 84 o An overall architecture, described in RFC 2571 [RFC2571]. 86 o Mechanisms for describing and naming objects and events for the 87 purpose of management. The first version of this Structure of 88 Management Information (SMI) is called SMIv1 and described in 89 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 90 1215 [RFC1215]. The second version, called SMIv2, is described 91 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 92 STD 58, RFC 2580 [RFC2580]. 94 o Message protocols for transferring management information. The 95 first version of the SNMP message protocol is called SNMPv1 and 96 described in STD 15, RFC 1157 [RFC1157]. A second version of 97 the SNMP message protocol, which is not an Internet standards 98 track protocol, is called SNMPv2c and described in RFC 1901 99 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 100 message protocol is called SNMPv3 and described in RFC 1906 101 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 103 o Protocol operations for accessing management information. The 104 first set of protocol operations and associated PDU formats is 105 described in STD 15, RFC 1157 [RFC1157]. A second set of 106 protocol operations and associated PDU formats is described in 107 RFC 1905 [RFC1905]. 109 o A set of fundamental applications described in RFC 2573 110 [RFC2573] and the view-based access control mechanism described 111 in RFC 2575 [RFC2575]. 113 A more detailed introduction to the current SNMP Management Framework 114 can be found in RFC 2570 [RFC2570]. 116 Managed objects are accessed via a virtual information store, termed 117 the Management Information Base or MIB. Objects in the MIB are 118 defined using the mechanisms defined in the SMI. 120 2.2. General Applicability 122 An advantage of SNMP compared to some other evaluated protocols is, 123 that it is very mature, well understood and approved to operate well 124 in numerous different real-world scenarios. Also there are a lot of 125 mature toolsets available for quickly and reliably realizing SNMP 126 managers and agents. 128 In practical life, SNMP is mainly used for monitoring rather than for 129 configuring network nodes. This reduces the value of the experience 130 described above. However, even the rather small use of SNMP for 131 configuring network nodes during the last decade provides a much 132 higher level of experience and maturity compared to more recently 133 developed protocols. 135 2.3. Existing Support for NAT and Firewall Control 137 For configuring NATs there is already a NAT MIB module [NAT-MIB] 138 under development by the NAT WG. The NAT MIB module matches all of 139 several of the Midcom requirements concerning NAT control except for 140 grouping of policy rules (requirement 2.2.3.). In order to support 141 grouping an additional grouping table in the NAT MIM module would be 142 required. The effort for this extension would be rather low. 144 For configuring firewalls, existing work just considered firewall 145 monitoring, not firewall configuration with SNMP. Several firewall 146 manufacturers offer private MIB modules for monitoring their 147 firewalls, for example the Juniper firewall MIB module [JFW-MIB] and 148 an expired Internet draft by Cindy Grall [GFW-MIB]. 150 3. Architectural Differences 152 There are a few architectural differences between the SNMP management 153 framework and the Midcom framework, but components can of the SNMP 154 management framework can be mapped to the Midcom framework in a way 155 that that every Midcom component is covered. 157 The roles of entities participating in SNMP communication are called 158 from the manager. This use of the term agent is different to its use 159 in the Midcom framework: The SNMP manager corresponds to the Midcom 160 agent and the SNMP agent corresponds to the Midcom PDP. 162 The SNMP management framework does not have the concept of a session, 163 however, session-like associations can be established, see below. 165 In order to implement the Midcom protocol based on SNMP, a Midcom MIB 166 module has to be designed. All requests from the Midcom agent to the 167 Midcom PDP would then be realized by write access to managed objects 168 defined in the Midcom MIB module. All replies to requests would be 169 signaled by the Midcom PDP (SNMP agent) by changing values of managed 170 objects. The Midcom agent (SNMP manager) can receive this information 171 by reading (or polling, if required) the according managed object. 173 4. Matching Midcom Requirements 175 This section discusses how the SNMP management framework matches the 176 Midcom requirements described explicitly in [MDC-REQ] and described 177 implicitly in [MDC-FRM]. 179 4.1. Midcom Requirements Met by SNMP 181 SNMP meets requirement 2.1.1. and 2.1.9., but probably not in the 182 same way as many than other protocols do. A straight forward way of 183 realizing sessions within the SNMP management framework would be by 184 using managed objects for session identification and control. In 185 SNMPv3 there is an association established between SNMP manager and 186 SNMP agent related to providing secure data transfer between them. 187 This association could serve as an already existing basis for 188 establishing a Midcom session.The previous paragraph described how 189 associations can be established. 191 SNMP manager can communicate simultaneously with several SNMP agents. 193 Thus it meets requirement 2.1.2. Also requirement 2.1.3 is met, 194 because an SNMP agent can communicate with several SNMP managers 195 simultaneously. 197 Deterministic behavior of SNMP agents when being accessed by multiple 198 managers is important for several management applications and 199 supported by SNMP. Thus, requirement 2.1.4 is met. Also a known and 200 stable state of the SNMP agent is imported for several management 201 applications and supported by SNMP meeting requirement 2.1.5. 203 SNMP also meets requirement 2.1.6. Status report in SNMP is usually 204 initiated by the SNMP manager polling status objects at the SNMP 205 agent. This method is also used for determining whether or not a 206 previous request was successful (meeting requirement 2.1.10). Beyond 207 this, SNMP agents may send asynchronous notifications to SNMP 208 managers meeting requirement 2.1.7. Capability exchange in SNMP is 209 usually uni-directional. Managed objects at the Midcom PDP (SNMP 210 agent) keep information about the capabilities of the Midcom PDP. 211 They can be read by the Midcom agent (SNMP manager) allowing the 212 Midcom agent to utilize its own capabilities accordingly. Since 213 furthermore extensibility is a basic feature of the SNMP management 214 framework, it meets requirement 2.1.11. and 2.2.1. 216 Requirement 2.1.12 is met by the SNMP framework, because it supports 217 atomic operations and based on this deterministic behavior in 218 presence of overlapping rules can be realized by a Midcom PDP (SNMP 219 agent) implementation. 221 Requirements 2.2.2. - 2.2.5. and 2.2.7. - 2.2.11. are met by the SNMP 222 management framework. Meeting all of them has to be realized by an 223 appropriate definition of a Midcom MIB module. SMI, the language used 224 for defining MIB modules, is flexible enough to allow the implementor 225 of a MIB module to meet all these sematic requirements. 227 The basic support of multiple manager in the SNMP framework includes 228 multiple managers working on the same managed objects. Thus 229 requirement 2.2.7. is met. The View-based Access Control Model (VACM, 230 [RFC2575]) even offers means to customize the access rights of 231 different managers in a fine-grained way. 233 SNMPv1 and SNMPv2 do not meet requirements 2.3.1. - 2.3.4. However, 234 the current version, SNMPv3, includes the User-based Security Model 235 (USM, [RFC2574]) that meets requirements 2.3.1. - 2.3.4. USM offers 236 three standardized methods for providing authentication, 237 confidentiality, and integrity, and it is open to add further methods 238 (requirement 2.3.1). Which method to use can be chosen (requirement 239 2.3.2) and they operate securely across untrusted domains 240 (requirement 2.3.3). Additionally, USM has specific built-in 241 mechanisms for preventing replay attacks including unique protocol 242 engine IDs, timers and counters per engine and time windows for the 243 validity of messages (requirement 2.3.4). 245 4.2. Midcom Requirements Partially Met by SNMP 247 SNMPv3 meets partially requirement 2.1.8. Authentication of the 248 Midcom agent is supported, but not authentication of the Midcom PDP. 249 However, SNMPv3 also contains some protection against replay attacks, 250 nd when private keys are used, implicit authentication can be 251 achieved. 253 4.3. Midcom Requirements Not Met by SNMP 255 This section is empty. 257 5. Summary of the Evaluation 259 As described above, the SNMP management framework matches all 260 requirements specified Midcom requirements. It also is a well 261 approved technology with stable and well approved development tools, 262 and it already offers support for NAT configuration. For matching 263 the security requirements, only the most recent version, SNMPv3, is 264 suited. 266 6. Security Considerations 268 Security issues of SNMP are discussed in the several related RFCs. It 269 should be noted that only SNMPv3 matches the the security 270 requirements for Midcom specified in [MDC-REQ]. SNMPv1 and SNMPv2c 271 have significantly weaker security models. 273 7. References 275 [MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., Shore, M., 276 "Middlebox Communications (MIDCOM) Protocol Requirements", 277 draft-ietf-midcom-requirements-05.txt, work in progress, 278 November 2001. 280 [MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., 281 Rayhan, A., "Middlebox Communications Architecture and 282 Framework", draft-ietf-midcom-framework-07.txt, work in 283 progress, February 2002. 285 [RFC3095] Bormann, C., et al. "An RObust Header Compression (ROHC): 286 Framework and four profiles: RTP, UDP, ESP, and uncompressed 287 ", RFC 3095, July 2001. 289 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 290 for Describing SNMP Management Frameworks", RFC 2571, April 291 1999. 293 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 294 of Management Information for TCP/IP-based Internets", STD 295 16, RFC 1155, May 1990. 297 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 298 16, RFC 1212, March 1991. 300 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 301 SNMP", RFC 1215, March 1991. 303 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 304 Rose, M., and S. Waldbusser, "Structure of Management 305 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 306 1999. 308 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 309 Rose, M., and S. Waldbusser, "Textual Conventions for 310 SMIv2", STD 58, RFC 2579, April 1999. 312 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 313 Rose, M., and S. Waldbusser, "Conformance Statements for 314 SMIv2", STD 58, RFC 2580, April 1999. 316 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 317 Network Management Protocol", STD 15, RFC 1157, May 1990. 319 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 320 "Introduction to Community-based SNMPv2", RFC 1901, January 321 1996. 323 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 324 "Transport Mappings for Version 2 of the Simple Network 325 Management Protocol (SNMPv2)", RFC 1906, January 1996. 327 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 328 Processing and Dispatching for the Simple Network Management 329 Protocol (SNMP)", RFC 2572, April 1999. 331 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 332 (USM) for version 3 of the Simple Network Management 333 Protocol (SNMPv3)", RFC 2574, April 1999. 335 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 336 "Protocol Operations for Version 2 of the Simple Network 337 Management Protocol (SNMPv2)", RFC 1905, January 1996. 339 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 340 RFC 2573, April 1999. 342 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 343 Access Control Model (VACM) for the Simple Network 344 Management Protocol (SNMP)", RFC 2575, April 1999. 346 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 347 "Introduction to Version 3 of the Internet-standard Network 348 Management Framework", RFC 2570, April 1999. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", RFC 2119, March 1997. 353 [JFW-MIB] Juniper Networks, Inc., "Firewalls MIB", 354 http://www.juniper.net/techpubs/software/junos50/swconfig50-net- 355 mgmt/html/mib-firewall.txt, 2002. 357 [JFW-MIB] Grall, C., "Firewall Management Information Base", grall- 358 firewall-mib-01, work in progress, 359 http://alternic.net/drafts/drafts-g-h/draft-grall-firewall- 360 mib-01.html, April 1998. 362 8. Author's Address 364 Juergen Quittek 365 NEC Europe Ltd. 366 Network Laboratories 367 Adenauerplatz 6 368 69115 Heidelberg 369 Germany 371 Phone: +49 6221 90511-15 372 EMail: quittek@ccrle.nec.de 374 9. Full Copyright Statement 376 Copyright (C) The Internet Society (2001). All Rights Reserved. 378 This document and translations of it may be copied and furnished to 379 others, and derivative works that comment on or otherwise explain it 380 or assist in its implementation may be prepared, copied, published 381 and distributed, in whole or in part, without restriction of any 382 kind, provided that the above copyright notice and this paragraph are 383 included on all such copies and derivative works. However, this 384 document itself may not be modified in any way, such as by removing 385 the copyright notice or references to the Internet Society or other 386 Internet organizations, except as needed for the purpose of 387 developing Internet standards in which case the procedures for 388 copyrights defined in the Internet Standards process must be 389 followed, or as required to translate it into languages other than 390 English. 392 The limited permissions granted above are perpetual and will not be 393 revoked by the Internet Society or its successors or assigns. 395 This document and the information contained herein is provided on an 396 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 397 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 398 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 399 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 400 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.