INTERNET-DRAFT K. Vaughn Intended Status: Standards Track Trevilon LLC Expires: May 24, 2014 A. Triglia OSS Nokalva, Inc. R. Rausch Transcore, LP November 20, 2013 Coexistence between Condensed Network Management Protocol (CNMP) and the Simple Network Management Protocol (SNMP) draft-vaughn-cnmp-coex-00 Abstract The purpose of this document is to describe coexistence between the Condensed Network Management Protocol (CNMP) and the various versions of the Simple Network Management Protocol (SNMP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents K. Vaughn Expires May 24, 2014 [Page 1] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Translating Notification Parameters . . . . . . . . . . . . . 3 5. Approaches to Coexistence in a Multi-lingual Network . . . . . 3 5.1. Access to MIB Data . . . . . . . . . . . . . . . . . . . . 4 5.2. Multi-lingual implementations . . . . . . . . . . . . . . 4 5.2.1. Command Generator . . . . . . . . . . . . . . . . . . 4 5.2.2. Command Responder . . . . . . . . . . . . . . . . . . 4 5.2.2.1. Integer Encoding . . . . . . . . . . . . . . . . . 4 5.2.2.2. New Structures . . . . . . . . . . . . . . . . . . 4 5.2.3. Notification Originator . . . . . . . . . . . . . . . 5 5.2.4. Notification Receiver . . . . . . . . . . . . . . . . 5 5.3. Proxy Implementations . . . . . . . . . . . . . . . . . . 5 5.3.1. CNMP Upstream and SNMP Downstream . . . . . . . . . . 5 5.3.1.1. Dynamic Object Messages . . . . . . . . . . . . . 5 5.3.1.2. Other Messages . . . . . . . . . . . . . . . . . . 5 5.3.2. CNMP Downstream and SNMP Upstream . . . . . . . . . . 8 5.3.2.1. Dynamic Objects . . . . . . . . . . . . . . . . . 8 5.3.2.2. Other Messages . . . . . . . . . . . . . . . . . . 8 5.4. Error Status Mappings . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 K. Vaughn Expires May 24, 2014 [Page 2] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 1. Introduction The purpose of this document is to describe coexistence between the Condensed Network Management Protocol (CNMP) and the Simple Network Management Protocol (SNMP). For a complete overview of CNMP, see [Intro]. There are four general aspects of coexistence described in this document. Each of these is described in a separate section: - Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 3. - Mapping of notification parameters is documented in section 4. - Approaches to coexistence between CNMP and SNMP entities in a multi-lingual network is documented in section 5. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Within this INTERNET-DRAFT and all referenced documents, CNMP is to be considered another version of SNMP. It is only given a different name because the protocol encoding does not follow the same message format as SNMP messages and the protocol will use a different binding with the transport layer. 3. MIB Modules MIB modules defined using the SMIv1 may continue to be used with CNMP, once they are updated to the SMIv2 format according to the rules defined in Clause 2 of [RFC3584]. 4. Translating Notification Parameters CNMP Notifications use the same format as SNMPv2 and SNMPv3. SNMPv1 notification parameters can between this format and SNMPv1 according to the rules defined in Clause 3 of [RFC3584]. 5. Approaches to Coexistence in a Multi-lingual Network This document defines how to translate between CNMP and SNMPv3. K. Vaughn Expires May 24, 2014 [Page 3] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 Messages can be further translated to SNMPv2 or SNMPv1 according to the rules defined in [RFC3584]. 5.1. Access to MIB Data The part of a CNMP agent which actually accesses instances of MIB objects and which actually initiates generation of notifications SHALL be identical to SNMPv2 Access to MIB Data. The conversion between this access and SNMPv1 Access to MIB Data SHALL be as defined in [RFC3584]. 5.2. Multi-lingual implementations A multi-lingual implementation SHALL conform to the following rules. 5.2.1. Command Generator A command generator SHALL select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version. In addition, a command generator SHALL 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. This is done by simply changing the operation type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero. 5.2.2. Command Responder A command responder SHALL follow the same rules as defined in Clause 4.2.2 of [RFC3584] with CNMP being treated as another message format for SNMPv2 Access to MIB Data, with the following additional rule: 5.2.2.1. Integer Encoding When converting a CNMP ObjectValue which is a byte, short, long, ubyte, or ushort to SNMP, the value SHALL be encoded as an SNMP integer-value. When converting an SNMP integer-value to CNMP, the value SHALL be encoded according to the rules defined in Clause 5.2.2. of [PDU]. 5.2.2.2. New Structures Structures that are new to CNMP do not need to be converted. For example, a GetDynObjX structure can only be generated by CNMP manager. If the agent does not support CNMP, it will ignore the request. A CNMP agent will never receive a GetDynObjX structure from K. Vaughn Expires May 24, 2014 [Page 4] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 a known SNMP version. Thus, no conversion rules are necessary. 5.2.3. Notification Originator A notification originator SHALL follow the same rules as defined in Clause 4.2.2 of [RFC3584] with CNMP being treated as another message format for SNMPv2 Access to MIB Data. 5.2.4. Notification Receiver There are no special requirements of a notification receiver. 5.3. Proxy Implementations A proxy implementation may be used to enable communication between one entity that only supports CNMP and another entity that only supports SNMP. This is accomplished in a proxy forwarder application by performing translations on messages. The following sections describe the translations between CNMP and SNMPv3; the rules defined in Clause 4.3 of [RFC3584] MAY be used to further translate to any older version of SNMP. In the following sections, the 'Upstream' refers to the link between the command generator or notification receiver and the proxy, and 'Downstream' refers to the link between the proxy and the command responder or notification originator, regardless of the PDU type or direction. NOTE: The proxy may change the port number used for the exchanges in a implementation dependent manner. 5.3.1. CNMP Upstream and SNMP Downstream 5.3.1.1. Dynamic Object Messages If a Dynamic Object Class PDU (a.k.a. a Simple Transportation Management Protocol [STMP] message) is received, the proxy SHALL forward the received message without change. 5.3.1.2. Other Messages If a Normal Object Class PDU is received, the proxy SHALL attempt to translate and forward the received message according to the following rules. 5.3.1.2.1. Caching If the proxy receives an Confirmed Class PDU, the proxy SHALL cache K. Vaughn Expires May 24, 2014 [Page 5] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 the following information: * pduType * msgID * request-id, if present * variable bindings, if present The proxy may clear messages from the cache in an implementation dependent manner. 5.3.1.2.2. msgVersion The msgVersion field SHALL be changed to indicate the appropriate version for the translated message. 5.3.1.2.3. msgID If the proxy receives a message containing an InformResponse-PDU from the Upstream entity, the proxy SHALL search its cache for a pduType of InformRequest-PDU and a msgID where the lowest 16-bits match the value of the incoming msgID. The proxy SHALL forward the cached value of msgID. For all other messages, the msgID SHALL be truncated to a 16-bit unsigned value before forwarding. 5.3.1.2.4. msgMaxSize If the msgMaxSize value is greater than 65535, the forwarded msgMaxSize SHALL be 65535; otherwise, the msgMaxSize value shall be forwarded unchanged. 5.3.1.2.5. msgFlags The msgFlags shall be forwarded unchanged. 5.3.1.2.6. msgSecurityModel The msgSecurityModel shall be translated in an implementation dependent manner. 5.3.1.2.7. msgSecurityParameters The msgSecurityParameters shall be updated according to the selected msgFlags, i.e., authenticated and encrypted messages will be 1) authenticated, 2) unencrypted, 3) translated, 4) re-encrypted, and 5) re-authenticated. 5.3.1.2.8. contextEngineID K. Vaughn Expires May 24, 2014 [Page 6] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 The contextEngineID, if present, shall be forwarded unchanged. If the contextEngineID is absent, the proxy SHALL determine the default contextEngineID in an implementation dependent manner and forward that value. 5.3.1.2.9. contextName The contextName, if present, shall be forwarded unchanged. If the contextName is absent, the proxy SHALL determine the default contextName in an implementation dependent manner and forward that value. 5.3.1.2.10. request-id If the proxy receives a message containing an InformResponse-PDU from the Upstream entity, the proxy SHALL search its cache for a pduType of InformRequest-PDU and a msgID where the lowest 16-bits match the value of the incoming msgID. The proxy SHALL forward the cached value of request-id. For any other message received from the Upstream entity, the request- id in the Downstream message SHALL be the same as the msgID contained in the Upstream message. For any message received from the Downstream entity, the request-id value SHALL NOT be forwarded. 5.3.1.2.11. PDU Translations 1) If the proxy receives a message containing a Response-PDU from the Downstream entity, the proxy SHALL search its cache for a msgID that matches the value of the incoming msgID. a) If a match is not found, the proxy SHALL NOT forward the message and processing of the message is complete. b) If the pduType of the cached message is SetNoReply-PDU, the proxy SHALL NOT forward the message and processing of the message is complete. c) If the received message contains a non-zero error-status value, the proxy SHALL forward the error-status value and error-index value in an ErrorResponse-PDU. The errorVariable SHALL be set to "null" (0.0), if the error-index is zero; otherwise, it SHALL be set to the referenced ObjectName. d) Otherwise, if the pduType of the cached message is a SetRequest-PDU, the proxy SHALL forward a SetResponse-PDU. K. Vaughn Expires May 24, 2014 [Page 7] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 e) Otherwise, the proxy SHALL forward a GetResponse-PDU containing the variable bindings in the received message. i) The proxy SHALL attempt to translate the ObjectName into the form used in the matched request. If any error occurs in this process, the forwarded message SHALL directly forward the ObjectName by using the fullOID form. ii)The proxy SHALL translate integer-values according to the rules in 5.2.2.1. f) Otherwise, the message SHALL NOT be forwarded. 2) If the proxy receives a message containing a Notification Class PDU from the Downstream entity, the proxy SHALL forward the translated PDU contents. 3) If the proxy receives a message containing a Read Class or a Write Class PDU from the Upstream entity, the proxy SHALL forward the translated PDU contents. a) CNMP PDUs SHALL map to their corresponding SNMP PDU, with the exception that a CNMP SetNoReply-PDU SHALL map to an SNMP SetRequest-PDU. b) Missing ObjectValue fields from CNMP Read Class PDUs SHALL be replaced with NULL values (i.e., the unSpecified encoding option). 4) If the proxy receives a message containing an InformResponse-PDU from the Upstream entity, the proxy SHALL forward the translated PDU contents as a Response-PDU filling in the variable-bindings field based on the cached information. 5.3.2. CNMP Downstream and SNMP Upstream 5.3.2.1. Dynamic Objects If a Dynamic Object Class PDU (a.k.a. a Simple Transportation Management Protocol [STMP] message) is received, the proxy SHALL forward the received message without change. 5.3.2.2. Other Messages If a Normal Object Class PDU is received, the proxy SHALL attempt to translate and forward the received message according to the following rules. K. Vaughn Expires May 24, 2014 [Page 8] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 5.3.2.2.1. Caching If the proxy receives an Confirmed Class PDU, the proxy SHALL cache the following information: * pduType * msgID * request-id, if present * variable bindings, if present The proxy may clear messages from the cache in an implementation dependent manner. 5.3.2.2.2. msgVersion The msgVersion field SHALL be changed to indicate the appropriate version for the translated message. 5.3.2.2.3. msgID If the proxy receives a message containing an Response Class PDU from the Downstream entity, the proxy SHALL search its cache for a Read or Write Class PDU with a msgID where the lowest 16-bits match the value of the incoming msgID. The proxy SHALL forward the cached value of msgID. For all other messages, the msgID SHALL be truncated to a 16-bit unsigned value before forwarding. 5.3.2.2.4. msgMaxSize If the msgMaxSize value is greater than 65535, the forwarded msgMaxSize SHALL be 65535; otherwise, the msgMaxSize value shall be forwarded unchanged. 5.3.2.2.5. msgFlags The msgFlags shall be forwarded unchanged. 5.3.2.2.6. msgSecurityModel The msgSecurityModel shall be translated in an implementation dependent manner. 5.3.2.2.7. msgSecurityParameters The msgSecurityParameters shall be updated according to the selected msgFlags, i.e., authenticated and encrypted messages will be 1) authenticated, 2) unencrypted, 3) translated, 4) re- K. Vaughn Expires May 24, 2014 [Page 9] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 encrypted, and 5) re-authenticated. 5.3.2.2.8. contextEngineID The contextEngineID, if present, shall be forwarded unchanged. If the contextEngineID is absent, the proxy SHALL determine the default contextEngineID in an implementation dependent manner and forward that value. 5.3.2.2.9. contextName The contextName, if present, shall be forwarded unchanged. If the contextName is absent, the proxy SHALL determine the default contextName in an implementation dependent manner and forward that value. 5.3.2.2.10. request-id If the proxy receives a message containing an Response Class PDU from the Downstream entity, the proxy SHALL search its cache for a Read or Write Class PDU with a msgID where the lowest 16-bits match the value of the incoming msgID. The proxy SHALL forward the cached value of request-id. For any other message received from the Downstream entity, the request-id in the Upstream message SHALL be the same as the msgID contained in the Downstream message. For any message received from the Upstream entity, the request-id value SHALL NOT be forwarded. 5.3.2.2.11. PDU Translations 1) If the proxy receives a message containing a Read Class or a Write Class PDU from the Upstream entity, the proxy SHALL forward the translated PDU contents. a) The proxy MAY use more compact forms to encode the ObjectName. b) The proxy SHALL translate integer-values according to the rules in 5.2.2.1. 2) If the proxy receives a message containing an Response-PDU from the Upstream entity, the proxy SHALL search its cache for a msgID that matches the value of the incoming msgID. a) If a match is not found, the proxy SHALL NOT forward the message and processing of the message is complete. K. Vaughn Expires May 24, 2014 [Page 10] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 b) If the pduType of the cached message is InformRequest-PDU, the proxy SHALL forward the translated PDU contents as a InformResponse-PDU. c) Otherwise, the proxy SHALL NOT forward the message and processing of the message is complete. 3) If the proxy receives a message containing a Response Class PDU from the Downstream entity, the proxy SHALL search its cache for a Read or Write Class PDU with a msgID where the lowest 16-bits match the value of the incoming msgID. a) If a match is not found, the proxy SHALL NOT forward the message and processing of the message is complete. b) If the received message contains an ErrorResponse-PDU, the proxy SHALL forward the error-status value and error-index value in an Response-PDU. The proxy SHALL include the variable-bindings information from the cache. c) Otherwise, if the received message contains an SetResponse-PDU, the proxy SHALL forward a Response-PDU. The proxy SHALL include the variable-bindings information from the cache. d) Otherwise, if the received message contains an GetResponse- PDU,the proxy SHALL forward a Response-PDU containing the information from the VarBinds. i) The proxy SHALL translate all ObjectNames into their full OIDs. ii)The proxy SHALL translate long, short, byte, ubyte, and ushort values to integer-values. f) Otherwise, the message SHALL NOT be forwarded. 4) If the proxy receives a message containing a Notification Class PDU from the Downstream entity, the proxy SHALL forward the translated PDU contents. 5.4. Error Status Mappings All error codes SHALL be passed without translation, with the exception of the following CNMP error codes that do not exist in SNMPv3. These error codes SHALL be translated as follows. K. Vaughn Expires May 24, 2014 [Page 11] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 CNMP error-status SNMPv3 error-status =================== =================== invalidName inconsistentName processTimeout resourceUnavailable 6. Security Considerations Security issues for each protocol are defined within the context of each protocol definition. When protocols co-exist, the security of the system will be defined by the weakest link in the system. It is recommended that the implementors consider the security features as provided by the CNMP and SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414], the Transport Security Model [RFC5590], and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the entity giving access to a MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them. 7. IANA Considerations This document has no IANA actions. 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", K. Vaughn Expires May 24, 2014 [Page 12] INTERNET DRAFT Document Roadmap for CNMP November 20, 2013 RFC 5590, June 2009. [PDU] Vaughn, K., "Protocol Operations for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-pdu-00, November 2013. 8.2 Informative References [Intro] Vaughn, K., "Document Roadmap for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-intro-00, November 2013. [STMP] "Transport Management Protocols", published by American Association of State Highway Officials (AASHTO), Institute of Transportation Engineers (ITE), and National Electrical Manufacturers Association (NEMA). NTCIP (National Transportation Communications for ITS Protocol) 1103v02.17, July 2010. Authors' Addresses Kenneth Vaughn Trevilon LLC 6606 FM 1488 RD STE 148-503 Magnolia, TX 77316 USA Phone: +1-571-331-5670 Email: kvaughn@trevilon.com Alessandro Triglia OSS Nokolva, Inc. 1 Executive Drive Suite 450 Somerset, NJ 08873 Email: sandro@oss.com Robert Rausch Transcore, LP 192 Technology Parkway Suite 500 Norcross, GA 30092 Email: robert.rausch@transcore.com K. Vaughn Expires May 24, 2014 [Page 13]