< draft-hardaker-isms-dtls-tm-03.txt   draft-hardaker-isms-dtls-tm-04.txt >
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track March 9, 2009 Intended status: Standards Track May 8, 2009
Expires: September 10, 2009 Expires: November 9, 2009
Datagram Transport Layer Security Transport Model for SNMP Datagram Transport Layer Security Transport Model for SNMP
draft-hardaker-isms-dtls-tm-03.txt draft-hardaker-isms-dtls-tm-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on November 9, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 8 skipping to change at page 3, line 8
connectionless (e.g. UDP or SCTP) transport is preferred, and connectionless (e.g. UDP or SCTP) transport is preferred, and
integrates well into existing public keying infrastructures. integrates well into existing public keying infrastructures.
This document also defines a portion of the Management Information This document also defines a portion of the Management Information
Base (MIB) for monitoring and managing the DTLS Transport Model for Base (MIB) for monitoring and managing the DTLS Transport Model for
SNMP. SNMP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 7 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2. The Datagram Transport Layer Security Protocol . . . . . . . . 8 2. The Datagram Transport Layer Security Protocol . . . . . . . . 8
2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 8 2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 8
2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 9 2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 9
2.3. SNMP requirements of DTLS . . . . . . . . . . . . . . . . 10 2.3. SNMP requirements of DTLS . . . . . . . . . . . . . . . . 9
3. How the DTLSTM fits into the Transport Subsystem . . . . . . . 10 3. How the DTLSTM fits into the Transport Subsystem . . . . . . . 10
3.1. Security Capabilities of this Model . . . . . . . . . . . 12 3.1. Security Capabilities of this Model . . . . . . . . . . . 11
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 14 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 14
3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 15 3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 14
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 15 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 15
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 16 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 15
4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 17 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 16
4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 17 4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 16
4.1.2. Provisioning for the Certificate . . . . . . . . . . . 18 4.1.2. Provisioning for the Certificate . . . . . . . . . . . 18
4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 19 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 19 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 19
4.3.2. SNMP Services for an Incoming Message . . . . . . . . 20 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 20
4.4. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 21 4.4. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1. Services for Establishing a Session . . . . . . . . . 21 4.4.1. Services for Establishing a Session . . . . . . . . . 21
4.4.2. DTLS Services for an Incoming Message . . . . . . . . 23 4.4.2. DTLS Services for an Incoming Message . . . . . . . . 22
4.4.3. DTLS Services for an Outgoing Message . . . . . . . . 24 4.4.3. DTLS Services for an Outgoing Message . . . . . . . . 23
4.5. Cached Information and References . . . . . . . . . . . . 24 4.5. Cached Information and References . . . . . . . . . . . . 24
4.5.1. DTLS Transport Model Cached Information . . . . . . . 25 4.5.1. DTLS Transport Model Cached Information . . . . . . . 24
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 25 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 25 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 25
5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 25 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 25
5.1.2. Transport Processing for Incoming Messages . . . . . . 27 5.1.2. Transport Processing for Incoming Messages . . . . . . 26
5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 28 5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 27
5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 29 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 28
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 31 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 31
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 32 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 31
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 32 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 31
6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 32 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 32
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 32 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 32
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 32 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 32
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 33 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 32
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 33 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 32
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 33 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 32
8. Operational Considerations . . . . . . . . . . . . . . . . . . 48 8. Operational Considerations . . . . . . . . . . . . . . . . . . 47
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2. Notification Receiver Credential Selection . . . . . . . . 49 8.2. Notification Receiver Credential Selection . . . . . . . . 48
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 49 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.1. Certificates, Authentication, and Authorization . . . . . 50 9.1. Certificates, Authentication, and Authorization . . . . . 49
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 51 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 50
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 51 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . . 54 12.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Target and Notificaton Configuration Example . . . . 55 Appendix A. Target and Notificaton Configuration Example . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
It is important to understand the SNMPv3 architecture [RFC3411], as It is important to understand the modular SNMPv3 architecture as
enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also defined by [RFC3411] and enhanced by the Transport Subsystem
important to understand the terminology of the SNMPv3 architecture in [I-D.ietf-isms-tmsm]. It is also important to understand the
order to understand where the Transport Model described in this terminology of the SNMPv3 architecture in order to understand where
document fits into the architecture and how it interacts with the the Transport Model described in this document fits into the
other architecture subsystems. For a detailed overview of the architecture and how it interacts with the other architecture
documents that describe the current Internet-Standard Management subsystems. For a detailed overview of the documents that describe
Framework, please refer to Section 7 of [RFC3410]. the current Internet-Standard Management Framework, please refer to
Section 7 of [RFC3410].
This document describes a Transport Model that makes use of the This document describes a Transport Model that makes use of the
Datagram Transport Layer Security (DTLS) Protocol [RFC4347], the Datagram Transport Layer Security (DTLS) Protocol [RFC4347], the
datagram variant of the existing and commonly deployed Transport datagram variant of the existing and commonly deployed Transport
Layer Security (TLS) protocol [RFC5246], within a transport subsystem Layer Security (TLS) protocol [RFC5246], within a transport subsystem
[I-D.ietf-isms-tmsm]. The Transport Model in this document is [I-D.ietf-isms-tmsm]. The Transport Model in this document is
referred to as the Datagram Transport Layer Security Transport Model referred to as the Datagram Transport Layer Security Transport Model
(DTLSTM). DTLS takes advantage of the X.509 public keying (DTLSTM). DTLS takes advantage of the X.509 public keying
infrastructure [X509]. This transport model is designed to meet the infrastructure [X509]. This transport model is designed to meet the
security and operational needs of network administrators, operate in security and operational needs of network administrators, operate in
environments where a connectionless (e.g. UDP or SCTP) transport is environments where a connectionless (e.g. UDP or SCTP) transport is
preferred, and integrate well into existing public keying preferred, and integrate well into existing public keying
infrastructures. infrastructures.
This document also specifies a portion of the Management Information
Base (MIB) to define objects for monitoring and managing the DTLS
Transport Model for SNMP.
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58, module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580]. [RFC2580].
This document also specifies a portion of the Management Information
Base (MIB) to define objects for monitoring and managing the DTLS
Transport Model for SNMP.
The diagram shown below gives a conceptual overview of two SNMP The diagram shown below gives a conceptual overview of two SNMP
entities communicating using the DTLS Transport Model. One entity entities communicating using the DTLS Transport Model. One entity
contains a Command Responder and Notification Originator application, contains a Command Responder and Notification Originator application,
and the other a Command Generator and Notification Responder and the other a Command Generator and Notification Responder
application. It should be understood that this particular mix of application. It should be understood that this particular mix of
application types is an example only and other combinations are application types is an example only and other combinations are
equally as legitimate. equally as legitimate.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| Network | | Network |
skipping to change at page 7, line 5 skipping to change at page 7, line 5
| | | | | | | | | | | | | | | |
| v v | | V V | | v v | | V V |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | |
| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | | | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | |
| | application | | applications | | | |application| | application | | | | application | | applications | | | |application| | application | |
| +-------------+ +--------------+ | | +-----------+ +--------------+ | | +-------------+ +--------------+ | | +-----------+ +--------------+ |
| SNMP entity | | SNMP entity | | SNMP entity | | SNMP entity |
+----------------------------------+ +--------------------------------+ +----------------------------------+ +--------------------------------+
1.1. Requirements Terminology 1.1. 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 [RFC2119].
1.2. Conventions
For consistency with SNMP-related specifications, this document For consistency with SNMP-related specifications, this document
favors terminology as defined in STD62 rather than favoring favors terminology as defined in STD62 rather than favoring
terminology that is consistent with non-SNMP specifications. This is terminology that is consistent with non-SNMP specifications. This is
consistent with the IESG decision to not require the SNMPv3 consistent with the IESG decision to not require the SNMPv3
terminology be modified to match the usage of other non-SNMP terminology be modified to match the usage of other non-SNMP
specifications when SNMPv3 was advanced to Full Standard. specifications when SNMPv3 was advanced to Full Standard.
Authentication in this document typically refers to the English Authentication in this document typically refers to the English
meaning of "serving to prove the authenticity of" the message, not meaning of "serving to prove the authenticity of" the message, not
skipping to change at page 7, line 34 skipping to change at page 7, line 28
The terms "manager" and "agent" are not used in this document, The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture [RFC3411], all SNMP entities because in the RFC 3411 architecture [RFC3411], all SNMP entities
have the capability of acting in either manager or agent or in both have the capability of acting in either manager or agent or in both
roles depending on the SNMP application types supported in the roles depending on the SNMP application types supported in the
implementation. Where distinction is required, the application names implementation. Where distinction is required, the application names
of Command Generator, Command Responder, Notification Originator, of Command Generator, Command Responder, Notification Originator,
Notification Receiver, and Proxy Forwarder are used. See "SNMP Notification Receiver, and Proxy Forwarder are used. See "SNMP
Applications" [RFC3413] for further information. Applications" [RFC3413] for further information.
Throughout this document, the terms "client" and "server" are used to Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the SSH transport connection. The client refer to the two ends of the DTLS transport connection. The client
actively opens the SSH connection, and the server passively listens actively opens the DTLS connection, and the server passively listens
for the incoming SSH connection. Either SNMP entity may act as for the incoming DTLS connection. Either SNMP entity may act as
client or as server, as discussed further below. client or as server, as discussed further below.
The User-Based Security Model (USM) [RFC3414] is a mandatory-to- The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
implement Security Model in STD 62. While SSH and USM frequently implement Security Model in STD 62. While DTLS and USM frequently
refer to a user, the terminology preferred in RFC3411 [RFC3411] and refer to a user, the terminology preferred in RFC3411 [RFC3411] and
in this memo is "principal". A principal is the "who" on whose in this memo is "principal". A principal is the "who" on whose
behalf services are provided or processing takes place. A principal behalf services are provided or processing takes place. A principal
can be, among other things, an individual acting in a particular can be, among other things, an individual acting in a particular
role; a set of individuals, with each acting in a particular role; an role; a set of individuals, with each acting in a particular role; an
application or a set of applications, or a combination of these application or a set of applications, or a combination of these
within an administrative domain. within an administrative domain.
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 [RFC2119].
Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the DTLS session. The client actively opens
the DTLS session, and the server passively listens for the incoming
DTLS session. Any SNMP entity may act as a client or as a server.
While security protocols (like DTLS [RFC4347] and USM [RFC3414])
frequently refer to a "user", the terminology preferred in RFC3411
[RFC3411] and in this document is "principal". A principal is the
"who" on whose behalf services are provided or processing takes
place. A principal can be, among other things, an individual acting
in a particular role; a set of individuals, with each acting in a
particular role; an application or a set of applications, or a
combination of these within an administrative domain.
Throughout this document, the term "session" is used to refer to a Throughout this document, the term "session" is used to refer to a
secure association between two DTLS Transport Models that permits the secure association between two DTLS Transport Models that permits the
transmission of one or more SNMP messages within the lifetime of the transmission of one or more SNMP messages within the lifetime of the
session. session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Datagram Transport Layer Security Protocol 2. The Datagram Transport Layer Security Protocol
skipping to change at page 10, line 30 skipping to change at page 10, line 7
2.3. SNMP requirements of DTLS 2.3. SNMP requirements of DTLS
To properly support the SNMP over DTLS Transport Model, the DTLS To properly support the SNMP over DTLS Transport Model, the DTLS
implementation requires the following: implementation requires the following:
o The DTLS Transport Model SHOULD always use authentication of both o The DTLS Transport Model SHOULD always use authentication of both
the server and the client. the server and the client.
o At a minimum the DTLS Transport MUST support authentication of the o At a minimum the DTLS Transport MUST support authentication of the
Command Generator principals to guarantee the authenticity of the Command Generator principals to guarantee the authenticity of the
securityName (a parameter used to pass the authenticated identity securityName.
name from the transport model to security model for even later use
by the access control subsystem).
o The DTLS Transport SHOULD support the message encryption to o The DTLS Transport SHOULD support the message encryption to
protect sensitive data from eavesdropping attacks. protect sensitive data from eavesdropping attacks.
3. How the DTLSTM fits into the Transport Subsystem 3. How the DTLSTM fits into the Transport Subsystem
A transport model is a component of the Transport Subsystem. The A transport model is a component of the Transport Subsystem. The
DTLS Transport Model thus fits between the underlying DTLS transport DTLS Transport Model thus fits between the underlying DTLS transport
layer and the message Dispatcher [RFC3411] component of the SNMP layer and the message dispatcher [RFC3411] component of the SNMP
engine and the Transport Subsystem. engine and the Transport Subsystem.
The DTLS Transport Model will establish a session between itself and The DTLS Transport Model will establish a session between itself and
the DTLS Transport Model of another SNMP engine. The sending the DTLS Transport Model of another SNMP engine. The sending
transport model passes unprotected messages from the dispatcher to transport model passes unprotected messages from the dispatcher to
DTLS to be protected, and the receiving transport model accepts DTLS to be protected, and the receiving transport model accepts
decrypted and authenticated/integrity-checked incoming messages from decrypted and authenticated/integrity-checked incoming messages from
DTLS and passes them to the dispatcher. DTLS and passes them to the dispatcher.
After a DTLS Transport model session is established, SNMP messages After a DTLS Transport model session is established, SNMP messages
skipping to change at page 19, line 40 skipping to change at page 19, line 17
As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit
within a single DTLS datagram. The DTLSTM SHOULD prohibit SNMP within a single DTLS datagram. The DTLSTM SHOULD prohibit SNMP
messages from being sent that exceeds the maximum DTLS message. The messages from being sent that exceeds the maximum DTLS message. The
DTLSTM implementation SHOULD return an error when the DTLS message DTLSTM implementation SHOULD return an error when the DTLS message
size would be exceeded and the message won't be sent. size would be exceeded and the message won't be sent.
4.3. SNMP Services 4.3. SNMP Services
This section describes the services provided by the DTLS Transport This section describes the services provided by the DTLS Transport
Model with their inputs and outputs. The services are between the Model with their inputs and outputs. The services are between the
Transport Model and the Dispatcher. Transport Model and the dispatcher.
The services are described as primitives of an abstract service The services are described as primitives of an abstract service
interface (ASI) and the inputs and outputs are described as abstract interface (ASI) and the inputs and outputs are described as abstract
data elements as they are passed in these abstract service data elements as they are passed in these abstract service
primitives. primitives.
4.3.1. SNMP Services for an Outgoing Message 4.3.1. SNMP Services for an Outgoing Message
The Dispatcher passes the information to the DTLS Transport Model The dispatcher passes the information to the DTLS Transport Model
using the ASI defined in the transport subsystem: using the ASI defined in the transport subsystem:
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
skipping to change at page 20, line 44 skipping to change at page 20, line 20
encapsulation. encapsulation.
outgoingMessageLength: The length of the outgoing message. outgoingMessageLength: The length of the outgoing message.
tmStateReference: A handle/reference to tmSecurityData to be used tmStateReference: A handle/reference to tmSecurityData to be used
when securing outgoing messages. when securing outgoing messages.
4.3.2. SNMP Services for an Incoming Message 4.3.2. SNMP Services for an Incoming Message
The DTLS Transport Model processes the received message from the The DTLS Transport Model processes the received message from the
network using the DTLS service and then passes it to the Dispatcher network using the DTLS service and then passes it to the dispatcher
using the following ASI: using the following ASI:
statusInformation =
receiveMessage( receiveMessage(
IN transportDomain -- origin transport domain IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address IN transportAddress -- origin transport address
IN incomingMessage -- the message received IN incomingMessage -- the message received
IN incomingMessageLength -- its length IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
The abstract data elements passed as parameters in the abstract The abstract data elements passed as parameters in the abstract
service primitives are as follows: service primitives are as follows:
skipping to change at page 28, line 7 skipping to change at page 27, line 26
when stored in the tmStateReference and dtlsSessionID refers when stored in the tmStateReference and dtlsSessionID refers
to the session identifier when stored in the LCD. They MUST to the session identifier when stored in the LCD. They MUST
always be equal when processing a given session's traffic. always be equal when processing a given session's traffic.
2) The wholeMessage and the wholeMessageLength are assigned values 2) The wholeMessage and the wholeMessageLength are assigned values
from the incomingMessage and incomingMessageLength values from from the incomingMessage and incomingMessageLength values from
the DTLS processing. the DTLS processing.
3) The DTLS Transport Model passes the transportDomain, 3) The DTLS Transport Model passes the transportDomain,
transportAddress, wholeMessage, and wholeMessageLength to the transportAddress, wholeMessage, and wholeMessageLength to the
Dispatcher using the receiveMessage ASI: dispatcher using the receiveMessage ASI:
statusInformation = statusInformation =
receiveMessage( receiveMessage(
IN transportDomain -- snmpSSHDomain IN transportDomain -- snmpDTLSUDPDomain or snmpDTLSSCTPDomain
IN transportAddress -- address for the received message IN transportAddress -- address for the received message
IN wholeMessage -- the whole SNMP message from SSH IN wholeMessage -- the whole SNMP message from DTLS
IN wholeMessageLength -- the length of the SNMP message IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- (NEW) transport info IN tmStateReference -- (NEW) transport info
) )
5.2. Procedures for an Outgoing Message 5.2. Procedures for an Outgoing Message
The Dispatcher sends a message to the DTLS Transport Model using the The dispatcher sends a message to the DTLS Transport Model using the
following ASI: following ASI:
statusInformation = statusInformation =
sendMessage( sendMessage(
IN destTransportDomain -- transport domain to be used IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info IN tmStateReference -- (NEW) transport info
) )
skipping to change at page 33, line 27 skipping to change at page 32, line 48
This MIB module is for managing DTLS Transport Model information. This MIB module is for managing DTLS Transport Model information.
6.5.1. MIB Modules Required for IMPORTS 6.5.1. MIB Modules Required for IMPORTS
The following MIB module imports items from SNMPV2-SMI [RFC2578], The following MIB module imports items from SNMPV2-SMI [RFC2578],
SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB
[RFC3413] and SNMP-CONF [RFC2580]. [RFC3413] and SNMP-CONF [RFC2580].
7. MIB Module Definition 7. MIB Module Definition
DTLSTM-MIB DEFINITIONS ::= BEGIN DTLSTM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, snmpModules, snmpDomains,
Counter32, Unsigned32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
snmpTargetParamsEntry
FROM SNMP-TARGET-MIB
;
dtlstmMIB MODULE-IDENTITY IMPORTS
LAST-UPDATED "200807070000Z" MODULE-IDENTITY, OBJECT-TYPE,
ORGANIZATION " " OBJECT-IDENTITY, snmpModules, snmpDomains,
CONTACT-INFO "WG-EMail: Counter32, Unsigned32
Subscribe: FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
snmpTargetParamsEntry
FROM SNMP-TARGET-MIB
;
Chairs: dtlstmMIB MODULE-IDENTITY
Co-editors: LAST-UPDATED "200807070000Z"
" ORGANIZATION " "
CONTACT-INFO "WG-EMail:
Subscribe:
DESCRIPTION "The DTLS Transport Model MIB Chairs:
Co-editors:
"
Copyright (C) The IETF Trust (2008). This DESCRIPTION "The DTLS Transport Model MIB
version of this MIB module is part of RFC XXXX;
see the RFC itself for full legal notices."
-- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
REVISION "200807070000Z" Copyright (C) The IETF Trust (2008). This
DESCRIPTION "The initial version, published in RFC XXXX." version of this MIB module is part of RFC XXXX;
-- NOTE to RFC editor: replace XXXX with actual RFC number see the RFC itself for full legal notices."
-- for this document and remove this note -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
::= { snmpModules xxxx } REVISION "200807070000Z"
-- RFC Ed.: replace xxxx with IANA-assigned number and DESCRIPTION "The initial version, published in RFC XXXX."
-- remove this note -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and remove this note
-- ************************************************ ::= { snmpModules xxxx }
-- subtrees of the SNMP-DTLS-TM-MIB -- RFC Ed.: replace xxxx with IANA-assigned number and
-- ************************************************ -- remove this note
dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 } -- ************************************************
dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 } -- subtrees of the SNMP-DTLS-TM-MIB
dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 } -- ************************************************
-- ************************************************ dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 }
-- Objects dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 }
-- ************************************************ dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 }
-- ************************************************
-- Objects
-- ************************************************
snmpDTLSUDPDomain OBJECT-IDENTITY snmpDTLSUDPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over DTLS transport domain. The corresponding "The SNMP over DTLS transport domain. The corresponding
transport address is of type SnmpDTLSUDPAddress. transport address is of type SnmpDTLSUDPAddress.
When an SNMP entity uses the snmpDTLSUDPDomain transport When an SNMP entity uses the snmpDTLSUDPDomain transport
model, it must be capable of accepting messages up to model, it must be capable of accepting messages up to
the maximum MTU size for an interface it supports, minus the the maximum MTU size for an interface it supports, minus the
needed IP, UDP, DTLS and other protocol overheads. needed IP, UDP, DTLS and other protocol overheads.
The securityName prefix to be associated with the The securityName prefix to be associated with the
snmpDTLSUDPDomain is 'dudp'. This prefix may be used by snmpDTLSUDPDomain is 'dudp'. This prefix may be used by
security models or other components to identify what secure security models or other components to identify what secure
transport infrastructure authenticated a securityName." transport infrastructure authenticated a securityName."
::= { snmpDomains yy } ::= { snmpDomains yy }
-- RFC Ed.: replace yy with IANA-assigned number and -- RFC Ed.: replace yy with IANA-assigned number and
-- remove this note -- remove this note
-- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string -- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string
-- if 'dtls' is not assigned to this document. -- if 'dtls' is not assigned to this document.
snmpDTLSSCTPDomain OBJECT-IDENTITY snmpDTLSSCTPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over DTLS transport domain. The corresponding "The SNMP over DTLS transport domain. The corresponding
transport address is of type SnmpDTLSSCTPAddress. transport address is of type SnmpDTLSSCTPAddress.
When an SNMP entity uses the snmpDTLSSCTPDomain transport When an SNMP entity uses the snmpDTLSSCTPDomain transport
model, it must be capable of accepting messages up to model, it must be capable of accepting messages up to
the maximum MTU size for an interface it supports, minus the the maximum MTU size for an interface it supports, minus the
needed IP, SCTP, DTLS and other protocol overheads. needed IP, SCTP, DTLS and other protocol overheads.
The securityName prefix to be associated with the The securityName prefix to be associated with the
snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by
security models or other components to identify what secure security models or other components to identify what secure
transport infrastructure authenticated a securityName." transport infrastructure authenticated a securityName."
::= { snmpDomains zz } ::= { snmpDomains zz }
-- RFC Ed.: replace zz with IANA-assigned number and -- RFC Ed.: replace zz with IANA-assigned number and
-- remove this note -- remove this note
-- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string -- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string
-- if 'dtls' is not assigned to this document. -- if 'dtls' is not assigned to this document.
SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a" DISPLAY-HINT "1a"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a UDP connection address for an IPv4 address, an "Represents a UDP connection address for an IPv4 address, an
IPv6 address or an ASCII encoded host name and port number. IPv6 address or an ASCII encoded host name and port number.
The hostname must be encoded in ASCII, as specified in RFC3490 The hostname must be encoded in ASCII, as specified in RFC3490
(Internationalizing Domain Names in Applications) followed by (Internationalizing Domain Names in Applications) followed by
a colon ':' (ASCII character 0x3A) and a decimal port number a colon ':' (ASCII character 0x3A) and a decimal port number
in ASCII. The name SHOULD be fully qualified whenever in ASCII. The name SHOULD be fully qualified whenever
possible. possible.
An IPv4 address must be a dotted decimal format followed by a An IPv4 address must be a dotted decimal format followed by a
colon ':' (ASCII character 0x3A) and a decimal port number in colon ':' (ASCII character 0x3A) and a decimal port number in
ASCII. ASCII.
An IPv6 address must be a colon separated format, surrounded An IPv6 address must be a colon separated format, surrounded
by square brackets (ASCII characters 0x5B and 0x5D), followed by square brackets (ASCII characters 0x5B and 0x5D), followed
by a colon ':' (ASCII character 0x3A) and a decimal port by a colon ':' (ASCII character 0x3A) and a decimal port
number in ASCII. number in ASCII.
Values of this textual convention may not be directly usable Values of this textual convention may not be directly usable
as transport-layer addressing information, and may require as transport-layer addressing information, and may require
run-time resolution. As such, applications that write them run-time resolution. As such, applications that write them
must be prepared for handling errors if such values are not must be prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the supported, or cannot be resolved (if resolution occurs at the
time of the management operation). time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may The DESCRIPTION clause of TransportAddress objects that may
have snmpDTLSUDPAddress values must fully describe how (and have snmpDTLSUDPAddress values must fully describe how (and
when) such names are to be resolved to IP addresses and vice when) such names are to be resolved to IP addresses and vice
versa. versa.
This textual convention SHOULD NOT be used directly in object This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific definitions since it restricts addresses to a specific
format. However, if it is used, it MAY be used either on its format. However, if it is used, it MAY be used either on its
own or in conjunction with TransportAddressType or own or in conjunction with TransportAddressType or
TransportDomain as a pair. TransportDomain as a pair.
When this textual convention is used as a syntax of an index When this textual convention is used as a syntax of an index
object, there may be issues with the limit of 128 object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED
that all MIB documents using this textual convention make that all MIB documents using this textual convention make
explicit any limitations on index component lengths that explicit any limitations on index component lengths that
management software must observe. This may be done either by management software must observe. This may be done either by
including SIZE constraints on the index components or by including SIZE constraints on the index components or by
specifying applicable constraints in the conceptual row specifying applicable constraints in the conceptual row
DESCRIPTION clause or in the surrounding documentation." DESCRIPTION clause or in the surrounding documentation."
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a" DISPLAY-HINT "1a"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a SCTP connection address for an IPv4 address, an "Represents a SCTP connection address for an IPv4 address, an
IPv6 address or an ASCII encoded host name and port number. IPv6 address or an ASCII encoded host name and port number.
The hostname must be encoded in ASCII, as specified in RFC3490 The hostname must be encoded in ASCII, as specified in RFC3490
(Internationalizing Domain Names in Applications) followed by (Internationalizing Domain Names in Applications) followed by
a colon ':' (ASCII character 0x3A) and a decimal port number a colon ':' (ASCII character 0x3A) and a decimal port number
in ASCII. The name SHOULD be fully qualified whenever in ASCII. The name SHOULD be fully qualified whenever
possible. possible.
An IPv4 address must be a dotted decimal format followed by a An IPv4 address must be a dotted decimal format followed by a
colon ':' (ASCII character 0x3A) and a decimal port number in colon ':' (ASCII character 0x3A) and a decimal port number in
ASCII. ASCII.
An IPv6 address must be a colon separated format, surrounded An IPv6 address must be a colon separated format, surrounded
by square brackets (ASCII characters 0x5B and 0x5D), followed by square brackets (ASCII characters 0x5B and 0x5D), followed
by a colon ':' (ASCII character 0x3A) and a decimal port by a colon ':' (ASCII character 0x3A) and a decimal port
number in ASCII. number in ASCII.
Values of this textual convention may not be directly usable Values of this textual convention may not be directly usable
as transport-layer addressing information, and may require as transport-layer addressing information, and may require
run-time resolution. As such, applications that write them run-time resolution. As such, applications that write them
must be prepared for handling errors if such values are not must be prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the supported, or cannot be resolved (if resolution occurs at the
time of the management operation). time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may The DESCRIPTION clause of TransportAddress objects that may
have snmpDTLSSCTPAddress values must fully describe how (and have snmpDTLSSCTPAddress values must fully describe how (and
when) such names are to be resolved to IP addresses and vice when) such names are to be resolved to IP addresses and vice
versa. versa.
This textual convention SHOULD NOT be used directly in object This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific definitions since it restricts addresses to a specific
format. However, if it is used, it MAY be used either on its format. However, if it is used, it MAY be used either on its
own or in conjunction with TransportAddressType or own or in conjunction with TransportAddressType or
TransportDomain as a pair. TransportDomain as a pair.
When this textual convention is used as a syntax of an index When this textual convention is used as a syntax of an index
object, there may be issues with the limit of 128 object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED
that all MIB documents using this textual convention make that all MIB documents using this textual convention make
explicit any limitations on index component lengths that explicit any limitations on index component lengths that
management software must observe. This may be done either by management software must observe. This may be done either by
including SIZE constraints on the index components or by including SIZE constraints on the index components or by
specifying applicable constraints in the conceptual row specifying applicable constraints in the conceptual row
DESCRIPTION clause or in the surrounding documentation." DESCRIPTION clause or in the surrounding documentation."
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
X509IdentifierHashType ::= TEXTUAL-CONVENTION X509IdentifierHashType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies a hashing algorithm type that will be used for "Identifies a hashing algorithm type that will be used for
identifying an X.509 certificate. identifying an X.509 certificate.
The md5(1) value SHOULD NOT be used." The md5(1) value SHOULD NOT be used."
SYNTAX INTEGER { md5(1), sha1(2), sha256(3) } SYNTAX INTEGER { md5(1), sha1(2), sha256(3) }
X509IdentifierHash ::= TEXTUAL-CONVENTION X509IdentifierHash ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A hash value that uniquely identifies a certificate within a "A hash value that uniquely identifies a certificate within a
systems local certificate store. The length of the value systems local certificate store. The length of the value
stored in an object of type X509IdentifierHash is dependent on stored in an object of type X509IdentifierHash is dependent on
the hashing algorithm that produced the hash. the hashing algorithm that produced the hash.
MIB structures making use of this textual convention should MIB structures making use of this textual convention should
have an accompanying object of type X509IdentifierHashType. have an accompanying object of type X509IdentifierHashType.
" "
SYNTAX OCTET STRING SYNTAX OCTET STRING
-- The dtlstmSession Group -- The dtlstmSession Group
dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 } dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 }
dtlstmSessionOpens OBJECT-TYPE dtlstmSessionOpens OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an openSession() request has been "The number of times an openSession() request has been
executed as an SSH client, whether it succeeded or failed." executed as an DTLS client, whether it succeeded or failed."
::= { dtlstmSession 1 } ::= { dtlstmSession 1 }
dtlstmSessionCloses OBJECT-TYPE dtlstmSessionCloses OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times a closeSession() request has been "The number of times a closeSession() request has been
executed as an SSH client, whether it succeeded or failed." executed as an DTLS client, whether it succeeded or failed."
::= { dtlstmSession 2 } ::= { dtlstmSession 2 }
dtlstmSessionOpenErrors OBJECT-TYPE dtlstmSessionOpenErrors OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an openSession() request failed to open a "The number of times an openSession() request failed to open a
session as a SSH client, for any reason." session as a DTLS client, for any reason."
::= { dtlstmSession 3 } ::= { dtlstmSession 3 }
dtlstmSessionNoAvailableSessions OBJECT-TYPE dtlstmSessionNoAvailableSessions OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an outgoing message was dropped because "The number of times an outgoing message was dropped because
the session associated with the passed tmStateReference was no the session associated with the passed tmStateReference was no
longer (or was never) available." longer (or was never) available."
::= { dtlstmSession 4 } ::= { dtlstmSession 4 }
dtlstmSessionInvalidClientCertificates OBJECT-TYPE dtlstmSessionInvalidClientCertificates OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an incoming session was not established "The number of times an incoming session was not established
on an SSH server because the presented client certificate was on an DTLS server because the presented client certificate was
invalid. Reasons for invalidation includes, but is not invalid. Reasons for invalidation includes, but is not
limited to, crypographic validation failures and lack of a limited to, cryptographic validation failures and lack of a
suitable mapping row in the dtlstmCertificateToSNTable." suitable mapping row in the dtlstmCertificateToSNTable."
::= { dtlstmSession 5 } ::= { dtlstmSession 5 }
dtlstmSessionInvalidServerCertificates OBJECT-TYPE dtlstmSessionInvalidServerCertificates OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times an outgoing session was not established "The number of times an outgoing session was not established
on an SSH client because the presented server certificate was on an DTLS client because the presented server certificate was
invalid. Reasons for invalidation includes, but is not invalid. Reasons for invalidation includes, but is not
limited to, crypographic validation failures and an unexpected limited to, cryptographic validation failures and an unexpected
presented certificate identity." presented certificate identity."
::= { dtlstmSession 6 } ::= { dtlstmSession 6 }
dtlstmDTLSProtectionErrors OBJECT-TYPE dtlstmDTLSProtectionErrors OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The number of times DTLS processing resulted in a message "The number of times DTLS processing resulted in a message
being discarded because it failed its integrity test, being discarded because it failed its integrity test,
decryption processing or other DTLS processing." decryption processing or other DTLS processing."
::= { dtlstmSession 7 } ::= { dtlstmSession 7 }
-- Configuration Objects -- Configuration Objects
dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 } dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 }
-- Certificate mapping -- Certificate mapping
dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 } dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 }
dtlstmCertificateToSNCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the number of entries in the
dtlstmCertificateToSNTable"
::= { dtlstmCertificateMapping 1 }
dtlstmCertificateToSNTableLastChanged OBJECT-TYPE dtlstmCertificateToSNCount OBJECT-TYPE
SYNTAX TimeStamp SYNTAX Unsigned32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of sysUpTime.0 when the dtlstmCertificateToSNTable "A count of the number of entries in the
was last modified through any means, or 0 if it has not been dtlstmCertificateToSNTable"
modified since the command responder was started." ::= { dtlstmCertificateMapping 1 }
::= { dtlstmCertificateMapping 2 }
dtlstmCertificateToSNTable OBJECT-TYPE dtlstmCertificateToSNTableLastChanged OBJECT-TYPE
SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry SYNTAX TimeStamp
MAX-ACCESS not-accessible MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table listing the X.509 certificates known to the entity "The value of sysUpTime.0 when the dtlstmCertificateToSNTable
and the associated method for determining the SNMPv3 security was last modified through any means, or 0 if it has not been
name from a certificate. modified since the command responder was started."
::= { dtlstmCertificateMapping 2 }
On an incoming DTLS/SNMP connection the client's presented dtlstmCertificateToSNTable OBJECT-TYPE
certificate should be examined and validated based on an SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry
established trusted CA certificate or self-signed public MAX-ACCESS not-accessible
certificate. This table does not provide a mechanism for STATUS current
uploading the certificates as that is expected to occur DESCRIPTION
through an out-of-band transfer. "A table listing the X.509 certificates known to the entity
and the associated method for determining the SNMPv3 security
name from a certificate.
Once the authenticity of the certificate has been verified, On an incoming DTLS/SNMP connection the client's presented
this table can be consulted to determine the appropriate certificate should be examined and validated based on an
securityName to identify the remote connection. This is done established trusted CA certificate or self-signed public
by comparing the issuer's fingerprint hash type and value and certificate. This table does not provide a mechanism for
the certificate's fingerprint hash type and value against the uploading the certificates as that is expected to occur
dtlstmCertHashType and dtlstmCertHashValue values in each through an out-of-band transfer.
entry of this table. If a matching entry is found then the
securityName is selected based on the dtlstmCertMapType,
dtlstmCertHashType, dtlstmCertHashValue and
dtlstmCertSecurityName fields and the resulting securityName
is used to identify the other side of the DTLS connection.
This table should be treated as an ordered list of mapping Once the authenticity of the certificate has been verified,
rules to check. The first mapping rule appropriately matching this table can be consulted to determine the appropriate
a certificate in the local certificate store with a securityName to identify the remote connection. This is done
corresponding hash type (dtlstmCertHashType) and hash value by comparing the issuer's fingerprint hash type and value and
(dtlstmCertHashValue) will be used to perform the mapping from the certificate's fingerprint hash type and value against the
X.509 certificate values to a securityName. If, after a dtlstmCertHashType and dtlstmCertHashValue values in each
matching row is found but the mapping can not succeed for some entry of this table. If a matching entry is found then the
other reason then further attempts to perform the mapping MUST securityName is selected based on the dtlstmCertMapType,
NOT be taken. For example, if the entry being checked dtlstmCertHashType, dtlstmCertHashValue and
contains a dtlstmCertMapType of bySubjectAltName(2) and an dtlstmCertSecurityName fields and the resulting securityName
incoming connection uses a certificate with an issuer is used to identify the other side of the DTLS connection.
certificate matching the dtlstmCertHashType and
dtlstmCertHashValue fields but the connecting certificate does
not contain a subjectAltName field then the lookup operation
must be treated as a failure. No further rows are examined for
other potential mappings.
Missing values of dtlstmCertID are acceptable and This table should be treated as an ordered list of mapping
implementations should treat missing entries as a failed match rules to check. The first mapping rule appropriately matching
and should continue to the next highest numbered row. E.G., a certificate in the local certificate store with a
the table may legally contain only two rows with dtlstmCertID corresponding hash type (dtlstmCertHashType) and hash value
values of 10 and 20. (dtlstmCertHashValue) will be used to perform the mapping from
X.509 certificate values to a securityName. If, after a
matching row is found but the mapping can not succeed for some
other reason then further attempts to perform the mapping MUST
NOT be taken. For example, if the entry being checked
contains a dtlstmCertMapType of bySubjectAltName(2) and an
incoming connection uses a certificate with an issuer
certificate matching the dtlstmCertHashType and
dtlstmCertHashValue fields but the connecting certificate does
not contain a subjectAltName field then the lookup operation
must be treated as a failure. No further rows are examined for
other potential mappings.
Users are encouraged to make use of certificates with Missing values of dtlstmCertID are acceptable and
subjectAltName fields that can be used as securityNames so implementations should treat missing entries as a failed match
that a single root CA certificate can allow all child and should continue to the next highest numbered row. E.G.,
certificate's subjectAltName to map directly to a securityName the table may legally contain only two rows with dtlstmCertID
via a 1:1 transformation. However, this table is flexible values of 10 and 20.
enough to allow for situations where existing deployed
certificate infrastructures do not provide adequate
subjectAltName values for use as SNMPv3 securityNames.
Certificates may also be mapped to securityNames using the
CommonName portion of the Subject field which is also a
scalable method of mapping certificate components to
securityNames. Finally, direct mapping from each individual
certificate fingerprint to a securityName is possible but
requires one entry in the table per securityName."
::= { dtlstmCertificateMapping 3 }
dtlstmCertificateToSNEntry OBJECT-TYPE Users are encouraged to make use of certificates with
SYNTAX DtlstmCertificateToSNEntry subjectAltName fields that can be used as securityNames so
MAX-ACCESS not-accessible that a single root CA certificate can allow all child
STATUS current certificate's subjectAltName to map directly to a securityName
DESCRIPTION via a 1:1 transformation. However, this table is flexible
"A row in the dtlstmCertificateToSNTable that specifies a enough to allow for situations where existing deployed
mapping for an incoming DTLS certificate to a securityName to certificate infrastructures do not provide adequate
use for the connection." subjectAltName values for use as SNMPv3 securityNames.
INDEX { dtlstmCertID } Certificates may also be mapped to securityNames using the
::= { dtlstmCertificateToSNTable 1 } CommonName portion of the Subject field which is also a
scalable method of mapping certificate components to
securityNames. Finally, direct mapping from each individual
certificate fingerprint to a securityName is possible but
requires one entry in the table per securityName."
::= { dtlstmCertificateMapping 3 }
DtlstmCertificateToSNEntry ::= SEQUENCE { dtlstmCertificateToSNEntry OBJECT-TYPE
dtlstmCertID Unsigned32, SYNTAX DtlstmCertificateToSNEntry
dtlstmCertHashType X509IdentifierHashType, MAX-ACCESS not-accessible
dtlstmCertHashValue X509IdentifierHash, STATUS current
dtlstmCertMapType INTEGER, DESCRIPTION
dtlstmCertSecurityName SnmpAdminString, "A row in the dtlstmCertificateToSNTable that specifies a
dtlstmCertStorageType StorageType, mapping for an incoming DTLS certificate to a securityName to
dtlstmCertRowStatus RowStatus use for the connection."
} INDEX { dtlstmCertID }
::= { dtlstmCertificateToSNTable 1 }
dtlstmCertID OBJECT-TYPE DtlstmCertificateToSNEntry ::= SEQUENCE {
SYNTAX Unsigned32 dtlstmCertID Unsigned32,
MAX-ACCESS not-accessible dtlstmCertHashType X509IdentifierHashType,
STATUS current dtlstmCertHashValue X509IdentifierHash,
DESCRIPTION dtlstmCertMapType INTEGER,
"A unique arbitrary number index for a given certificate dtlstmCertSecurityName SnmpAdminString,
entry." dtlstmCertStorageType StorageType,
::= { dtlstmCertificateToSNEntry 1 } dtlstmCertRowStatus RowStatus
}
dtlstmCertHashType OBJECT-TYPE dtlstmCertID OBJECT-TYPE
SYNTAX X509IdentifierHashType SYNTAX Unsigned32
MAX-ACCESS read-create MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The hash algorithm to use when applying a hash to a X.509 "A unique arbitrary number index for a given certificate
certificate for purposes of referring to it from the entry."
dtlstmCertHashValue column. ::= { dtlstmCertificateToSNEntry 1 }
The md5(1) value SHOULD NOT be used." dtlstmCertHashType OBJECT-TYPE
DEFVAL { sha256 } SYNTAX X509IdentifierHashType
::= { dtlstmCertificateToSNEntry 2 } MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The hash algorithm to use when applying a hash to a X.509
certificate for purposes of referring to it from the
dtlstmCertHashValue column.
dtlstmCertHashValue OBJECT-TYPE The md5(1) value SHOULD NOT be used."
SYNTAX X509IdentifierHash DEFVAL { sha256 }
MAX-ACCESS read-create ::= { dtlstmCertificateToSNEntry 2 }
STATUS current
DESCRIPTION
"A cryptographic hash of a X.509 certificate. The use of this
hash is dictated by the dtlstmCertMapType column.
"
::= { dtlstmCertificateToSNEntry 3 }
dtlstmCertMapType OBJECT-TYPE dtlstmCertHashValue OBJECT-TYPE
SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) } SYNTAX X509IdentifierHash
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The mapping type used to obtain the securityName from the "A cryptographic hash of a X.509 certificate. The use of this
certificate. The possible values of use and their usage hash is dictated by the dtlstmCertMapType column.
methods are defined as follows: "
::= { dtlstmCertificateToSNEntry 3 }
specified(1): The securityName that should be used locally to dtlstmCertMapType OBJECT-TYPE
identify the remote entity is directly specified SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) }
in the dtlstmCertSecurityName column from this MAX-ACCESS read-create
table. The dtlstmCertHashValue MUST refer to a STATUS current
X.509 client certificate that will be mapped DESCRIPTION
directly to the securityName specified in the "The mapping type used to obtain the securityName from the
dtlstmCertSecurityName column. certificate. The possible values of use and their usage
methods are defined as follows:
bySubjectAltName(2): specified(1): The securityName that should be used locally to
The securityName that should be used locally to identify the remote entity is directly specified
identify the remote entity should be taken from in the dtlstmCertSecurityName column from this
the subjectAltName portion of the X.509 table. The dtlstmCertHashValue MUST refer to a
certificate. The dtlstmCertHashValue MUST refer X.509 client certificate that will be mapped
to a trust anchor certificate that is directly to the securityName specified in the
responsible for issuing certificates with dtlstmCertSecurityName column.
carefully controlled subjectAltName fields.
byCN(3): The securityName that should be used locally to bySubjectAltName(2):
identify the remote entity should be taken from The securityName that should be used locally to
the CommonName portion of the Subject field from identify the remote entity should be taken from
the X.509 certificate. The dtlstmCertHashValue the subjectAltName portion of the X.509
MUST refer to a trust anchor certificate that is certificate. The dtlstmCertHashValue MUST refer
responsible for issuing certificates with to a trust anchor certificate that is
carefully controlled CommonName fields." responsible for issuing certificates with
DEFVAL { specified } carefully controlled subjectAltName fields.
::= { dtlstmCertificateToSNEntry 4 }
dtlstmCertSecurityName OBJECT-TYPE byCN(3): The securityName that should be used locally to
SYNTAX SnmpAdminString (SIZE(0..32)) identify the remote entity should be taken from
MAX-ACCESS read-create the CommonName portion of the Subject field from
STATUS current the X.509 certificate. The dtlstmCertHashValue
DESCRIPTION MUST refer to a trust anchor certificate that is
"The securityName that the session should use if the responsible for issuing certificates with
dtlstmCertMapType is set to specified(1), otherwise the value carefully controlled CommonName fields."
in this column should be ignored. If dtlstmCertMapType is set
to specifed(1) and this column contains a zero-length string
(which is not a legal securityName value) this row is
effectively disabled and the match will not be considered
successful."
DEFVAL { "" }
::= { dtlstmCertificateToSNEntry 5 }
dtlstmCertStorageType OBJECT-TYPE DEFVAL { specified }
SYNTAX StorageType ::= { dtlstmCertificateToSNEntry 4 }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row. Conceptual rows
having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { dtlstmCertificateToSNEntry 6 }
dtlstmCertRowStatus OBJECT-TYPE dtlstmCertSecurityName OBJECT-TYPE
SYNTAX RowStatus SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this conceptual row. This object may be used "The securityName that the session should use if the
to create or remove rows from this table. dtlstmCertMapType is set to specified(1), otherwise the value
in this column should be ignored. If dtlstmCertMapType is set
to specifed(1) and this column contains a zero-length string
(which is not a legal securityName value) this row is
effectively disabled and the match will not be considered
successful."
DEFVAL { "" }
::= { dtlstmCertificateToSNEntry 5 }
The value of this object has no effect on whether dtlstmCertStorageType OBJECT-TYPE
other objects in this conceptual row can be modified." SYNTAX StorageType
::= { dtlstmCertificateToSNEntry 7 } MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row. Conceptual rows
having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { dtlstmCertificateToSNEntry 6 }
-- Maps securityNames to certificates for use by the SNMP-TARGET-MIB dtlstmCertRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row. This object may be used
to create or remove rows from this table.
dtlstmParamsCount OBJECT-TYPE The value of this object has no effect on whether
SYNTAX Unsigned32 other objects in this conceptual row can be modified."
MAX-ACCESS read-only ::= { dtlstmCertificateToSNEntry 7 }
STATUS current
DESCRIPTION
"A count of the number of entries in the
dtlstmParamsTable"
::= { dtlstmCertificateMapping 4 }
dtlstmParamsTableLastChanged OBJECT-TYPE -- Maps securityNames to certificates for use by the SNMP-TARGET-MIB
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime.0 when the dtlstmParamsTable
was last modified through any means, or 0 if it has not been
modified since the command responder was started."
::= { dtlstmCertificateMapping 5 }
dtlstmParamsTable OBJECT-TYPE dtlstmParamsCount OBJECT-TYPE
SYNTAX SEQUENCE OF DtlstmParamsEntry SYNTAX Unsigned32
MAX-ACCESS not-accessible MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table augments the SNMP-TARGET-MIB's "A count of the number of entries in the
snmpTargetParamsTable with additional a DTLS client-side dtlstmParamsTable"
certificate certificate identifier to use when establishing ::= { dtlstmCertificateMapping 4 }
new DTLS connections."
::= { dtlstmCertificateMapping 6 }
dtlstmParamsEntry OBJECT-TYPE dtlstmParamsTableLastChanged OBJECT-TYPE
SYNTAX DtlstmParamsEntry SYNTAX TimeStamp
MAX-ACCESS not-accessible MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A conceptual row containing a locally held certificate's hash "The value of sysUpTime.0 when the dtlstmParamsTable
type and hash value for a given snmpTargetParamsEntry. The was last modified through any means, or 0 if it has not been
values in this row should be ignored if not the connection modified since the command responder was started."
that needs to be established, as indicated by the ::= { dtlstmCertificateMapping 5 }
SNMP-TARGET-MIB infrastructure, is not a DTLS based
connection."
AUGMENTS { snmpTargetParamsEntry }
::= { dtlstmParamsTable 1 }
DtlstmParamsEntry ::= SEQUENCE { dtlstmParamsTable OBJECT-TYPE
dtlstmParamsHashType X509IdentifierHashType, SYNTAX SEQUENCE OF DtlstmParamsEntry
dtlstmParamsHashValue X509IdentifierHash, MAX-ACCESS not-accessible
dtlstmParamsStorageType StorageType, STATUS current
dtlstmParamsRowStatus RowStatus DESCRIPTION
} "This table augments the SNMP-TARGET-MIB's
snmpTargetParamsTable with an additional DTLS client-side
certificate certificate identifier to use when establishing
new DTLS connections."
::= { dtlstmCertificateMapping 6 }
dtlstmParamsHashType OBJECT-TYPE dtlstmParamsEntry OBJECT-TYPE
SYNTAX X509IdentifierHashType SYNTAX DtlstmParamsEntry
MAX-ACCESS read-create MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The hash algorithm type for the hash stored in the "A conceptual row containing a locally held certificate's hash
dtlstmParamsHash column to identify a locally-held X.509 type and hash value for a given snmpTargetParamsEntry. The
certificate that should be used when initiating a DTLS values in this row should be ignored if the connection
connection as a DTLS client." that needs to be established, as indicated by the
DEFVAL { sha256 } SNMP-TARGET-MIB infrastructure, is not a DTLS based
::= { dtlstmParamsEntry 1 } connection."
AUGMENTS { snmpTargetParamsEntry }
::= { dtlstmParamsTable 1 }
dtlstmParamsHashValue OBJECT-TYPE DtlstmParamsEntry ::= SEQUENCE {
SYNTAX X509IdentifierHash dtlstmParamsHashType X509IdentifierHashType,
MAX-ACCESS read-create dtlstmParamsHashValue X509IdentifierHash,
STATUS current dtlstmParamsStorageType StorageType,
DESCRIPTION dtlstmParamsRowStatus RowStatus
"A cryptographic hash of a X.509 certificate. This object }
should store the hash of a locally held X.509 certificate that
should be used when initiating a DTLS connection as a DTLS
client."
::= { dtlstmParamsEntry 2 } dtlstmParamsHashType OBJECT-TYPE
SYNTAX X509IdentifierHashType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The hash algorithm type for the hash stored in the
dtlstmParamsHash column to identify a locally-held X.509
certificate that should be used when initiating a DTLS
connection as a DTLS client."
DEFVAL { sha256 }
::= { dtlstmParamsEntry 1 }
dtlstmParamsStorageType OBJECT-TYPE dtlstmParamsHashValue OBJECT-TYPE
SYNTAX StorageType SYNTAX X509IdentifierHash
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The storage type for this conceptual row. Conceptual rows "A cryptographic hash of a X.509 certificate. This object
having the value 'permanent' need not allow write-access to should store the hash of a locally held X.509 certificate that
any columnar objects in the row." should be used when initiating a DTLS connection as a DTLS
DEFVAL { nonVolatile } client."
::= { dtlstmParamsEntry 3 } ::= { dtlstmParamsEntry 2 }
dtlstmParamsRowStatus OBJECT-TYPE dtlstmParamsStorageType OBJECT-TYPE
SYNTAX RowStatus SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The status of this conceptual row. This object may be used "The storage type for this conceptual row. Conceptual rows
to create or remove rows from this table. having the value 'permanent' need not allow write-access to
any columnar objects in the row."
DEFVAL { nonVolatile }
::= { dtlstmParamsEntry 3 }
The value of this object has no effect on whether dtlstmParamsRowStatus OBJECT-TYPE
other objects in this conceptual row can be modified." SYNTAX RowStatus
::= { dtlstmParamsEntry 4 } MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row. This object may be used
to create or remove rows from this table.
-- ************************************************ The value of this object has no effect on whether
-- dtlstmMIB - Conformance Information other objects in this conceptual row can be modified."
-- ************************************************ ::= { dtlstmParamsEntry 4 }
dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 } -- ************************************************
-- dtlstmMIB - Conformance Information
-- ************************************************
dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 } dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 }
-- ************************************************ dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 }
-- Compliance statements
-- ************************************************
dtlstmCompliance MODULE-COMPLIANCE -- ************************************************
STATUS current -- Compliance statements
DESCRIPTION -- ************************************************
"The compliance statement for SNMP engines that support the
SNMP-DTLS-TM-MIB"
MODULE
MANDATORY-GROUPS { dtlstmStatsGroup,
dtlstmIncomingGroup, dtlstmOutgoingGroup }
::= { dtlstmCompliances 1 } dtlstmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines that support the
SNMP-DTLS-TM-MIB"
MODULE
MANDATORY-GROUPS { dtlstmStatsGroup,
dtlstmIncomingGroup, dtlstmOutgoingGroup }
::= { dtlstmCompliances 1 }
-- ************************************************ -- ************************************************
-- Units of conformance -- Units of conformance
-- ************************************************ -- ************************************************
dtlstmStatsGroup OBJECT-GROUP dtlstmStatsGroup OBJECT-GROUP
OBJECTS { OBJECTS {
dtlstmSessionOpens, dtlstmSessionOpens,
dtlstmSessionCloses, dtlstmSessionCloses,
dtlstmSessionOpenErrors, dtlstmSessionOpenErrors,
dtlstmSessionNoAvailableSessions, dtlstmSessionNoAvailableSessions,
dtlstmSessionInvalidClientCertificates, dtlstmSessionInvalidClientCertificates,
dtlstmSessionInvalidServerCertificates, dtlstmSessionInvalidServerCertificates,
dtlstmDTLSProtectionErrors dtlstmDTLSProtectionErrors
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects for maintaining "A collection of objects for maintaining
statistical information of an SNMP engine which statistical information of an SNMP engine which
implements the SNMP DTLS Transport Model." implements the SNMP DTLS Transport Model."
::= { dtlstmGroups 1 } ::= { dtlstmGroups 1 }
dtlstmIncomingGroup OBJECT-GROUP dtlstmIncomingGroup OBJECT-GROUP
OBJECTS { OBJECTS {
dtlstmCertificateToSNCount, dtlstmCertificateToSNCount,
dtlstmCertificateToSNTableLastChanged, dtlstmCertificateToSNTableLastChanged,
dtlstmCertHashType, dtlstmCertHashType,
dtlstmCertHashValue, dtlstmCertHashValue,
dtlstmCertMapType, dtlstmCertMapType,
dtlstmCertSecurityName, dtlstmCertSecurityName,
dtlstmCertStorageType, dtlstmCertStorageType,
dtlstmCertRowStatus dtlstmCertRowStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects for maintaining "A collection of objects for maintaining
incoming connection certificate mappings to incoming connection certificate mappings to
securityNames of an SNMP engine which implements the securityNames of an SNMP engine which implements the
SNMP DTLS Transport Model." SNMP DTLS Transport Model."
::= { dtlstmGroups 2 } ::= { dtlstmGroups 2 }
dtlstmOutgoingGroup OBJECT-GROUP dtlstmOutgoingGroup OBJECT-GROUP
OBJECTS { OBJECTS {
dtlstmParamsCount, dtlstmParamsCount,
dtlstmParamsTableLastChanged, dtlstmParamsTableLastChanged,
dtlstmParamsHashType, dtlstmParamsHashType,
dtlstmParamsHashValue, dtlstmParamsHashValue,
dtlstmParamsStorageType, dtlstmParamsStorageType,
dtlstmParamsRowStatus dtlstmParamsRowStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects for maintaining "A collection of objects for maintaining
outgoing connection certificates to use when opening outgoing connection certificates to use when opening
connections as a result of SNMP-TARGET-MIB settings." connections as a result of SNMP-TARGET-MIB settings."
::= { dtlstmGroups 3 } ::= { dtlstmGroups 3 }
END END
8. Operational Considerations 8. Operational Considerations
This section discusses various operational aspects of the solution This section discusses various operational aspects of the solution
8.1. Sessions 8.1. Sessions
A session is discussed throughout this document as meaning a security A session is discussed throughout this document as meaning a security
association between the DTLS client and the DTLS server. State association between the DTLS client and the DTLS server. State
information for the sessions are maintained in each DTLSTM and this information for the sessions are maintained in each DTLSTM and this
skipping to change at page 48, line 43 skipping to change at page 48, line 16
To simplify session management it is RECOMMENDED that implementations To simplify session management it is RECOMMENDED that implementations
utilize two separate ports, one for Notification sessions and one for utilize two separate ports, one for Notification sessions and one for
Command sessions. If this implementation recommendation is followed, Command sessions. If this implementation recommendation is followed,
DTLS clients will always send REQUEST messages and DTLS servers will DTLS clients will always send REQUEST messages and DTLS servers will
always send RESPONSE messages. With this assertion, implementations always send RESPONSE messages. With this assertion, implementations
may be able to simplify "broken" session handling, session may be able to simplify "broken" session handling, session
resumption, and other aspects of session management such as resumption, and other aspects of session management such as
guaranteeing that Request- Response pairs use the same session. guaranteeing that Request- Response pairs use the same session.
Depending on the algorithms used for generation of the master session Implementations SHOULD limit the lifetime of established sessions
depending on the algorithms used for generation of the master session
secret, the privacy and integrity algorithms used to protect secret, the privacy and integrity algorithms used to protect
messages, the environment of the session, the amount of data messages, the environment of the session, the amount of data
transferred, and the sensitivity of the data, a time-to-live (TTL) transferred, and the sensitivity of the data.
value SHOULD be established for sessions. An upper limit of 24 hours
is suggested for this TTL value. The TTL value could be stored in
the LCD and checked before passing a message to the DTLS session.
8.2. Notification Receiver Credential Selection 8.2. Notification Receiver Credential Selection
When an SNMP engine needs to establish an outgoing session for When an SNMP engine needs to establish an outgoing session for
notifications, the snmpTargetParamsTable includes an entry for the notifications, the snmpTargetParamsTable includes an entry for the
snmpTargetParamsSecurityName of the target. However, the receiving snmpTargetParamsSecurityName of the target. However, the receiving
SNMP engine (Server) does not know which DTLS certificate to offer to SNMP engine (Server) does not know which DTLS certificate to offer to
the Client so that the tmSecurityName identity-authentication will be the Client so that the tmSecurityName identity-authentication will be
successful. The best solution would be to maintain a one-to-one successful. The best solution would be to maintain a one-to-one
mapping between certificates and incoming ports for notification mapping between certificates and incoming ports for notification
skipping to change at page 52, line 36 skipping to change at page 51, line 50
9. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in 9. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in
the SNMP Transport Model registry; the SNMP Transport Model registry;
11. Acknowledgements 11. Acknowledgements
This document closely follows and copies the Secure Shell Transport This document closely follows and copies the Secure Shell Transport
Model for SNMP defined by David Harrington and Joseph Salowey in Model for SNMP defined by David Harrington and Joseph Salowey in
[I-D.ietf-isms-secshell]. [I-D.ietf-isms-secshell].
This document was reviewed by the following people who helped provide
useful comments: David Harrington, Alan Luchuk, Ray Purvis.
This work was supported in part by the United States Department of This work was supported in part by the United States Department of
Defense. Large portions of this document are based on work by Defense. Large portions of this document are based on work by
General Dynamics C4 Systems and the following individuals: Brian General Dynamics C4 Systems and the following individuals: Brian
Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
12. References 12. References
12.1. Normative References 12.1. Normative References
 End of changes. 133 change blocks. 
704 lines changed or deleted 680 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/