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 Message Processing for Condensed Network Management Protocol (CNMP) draft-vaughn-cnmp-message-00 Abstract This document specifies the message processing and dispatching for Condensed Network Management Protocol (CNMP) messages. It defines the procedures for dispatching messages to the proper message processing models, and for dispatching the contents to CNMP applications. This document also describes one message processing model - the CNMP Message Processing Model. 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. K. Vaughn Expires May 24, 2014 [Page 1] INTERNET DRAFT Message Processing for CNMP November 20, 2013 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Dispatcher . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Message Processing Subsystem . . . . . . . . . . . . . . . 7 4. Elements of Message Processing and Dispatching . . . . . . . . 7 4.1. pduType . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Dispatcher Elements of Procedure . . . . . . . . . . . . . . . 9 5.1. CNMP Management Objects . . . . . . . . . . . . . . . . . 9 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. The CNMP Message Format . . . . . . . . . . . . . . . . . . . 13 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.1. CNMPVersionedMessage . . . . . . . . . . . . . . . . . 17 7.2.2. Dynamic Object Messages . . . . . . . . . . . . . . . 17 7.3. CNMPVersionedMessage . . . . . . . . . . . . . . . . . . . 18 7.5.1. msgVersion . . . . . . . . . . . . . . . . . . . . . . 18 7.5.2. msgID . . . . . . . . . . . . . . . . . . . . . . . . 18 7.5.3. msgMaxSize . . . . . . . . . . . . . . . . . . . . . . 18 7.5.4 msgSecurityFlags . . . . . . . . . . . . . . . . . . . 18 7.5.5. msgSecurityParameters and the Null Security Model . . 19 7.5.6. msgData . . . . . . . . . . . . . . . . . . . . . . . 19 7.5.7. contextEngineID and contextName . . . . . . . . . . . 19 7.5.8. data . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Elements of Procedure for CNMPv1 Message Processing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2.1. prepareOutgoingMessage . . . . . . . . . . . . . . . . 20 8.2.2. prepareResponseMessage . . . . . . . . . . . . . . . . 21 8.2.3. prepareDataElements . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10.1. Communications Security . . . . . . . . . . . . . . . . . 22 10.1.1. Messages without Security . . . . . . . . . . . . . . 22 10.1.2. Authenticated Messages . . . . . . . . . . . . . . . 22 K. Vaughn Expires May 24, 2014 [Page 2] INTERNET DRAFT Message Processing for CNMP November 20, 2013 10.1.3. Private Messages . . . . . . . . . . . . . . . . . . 23 10.1.4. Lower Layer Security . . . . . . . . . . . . . . . . 23 10.2. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 23 10.3. Systems Security . . . . . . . . . . . . . . . . . . . . 23 10.3.1. Unauthorized Usage . . . . . . . . . . . . . . . . . 23 10.3.2. Inappropriate Usage . . . . . . . . . . . . . . . . . 23 10.3.3. Denial of Service . . . . . . . . . . . . . . . . . . 24 10.3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1 Normative References . . . . . . . . . . . . . . . . . . . 24 12.2 Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 K. Vaughn Expires May 24, 2014 [Page 3] INTERNET DRAFT Message Processing for CNMP November 20, 2013 1. Introduction The Architecture of CNMP conforms to the architecture of the Simple Network Management Protocol (SNMP) as defined in [RFC3411]. Within this context, a CNMP engine is composed of: 1) its own Dispatcher 2) one or more Message Processing Subsystems, 3) a Security Subsystem, which is shared with SNMP and 4) an Access Control Subsystem, which is shared with SNMP. Applications make use of the services of these subsystems. It is important to understand the architecture and its terminology to understand where the Message Processing Subsystem and Dispatcher described in this document fit into the architecture and interact with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture, defined in [RFC3411], its updates ([RFC5343] and [RFC5590]), and the Document Roadmap for CNMP as defined in [Intro]. The Dispatcher of a CNMP engine is nearly identical to that defined in [RFC3412] and [RFC5590]; however, since the parent message structure of a CNMP message is different from an SNMP message, CNMP uses a different transport mapping and therefore has its own Dispatcher. Otherwise, the CNMP Dispatcher provides the same basic functions as the SNMP Dispatcher of sending and receiving messages and dispatching PDUs to applications using version-specific Message Processing Models as necessary. This INTERNET-DRAFT defines a new Message Processing Models for CNMP, know as version 1. It fully backwards compatible with the Simple Transportation Management Protocol [STMP] as defined by the National Transportation Communications for ITS (Intelligent Transportation Systems) Protocol, but extends this protocol to allow for secure data exchanges. 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 K. Vaughn Expires May 24, 2014 [Page 4] INTERNET DRAFT Message Processing for CNMP November 20, 2013 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. When referencing other RFCs, the any reference to SNMP in those RFCs shall be interpreted to reference CNMP, unless specifically stated otherwise within this document. 3. Overview The following illustration depicts the Message Processing in relation to applications, the Security Subsystem and Transport Mappings. K. Vaughn Expires May 24, 2014 [Page 5] INTERNET DRAFT Message Processing for CNMP November 20, 2013 +-------------------------------------------------------------------+ | CNMP Entity | | | | +---------------------------------------------------------------+ | | | Applications | | | | +-----------+ +--------------+ | | | | | Command | | Notification | | | | | | Generator | | Originator | +-----------+ +--------------+| | | | +-----------+ +--------------+ | Proxy | | Other || | | | +-----------+ +--------------+ | Forwarder | |Application(s)|| | | | | Command | | Notification | +-----------+ +--------------+| | | | | Responder | | Receiver | | | | | +-----------+ +--------------+ | | | +---------------------------------------------------------------+ | | ^ ^ ^ ^ | | | | | | | | v v v v | | +--------+-------+---------------+-----------+ | | ^ | | | +---------------------+ +-----------------+ | | | | Message Processing | | Security | | | CNMP Dispatcher v | Subsystem | | Subsystem | | | +------------------+ | | | | | | | PDU Dispatcher | | | | +-------------+ | | | | | | | | | Other | | | | | | | +------------+ | | | Security | | | | | | | +->| CNMPv1 * |<--->| | Model | | | | | Message | | | +------------+ | | +-------------+ | | | | Dispatcher <-------->+ | | | | | | | | | | | +-------------+ | | | | | | | | | | User-based | | | | | Transport | | | | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | | | +->| otherMP * |<--->| +-------------+ | | | +------------------+ | +------------+ | | | | | ^ +---------------------+ +-----------------+ | | | | +----------|--------------------------------------------------------+ v +------------------+ | Network | * One or more models may be present. +------------------+ 3.1. The Dispatcher There is only one Dispatcher in a CNMP engine, however, this Dispatcher is separate from the SNMP Dispatcher as it uses a separate Transport Mapping. Its job is to dispatch tasks to appropriate K. Vaughn Expires May 24, 2014 [Page 6] INTERNET DRAFT Message Processing for CNMP November 20, 2013 version-specific Message Processing Models, and to dispatch PDUs to appropriate applications. NOTE: In theory, CNMP could use the same port number and transport mapping as SNMP because an SNMP data packet will always start with an initial byte of 0x30 (i.e., an ASN.1 SEQUENCE encoded with BER) while the CNMP message uses the Octet Encoding Rules [OER], and will always start with a value of 0x60 or above. However, as it is a bit kludge to intermix encoding rules without a designator, we propose that the two protocols be kept separate. For outgoing messages, an application provides the unencrypted PDU to be sent, plus the data needed to prepare and send the message, and the application specifies which version-specific Message Processing Model will be used to prepare the message with the desired security processing. Once the message is prepared, the Dispatcher sends the message. For incoming messages, the Dispatcher determines the CNMP version of the incoming message and passes the message to the version-specific Message Processing Model to decrypt and extract the components of the message and to coordinate the processing of security services for the message. After version-specific processing, the PDU Dispatcher determines which application, if any, should receive the PDU for processing and forwards it accordingly. The Dispatcher, while sending and receiving CNMP messages, collects statistics about CNMP messages and the behavior of the CNMP engine in managed objects to make them accessible to remote SNMP/CNMP entities. This document defines these managed objects, the MIB module which contains them, and how these managed objects might be used to provide useful management. 3.2. Message Processing Subsystem The CNMP Message Processing Subsystem is the part of an CNMP engine which interacts with the Dispatcher to handle the version-specific CNMP messages. It contains one or more Message Processing Models. This document describes the CNMPv1 Message Processing Model. This Message Processing Model can be replaced or supplemented with other Message Processing Models in the future. 4. Elements of Message Processing and Dispatching The Message Processing and Dispatching of CNMP SHALL follow the rules defined for SNMPv3, as documented in Clause 3 of [RFC3412], with the following additional and expanded definitions. K. Vaughn Expires May 24, 2014 [Page 7] INTERNET DRAFT Message Processing for CNMP November 20, 2013 4.1. pduType The pduType shall be one of the following: * GetRequest, which is in the Read Class and Confirmed Class; * GetNextRequest, which is in the Read Class and Confirmed Class; * GetBulkRequest, which is in the Read Class and Confirmed Class; * GetDynObj, which is in the Read Class and Confirmed Class; * GetNextDynObj, which is in the Read Class and Confirmed Class; * SetRequest, which is in the Write Class and Confirmed Class; * SetNoReply, which is in the Write Class and Unconfirmed Class; * SetDynObj, which is in the Write Class and Confirmed Class; * SetNoReplyDynObj, which is in the Write Class and Unconfirmed Class; * Trap, which is in the Notification Class and Unconfirmed Class; * InformRequest, which is in the Notification Class and Confirmed Class; * GetResponse, which is in the Response Class and Unconfirmed Class; * GetRespDynObj, which is in the Response Class and Unconfirmed Class; * SetResponse, which is in the Response Class and Unconfirmed Class; * SetRespDynObj, which is in the Response Class and Unconfirmed Class; * ErrorResponse, which is in the Response Class and Unconfirmed Class; * ErrorRespDynObj, which is in the Response Class and Unconfirmed Class. * InformResponse, which is in the Response Class and Unconfirmed Class; The following pduTypes are defined to be in the Dynamic Object Class: * GetDynObj K. Vaughn Expires May 24, 2014 [Page 8] INTERNET DRAFT Message Processing for CNMP November 20, 2013 * SetDynObj * SetNoReplyDynObj * GetNextDynObj * GetRespDynObj * SetRespDynObj * ErrorRespDynObj The following pduTypes are defined to be in the Normal Object Class: * GetRequest * SetRequest * SetNoReply * GetNextRequest * GetBulRequest * GetResponse * SetResponse * ErrorResponse * Trap * InformRequest * InformResponse 5. Dispatcher Elements of Procedure A CNMP entity SHALL follow the same Dispatcher Elements of Procedures as defined in Clause 4 of [RFC3412] and [RFC5590], except as defined in the following clauses. 5.1. CNMP Management Objects All references to "snmp" objects, i.e., objects defined in [RFC3418], in Clause 4 of [RFC3412] SHALL be interpreted to mean the corresponding "cnmp" objects defined in Clause 6 of this INTERNET- DRAFT. 6. Definitions CNMP-MPD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, Counter32 FROM SNMPv2-SMI systemGroup FROM SNMPv2-MIB; cnmp OBJECT IDENTIFIER ::= { TBD1 } cnmpModules OBJECT IDENTIFIER ::= { cnmp 1 } cnmpMPDMIB MODULE-IDENTITY K. Vaughn Expires May 24, 2014 [Page 9] INTERNET DRAFT Message Processing for CNMP November 20, 2013 LAST-UPDATED "201310300000Z" ORGANIZATION "Trevilon LLC" CONTACT-INFO "name: Kenneth Vaughn phone: +1-571-331-5670 email: kvaughn@trevilon.com postal: 6606 FM 1488 RD STE 148-503 Magnolia, TX 77354 USA " DESCRIPTION "The MIB for CNMP Message Processing and Dispatching" ::= { cnmpModules 1 } -- Administrative assignments *************************************** cnmpMPDAdmin OBJECT IDENTIFIER ::= { cnmpMPDMIB 1 } cnmpMPDMIBObjects OBJECT IDENTIFIER ::= { cnmpMPDMIB 2 } cnmpMPDMIBConformance OBJECT IDENTIFIER ::= { cnmpMPDMIB 3 } -- Statistics for CNMP Messages ************************************* cnmpMPDStats OBJECT IDENTIFIER ::= { cnmpMPDMIBObjects 1 } cnmpUnknownSecurityModels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the CNMP engine which were dropped because they referenced a securityModel that was not known to or supported by the CNMP engine." ::= { cnmpMPDStats 1 } cnmpInvalidMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the CNMP engine which were dropped because there were invalid or inconsistent components in the CNMP message." ::= { cnmpMPDStats 2 } cnmpUnknownPDUHandlers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the CNMP K. Vaughn Expires May 24, 2014 [Page 10] INTERNET DRAFT Message Processing for CNMP November 20, 2013 engine which were dropped because the PDU contained in the packet could not be passed to an application responsible for handling the pduType, e.g. no CNMP application had registered for the proper combination of the contextEngineID and the pduType." ::= { cnmpMPDStats 3 } cnmpInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of messages delivered to the CNMP entity from the transport service." ::= { cnmpMPDStats 4 } cnmpInBadVersions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of CNMP messages which were delivered to the CNMP entity and were for an unsupported CNMP version." ::= { cnmpMPDStats 5 } cnmpInASNParseErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of ASN.1 parsing errors encountered by the CNMP entity when decoding received CNMP messages." ::= { cnmpMPDStats 6 } cnmpSilentDrops OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Confirmed Class PDUs delivered to the CNMP entity which were silently dropped because the size of a reply containing an alternate Response Class PDU with an empty variable-bindings field was greater than either a local constraint or the maximum message size associated with the originator of the request." ::= { cnmpMPDStats 7 } cnmpProxyDrops OBJECT-TYPE SYNTAX Counter32 K. Vaughn Expires May 24, 2014 [Page 11] INTERNET DRAFT Message Processing for CNMP November 20, 2013 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of Confirmed Class PDUs delivered to the SNMP entity which were silently dropped because the transmission of the (possibly translated) message to a proxy target failed in a manner (other than a time-out) such that no Response Class PDU could be returned." ::= { cnmpMPDStats 8 } cnmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating command generator applications to coordinate their use of the SNMP set operation. This object is used for coarse-grain coordination. To achieve fine-grain coordination, one or more similar objects might be defined within each MIB group, as appropriate." ::= { cnmpMPDStats 9 } -- Conformance information ****************************************** cnmpMPDMIBCompliances OBJECT IDENTIFIER ::= {cnmpMPDMIBConformance 1} cnmpMPDMIBGroups OBJECT IDENTIFIER ::= {cnmpMPDMIBConformance 2} -- Compliance statements cnmpMPDCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CNMP entities which implement the CNMP-MPD-MIB." MODULE -- this module MANDATORY-GROUPS { cnmpMPDGroup, systemGroup } ::= { cnmpMPDMIBCompliances 1 } cnmpMPDGroup OBJECT-GROUP OBJECTS { cnmpUnknownSecurityModels, cnmpInvalidMsgs, cnmpUnknownPDUHandlers, cnmpInPkts, cnmpInBadVersions, cnmpInASNParseErrs, cnmpSilentDrops, K. Vaughn Expires May 24, 2014 [Page 12] INTERNET DRAFT Message Processing for CNMP November 20, 2013 cnmpProxyDrops } STATUS current DESCRIPTION "A collection of objects providing for remote monitoring of the CNMP Message Processing and Dispatching process." ::= { cnmpMPDMIBGroups 1 } END 7. The CNMP Message Format 7.1. Overview A CNMPMessage contains one of the following: * A Versioned Message, which contains version and security information along with message contents, as described in Clause 7.2.1. * A Get Request for one of 13 Dynamic Objects, as described in Clause 7.2.2. * A Set Request for one of 13 Dynamic Objects, as described in Clause 7.2.3. * A Set-No Reply Request for one of 13 Dynamic Objects, as described in Clause 7.2.4. * A Get-Next Request for one of 13 Dynamic Objects, as described in Clause 7.2.5. * A Get Response for one of 13 Dynamic Objects, as described in Clause 7.2.6. * A Set Response for one of 13 Dynamic Objects, as described in Clause 7.2.7. * A Error Response for one of 13 Dynamic Objects, as described in Clause 7.2.8. 7.2. Definition CNMPMessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS CNMP-PDUs, GetDynObj1, GetDynObj2, GetDynObj3, GetDynObj4, GetDynObj5, GetDynObj6, GetDynObj7, GetDynObj8, GetDynObj9, GetDynObj10, GetDynObj11, GetDynObj12, K. Vaughn Expires May 24, 2014 [Page 13] INTERNET DRAFT Message Processing for CNMP November 20, 2013 GetDynObj13, SetDynObj1, SetDynObj2, SetDynObj3, SetDynObj4, SetDynObj5, SetDynObj6, SetDynObj7, SetDynObj8, SetDynObj9, SetDynObj10, SetDynObj11, SetDynObj12, SetDynObj13, SetNoReplyDynObj1, SetNoReplyDynObj2, SetNoReplyDynObj3, SetNoReplyDynObj4, SetNoReplyDynObj5, SetNoReplyDynObj6, SetNoReplyDynObj7, SetNoReplyDynObj8, SetNoReplyDynObj9, SetNoReplyDynObj10, SetNoReplyDynObj11, SetNoReplyDynObj12, SetNoReplyDynObj13, GetNextDynObj1, GetNextDynObj2, GetNextDynObj3, GetNextDynObj4, GetNextDynObj5, GetNextDynObj6, GetNextDynObj7, GetNextDynObj8, GetNextDynObj9, GetNextDynObj10, GetNextDynObj11, GetNextDynObj12, GetNextDynObj13, GetRespDynObj1, GetRespDynObj2, GetRespDynObj3, GetRespDynObj4, GetRespDynObj5, GetRespDynObj6, GetRespDynObj7, GetRespDynObj8, GetRespDynObj9, GetRespDynObj10, GetRespDynObj11, GetRespDynObj12, GetRespDynObj13, SetRespDynObj1, SetRespDynObj2, SetRespDynObj3, SetRespDynObj4, SetRespDynObj5, SetRespDynObj6, SetRespDynObj7, SetRespDynObj8, SetRespDynObj9, SetRespDynObj10, SetRespDynObj11, SetRespDynObj12, SetRespDynObj13, ErrorRespDynObj1, ErrorRespDynObj2, ErrorRespDynObj3, ErrorRespDynObj4, ErrorRespDynObj5, ErrorRespDynObj6, ErrorRespDynObj7, ErrorRespDynObj8, ErrorRespDynObj9, ErrorRespDynObj10, ErrorRespDynObj11, ErrorRespDynObj12, ErrorRespDynObj13 FROM CNMP-PDU; CNMPMessage ::= CHOICE { cNMPVersionedMessage CNMPVersionedMessage, getDynObj1 GetDynObj1, getDynObj2 GetDynObj2, getDynObj3 GetDynObj3, getDynObj4 GetDynObj4, getDynObj5 GetDynObj5, getDynObj6 GetDynObj6, K. Vaughn Expires May 24, 2014 [Page 14] INTERNET DRAFT Message Processing for CNMP November 20, 2013 getDynObj7 GetDynObj7, getDynObj8 GetDynObj8, getDynObj9 GetDynObj9, getDynObj10 GetDynObj10, getDynObj11 GetDynObj11, getDynObj12 GetDynObj12, getDynObj13 GetDynObj13, setDynObj1 SetDynObj1, setDynObj2 SetDynObj2, setDynObj3 SetDynObj3, setDynObj4 SetDynObj4, setDynObj5 SetDynObj5, setDynObj6 SetDynObj6, setDynObj7 SetDynObj7, setDynObj8 SetDynObj8, setDynObj9 SetDynObj9, setDynObj10 SetDynObj10, setDynObj11 SetDynObj11, setDynObj12 SetDynObj12, setDynObj13 SetDynObj13, setNoReplyDynObj1 SetNoReplyDynObj1, setNoReplyDynObj2 SetNoReplyDynObj2, setNoReplyDynObj3 SetNoReplyDynObj3, setNoReplyDynObj4 SetNoReplyDynObj4, setNoReplyDynObj5 SetNoReplyDynObj5, setNoReplyDynObj6 SetNoReplyDynObj6, setNoReplyDynObj7 SetNoReplyDynObj7, setNoReplyDynObj8 SetNoReplyDynObj8, setNoReplyDynObj9 SetNoReplyDynObj9, setNoReplyDynObj10 SetNoReplyDynObj10, setNoReplyDynObj11 SetNoReplyDynObj11, setNoReplyDynObj12 SetNoReplyDynObj12, setNoReplyDynObj13 SetNoReplyDynObj13, getNextDynObj1 GetNextDynObj1, getNextDynObj2 GetNextDynObj2, getNextDynObj3 GetNextDynObj3, getNextDynObj4 GetNextDynObj4, getNextDynObj5 GetNextDynObj5, getNextDynObj6 GetNextDynObj6, getNextDynObj7 GetNextDynObj7, getNextDynObj8 GetNextDynObj8, getNextDynObj9 GetNextDynObj9, getNextDynObj10 GetNextDynObj10, getNextDynObj11 GetNextDynObj11, getNextDynObj12 GetNextDynObj12, K. Vaughn Expires May 24, 2014 [Page 15] INTERNET DRAFT Message Processing for CNMP November 20, 2013 getNextDynObj13 GetNextDynObj13, getRespDynObj1 GetRespDynObj1, getRespDynObj2 GetRespDynObj2, getRespDynObj3 GetRespDynObj3, getRespDynObj4 GetRespDynObj4, getRespDynObj5 GetRespDynObj5, getRespDynObj6 GetRespDynObj6, getRespDynObj7 GetRespDynObj7, getRespDynObj8 GetRespDynObj8, getRespDynObj9 GetRespDynObj9, getRespDynObj10 GetRespDynObj10, getRespDynObj11 GetRespDynObj11, getRespDynObj12 GetRespDynObj12, getRespDynObj13 GetRespDynObj13, setRespDynObj1 SetRespDynObj1, setRespDynObj2 SetRespDynObj2, setRespDynObj3 SetRespDynObj3, setRespDynObj4 SetRespDynObj4, setRespDynObj5 SetRespDynObj5, setRespDynObj6 SetRespDynObj6, setRespDynObj7 SetRespDynObj7, setRespDynObj8 SetRespDynObj8, setRespDynObj9 SetRespDynObj9, setRespDynObj10 SetRespDynObj10, setRespDynObj11 SetRespDynObj11, setRespDynObj12 SetRespDynObj12, setRespDynObj13 SetRespDynObj13, errorRespDynObj1 ErrorRespDynObj1, errorRespDynObj2 ErrorRespDynObj2, errorRespDynObj3 ErrorRespDynObj3, errorRespDynObj4 ErrorRespDynObj4, errorRespDynObj5 ErrorRespDynObj5, errorRespDynObj6 ErrorRespDynObj6, errorRespDynObj7 ErrorRespDynObj7, errorRespDynObj8 ErrorRespDynObj8, errorRespDynObj9 ErrorRespDynObj9, errorRespDynObj10 ErrorRespDynObj10, errorRespDynObj11 ErrorRespDynObj11, errorRespDynObj12 ErrorRespDynObj12, errorRespDynObj13 ErrorRespDynObj13 } CNMPVersionedMessage ::= [APPLICATION 32] SEQUENCE { msgVersion MessageVersion, msgGlobalData HeaderData, K. Vaughn Expires May 24, 2014 [Page 16] INTERNET DRAFT Message Processing for CNMP November 20, 2013 msgSecurityParameters OCTET STRING, -- ScopedPDU, encrypted if indicated in msgSecurityFlags msgData OCTET STRING } MessageVersion ::= INTEGER { version-1 (1) } (0..255) HeaderData ::= SEQUENCE { msgID INTEGER (0..65535), msgMaxSize INTEGER (484..65535), msgSecurityFlags INTEGER (0..255) } ScopedPdu ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data CNMP-PDUs } END 7.2.1. CNMPVersionedMessage The CNMPVersionedMessage option listed in the CNMPMessage choice statement represents a CNMP message that includes version and security information as defined in Clause 7.3. 7.2.2. Dynamic Object Messages Each of the options listed in the CNMPMessage choice statement represent a request or response related to the dynObjectValue with the indicated dynamic object index. The messages are as follows: 1) A getDynObj message represents a get request for the indicated dynObjectValue object. 2) A setDynObj message represents a set request for the indicated dynObjectValue object. 3) A setNoReplyDynObj message represents a setNoReply request for the indicated dynObjectValue object. It is semantically equivalent to the setDynObj message, but will not generate a response message from the agent. 4) A getNextDynObj message represents a get request for the next lexicographically ordered and 'active' dynObjectValue object. K. Vaughn Expires May 24, 2014 [Page 17] INTERNET DRAFT Message Processing for CNMP November 20, 2013 5) A getRespDynObj message represents a get response for the indicated dynObjectValue object. 6) A setRespDynObj message represents a set response for the indicated dynObjectValue object. 7) An errorRespDynObj message represents an error response for the indicated dynObjectValue object. Dynamic object messages do not contain any security information; they implicitly use the default contextEngineID and a contextName equal to the value of dynObjectOwner for the indicated dynamic object. See [PDU] for a complete definition of dynamic objects, including dynObjectValue and dynObjectOwner. 7.3. CNMPVersionedMessage The CNMPVersionedMessage is identical to the SNMPv3Message defined in [RFC3412], except as explained in the following clauses. 7.5.1. msgVersion The msgVersion field SHALL only have a range of a one-byte unsigned integer and references a CNMP version rather than an SNMP version. 7.5.2. msgID The msgID field SHALL only have a range of a two-byte unsigned integer and is used as both the message identifier and the request identifier. 7.5.3. msgMaxSize The msgMaxSize field SHALL have an upper range of a two-byte unsigned integer; its lower range SHALL be the same as SNMP at 484 bytes. 7.5.4 msgSecurityFlags The msgFlags and msgSecurityModel fields of SNMPv3Message SHALL be combined into a single, one-byte msgSecurityFlags field in CNMP. The high-order bit SHALL represent the reportableFlag, the second-most high-order bit SHALL represent the privFlag and the third-most high- order bit SHALL represent the authFlag. The lower five bits SHALL indicate the msgSecurityModel. The msgFlags SHALL be interpreted exactly as defined in [RFC3412]. The msgSecurityModel SHALL be interpreted exactly as defined in K. Vaughn Expires May 24, 2014 [Page 18] INTERNET DRAFT Message Processing for CNMP November 20, 2013 [RFC3412], with the following customizations. A CNMP engine SHALL only be able to support up to 32 security models at any one time; it is expected that most implementations will support much fewer than this. The value 0 SHALL be reserved as the Null Security Model as explained in Clause 7.5.5. The mapping of the values 1-31 to the appropriate securityModel SHALL be accomplished in an implementation- dependent manner. 7.5.5. msgSecurityParameters and the Null Security Model When using the Null Security Model, the msgSecurityParameters field shall be a zero-length OCTET STRING. When using this model, the msgSecurityFlags shall always request noAuthNoPriv. A message received with any other security setting SHALL be silently dropped. Users should be aware that the Null Security Model has a level of security (or lack thereof) equivalent to SNMPv1. 7.5.6. msgData The msgData field SHALL be defined as a simple OCTET STRING, which SHALL be the plain OER-encoding of ScopedPdu if the privFlag is zero; otherwise it SHALL be the encrypted version of the OER-encoding of ScopedPdu. Thus, it is semantically identical to the msgData field of SNMPv3, but without the extra CHOICE wrapper. 7.5.7. contextEngineID and contextName The values of contextEngineID and/or contextName can be zero-length strings, which SHALL be interpreted as a request to use default values. Every CNMP entity SHALL define a default contextEngineID which SHALL be used for such requests. The default contextName SHALL be "public". 7.5.8. data The data field uses the CNMP-PDUs structure rather than SNMPv2 PDUs. 8. Elements of Procedure for CNMPv1 Message Processing Subsystem This section describes the procedures followed by a CNMP engine when generating and processing CNMP messages according to the CNMPv1 Message Processing Model. The elements of procedure for CNMPv1 messages is identical to the K. Vaughn Expires May 24, 2014 [Page 19] INTERNET DRAFT Message Processing for CNMP November 20, 2013 elements of procedure defined for SNMPv3, as defined in Clause 7 of [RFC3412], with the following exceptions. 8.2.1. prepareOutgoingMessage If the call to the prepareOutgoingMessage service primitive specifies a pduType in the Dynamic Object Class, the following additional rules SHALL apply. 1) If the pduType is other than getDynObj, setDynObj, setNoReplyDynObj, or getNextDynObj; an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 2) If the securityLevel is not noAuthNoPriv, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 3) If the listing of objects in the PDU structure does not reference exactly one object, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 4) If the object referenced in the PDU structure is not a dynObjectValue with an index between 1 and 13 inclusive, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 5) If the contextEngine does not equal the default contextEngine, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 6) If the contextName does not equal the value of dynObjectOwner with the same index as the contained dynObjectValue, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 7) If the value of expectResponse is TRUE and the value of pduVersion is setNoReplyDynObj, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 8) If the value of expectResponse is FALSE and the value of pduVersion is getDynObj, setDynObj, or getNextDynObj, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 9) The cached information for Confirmed Class PDUs SHALL include the K. Vaughn Expires May 24, 2014 [Page 20] INTERNET DRAFT Message Processing for CNMP November 20, 2013 pduType. 8.2.2. prepareResponseMessage If the call to the prepareResponseMessage service primitive specifies a pduType in the Dynamic Object Class, the following additional rules SHALL apply. 1) If the pduType is other than getRespDynObj, setRespDynObj, or errorRespDynObj; an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 2) If the securityLevel is not noAuthNoPriv, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 3) If the listing of objects in the PDU structure does not reference exactly one object, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 4) If the object referenced in the PDU structure is not a dynObjectValue with an index between 1 and 13 inclusive, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 5) If the contextEngine does not equal the default contextEngine, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 6) If the contextName does not equal the value of dynObjectOwner with the same index as the contained dynObjectValue, an errorIndication (implementation specific) SHALL be returned to the calling application. No further processing is performed. 8.2.3. prepareDataElements If the parsing of the wholeMsg passed to the prepareDataElements service primitive indicates a pduType is in the Dynamic Object Class, the following additional rules SHALL apply. 1) The securityLevel SHALL be set to noAuthNoPriv. 2) The listing of objects in the PDU structure SHALL be set to reference the indicated dynamic object. 3) The contextEngine SHALL be set to the default contextEngine. K. Vaughn Expires May 24, 2014 [Page 21] INTERNET DRAFT Message Processing for CNMP November 20, 2013 4) The contextName SHALL be set to the value of dynObjectOwner with the same index as the indicated dynamic object. 9. Acknowledgements This document is based largely on material contained in [RFC3412] and [STMP]. 10. Security Considerations CNMP offers different levels of security based on the needs of the particular deployment environment. These issues are discussed in the following clauses. 10.1. Communications Security The following clauses describe the communication security issues as identified in [RFC3552]. 10.1.1. Messages without Security Messages without security include messages with an explicit security level of noAuthNoPriv as well as all Dynamic Object Class messages. Users should configure the View Access Control Model [RFC3415] to limit access to the device from such messages to the extent that is appropriate for the given deployment environment. Messages without security do not provide: * Confidentiality: While dynamic object messages do not provide any embedded clues about how to decode the dynamic data structures, these data structures are intended to be re-used over and over again. It is reasonable to assume that a determined third party would be able to crack the meaning of the structure with only a modest amount of effort. * Data integrity: There is no check for data integrity for dynamic object messages. A third party could intercept a dynamic object message, modify the contents, and forward the message to the destination without detection. * Peer entity authentication: There is no check for peer entity authentication for dynamic object messages. Any third party that is able to send an understandable dynamic object message will have it processed. 10.1.2. Authenticated Messages K. Vaughn Expires May 24, 2014 [Page 22] INTERNET DRAFT Message Processing for CNMP November 20, 2013 Messages with the authFlag set provide peer entity-authentication. The level of authentication provided is dependent upon the security model used. Assuming the use of default security model of USM, authenticated messages also provide data integrity since the authentication data is dependent upon the message contents. If the contents have been altered, the authentication should fail, thereby providing data integrity. Authenticated messages may also be private messages. 10.1.3. Private Messages Messages with the privFlag set are private messages. The level of privacy provided is dependent upon the security model used. Assuming the use of default security model of USM, private messages also provide data integrity. If the contents have been altered, the decryption should fail, thereby providing data integrity. Private messages may also be authenticated messages. 10.1.4. Lower Layer Security Security may also be provided by lower layers, such as a VPN. However, users should be aware that this will increase the size of messages. 10.2. Non-repudiation While messages may be private and authenticated, there is no mechanism for non-repudiation. If an authorized user name and password are compromised, a third party may spoof the authorized user. 10.3. Systems Security 10.3.1. Unauthorized Usage It is expected that CNMP communications may be implemented in a wide variety of environments. Some of the links on the network may support limited data rates and may span significant distances such that restricted access cannot be guaranteed. The use of authentication is strongly recommended for any such link. 10.3.2. Inappropriate Usage K. Vaughn Expires May 24, 2014 [Page 23] INTERNET DRAFT Message Processing for CNMP November 20, 2013 Administrators are strongly encouraged to keep all security configurations of their systems up to date and to only grant access to features to those users who need access. Proper and active administration is required to prevent disgruntled authorized users or former authorized users from abusing the system. 10.3.3. Denial of Service Protection from Denial of Service attacks is not provided by CNMP. 10.3.4. Proxies When considering the security of a system, one must consider the entire network. A proxy that translates to SNMPv1 may introduce a security issue, if not properly designed. 11. IANA Considerations IANA needs to assign an OBJECT IDENTIFIER value (TBD1) to the "cnmp" node defined near the top of Clause 6 of this Internet-Draft. This node number must be registered as a part of the "Structure and Identification of Management Information for TCP/IP-based Internets" (SMI) naming tree . It is suggested that the node be placed under the mgmt node (1.3.6.1.2), but we leave the exact location to the discretion of the registrar and the IETF. In order to define the node in the standard, the parent node will need to be imported into the module defined in Clause 6. This node number should be the same node number assigned for the variable TBD1 in draft-vaughn-cnmp-pdu-00. 12. References 12.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December K. Vaughn Expires May 24, 2014 [Page 24] INTERNET DRAFT Message Processing for CNMP November 20, 2013 2002. [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) Context EngineID Discovery", RFC 5343, September 2008. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. [OER] "Information Technology - ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)", published by International Telecommunications Union. Initial Draft X.oer, January 2014. 12.2 Informative References [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [Intro] Vaughn, K., "Document Roadmap for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-intro-00, November 2013. [PDU] Vaughn, K., "Protocol Operations for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-pdu-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 K. Vaughn Expires May 24, 2014 [Page 25] INTERNET DRAFT Message Processing for CNMP November 20, 2013 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 26]