rfc2962.txt

RFC 的详细文档！


RFC 2962            SNMP Payload Address Translation        October 2000


   confusion and erroneous behavior of management applications.
   However, a certain class of management applications like e.g.
   network discovery tools may work pretty well across NATs with a basic
   SNMP ALG in place.

   An advanced SNMP ALG described in Section 4.2 achieves better
   transparency.  However, an advanced SNMP ALG can only claim to be
   transparent for the set of data types (textual conventions)
   understood by the advanced SNMP ALG implementation and for a given
   set of MIB modules.  The price paid for better transparency is
   additional complexity, potentially increased SNMP packet sizes and
   mixed up lexicographic ordering.  Especially with SNMPv3, there is an
   opportunity that communication fails due to increased packet sizes.
   Management applications that rely on lexicographic ordering will show
   erroneous behavior.

   Both, basic and advanced SNMP ALGs, introduce problems when using
   SNMPv3 security features.  The SNMPv3 authentication mechanism
   protects the whole SNMP message against modifications while the
   SNMPv3 privacy mechanism protects the payload of SNMPv3 messages
   against unauthorized access.  Thus, an SNMP ALG must have access to
   all localized keys in use in order to modify SNMPv3 messages without
   invalidating them.  Furthermore, the SNMP ALG must track any key
   changes in order to function.  More details on the security
   implications of using SNMP ALGs can be found in Section 6.

   Finally, an SNMP ALG only deals with SNMP traffic and does not modify
   the payload of any other protocol.  However, management systems
   usually use a set of protocols to manage a network.  In particular
   the telnet protocol is often used to configure or troubleshoot
   managed devices.  Hence, a management system and the human network
   operator must generally be aware that a network address translation
   is occurring, even in the presence of an SNMP ALG.

   A possible alternative to SNMP ALGs are SNMP proxies, as defined in
   RFC 2573 [11].  An SNMP proxy forwarder application forwards SNMP
   messages to other SNMP engines according to the context, and
   irrespective of the specific managed object types being accessed.
   The proxy forwarder also forwards the response to such previously
   forwarded messages back to the SNMP engine from which the original
   message was received.  Such a proxy forwarder can be used in a NAT
   environment to address SNMP engines with conflicting IP addresses.
   (Just replace the box SNMP ALG with a box labeled SNMP PROXY in
   Figure 2.)  The deployment of SNMP proxys has the advantage that
   different security levels can be used inside and outside of the
   conflicting addressing realms.





Raz, et al.                  Informational                     [Page 11]

RFC 2962            SNMP Payload Address Translation        October 2000


   The proxy solution, which is structurally preferable, requires that
   the management application is aware of the proxy situation.
   Furthermore, management applications have to use internal data
   structures for network elements that allow for conflicting IP
   addresses since conflicting IP addresses are not translated by the
   SNMP proxy.  Deployment of proxies may also involve the need to
   reconfigure network elements and management stations to direct their
   traffic (notifications and requests) to the proxy forwarder.

6. Security Considerations

   SNMPv1 and SNMPv2c have very week security services based on
   community strings. All management information is sent in cleartext
   without encryption and/or authentication. In such an environment,
   SNMP messages can be modified by any intermediate node and management
   application are not able to verify the integrity of SNMP messages.
   Furthermore, an SNMP ALG does not need to have knowledge of the
   community strings in order to translate embedded IP addresses.  Thus,
   deployment of SNMP ALGs in an SNMPv1/SNMPv2c environment introduces
   no additional security problems.

   SNMPv3 supports three security levels: no authentication and no
   encryption (noAuth/noPriv), authentication and no encryption
   (auth/noPriv), and authentication and encryption (auth/priv).  SNMPv3
   messages without authentication and encryption (noAuth/noPriv) are
   send in cleartext.  In such a case the usage of SNMP ALGs introduces
   no additional security problems.

   However, the usage of SNMP ALG introduces new problems when SNMPv3
   authentication and optionally encryption is used.  First, SNMPv3
   messages with authentication and optionally encryption (auth/noPriv
   and auth/priv) can only be processed by an SNMP ALG which supports
   the corresponding cryptographic algorithms and which has access to
   the keys in use.  Furthermore, as keys may be updated, the SNMP ALG
   must have a mechanism that tracks key changes (either by analyzing
   the key change interactions or by propagating key changes by other
   mechanisms).  Second, the computational complexity of processing SNMP
   messages may increase dramatically.  The message has to be decrypted
   before the translation takes place.  If any translation is done the
   hash signature used to authenticate the message and to protect its
   integrity must be recomputed.

   In general, key exchange protocols are complicated and designing an
   SNMP ALG which maintains the keys for a set of SNMP engines is a
   non-trivial task. The User-based Security Model for SNMPv3 [12]
   defines a mechanism which takes a password and generates localized





Raz, et al.                  Informational                     [Page 12]

RFC 2962            SNMP Payload Address Translation        October 2000


   keys for every SNMP engine.  The localized keys have the property
   that a compromised single localized key does not automatically give
   an attacker access to other SNMP engines, even if the key for other
   SNMP engines is derived from the same password.

   An SNMP ALG implementation which maintains lists of (localized) keys
   is a potential target to attack the security of all the systems which
   use these keys.  An SNMP ALG implementation which maintains passwords
   in order to generate localized keys is a potential target to attack
   the security of all systems that use the same password.  Hence, an
   SNMP ALG implementation must be properly secured so that people who
   are not authorized to access keys or passwords can not access them.

   Finally, SNMP ALGs do not allow a network operator to use different
   security levels on both sides of the NAT.  Using a secure SNMP
   version outside of a private addressing realm while the private
   addressing realm runs an unsecured version of SNMP may be highly
   desirable in many scenarios, e.g. management outsourcing scenarios.
   The deployment of SNMPv3 proxies instead of SNMP ALGs should be
   considered in these cases since SNMP proxies can be configured to use
   different security levels and parameters on both sides of the
   proxies.

7. Summary and Recommendations

   Several approaches to address SNMP agents across NAT devices have
   been discussed in this memo.

   1.  Basic SNMP ALGs as described in Section 4.1 provide very limited
       transparency since they only translate IPv4 addresses encoded in
       the IpAddress base type.  They are fast and efficient and may be
       sufficient to execute simple management applications (e.g.
       topology discovery applications) in a NAT environment. However,
       other management applications are likely to fail due to the
       limited transparency provided by a basic SNMP ALG.  Basic SNMP
       ALGs are problematic in a secure SNMP environment since they need
       to maintain lists of keys or passwords in order to function.
   2.  Advanced SNMP ALGs as described in Section 4.2 provide better
       transparency.  They can be transparent for the set of data types
       they understand and for a given set of MIB modules.  However, an
       advanced SNMP ALG is much more complex and less efficiency than a
       basic SNMP ALG. An advanced SNMP ALG may break the lexicographic
       ordering when IP addresses are used to index conceptual tables
       and it may change the SNMP packet sizes.  Especially with SNMPv3,
       there is an opportunity that communication fails due to increased
       message sizes.  Advanced SNMP ALGs are problematic in a secure
       SNMP environment, since they need to maintain lists of keys or
       passwords in order to function.



Raz, et al.                  Informational                     [Page 13]

RFC 2962            SNMP Payload Address Translation        October 2000


   3.  SNMP proxies as described in RFC 2573 [11] allow management
       applications to access SNMP agents with conflicting IP addresses.
       No address translation is performed on the SNMP payload by an
       SNMP proxy forwarder.  Hence, management applications must be
       able to deal with network elements that have conflicting IP
       addresses.  This solution requires that management applications
       are aware of the proxy situation.  Deployment of proxies may also
       involve the need to reconfigure network elements and management
       stations to direct their traffic (notifications and requests) to
       the proxy forwarder.  SNMP proxies have the advantage that they
       allow to use different security levels inside and outside of a
       given addressing realm.

   It is recommended that network operators who need to manage networks
   in a NAT environment make a careful analysis before deploying a
   solution.  In particular, it must be analyzed whether the management
   applications will work with the transparency and the side-effects
   provided by SNMP ALGs.  Furthermore, it should be researched whether
   the management applications are able to deal with conflicting IP
   addresses for network devices.  Finally, the additional complexity
   introduced to the over all management system by using SNMP ALGs must
   be compared to the complexity introduced by the structurally
   preferable SNMP proxy forwarders.

8. Current Implementations

   A basic SNMP ALG as described in Section 4.1 was implemented for
   SNMPv1 at Bell-Labs, running on a Solaris Machine.  The solution
   described in Figure 2, where SNMP ALG was combined with the NAT
   implementation of Lucent's PortMaster3, was deployed successfully in
   a large network management service organization.

9. Acknowledgments

   We thank Pyda Srisuresh, for the support, encouragement, and advice
   throughout the work on this document.  We also thank Brett A. Denison
   for his contribution to the work that led to this document.
   Additional useful comments have been made by members of the NAT
   working group.

10. References

   [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [2]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
        Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.





Raz, et al.                  Informational                     [Page 14]

RFC 2962            SNMP Payload Address Translation        October 2000


   [3]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
        "Introduction to Community-based SNMPv2", RFC 1901, January
        1996.

   [4]  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.

   [5]  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.

   [6]  McCloghrie, K., "SNMPv2 Management Information Base for the
        Internet Protocol using SMIv2", RFC 2011, November 1996.

   [7]  Waldbusser, S., "Remote Network Monitoring Management
        Information Base Version 2 using SMIv2", RFC 2021, January 1997.

   [8]  Haskin, D. and S. Onishi, "Management Information Base for IP
        Version 6: Textual Conventions and General Group", RFC 2465,
        December 1998.

   [9]  Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
        to Version 3 of the Internet-standard Network Management
        Framework", RFC 2570, April 1999.

   [10] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
        Processing and Dispatching for the Simple Network Management
        Protocol (SNMP)", RFC 2572, April 1999.

   [11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
        2573, April 1999.

   [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", RFC 2574, April 1999.

   [13] ISO, "Information processing systems - Open Systems
        Interconnection - Specification of Abstract Syntax Notation One
        (ASN.1)", International Standard 8824, December 1987.

   [14] ISO, "Information processing systems - Open Systems
        Interconnection - Specification of Basic Encoding Rules for
        Abstract Syntax Notation One (ASN.1)", International Standard
        8825, December 1987.

   [15] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.



Raz, et al.                  Informational                     [Page 15]