[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

                <draft-quittek-midcom-snmp-eval-00.txt>

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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/