Network Working Group D. Harrington
Request for Comments: 5591 Huawei Technologies (USA)
Category: Standards Track W. Hardaker
Cobham Analytic Solutions
June 2009
Network Working Group D. Harrington
Request for Comments: 5591 Huawei Technologies (USA)
Category: Standards Track W. Hardaker
Cobham Analytic Solutions
June 2009
Transport Security Model for the Simple Network Management Protocol (SNMP)
简单网络管理协议（SNMP）的传输安全模型
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).
本备忘录描述了简单网络管理协议（SNMP）的传输安全模型。
This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP.
此备忘录还定义了管理信息库（MIB）的一部分，用于监视和管理SNMP的传输安全模型。
Table of Contents
目录
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................4
1.4. Motivation .................................................5
1.5. Constraints ................................................5
2. How the Transport Security Model Fits in the Architecture .......6
2.1. Security Capabilities of this Model ........................6
2.1.1. Threats .............................................6
2.1.2. Security Levels .....................................7
2.2. Transport Sessions .........................................7
2.3. Coexistence ................................................7
2.3.1. Coexistence with Message Processing Models ..........7
2.3.2. Coexistence with Other Security Models ..............8
2.3.3. Coexistence with Transport Models ...................8
3. Cached Information and References ...............................8
3.1. Transport Security Model Cached Information ................9
3.1.1. securityStateReference ..............................9
3.1.2. tmStateReference ....................................9
3.1.3. Prefixes and securityNames ..........................9
4. Processing an Outgoing Message .................................10
4.1. Security Processing for an Outgoing Message ...............10
4.2. Elements of Procedure for Outgoing Messages ...............11
5. Processing an Incoming SNMP Message ............................12
5.1. Security Processing for an Incoming Message ...............12
5.2. Elements of Procedure for Incoming Messages ...............13
6. MIB Module Overview ............................................14
6.1. Structure of the MIB Module ...............................14
6.1.1. The snmpTsmStats Subtree ...........................14
6.1.2. The snmpTsmConfiguration Subtree ...................14
6.2. Relationship to Other MIB Modules .........................14
6.2.1. MIB Modules Required for IMPORTS ...................15
7. MIB Module Definition ..........................................15
8. Security Considerations ........................................20
8.1. MIB Module Security .......................................20
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................4
1.4. Motivation .................................................5
1.5. Constraints ................................................5
2. How the Transport Security Model Fits in the Architecture .......6
2.1. Security Capabilities of this Model ........................6
2.1.1. Threats .............................................6
2.1.2. Security Levels .....................................7
2.2. Transport Sessions .........................................7
2.3. Coexistence ................................................7
2.3.1. Coexistence with Message Processing Models ..........7
2.3.2. Coexistence with Other Security Models ..............8
2.3.3. Coexistence with Transport Models ...................8
3. Cached Information and References ...............................8
3.1. Transport Security Model Cached Information ................9
3.1.1. securityStateReference ..............................9
3.1.2. tmStateReference ....................................9
3.1.3. Prefixes and securityNames ..........................9
4. Processing an Outgoing Message .................................10
4.1. Security Processing for an Outgoing Message ...............10
4.2. Elements of Procedure for Outgoing Messages ...............11
5. Processing an Incoming SNMP Message ............................12
5.1. Security Processing for an Incoming Message ...............12
5.2. Elements of Procedure for Incoming Messages ...............13
6. MIB Module Overview ............................................14
6.1. Structure of the MIB Module ...............................14
6.1.1. The snmpTsmStats Subtree ...........................14
6.1.2. The snmpTsmConfiguration Subtree ...................14
6.2. Relationship to Other MIB Modules .........................14
6.2.1. MIB Modules Required for IMPORTS ...................15
7. MIB Module Definition ..........................................15
8. Security Considerations ........................................20
8.1. MIB Module Security .......................................20
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
Appendix A. Notification Tables Configuration ....................24
A.1. Transport Security Model Processing for Notifications .....25
Appendix B. Processing Differences between USM and Secure
Transport ............................................26
B.1. USM and the RFC 3411 Architecture .........................26
B.2. Transport Subsystem and the RFC 3411 Architecture .........27
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
Appendix A. Notification Tables Configuration ....................24
A.1. Transport Security Model Processing for Notifications .....25
Appendix B. Processing Differences between USM and Secure
Transport ............................................26
B.1. USM and the RFC 3411 Architecture .........................26
B.2. Transport Subsystem and the RFC 3411 Architecture .........27
This memo describes a Transport Security Model for the Simple Network Management Protocol for use with secure Transport Models in the Transport Subsystem [RFC5590].
本备忘录描述了简单网络管理协议的传输安全模型，用于传输子系统[RFC5590]中的安全传输模型。
This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP.
此备忘录还定义了管理信息库（MIB）的一部分，用于监视和管理SNMP的传输安全模型。
It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Transport Security Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. It is expected that readers will have also read and understood [RFC3411], [RFC3412], [RFC3413], and [RFC3418].
理解SNMP体系结构和体系结构术语对于理解本备忘录中描述的传输安全模型在体系结构中的适用位置以及与体系结构中的其他子系统和模型的交互非常重要。预计读者还将阅读并理解[RFC3411]、[RFC3412]、[RFC3413]和[RFC3418]。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB 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 [RFC2580].
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块，如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]所述。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.
关键字的小写版本应该像普通英语一样阅读。它们通常（但不总是）用于与RFC 3411体系结构或此处定义的子系统的兼容性相关的上下文中，但可能不会影响导线兼容性。这些术语用作建议IETF模型设计者的指南，以使设计与RFC 3411子系统和抽象服务接口（ASI）兼容。实现者可以自由地以不同的方式实现。这些小写术语的一些用法只是普通的英语用法。
For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard.
为了与SNMP相关规范保持一致，本文件支持STD 62中定义的术语，而不支持与使用相同术语不同变体的非SNMP规范保持一致的术语。这与IESG的决定是一致的，即当SNMPv3升级到完整标准时，不要求修改SNMPv3术语以匹配其他非SNMP规范的使用。
Authentication in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication.
本文档中的身份验证通常指“用于证明”消息真实性的英文含义，而不是数据源身份验证或对等身份验证。
The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP applications included in the engine. Where distinction is needed, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "Simple Network Management Protocol (SNMP) Applications" [RFC3413] for further information.
本文档中不使用术语“管理器”和“代理”，因为在RFC 3411体系结构中，根据引擎中包含的SNMP应用程序，所有SNMP实体都具有充当管理器、代理或两者的功能。如果需要区分，则使用命令生成器、命令响应者、通知发起人、通知接收方和代理转发器的应用程序名称。有关更多信息，请参阅“简单网络管理协议（SNMP）应用程序”[RFC3413]。
While security protocols frequently refer to a user, the terminology used in [RFC3411] and in this memo 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 each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain.
虽然安全协议通常指用户，但[RFC3411]和本备忘录中使用的术语为“主体”。委托人是代表其提供服务或进行处理的“谁”。除其他外，委托人可以是以特定角色行事的个人、以特定角色行事的一组个人、一个应用程序或一组应用程序，或者是管理域内这些应用程序的组合。
The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590], which enables the use of external "lower-layer transport" protocols to provide message
读者应该已经阅读并理解了[RFC3411]中定义的SNMP体系结构的描述，以及“简单网络管理协议（SNMP）的传输子系统”[RFC5590]中指定的体系结构扩展，该扩展允许使用外部“较低层传输”协议来提供消息
security. Transport Models are tied into the SNMP architecture through the Transport Subsystem. The Transport Security Model is designed to work with such lower-layer, secure Transport Models.
安全传输模型通过传输子系统绑定到SNMP体系结构中。传输安全模型设计用于处理此类较低层的安全传输模型。
In keeping with the RFC 3411 design decisions to use self-contained documents, this memo includes the elements of procedure plus associated MIB objects that are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be referenced in other documents. This allows the Transport Security Model to be designed and documented as independent and self-contained, having no direct impact on other modules. It also allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules.
为了与RFC 3411使用自包含文档的设计决策保持一致，本备忘录包括过程元素以及处理SNMP传输安全模型所需的相关MIB对象。这些MIB对象不应在其他文档中引用。这允许将传输安全模型设计为独立的、自包含的，对其他模块没有直接影响。它还允许根据需要对该模块进行升级和补充，并在与其他模块不同的时间线上沿着标准轨道移动。
This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation.
规范的模块化并不意味着对实现强加任何特定的要求。
This memo describes a Security Model to make use of Transport Models that use lower-layer, secure transports and existing and commonly deployed security infrastructures. This Security Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible.
本备忘录描述了一个安全模型，以利用使用较低层、安全传输和现有及常用安全基础设施的传输模型。此安全模型旨在满足网络管理员的安全和操作需求，最大限度地提高操作环境中的可用性，以实现高部署成功率，同时最大限度地降低实施和部署成本，以尽可能缩短部署时间。
The design of this SNMP Security Model is also influenced by the following constraints:
此SNMP安全模型的设计还受到以下约束的影响：
1. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols).
1. 在网络压力下，安全协议及其底层安全机制不应仅依赖于其他网络服务（例如，网络时间协议（NTP）或身份验证、授权和计费（AAA）协议）的可用性。
2. When the network is not under stress, the Security Model and its underlying security mechanisms MAY depend upon the ready availability of other network services.
2. 当网络没有压力时，安全模型及其底层安全机制可能取决于其他网络服务的可用性。
3. It might not be possible for the Security Model to determine when the network is under stress.
3. 安全模型可能无法确定网络何时处于压力之下。
4. A Security Model SHOULD NOT require changes to the SNMP architecture.
4. 安全模型不应要求更改SNMP体系结构。
5. A Security Model SHOULD NOT require changes to the underlying security protocol.
5. 安全模型不应要求更改基础安全协议。
The Transport Security Model is designed to fit into the RFC 3411 architecture as a Security Model in the Security Subsystem and to utilize the services of a secure Transport Model.
传输安全模型设计为适合RFC 3411体系结构，作为安全子系统中的安全模型，并利用安全传输模型的服务。
For incoming messages, a secure Transport Model will pass a tmStateReference cache, described in [RFC5590]. To maintain RFC 3411 modularity, the Transport Model will not know which securityModel will process the incoming message; the Message Processing Model will determine this. If the Transport Security Model is used with a non-secure Transport Model, then the cache will not exist or will not be populated with security parameters, which will cause the Transport Security Model to return an error (see Section 5.2).
对于传入消息，安全传输模型将传递参考缓存，如[RFC5590]中所述。为了保持RFC 3411模块化，传输模型将不知道哪个securityModel将处理传入消息；消息处理模型将决定这一点。如果传输安全模型与非安全传输模型一起使用，则缓存将不存在或不会填充安全参数，这将导致传输安全模型返回错误（请参阅第5.2节）。
The Transport Security Model will create the securityName and securityLevel to be passed to applications, and will verify that the tmTransportSecurityLevel reported by the Transport Model is at least as strong as the securityLevel requested by the Message Processing Model.
传输安全模型将创建要传递给应用程序的securityName和securityLevel，并将验证传输模型报告的tmTransportSecurityLevel至少与消息处理模型请求的securityLevel一样强。
For outgoing messages, the Transport Security Model will create a tmStateReference cache (or use an existing one), and will pass the tmStateReference to the specified Transport Model.
对于传出消息，传输安全模型将创建tmStateReference缓存（或使用现有缓存），并将tmStateReference传递给指定的传输模型。
The Transport Security Model is compatible with the RFC 3411 architecture and provides protection against the threats identified by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself. Which threats are addressed and how they are mitigated depends on the Transport Model used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision.
传输安全模型与RFC 3411体系结构兼容，并针对RFC 3411体系结构识别的威胁提供保护。但是，传输安全模型本身不提供身份验证和加密等安全机制。解决哪些威胁以及如何缓解这些威胁取决于所使用的传输模型。为避免产生潜在的安全漏洞，运营商应配置其系统，以便此安全模型始终与提供适当安全性的传输模型一起使用，其中“适当”特定部署是一项管理决策。
The RFC 3411 architecture recognizes three levels of security:
RFC 3411体系结构可识别三个安全级别：
- without authentication and without privacy (noAuthNoPriv)
- 没有身份验证和隐私（noAuthNoPriv）
- with authentication but without privacy (authNoPriv)
- 具有身份验证但不具有隐私（authNoPriv）
- with authentication and with privacy (authPriv)
- 具有身份验证和隐私（authPriv）
The model-independent securityLevel parameter is used to request specific levels of security for outgoing messages and to assert that specific levels of security were applied during the transport and processing of incoming messages.
独立于模型的securityLevel参数用于请求传出消息的特定安全级别，并断言在传入消息的传输和处理过程中应用了特定的安全级别。
The transport-layer algorithms used to provide security should not be exposed to the Transport Security Model, as the Transport Security Model has no mechanisms by which it can test whether an assertion made by a Transport Model is accurate.
用于提供安全性的传输层算法不应暴露于传输安全性模型，因为传输安全性模型没有可以测试传输模型所做断言是否准确的机制。
The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as reported in tmTransportSecurityLevel.
传输安全模型相信底层安全传输连接已正确配置，以支持至少与tmTransportSecurityLevel中报告的安全特性一样强的安全特性。
The Transport Security Model does not work with transport sessions directly. Instead the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName, and securityLevel, and is referenced via the tmStateReference parameter. How and if this is mapped to a particular transport or channel is the responsibility of the Transport Subsystem.
传输安全模型不能直接用于传输会话。相反，传输相关状态与transportDomain、transportAddress、securityName和securityLevel的唯一组合相关联，并通过tmStateReference参数进行引用。运输子系统负责如何以及是否将其映射到特定的运输或通道。
In the RFC 3411 architecture, a Message Processing Model determines which Security Model SHALL be called. As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model).
在RFC 3411体系结构中，消息处理模型确定应调用哪个安全模型。截至本文撰写之时，IANA已注册了四种消息处理模型（SNMPv1、SNMPv2c、SNMPv2u/SNMPv2*和SNMPv3）和三种其他安全模型（SNMPv1、SNMPv2c和基于用户的安全模型）。
The SNMPv1 and SNMPv2c message processing described in BCP 74 [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security Models. Since there is no mechanism defined in RFC 3584 to select an
BCP 74[RFC3584]中描述的SNMPv1和SNMPv2c消息处理始终选择SNMPv1（1）和SNMPv2c（2）安全模型。由于RFC 3584中没有定义用于选择
alternative Security Model, SNMPv1 and SNMPv2c messages cannot use the Transport Security Model. Messages might still be able to be conveyed over a secure transport protocol, but the Transport Security Model will not be invoked.
替代安全模型SNMPv1和SNMPv2c消息不能使用传输安全模型。消息可能仍然能够通过安全传输协议传输，但不会调用传输安全模型。
The SNMPv2u/SNMPv2* Message Processing Model is an historic artifact for which there is no existing IETF specification.
SNMPv2u/SNMPv2*消息处理模型是一个历史性的工件，没有现有的IETF规范。
The SNMPv3 message processing defined in [RFC3412] extracts the securityModel from the msgSecurityModel field of an incoming SNMPv3Message. When this value is transportSecurityModel(4), security processing is directed to the Transport Security Model. For an outgoing message to be secured using the Transport Security Model, the application MUST specify a securityModel parameter value of transportSecurityModel(4) in the sendPdu Abstract Service Interface (ASI).
[RFC3412]中定义的SNMPv3消息处理从传入SNMPv3消息的msgSecurityModel字段中提取securityModel。当此值为transportSecurityModel（4）时，安全处理将定向到传输安全模型。要使用传输安全模型保护传出消息，应用程序必须在sendPdu抽象服务接口（ASI）中指定transportSecurityModel（4）的securityModel参数值。
The Transport Security Model uses its own MIB module for processing to maintain independence from other Security Models. This allows the Transport Security Model to coexist with other Security Models, such as the User-based Security Model (USM) [RFC3414].
传输安全模型使用自己的MIB模块进行处理，以保持与其他安全模型的独立性。这允许传输安全模型与其他安全模型共存，例如基于用户的安全模型（USM）[RFC3414]。
The Transport Security Model (TSM) MAY work with multiple Transport Models, but the RFC 3411 Abstract Service Interfaces (ASIs) do not carry a value for the Transport Model. The MIB module defined in this memo allows an administrator to configure whether or not TSM prepends a Transport Model prefix to the securityName. This will allow SNMP applications to consider Transport Model as a factor when making decisions, such as access control, notification generation, and proxy forwarding.
传输安全模型（TSM）可以与多个传输模型一起工作，但RFC 3411抽象服务接口（ASI）没有传输模型的值。此备忘录中定义的MIB模块允许管理员配置TSM是否将传输模型前缀前置到securityName。这将允许SNMP应用在作出决策时考虑传输模型作为一个因素，例如访问控制、通知生成和代理转发。
To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [RFC5592].
为了让SNMP正确地利用由传输安全模型协调的安全服务，此安全模型只能与知道如何处理tmStateReference的传输模型一起使用，例如安全外壳传输模型[RFC5592]。
When performing SNMP processing, there are two levels of state information that might need to be retained: the immediate state linking a request-response pair and a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590] defines general requirements for caches and references.
在执行SNMP处理时，可能需要保留两个级别的状态信息：链接请求-响应对的即时状态和与传输和安全性相关的潜在长期状态。“简单网络管理协议（SNMP）的传输子系统”[RFC5590]定义了缓存和引用的一般要求。
This document defines additional cache requirements related to the Transport Security Model.
本文档定义了与传输安全模型相关的其他缓存要求。
The Transport Security Model has specific responsibilities regarding the cached information.
传输安全模型对缓存的信息负有特定的责任。
The Transport Security Model adds the tmStateReference received from the processIncomingMsg ASI to the securityStateReference. This tmStateReference can then be retrieved during the generateResponseMsg ASI so that it can be passed back to the Transport Model.
传输安全模型将从processIncomingMsg ASI接收的tmStateReference添加到securityStateReference。然后可以在generateResponseMsg ASI期间检索此tmStateReference，以便将其传回传输模型。
For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to look up or create a tmStateReference.
对于传出消息，传输安全模型使用SNMP应用程序提供的参数来查找或创建引用。
For the Transport Security Model, the security parameters used for a response MUST be the same as those used for the corresponding request. This Security Model uses the tmStateReference stored as part of the securityStateReference when appropriate. For responses and reports, this Security Model sets the tmSameSecurity flag to true in the tmStateReference before passing it to a Transport Model.
对于传输安全模型，用于响应的安全参数必须与用于相应请求的安全参数相同。此安全模型在适当时使用作为securityStateReference的一部分存储的tmStateReference。对于响应和报告，此安全模型在将其传递给传输模型之前，在tmStateReference中将tmSameSecurity标志设置为true。
For incoming messages, the Transport Security Model uses parameters provided in the tmStateReference cache to establish a securityName, and to verify adequate security levels.
对于传入消息，传输安全模型使用tmStateReference缓存中提供的参数来建立securityName，并验证足够的安全级别。
The SNMP-VIEW-BASED-ACM-MIB module [RFC3415], the SNMP-TARGET-MIB module [RFC3413], and other MIB modules contain objects to configure security parameters for use by applications such as access control, notification generation, and proxy forwarding.
SNMP-VIEW-BASED-ACM-MIB模块[RFC3415]、SNMP-TARGET-MIB模块[RFC3413]和其他MIB模块包含用于配置安全参数的对象，以供访问控制、通知生成和代理转发等应用程序使用。
Transport domains and their corresponding prefixes are coordinated via the IANA registry "SNMP Transport Domains".
传输域及其相应前缀通过IANA注册表“SNMP传输域”进行协调。
If snmpTsmConfigurationUsePrefix is set to true, then all securityNames provided by, or provided to, the Transport Security Model MUST include a valid transport domain prefix.
如果SNMPTSConfiguration UsePrefix设置为true，则传输安全模型提供的或提供给传输安全模型的所有安全名称必须包含有效的传输域前缀。
If snmpTsmConfigurationUsePrefix is set to false, then all securityNames provided by, or provided to, the Transport Security Model MUST NOT include a transport domain prefix.
如果SNMPTSConfiguration UsePrefix设置为false，则传输安全模型提供的或提供给传输安全模型的所有安全名称都不得包含传输域前缀。
The tmSecurityName in the tmStateReference stored as part of the securityStateReference does not contain a prefix.
作为securityStateReference的一部分存储的tmStateReference中的TMSSecurityName不包含前缀。
An error indication might return an Object Identifier (OID) and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected.
错误指示可能会返回递增计数器的对象标识符（OID）和值、securityLevel的值、计数器的contextEngineID和contextName的值，以及securityStateReference，前提是在检测到错误的点上有此信息。
This section describes the procedure followed by the Transport Security Model.
本节介绍传输安全模型遵循的过程。
The parameters needed for generating a message are supplied to the Security Model by the Message Processing Model via the generateRequestMsg() or the generateResponseMsg() ASI. The Transport Subsystem architectural extension has added the transportDomain, transportAddress, and tmStateReference parameters to the original RFC 3411 ASIs.
生成消息所需的参数由消息处理模型通过GenerateRequestsMsg（）或generateResponseMsg（）ASI提供给安全模型。传输子系统架构扩展已将transportDomain、transportAddress和tmStateReference参数添加到原始RFC 3411 ASIs中。
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)
statusInformation = -- success or errorIndication generateResponseMsg( IN messageProcessingModel -- typically, SNMP version
statusInformation=--成功或错误指示generateResponseMsg（在messageProcessingModel中--通常为SNMP版本
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)
1. If there is a securityStateReference (Response or Report message), then this Security Model uses the cached information rather than the information provided by the ASI. Extract the tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted tmTransportSecurityLevel. Set the tmSameSecurity parameter in the tmStateReference cache to true. The cachedSecurityData for this message can now be discarded.
1. 如果存在securityStateReference（响应或报告消息），则此安全模型使用缓存的信息，而不是ASI提供的信息。从securityStateReference缓存中提取tmStateReference。将tmRequestedSecurityLevel设置为提取的tmTransportSecurityLevel的值。将tmStateReference缓存中的tmSameSecurity参数设置为true。现在可以丢弃此邮件的CachedSecurity数据。
2. If there is no securityStateReference (e.g., a Request-type or Notification message), then create a tmStateReference cache. Set tmTransportDomain to the value of transportDomain, tmTransportAddress to the value of transportAddress, and tmRequestedSecurityLevel to the value of securityLevel. (Implementers might optimize by pointing to saved copies of these session-specific values.) Set the transaction-specific tmSameSecurity parameter to false.
2. 如果没有securityStateReference（例如，请求类型或通知消息），则创建tmStateReference缓存。将tmTransportDomain的值设置为transportDomain，将tmTransportAddress的值设置为transportAddress，将tmRequestedSecurityLevel的值设置为securityLevel。（实现者可以通过指向这些特定于会话的值的保存副本进行优化。）将特定于事务的tmSameSecurity参数设置为false。
If the snmpTsmConfigurationUsePrefix object is set to false, then set tmSecurityName to the value of securityName.
如果SNMPTSConfiguration UsePrefix对象设置为false，则将tmSecurityName设置为securityName的值。
If the snmpTsmConfigurationUsePrefix object is set to true, then use the transportDomain to look up the corresponding prefix. (Since the securityStateReference stores the tmStateReference with the tmSecurityName for the incoming message, and since tmSecurityName never has a prefix, the prefix-stripping step only occurs when we are not using the securityStateReference).
如果SNMPTSConfiguration UsePrefix对象设置为true，则使用transportDomain查找相应的前缀。（由于securityStateReference将tmStateReference与传入消息的tmSecurityName一起存储，并且由于tmSecurityName从来没有前缀，因此只有在不使用securityStateReference时才会发生前缀剥离步骤）。
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
如果前缀查找因任何原因失败，那么snmpTsmUnknownPrefixes计数器将递增，错误指示将返回给调用模块，消息处理将停止。
If the lookup succeeds, but there is no prefix in the securityName, or the prefix returned does not match the prefix in the securityName, or the length of the prefix is less than 1 or greater than 4 US-ASCII alpha-numeric characters, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
如果查找成功，但securityName中没有前缀，或返回的前缀与securityName中的前缀不匹配，或前缀长度小于1或大于4个US-ASCII字母数字字符，则snmpTsmInvalidPrefixes计数器将递增，并向调用模块返回错误指示，消息处理停止。
Strip the transport-specific prefix and trailing ':' character (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the value of securityName.
从securityName中去除传输特定前缀和尾随“：”字符（US-ASCII 0x3a）。将tmSecurityName设置为securityName的值。
3. Set securityParameters to a zero-length OCTET STRING ('0400').
3. 将securityParameters设置为长度为零的八位字节字符串（“0400”）。
4. Combine the message parts into a wholeMsg and calculate wholeMsgLength.
4. 将消息部分组合成一个wholeMsg并计算wholeMsgLength。
5. The wholeMsg, wholeMsgLength, securityParameters, and tmStateReference are returned to the calling Message Processing Model with the statusInformation set to success.
5. wholeMsg、wholeMsgLength、securityParameters和tmStateReference返回到调用消息处理模型，statusInformation设置为success。
An error indication might return an OID and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected.
错误指示可能返回递增计数器的OID和值、securityLevel的值、计数器的contextEngineID和contextName的值，以及securityStateReference（如果在检测到错误的点上有此信息）。
This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message from a Message Processing Model. The ASI from a Message Processing Model to the Security Subsystem for a received message is:
本节描述传输安全模型在从消息处理模型接收传入消息时遵循的过程。从消息处理模型到接收消息的安全子系统的ASI为：
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- from the received message
IN securityParameters -- from the received message
IN securityModel -- from the received message
IN securityLevel -- from the received message
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- from the received message
IN securityParameters -- from the received message
IN securityModel -- from the received message
IN securityLevel -- from the received message
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- (NEW) from the Transport Model
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- (NEW) from the Transport Model
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
1. Set the securityEngineID to the local snmpEngineID.
1. 将securityEngineID设置为本地snmpEngineID。
2. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, and tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message.
2. 如果tmStateReference未引用包含tmTransportDomain、tmTransportAddress、tmSecurityName和tmTransportSecurityLevel值的缓存，则snmpTsmInvalidCaches计数器将递增，错误指示将返回给调用模块，安全模型处理将停止此消息。
3. Copy the tmSecurityName to securityName.
3. 将tmSecurityName复制到securityName。
If the snmpTsmConfigurationUsePrefix object is set to true, then use the tmTransportDomain to look up the corresponding prefix.
如果SNMPTSConfiguration UsePrefix对象设置为true，则使用tmTransportDomain查找相应的前缀。
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
如果前缀查找因任何原因失败，那么snmpTsmUnknownPrefixes计数器将递增，错误指示将返回给调用模块，消息处理将停止。
If the lookup succeeds but the prefix length is less than 1 or greater than 4 octets, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
如果查找成功，但前缀长度小于1或大于4个八位字节，则snmpTsmInvalidPrefixes计数器将递增，错误指示将返回给调用模块，消息处理将停止。
Set the securityName to be the concatenation of the prefix, a ':' character (US-ASCII 0x3a), and the tmSecurityName.
将securityName设置为前缀“：”字符（US-ASCII 0x3a）和tmSecurityName的串联。
4. Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv) and tmTransportSecurityLevel specifies no privacy (noPriv), or if securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the snmpTsmInadequateSecurityLevels counter is incremented, an error indication (unsupportedSecurityLevel) together with the OID and
4. 比较tmStateReference缓存中tmTransportSecurityLevel的值与processIncomingMsg ASI中传递的securityLevel参数的值。如果securityLevel指定隐私（Priv）且tmTransportSecurityLevel指定无隐私（noPriv），或者如果securityLevel指定身份验证（auth）且tmTransportSecurityLevel指定传输模型未提供身份验证（noAuth），则SNMPTSMINADEqualizeSecurityLevel计数器将递增，这是一个错误指示（无支持的安全级别）以及OID和
value of the incremented counter is returned to the calling module, and Transport Security Model processing stops for this message.
递增计数器的值将返回给调用模块，传输安全模型将停止对此消息的处理。
5. The tmStateReference is cached as cachedSecurityData so that a possible response to this message will use the same security parameters. Then securityStateReference is set for subsequent references to this cached data.
5. tmStateReference被缓存为cachedSecurityData，因此对此消息的可能响应将使用相同的安全参数。然后，为该缓存数据的后续引用设置securityStateReference。
6. The scopedPDU component is extracted from the wholeMsg.
6. scopedPDU组件是从整个sg中提取的。
7. The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message.
7. 计算最大SizeResponseScopedPDU。这是scopedPDU允许的可能响应消息的最大大小。
8. The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg ASI.
8. statusInformation设置为success，并向调用模块返回processIncomingMsg ASI中指定的输出参数。
This MIB module provides objects for use only by the Transport Security Model. It defines a configuration scalar and related error counters.
此MIB模块提供仅由传输安全模型使用的对象。它定义配置标量和相关错误计数器。
Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below.
此MIB模块中的对象被排列到子树中。每个子树都组织为一组相关对象。下面显示了对象的总体结构和对其子树的分配，以及每个子树的预期用途。
This subtree contains error counters specific to the Transport Security Model.
此子树包含特定于传输安全模型的错误计数器。
This subtree contains a configuration object that enables administrators to specify if they want a transport domain prefix prepended to securityNames for use by applications.
此子树包含一个配置对象，管理员可以通过该对象指定是否希望在SecurityName前面添加传输域前缀，以供应用程序使用。
Some management objects defined in other MIB modules are applicable to an entity implementing the Transport Security Model. In particular, it is assumed that an entity implementing the Transport Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the
其他MIB模块中定义的一些管理对象适用于实现传输安全模型的实体。特别是，假设实现传输安全模型的实体将实现SNMP-FRAMEWORK-MIB[RFC3411]，即
SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and the SNMPv2-MIB [RFC3418]. These are not needed to implement the SNMP-TSM-MIB.
SNMP-TARGET-MIB[RFC3413]、基于SNMP-VIEW-ACM-MIB[RFC3415]和SNMPv2-MIB[RFC3418]。实现SNMP-TSM-MIB不需要这些。
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
以下MIB模块从[RFC2578]、[RFC2579]和[RFC2580]导入项目。
SNMP-TSM-MIB DEFINITIONS ::= BEGIN
SNMP-TSM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Counter32 FROM SNMPv2-SMI -- RFC2578 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 TruthValue FROM SNMPv2-TC -- RFC2579 ;
从SNMPv2 SMI导入模块标识、对象类型、mib-2、计数器32——从SNMPv2 CONF导入RFC2578模块符合性、从SNMPv2 TC导入对象组——从SNMPv2 TC导入RFC2580 TruthValue——从RFC2579导入；
snmpTsmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org
snmpTsmMIB模块标识最后更新的“200906090000Z”组织ISMS工作组“联系方式”工作组电子邮件：isms@lists.ietf.org订阅：isms-request@lists.ietf.org
Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de
主席：Juergen Quittek NEC欧洲有限公司网络实验室Kurfuersten Anlage 36 69115德国海德堡+49 6221 90511-15quittek@netlab.nec.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de
Juergen Schoenwaeld Jacobs大学不来梅校区环128725德国不来梅+49 421 200-3587 j。schoenwaelder@jacobs-德国大学
Editor: David Harrington Huawei Technologies USA 1700 Alma Dr. Plano TX 75075 USA +1 603-436-8634 ietfdbh@comcast.net
编辑：David Harrington Huawei Technologies USA 1700 Alma德克萨斯州Plano博士75075 USA+1 603-436-8634ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Transport Security Model MIB.
Wes Hardaker Cobham分析解决方案美国加利福尼亚州戴维斯382号信箱95617+1 530 792 1913ietf@hardakers.net“说明”传输安全模型MIB。
In keeping with the RFC 3411 design decisions to use self-contained documents, the RFC that contains the definition of this MIB module also includes the elements of procedure that are needed for processing the Transport Security Model for SNMP. These MIB objects SHOULD NOT be modified via other subsystems or models defined in other documents. This allows the Transport Security Model for SNMP to be designed and documented as independent and self-contained, having no direct impact on other modules, and this allows this module to be upgraded and supplemented as the need arises, and to move along the standards track on different time-lines from other modules.
根据RFC 3411使用自包含文档的设计决策，包含此MIB模块定义的RFC还包括处理SNMP传输安全模型所需的过程元素。这些MIB对象不应通过其他文档中定义的其他子系统或模型进行修改。这使得SNMP的传输安全模型可以设计和记录为独立的、自包含的，对其他模块没有直接影响，并且允许根据需要对该模块进行升级和补充，并在与其他模块不同的时间线上沿着标准轨道移动。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
This version of this MIB module is part of RFC 5591; see the RFC itself for full legal notices."
此版本的MIB模块是RFC 5591的一部分；有关完整的法律通知，请参见RFC本身。”
REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5591."
修订版“200906090000Z”说明“初始版本，在RFC 5591中发布。”
::= { mib-2 190 }
::= { mib-2 190 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-TSM-MIB
-- ---------------------------------------------------------- --
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-TSM-MIB
-- ---------------------------------------------------------- --
snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 }
snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 }
snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 }
snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 }
snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 }
snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- Statistics for the Transport Security Model
--运输安全模型的统计数据
snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 }
snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 }
snmpTsmInvalidCaches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the
snmpTsmInvalidCaches对象类型语法计数器32 MAX-ACCESS只读状态当前说明“由于
tmStateReference referred to an invalid cache.
"
::= { snmpTsmStats 1 }
tmStateReference referred to an invalid cache.
"
::= { snmpTsmStats 1 }
snmpTsmInadequateSecurityLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of incoming messages dropped because
the securityLevel asserted by the Transport Model was
less than the securityLevel requested by the
application.
"
::= { snmpTsmStats 2 }
snmpTsmInadequateSecurityLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of incoming messages dropped because
the securityLevel asserted by the Transport Model was
less than the securityLevel requested by the
application.
"
::= { snmpTsmStats 2 }
snmpTsmUnknownPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
snmpTsmConfigurationUsePrefix was set to true and
there is no known prefix for the specified transport
domain.
"
::= { snmpTsmStats 3 }
snmpTsmUnknownPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
snmpTsmConfigurationUsePrefix was set to true and
there is no known prefix for the specified transport
domain.
"
::= { snmpTsmStats 3 }
snmpTsmInvalidPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
the securityName associated with an outgoing message
did not contain a valid transport domain prefix.
"
::= { snmpTsmStats 4 }
snmpTsmInvalidPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
the securityName associated with an outgoing message
did not contain a valid transport domain prefix.
"
::= { snmpTsmStats 4 }
-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------
-- Configuration for the Transport Security Model
--传输安全模型的配置
snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 }
snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 }
snmpTsmConfigurationUsePrefix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current
SNMPTSConfiguration UsePrefix对象类型语法TruthValue最大访问读写状态当前
DESCRIPTION "If this object is set to true, then securityNames
passing to and from the application are expected to
contain a transport-domain-specific prefix. If this
object is set to true, then a domain-specific prefix
will be added by the TSM to the securityName for
incoming messages and removed from the securityName
when processing outgoing messages. Transport domains
and prefixes are maintained in a registry by IANA.
This object SHOULD persist across system reboots.
"
DEFVAL { false }
::= { snmpTsmConfiguration 1 }
DESCRIPTION "If this object is set to true, then securityNames
passing to and from the application are expected to
contain a transport-domain-specific prefix. If this
object is set to true, then a domain-specific prefix
will be added by the TSM to the securityName for
incoming messages and removed from the securityName
when processing outgoing messages. Transport domains
and prefixes are maintained in a registry by IANA.
This object SHOULD persist across system reboots.
"
DEFVAL { false }
::= { snmpTsmConfiguration 1 }
-- -------------------------------------------------------------
-- snmpTsmMIB - Conformance Information
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- snmpTsmMIB - Conformance Information
-- -------------------------------------------------------------
snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 }
snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 }
snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 }
snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 }
-- -------------------------------------------------------------
-- Compliance statements
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Compliance statements
-- -------------------------------------------------------------
snmpTsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines that support
the SNMP-TSM-MIB.
"
MODULE
MANDATORY-GROUPS { snmpTsmGroup }
::= { snmpTsmCompliances 1 }
snmpTsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines that support
the SNMP-TSM-MIB.
"
MODULE
MANDATORY-GROUPS { snmpTsmGroup }
::= { snmpTsmCompliances 1 }
-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
snmpTsmGroup OBJECT-GROUP
OBJECTS {
snmpTsmInvalidCaches,
snmpTsmInadequateSecurityLevels,
snmpTsmUnknownPrefixes,
snmpTsmInvalidPrefixes,
snmpTsmConfigurationUsePrefix
}
STATUS current
DESCRIPTION "A collection of objects for maintaining
information of an SNMP engine that implements
-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
snmpTsmGroup OBJECT-GROUP
OBJECTS {
snmpTsmInvalidCaches,
snmpTsmInadequateSecurityLevels,
snmpTsmUnknownPrefixes,
snmpTsmInvalidPrefixes,
snmpTsmConfigurationUsePrefix
}
STATUS current
DESCRIPTION "A collection of objects for maintaining
information of an SNMP engine that implements
the SNMP Transport Security Model. "
SNMP传输安全模型。"
::= { snmpTsmGroups 2 }
::= { snmpTsmGroups 2 }
END
终止
This document describes a Security Model, compatible with the RFC 3411 architecture, that permits SNMP to utilize security services provided through an SNMP Transport Model. The Transport Security Model relies on Transport Models for mutual authentication, binding of keys, confidentiality, and integrity.
本文档描述了与RFC 3411体系结构兼容的安全模型，该模型允许SNMP利用通过SNMP传输模型提供的安全服务。传输安全模型依赖于传输模型来实现相互身份验证、密钥绑定、机密性和完整性。
The Transport Security Model relies on secure Transport Models to provide an authenticated principal identifier and an assertion of whether authentication and privacy are used during transport. This Security Model SHOULD always be used with Transport Models that provide adequate security, but "adequate security" is a configuration and/or run-time decision of the operator or management application. The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports.
传输安全模型依赖于安全传输模型来提供经过身份验证的主体标识符以及在传输过程中是否使用身份验证和隐私的断言。此安全模型应始终与提供足够安全性的传输模型一起使用，但“足够安全性”是运营商或管理应用程序的配置和/或运行时决策。传输模型和底层安全传输的规范中应详细介绍安全威胁以及如何缓解这些威胁。
An authenticated principal identifier (securityName) is used in SNMP applications for purposes such as access control, notification generation, and proxy forwarding. This Security Model supports multiple Transport Models. Operators might judge some transports to be more secure than others, so this Security Model can be configured to prepend a prefix to the securityName to indicate the Transport Model used to authenticate the principal. Operators can use the prefixed securityName when making application decisions about levels of access.
已验证的主体标识符（securityName）在SNMP应用程序中用于访问控制、通知生成和代理转发等目的。此安全模型支持多种传输模型。操作员可能会判断某些传输比其他传输更安全，因此可以将此安全模型配置为在securityName前面加上前缀，以指示用于验证主体的传输模型。操作员可以在应用程序决定访问级别时使用前缀securityName。
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:
此MIB模块中定义了许多管理对象，其MAX-ACCESS子句为read-write和/或read-create。在某些网络环境中，此类对象可能被视为敏感或易受攻击。在没有适当保护的非安全环境中支持SET操作可能会对网络操作产生负面影响。以下是表和对象及其敏感度/漏洞：
o The snmpTsmConfigurationUsePrefix object could be modified, creating a denial of service or authorizing SNMP messages that would not have previously been authorized by an Access Control Model (e.g., the View-based Access Control Model (VACM)).
o 可以修改SNMPTSConfigurationUsePrefix对象，创建拒绝服务或授权SNMP消息，这些消息以前不会被访问控制模型（例如，基于视图的访问控制模型（VACM））授权。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
在某些网络环境中，此MIB模块中的某些可读对象（即具有MAX-ACCESS而非not ACCESS的对象）可能被视为敏感或易受攻击。因此，在通过SNMP通过网络发送这些对象时，控制甚至获取和/或通知对这些对象的访问，甚至可能加密这些对象的值，这一点非常重要。以下是表和对象及其敏感度/漏洞：
o All the counters in this module refer to configuration errors and do not expose sensitive information.
o 此模块中的所有计数器都引用配置错误，并且不公开敏感信息。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如通过使用IPsec），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）此MIB模块中的对象。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy).
建议实施者考虑SNMPv3框架所提供的安全特性（参见[RCFC310]，第8节），包括对UM和传输安全模型加密机制的完全支持（用于身份验证和隐私）。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
此外，不建议部署SNMPv3之前的SNMP版本。相反，建议部署SNMPv3并启用加密安全性。然后，客户/运营商应负责确保授予访问此MIB模块实例权限的SNMP实体已正确配置为仅授予那些拥有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）访问对象。
IANA has assigned:
IANA已分配：
1. An SMI number (190) with a prefix of mib-2 in the MIB module registry for the MIB module in this document.
1. 本文档中mib模块的mib模块注册表中前缀为mib-2的SMI编号（190）。
2. A value (4) to identify the Transport Security Model, in the Security Models registry of the SNMP Number Spaces registry. This results in the following table of values:
2. 用于标识传输安全模型的值（4），位于SNMP数字空间注册表的安全模型注册表中。这将产生下表中的值：
Value Description References
----- ----------- ----------
0 reserved for 'any' [RFC3411]
1 reserved for SNMPv1 [RFC3411]
2 reserved for SNMPv2c [RFC3411]
3 User-Based Security Model (USM) [RFC3411]
4 Transport Security Model (TSM) [RFC5591]
Value Description References
----- ----------- ----------
0 reserved for 'any' [RFC3411]
1 reserved for SNMPv1 [RFC3411]
2 reserved for SNMPv2c [RFC3411]
3 User-Based Security Model (USM) [RFC3411]
4 Transport Security Model (TSM) [RFC5591]
The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity.
编辑们要感谢Jeffrey Hutzelman分享他的SSH见解，并感谢Dave Shield出色地完成了对现有文档的文字处理，以提高组织性和清晰度。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
此外，Juergen Schoenwaeld还提供了有用的文件审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[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.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[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 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590]Harrington，D.和J.Schoenwaeld，“简单网络管理协议（SNMP）的传输子系统”，RFC 55902009年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5592]Harrington，D.，Salowey，J.，和W.Hardaker，“简单网络管理协议（SNMP）的安全外壳传输模型”，RFC 55922009年6月。
The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations to which notifications should be sent.
SNMP-TARGET-MIB和SNMP-NOTIFICATION-MIB[RFC3413]用于配置通知发起人和通知应发送到的目标。
Most of the configuration is Security-Model-independent and Transport-Model-independent.
大多数配置与安全模型无关，与传输模型无关。
The values we will use in the examples for the five model-independent security and transport parameters are:
我们将在示例中为五个独立于模型的安全和传输参数使用的值为：
transportDomain = snmpSSHDomain
transportDomain = snmpSSHDomain
transportAddress = 192.0.2.1:5162
transportAddress=192.0.2.1:5162
securityModel = Transport Security Model
securityModel = Transport Security Model
securityName = alice
securityName = alice
securityLevel = authPriv
securityLevel = authPriv
The following example will configure the notification originator to send informs to a notification receiver at 192.0.2.1:5162 using the securityName "alice". "alice" is the name for the recipient from the standpoint of the notification originator and is used for processing access controls before sending a notification.
以下示例将配置通知发起人使用securityName“alice”在192.0.2.1:5162处向通知接收方发送通知。“alice”是从通知发起人的角度来看收件人的名称，用于在发送通知之前处理访问控制。
The columns marked with an "*" are the items that are Security-Model-specific or Transport-Model-specific.
标有“*”的列是特定于安全模型或特定于传输模型的项。
The configuration for the "alice" settings in the SNMP-VIEW-BASED-ACM-MIB objects are not shown here for brevity. First, we configure which type of notification will be sent for this taglist (toCRTag). In this example, we choose to send an Inform. snmpNotifyTable row: snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType nonVolatile snmpNotifyColumnStatus createAndGo
为简洁起见，此处不显示SNMP-VIEW-BASED-ACM-MIB对象中“alice”设置的配置。首先，我们配置将为此标记列表（toCRTag）发送哪种类型的通知。在本例中，我们选择发送通知。snmpNotifyTable行：snmpNotifyName CRNotif snmpNotifyTag toCRTag snmpNotifyType inform snmpNotifyStorageType非易失性snmpNotifyColumnStatus createAndGo
Then we configure a transport address to which notifications associated with this taglist will be sent, and we specify which snmpTargetParamsEntry will be used (toCR) when sending to this transport address.
然后，我们配置一个传输地址，将与此标记列表关联的通知发送到该地址，并指定在发送到此传输地址时将使用哪个snmpTargetParamsEntry（toCR）。
snmpTargetAddrTable row: snmpTargetAddrName toCRAddr * snmpTargetAddrTDomain snmpSSHDomain * snmpTargetAddrTAddress 192.0.2.1:5162 snmpTargetAddrTimeout 1500 snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (MUST match below) snmpTargetAddrStorageType nonVolatile snmpTargetAddrColumnStatus createAndGo
snmpTargetAddrTable行：snmpTargetAddrName TOCRADR*snmpTargetAddrTDomain snmpSSHDomain*SNMPTargetADDRTADRTADRADDRTADRADR 192.0.2.1:5162 SNMPTargetADDRTADDR超时1500 snmpTargetAddrRetryCount 3 SNMPTargetADDRTARGETTADRTABLIST TOCTAG SNMPTargetADRDR参数toCR（必须在下面匹配）SNMPTargetADRDR存储类型非易失性SNMPTargetADRDR列状态createAndGo
Then we configure which principal at the host will receive the notifications associated with this taglist. Here, we choose "alice", who uses the Transport Security Model. snmpTargetParamsTable row: snmpTargetParamsName toCR snmpTargetParamsMPModel SNMPv3 * snmpTargetParamsSecurityModel TransportSecurityModel snmpTargetParamsSecurityName "alice" snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType nonVolatile snmpTargetParamsRowStatus createAndGo
然后，我们配置主机上的哪个主体将接收与此标记列表关联的通知。这里，我们选择“alice”，她使用传输安全模型。snmpTargetParamsTable行：snmpTargetParamsName toCR SNMPTargetParamsSMPModel SNMPv3*snmpTargetParamsSecurityModel传输安全模型snmpTargetParamsSecurityName“alice”snmpTargetParamsSecurityLevel authPriv snmpTargetParamsStorageType非易失性snmpTargetParamsRowStatus createAndGo
The Transport Security Model is called using the generateRequestMsg() ASI, with the following parameters (those with an * are from the above tables):
使用GenerateRequestsMsg（）ASI调用传输安全模型，参数如下（带*的参数来自上表）：
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- *snmpTargetParamsMPModel
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- *snmpTargetAddrTDomain
IN transportAddress -- *snmpTargetAddrTAddress
IN securityModel -- *snmpTargetParamsSecurityModel
IN securityEngineID -- immaterial; TSM will ignore.
IN securityName -- snmpTargetParamsSecurityName
IN securityLevel -- *snmpTargetParamsSecurityLevel
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to transport info
)
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- *snmpTargetParamsMPModel
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- *snmpTargetAddrTDomain
IN transportAddress -- *snmpTargetAddrTAddress
IN securityModel -- *snmpTargetParamsSecurityModel
IN securityEngineID -- immaterial; TSM will ignore.
IN securityName -- snmpTargetParamsSecurityName
IN securityLevel -- *snmpTargetParamsSecurityLevel
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to transport info
)
The Transport Security Model will determine the Transport Model based on the snmpTargetAddrTDomain. The selected Transport Model will select the appropriate transport connection using the tmStateReference cache created from the values of snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel.
传输安全模型将根据SNMPTargetADRDTDOMain确定传输模型。所选传输模型将使用从snmpTargetAddRtaAddress、snmpTargetParamsSecurityName和snmpTargetParamsSecurityLevel的值创建的tmStateReference缓存选择适当的传输连接。
USM and secure transports differ in the processing order and responsibilities within the RFC 3411 architecture. While the steps are the same, they occur in a different order and might be done by different subsystems. The following lists illustrate the difference in the flow and the responsibility for different processing steps for incoming messages when using USM and when using a secure transport. (These lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models MUST provide the detailed elements of procedure.)
USM和secure transports在RFC 3411体系结构中的处理顺序和职责不同。虽然步骤相同，但它们以不同的顺序出现，可能由不同的子系统完成。以下列表说明了在使用USM和使用安全传输时，传入消息的不同处理步骤的流程和责任。（为了便于说明，对这些列表进行了简化，并不代表处理的所有细节。运输模型必须提供详细的程序要素。）
With USM, SNMPv1, and SNMPv2c Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to extract header fields that are used to determine which Security Model will process the message to perform authentication, decryption, timeliness checking, integrity checking, and translation of parameters to model-independent parameters. By comparison, a secure transport performs those security functions on the message, before the ASN.1 is decoded.
对于USM、SNMPv1和SNMPv2c安全模型，当消息处理模型解码ASN.1消息的部分以提取用于确定哪个安全模型将处理消息以执行身份验证、解密、及时性检查、完整性检查、，并将参数转换为与模型无关的参数。相比之下，安全传输在ASN.1解码之前对消息执行这些安全功能。
Step 6 cannot occur until after decryption occurs. Steps 6 and beyond are the same for USM and a secure transport.
在解密发生之前，无法执行步骤6。步骤6及以上对于USM和安全传输是相同的。
1) Decode the ASN.1 header (Message Processing Model).
1) 解码ASN.1报头（消息处理模型）。
2) Determine the SNMP Security Model and parameters (Message Processing Model).
2) 确定SNMP安全模型和参数（消息处理模型）。
3) Verify securityLevel (Security Model).
3) 验证securityLevel（安全模型）。
4) Translate parameters to model-independent parameters (Security Model).
4) 将参数转换为独立于模型的参数（安全模型）。
5) Authenticate the principal, check message integrity and timeliness, and decrypt the message (Security Model).
5) 对主体进行身份验证，检查消息的完整性和及时性，并解密消息（安全模型）。
6) Determine the pduType in the decrypted portions (Message Processing Model).
6) 确定解密部分中的pduType（消息处理模型）。
7) Pass on the decrypted portions with model-independent parameters.
7) 使用与模型无关的参数传递解密的部分。
1) Authenticate the principal, check integrity and timeliness of the message, and decrypt the message (Transport Model).
1) 验证主体，检查消息的完整性和及时性，并解密消息（传输模型）。
2) Translate parameters to model-independent parameters (Transport Model).
2) 将参数转换为与模型无关的参数（传输模型）。
3) Decode the ASN.1 header (Message Processing Model).
3) 解码ASN.1报头（消息处理模型）。
4) Determine the SNMP Security Model and parameters (Message Processing Model).
4) 确定SNMP安全模型和参数（消息处理模型）。
5) Verify securityLevel (Security Model).
5) 验证securityLevel（安全模型）。
6) Determine the pduType in the decrypted portions (Message Processing Model).
6) 确定解密部分中的pduType（消息处理模型）。
7) Pass on the decrypted portions with model-independent security parameters.
7) 使用独立于模型的安全参数传递解密的部分。
If a message is secured using a secure transport layer, then the Transport Model will provide the translation from the authenticated identity (e.g., an SSH user name) to a human-friendly identifier (tmSecurityName) in step 2. The Security Model will provide a mapping from that identifier to a model-independent securityName.
如果使用安全传输层保护消息，则传输模型将在步骤2中提供从经过身份验证的标识（例如SSH用户名）到人类友好标识符（tmSecurityName）的转换。安全模型将提供从该标识符到独立于模型的securityName的映射。
Authors' Addresses
作者地址
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
David Harrington Huawei Technologies（美国）1700 Alma Dr.Suite 100 Plano，TX 75075美国
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
韦斯·哈达克·科巴姆分析解决方案美国加利福尼亚州戴维斯市382号信箱，邮编95617
Phone: +1 530 792 1913
EMail: ietf@hardakers.net
Phone: +1 530 792 1913
EMail: ietf@hardakers.net