Internet DRAFT - draft-vaughn-cnmp-message
draft-vaughn-cnmp-message
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 <http://www.iana.org/assignments/smi-numbers>. 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]
