Internet Draft J. Quittek Document: draft-quittek-midcom-snmp-eval-00.txt NEC Europe Ltd. Expires: October 2002 November 2001 Using SNMP as Midcom Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo evaluates the Simple Network Management Protocol (SNMP) as a candidate for realizing a Midcom protocol. The properties and capabilities of the SNMP management framework are compared to the Midcom requirements [MDC-REQ] and to the Midcom framework and architecture [MDC-FRM]. It is shown that SNMP matches almost all Midcom requirements and that with the already existing support for NATs [NAT-MIB] only little additional effort is required for creating a Midcom protocol solution based on the SNMP management framework. Quittek [Page 1] Internet-Draft SNMP for Midcom April 2001 Table of Contents 1 Introduction ................................................. 2 2 The SNMP Management Framework ................................ 2 2.1 Overview ................................................... 2 2.2 General Applicability ...................................... 3 2.3 Existing Support for NAT and Firewall Control .............. 3 3 Architectural Differences .................................... 3 4 Matching Midcom Requirements ................................. 4 4.1 Midcom Requirements Met by SNMP ............................ 4 4.2 Midcom Requirements Partially Met by SNMP .................. 5 4.3 Midcom Requirements Not Met by SNMP ........................ 5 5 Summary of the Evaluation .................................... 6 6 Security Considerations ...................................... 6 7 References ................................................... 6 8 Author's Address ............................................. 8 9 Full Copyright Statement ..................................... 9 1. Introduction This memo evaluates the Simple Network Management Protocol (SNMP) as a candidate for realizing a Midcom protocol. First the SNMP management framework is introduced in section 2. Then major differences to the Midcom architecture and framework [MDC-FRM] are outlined in Section 3. The properties and capabilities of the SNMP management framework are compared to the Midcom requirements [MDC- REQ] item by item in Section 4. Section 5 summarizes the evaluation. 2. The SNMP Management Framework This section gives an overview of the SNMP Management Framework and discusses some of its properties and it discusses specific advantages of SNMP and already existing support for NAT and firewall control. 2.1. Overview The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Quittek [Page 2] Internet-Draft SNMP for Midcom April 2001 o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. 2.2. General Applicability An advantage of SNMP compared to some other evaluated protocols is, that it is very mature, well understood and approved to operate well in numerous different real-world scenarios. Also there are a lot of mature toolsets available for quickly and reliably realizing SNMP managers and agents. In practical life, SNMP is mainly used for monitoring rather than for configuring network nodes. This reduces the value of the experience described above. However, even the rather small use of SNMP for configuring network nodes during the last decade provides a much higher level of experience and maturity compared to more recently developed protocols. 2.3. Existing Support for NAT and Firewall Control For configuring NATs there is already a NAT MIB module [NAT-MIB] under development by the NAT WG. The NAT MIB module matches all of several of the Midcom requirements concerning NAT control except for grouping of policy rules (requirement 2.2.3.). In order to support grouping an additional grouping table in the NAT MIM module would be required. The effort for this extension would be rather low. Quittek [Page 3] Internet-Draft SNMP for Midcom April 2001 For configuring firewalls, existing work just considered firewall monitoring, not firewall configuration with SNMP. Several firewall manufacturers offer private MIB modules for monitoring their firewalls, for example the Juniper firewall MIB module [JFW-MIB] and an expired Internet draft by Cindy Grall [GFW-MIB]. 3. Architectural Differences There are a few architectural differences between the SNMP management framework and the Midcom framework, but components can of the SNMP management framework can be mapped to the Midcom framework in a way that that every Midcom component is covered. The roles of entities participating in SNMP communication are called from the manager. This use of the term agent is different to its use in the Midcom framework: The SNMP manager corresponds to the Midcom agent and the SNMP agent corresponds to the Midcom PDP. The SNMP management framework does not have the concept of a session, however, session-like associations can be established, see below. In order to implement the Midcom protocol based on SNMP, a Midcom MIB module has to be designed. All requests from the Midcom agent to the Midcom PDP would then be realized by write access to managed objects defined in the Midcom MIB module. All replies to requests would be signaled by the Midcom PDP (SNMP agent) by changing values of managed objects. The Midcom agent (SNMP manager) can receive this information by reading (or polling, if required) the according managed object. 4. Matching Midcom Requirements This section discusses how the SNMP management framework matches the Midcom requirements described explicitly in [MDC-REQ] and described implicitly in [MDC-FRM]. 4.1. Midcom Requirements Met by SNMP SNMP meets requirement 2.1.1. and 2.1.9., but probably not in the same way as many than other protocols do. A straight forward way of realizing sessions within the SNMP management framework would be by using managed objects for session identification and control. In SNMPv3 there is an association established between SNMP manager and SNMP agent related to providing secure data transfer between them. This association could serve as an already existing basis for establishing a Midcom session.The previous paragraph described how associations can be established. SNMP manager can communicate simultaneously with several SNMP agents. Quittek [Page 4] Internet-Draft SNMP for Midcom April 2001 Thus it meets requirement 2.1.2. Also requirement 2.1.3 is met, because an SNMP agent can communicate with several SNMP managers simultaneously. Deterministic behavior of SNMP agents when being accessed by multiple managers is important for several management applications and supported by SNMP. Thus, requirement 2.1.4 is met. Also a known and stable state of the SNMP agent is imported for several management applications and supported by SNMP meeting requirement 2.1.5. SNMP also meets requirement 2.1.6. Status report in SNMP is usually initiated by the SNMP manager polling status objects at the SNMP agent. This method is also used for determining whether or not a previous request was successful (meeting requirement 2.1.10). Beyond this, SNMP agents may send asynchronous notifications to SNMP managers meeting requirement 2.1.7. Capability exchange in SNMP is usually uni-directional. Managed objects at the Midcom PDP (SNMP agent) keep information about the capabilities of the Midcom PDP. They can be read by the Midcom agent (SNMP manager) allowing the Midcom agent to utilize its own capabilities accordingly. Since furthermore extensibility is a basic feature of the SNMP management framework, it meets requirement 2.1.11. and 2.2.1. Requirement 2.1.12 is met by the SNMP framework, because it supports atomic operations and based on this deterministic behavior in presence of overlapping rules can be realized by a Midcom PDP (SNMP agent) implementation. Requirements 2.2.2. - 2.2.5. and 2.2.7. - 2.2.11. are met by the SNMP management framework. Meeting all of them has to be realized by an appropriate definition of a Midcom MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementor of a MIB module to meet all these sematic requirements. The basic support of multiple manager in the SNMP framework includes multiple managers working on the same managed objects. Thus requirement 2.2.7. is met. The View-based Access Control Model (VACM, [RFC2575]) even offers means to customize the access rights of different managers in a fine-grained way. SNMPv1 and SNMPv2 do not meet requirements 2.3.1. - 2.3.4. However, the current version, SNMPv3, includes the User-based Security Model (USM, [RFC2574]) that meets requirements 2.3.1. - 2.3.4. USM offers three standardized methods for providing authentication, confidentiality, and integrity, and it is open to add further methods (requirement 2.3.1). Which method to use can be chosen (requirement 2.3.2) and they operate securely across untrusted domains (requirement 2.3.3). Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the Quittek [Page 5] Internet-Draft SNMP for Midcom April 2001 validity of messages (requirement 2.3.4). 4.2. Midcom Requirements Partially Met by SNMP SNMPv3 meets partially requirement 2.1.8. Authentication of the Midcom agent is supported, but not authentication of the Midcom PDP. However, SNMPv3 also contains some protection against replay attacks, nd when private keys are used, implicit authentication can be achieved. 4.3. Midcom Requirements Not Met by SNMP This section is empty. 5. Summary of the Evaluation As described above, the SNMP management framework matches all requirements specified Midcom requirements. It also is a well approved technology with stable and well approved development tools, and it already offers support for NAT configuration. For matching the security requirements, only the most recent version, SNMPv3, is suited. 6. Security Considerations Security issues of SNMP are discussed in the several related RFCs. It should be noted that only SNMPv3 matches the the security requirements for Midcom specified in [MDC-REQ]. SNMPv1 and SNMPv2c have significantly weaker security models. 7. References [MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., Shore, M., "Middlebox Communications (MIDCOM) Protocol Requirements", draft-ietf-midcom-requirements-05.txt, work in progress, November 2001. [MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, A., "Middlebox Communications Architecture and Framework", draft-ietf-midcom-framework-07.txt, work in progress, February 2002. [RFC3095] Bormann, C., et al. "An RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001. Quittek [Page 6] Internet-Draft SNMP for Midcom April 2001 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Quittek [Page 7] Internet-Draft SNMP for Midcom April 2001 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [JFW-MIB] Juniper Networks, Inc., "Firewalls MIB", http://www.juniper.net/techpubs/software/junos50/swconfig50-net- mgmt/html/mib-firewall.txt, 2002. [JFW-MIB] Grall, C., "Firewall Management Information Base", grall- firewall-mib-01, work in progress, http://alternic.net/drafts/drafts-g-h/draft-grall-firewall- mib-01.html, April 1998. 8. Author's Address Juergen Quittek NEC Europe Ltd. Network Laboratories Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Quittek [Page 8] Internet-Draft SNMP for Midcom April 2001 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Quittek [Page 9] Internet-Draft SNMP for Midcom April 2001