Internet Engineering Task Force (IETF) S. Hares
Request for Comments: 8241 Huawei
Category: Informational D. Migault
ISSN: 2070-1721 J. Halpern
Ericsson
September 2017
Internet Engineering Task Force (IETF) S. Hares
Request for Comments: 8241 Huawei
Category: Informational D. Migault
ISSN: 2070-1721 J. Halpern
Ericsson
September 2017
Interface to the Routing System (I2RS) Security-Related Requirements
与路由系统（I2RS）安全相关要求的接口
Abstract
摘要
This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.
本文档介绍了路由系统（I2RS）协议接口的安全相关要求，该协议为I2RS体系结构文档（RFC 7921）中描述的路由系统提供了一个新接口。I2RS协议是通过重用现有IETF协议的一部分并向其添加新功能来实现的。其中一种重用是安全传输的安全特性（例如，传输层安全（TLS）、安全外壳（SSH）协议、数据报TLS（DTL）），例如加密、消息完整性、相互对等身份验证和反重放保护。从安全的角度考虑的新的I2RS特征如下：处理多头写事务的优先级机制、使用I2RS客户端标识应用的不透明的第二标识符和极其受限的只读非安全传输。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8241.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8241.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology and Concepts ........................................4
2.1. Requirements Language ......................................4
2.2. Security Terminology .......................................4
2.3. I2RS-Specific Terminology ..................................5
2.4. Concepts ...................................................5
3. Security Features and Protocols: Reused and New .................6
3.1. Security Protocols Reused by the I2RS Protocol .............6
3.2. New Features Related to Security ...........................7
3.3. I2RS Protocol Security Requirements vs. IETF
Management Protocols .......................................8
4. Security-Related Requirements ..................................10
4.1. I2RS Peer (Agent and Client) Identity Authentication ......10
4.2. Identity Validation before Role-Based Message Actions .....11
4.3. Peer Identity, Priority, and Client Redundancy ............12
4.4. Multi-Channel Transport: Secure and Non-Secure ............13
4.5. Management Protocol Security ..............................15
4.6. Role-Based Data Model Security ............................16
4.7. Security of the Environment ...............................17
5. IANA Considerations ............................................17
6. Security Considerations ........................................17
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................18
Acknowledgements ..................................................20
Authors' Addresses ................................................20
1. Introduction ....................................................3
2. Terminology and Concepts ........................................4
2.1. Requirements Language ......................................4
2.2. Security Terminology .......................................4
2.3. I2RS-Specific Terminology ..................................5
2.4. Concepts ...................................................5
3. Security Features and Protocols: Reused and New .................6
3.1. Security Protocols Reused by the I2RS Protocol .............6
3.2. New Features Related to Security ...........................7
3.3. I2RS Protocol Security Requirements vs. IETF
Management Protocols .......................................8
4. Security-Related Requirements ..................................10
4.1. I2RS Peer (Agent and Client) Identity Authentication ......10
4.2. Identity Validation before Role-Based Message Actions .....11
4.3. Peer Identity, Priority, and Client Redundancy ............12
4.4. Multi-Channel Transport: Secure and Non-Secure ............13
4.5. Management Protocol Security ..............................15
4.6. Role-Based Data Model Security ............................16
4.7. Security of the Environment ...............................17
5. IANA Considerations ............................................17
6. Security Considerations ........................................17
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................18
Acknowledgements ..................................................20
Authors' Addresses ................................................20
The Interface to the Routing System (I2RS) protocol provides read and write access to information and state within the routing system. An I2RS client interacts with one or more I2RS agents to collect information from network routing systems. [RFC7921] describes the architecture of this interface, and this document assumes the reader is familiar with this architecture and its definitions.
路由系统（I2RS）协议的接口提供对路由系统内信息和状态的读写访问。I2RS客户端与一个或多个I2RS代理交互，以从网络路由系统收集信息。[RFC7921]描述了该接口的体系结构，本文档假设读者熟悉该体系结构及其定义。
The I2RS interface is instantiated by the I2RS protocol connecting an I2RS client and an I2RS agent associated with a routing system. The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. As a reuse protocol, it can be considered a higher-layer protocol because it can be instantiated in multiple management protocols (e.g., NETCONF [RFC6241] or RESTCONF [RFC8040]) operating over a secure transport. These protocols are what provide its security.
I2RS接口由连接I2RS客户端和与路由系统关联的I2RS代理的I2RS协议实例化。I2RS协议是通过重用现有IETF协议的一部分并向其添加新功能来实现的。作为一个重用协议，它可以被视为一个更高层的协议，因为它可以在多个管理协议（例如，NETCONF[RFC6241]或RESTCONF[RFC8040]）中实例化，这些协议通过安全传输进行操作。这些协议提供了它的安全性。
This document is part of a suite of documents outlining requirements for the I2RS protocol, which also includes the following:
本文件是概述I2RS协议要求的一套文件的一部分，其中还包括以下内容：
o "An Architecture for the Interface to the Routing System" [RFC7921]
o “路由系统接口的体系结构”[RFC7921]
o "I2RS Ephemeral State Requirements" [RFC8242]
o “I2RS临时状态要求”[RFC8242]
o "Interface to the Routing System (I2RS) Traceability: Framework and Information Model" (which discusses traceability) [RFC7923]
o “路由系统接口（I2RS）可追溯性：框架和信息模型”（讨论可追溯性）[RFC7923]
o "Requirements for Subscription to YANG Datastores" (which highlights the publication/subscription requirements) [RFC7922]
o “YANG数据存储订阅要求”（突出了发布/订阅要求）[RFC7922]
Since the I2RS "higher-layer" protocol changes the interface to the routing systems, it is important that implementers understand the new security requirements for the environment the I2RS protocol operates in. A summary of the I2RS protocol security environment is found in the I2RS architecture [RFC7921].
由于I2RS“更高层”协议改变了与路由系统的接口，因此实现人员必须了解I2RS协议运行环境的新安全要求。I2RS协议安全环境的概述见I2RS体系结构[RFC7921]。
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) that support encryption, message integrity, peer authentication, and key distribution protocols. Optionally, implementers may utilize Authentication, Authorization, and Accounting (AAA) protocols (Radius over TLS or Diameter over TLS) to securely distribute identity information.
I2RS重用支持加密、消息完整性、对等身份验证和密钥分发协议的安全传输协议（TLS、SSH、DTL）。可选地，实施者可以利用身份验证、授权和记帐（AAA）协议（TLS上的Radius或TLS上的Diameter）来安全地分发身份信息。
Section 2 highlights some of the terminology and concepts that the reader is required to be familiar with.
第2节重点介绍了读者需要熟悉的一些术语和概念。
Section 3 provides an overview of security features and protocols being reused (Section 3.1), lists the new security features being required (Section 3.2), and explores how existing and new security features and protocols would be paired with existing IETF management protocols (Section 3.3).
第3节概述了重复使用的安全功能和协议（第3.1节），列出了所需的新安全功能（第3.2节），并探讨了现有和新安全功能和协议如何与现有IETF管理协议配对（第3.3节）。
The new features I2RS extends to these protocols are a priority mechanism to handle multi-headed writes, an opaque secondary identifier to allow traceability of an application utilizing a specific I2RS client to communicate with an I2RS agent, and non-secure transport constrained to be used only for read-only data, which may include publicly available data (e.g., public BGP events, public telemetry information, web service availability) and some legacy data.
I2RS扩展到这些协议的新功能包括：处理多头写入的优先级机制、允许使用特定I2RS客户端与I2RS代理通信的应用程序可跟踪性的不透明二级标识符，以及仅用于只读数据的非安全传输，其中可能包括公共可用数据（例如，公共BGP事件、公共遥测信息、web服务可用性）和一些遗留数据。
Section 4 provides the I2RS protocol security requirements of several security features. Protocols designed to be I2RS higher-layer protocols need to fulfill these security requirements.
第4节提供了几个安全特性的I2RS协议安全要求。设计为I2RS更高层协议的协议需要满足这些安全要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document uses the terminology found in [RFC4949] and [RFC7921]. Specifically, this document reuses the following terms from [RFC4949]:
本文件使用[RFC4949]和[RFC7921]中的术语。具体而言，本文档重用了[RFC4949]中的以下术语：
o access control o authentication o data confidentiality o data integrity o data privacy o identity o identifier o mutual authentication o role o role-based access control o security audit trail o trust
o 访问控制o身份验证o数据机密性o数据完整性o数据隐私o身份o标识符o相互身份验证o角色o基于角色的访问控制o安全审核跟踪o信任
[RFC7922] describes traceability for the I2RS interface and the I2RS protocol. Traceability is not equivalent to a security audit trail or simple logging of information. A security audit trail may utilize traceability information.
[RFC7922]描述了I2RS接口和I2RS协议的可追溯性。可追溯性并不等同于安全审计跟踪或简单的信息记录。安全审计跟踪可利用可追溯性信息。
This document discusses the security of the multiple I2RS communication channels that operate over the higher-layer I2RS protocol. The higher-layer I2RS protocol combines a secure transport and I2RS contextual information, and it reuses IETF protocols and data models to create the secure transport and the contextual information driven by the I2RS data model. To describe how the I2RS higher-layer protocol combines other protocols, the following terms are used:
本文档讨论了在更高层I2RS协议上运行的多个I2RS通信信道的安全性。更高层的I2RS协议结合了安全传输和I2RS上下文信息，并重用IETF协议和数据模型，以创建由I2RS数据模型驱动的安全传输和上下文信息。为了描述I2RS高层协议如何结合其他协议，使用以下术语：
I2RS component protocols
I2RS组件协议
Protocols that are reused and combined to create the I2RS higher-layer protocol.
重新使用和组合以创建I2RS高层协议的协议。
I2RS secure transport component protocols (required)
I2RS安全传输组件协议（必需）
Secure transport protocols that combine to support the I2RS higher-layer protocol.
结合起来支持I2RS高层协议的安全传输协议。
I2RS management component protocols (required)
I2RS管理组件协议（必需）
Management protocols that combine to provide the management-information context for the I@RS higher-layer protocol.
管理协议，这些协议组合起来为I@RS高层协议。
I2RS AAA component protocols (optional)
I2RS AAA组件协议（可选）
AAA protocols supporting the I2RS higher-layer protocol.
支持I2RS高层协议的AAA协议。
The reader should be familiar with the pervasive security requirements in [RFC7258].
读者应熟悉[RFC7258]中的普遍安全要求。
This document uses the following concepts from the I2RS architecture [RFC7921] listed below with their respective section numbers from said RFC:
本文件使用了下列I2RS体系结构[RFC7921]中的以下概念，以及上述RFC中的相应章节号：
o I2RS client, agent, and protocol (Section 2)
o I2RS客户端、代理和协议（第2节）
o I2RS higher-layer protocol (Section 7.2)
o I2RS高层协议（第7.2节）
o scope: read, notification, identity, and write (Section 2)
o 范围：读取、通知、标识和写入（第2节）
o identity and secondary identity (Section 2)
o 身份和次要身份（第2节）
o roles or security rules (Section 2)
o 角色或安全规则（第2节）
o routing system/subsystem (Section 2)
o 路由系统/子系统（第2节）
o I2RS assumed security environment (Section 4)
o I2RS假定的安全环境（第4节）
o I2RS identity and authentication (Section 4.1)
o I2RS标识和认证（第4.1节）
o scope of Authorization in I2RS client and agent (Section 4.2)
o I2RS客户和代理的授权范围（第4.2节）
o client redundancy with a single client identity (Section 4.3),
o 具有单一客户身份的客户机冗余（第4.3节），
o restrictions on I2RS in personal devices (Section 4.4)
o 个人设备中I2R的限制（第4.4节）
o communication channels and I2RS higher-layer protocol (Section 7.2)
o 通信信道和I2RS高层协议（第7.2节）
o active communication versus connectivity (Section 7.5)
o 主动通信与连接（第7.5节）
o multi-headed control (Section 7.8)
o 多头控制（第7.8节）
o transaction, message, multi-message atomicity (Section 7.9)
o 事务、消息、多消息原子性（第7.9节）
I2RS requires a secure transport protocol and key distribution protocols. The secure transport for I2RS requires one to provide peer authentication. In addition, the features required for I2RS messages are confidentiality, authentication, and replay protection. According to [RFC8095], the secure transport protocols that support peer authentication, confidentiality, data integrity, and replay protection are the following:
I2RS需要一个安全的传输协议和密钥分发协议。I2RS的安全传输要求提供对等身份验证。此外，I2RS消息所需的功能包括机密性、身份验证和重播保护。根据[RFC8095]，支持对等身份验证、机密性、数据完整性和重播保护的安全传输协议如下：
1. TLS [RFC5246] over TCP or Stream Control Transmission Protocol (SCTP)
1. TCP或流控制传输协议（SCTP）上的TLS[RFC5246]
2. DTLS over UDP with replay detection and an anti-DoS stateless cookie mechanism required for the I2RS protocol and the DTLS options of record-size negotiation and conveyance of the Don't Fragment (DF) bit are set for IPv4, or no fragmentation extension headers for IPv6 to be optional in deployments are allowed by the I2RS protocol
2. I2RS协议所需的通过UDP的DTLS（具有重播检测和反DoS无状态cookie机制）以及记录大小协商和不分段（DF）位传输的DTLS选项已为IPv4设置，或者I2RS协议不允许在部署中选择IPv6的分段扩展头
3. HTTP over TLS (over TCP or SCTP)
3. TLS上的HTTP（通过TCP或SCTP）
4. HTTP over DTLS (with the requirements and optional features specified above in item 2)
4. DTLS上的HTTP（具有上述第2项中规定的要求和可选功能）
As detailed in Section 3.3, the following protocols would need to be extended to provide confidentiality, data integrity, peer authentication, and key distribution and to run over a secure transport (TLS or DTLS):
如第3.3节所述，需要扩展以下协议，以提供机密性、数据完整性、对等身份验证和密钥分发，并在安全传输（TLS或DTLS）上运行：
o IP Flow Information Export (IPFIX) over SCTP, TCP, or UDP
o 通过SCTP、TCP或UDP导出IP流信息（IPFIX）
o Forwarding and Control Element Separation (ForCES) Transport Mapping Layer (TML) over SCTP
o SCTP上的转发和控制元素分离（ForCES）传输映射层（TML）
The specific type of key management protocols an I2RS secure transport uses depends on the transport. Key management protocols utilized for the I2RS protocols SHOULD support automatic rotation.
I2RS安全传输使用的特定类型的密钥管理协议取决于传输。用于I2RS协议的密钥管理协议应支持自动轮换。
An I2RS implementer may use AAA protocols over secure transport to distribute the identities for the I2RS client, I2RS agent, and role-authorization information. Two AAA protocols are as follows: Diameter [RFC6733] and Radius [RFC2865]. To provide I2RS peer identities with the best security, the AAA protocols MUST be run over a secure transport (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius over a secure transport (TLS) [RFC6614]).
I2RS实现者可以通过安全传输使用AAA协议来分发I2RS客户端、I2RS代理和角色授权信息的身份。两个AAA协议如下：直径[RFC6733]和半径[RFC2865]。为了提供具有最佳安全性的I2RS对等身份，AAA协议必须在安全传输上运行（Diameter over secure transport（TLS over TCP）[RFC6733]），Radius over a secure transport（TLS）[RFC6614]）。
The new features are priority, an opaque secondary identifier, and a non-secure protocol for read-only data constrained to specific standard usages. The I2RS protocol allows multi-headed control by several I2RS clients. This multi-headed control is based on the assumption that the operator deploying the I2RS clients, I2RS agents, and the I2RS protocol will coordinate the read, write, and notification scope so the I2RS clients will not contend for the same write scope. However, just in case there is an unforeseen overlap of I2RS clients attempting to write a particular piece of data, the I2RS architecture [RFC7921] provides the concept of each I2RS client having a priority. The I2RS client with the highest priority will have its write succeed. This document specifies requirements for this new concept of priority (see Section 4.3).
新特性包括优先级、不透明的二级标识符，以及一个针对只读数据的非安全协议，这些数据仅限于特定的标准用途。I2RS协议允许多个I2RS客户端进行多头控制。这种多头控制基于这样的假设：部署I2RS客户端、I2RS代理和I2RS协议的操作员将协调读、写和通知范围，以便I2RS客户端不会争夺相同的写范围。然而，为了防止I2RS客户端试图写入特定数据段时出现不可预见的重叠，I2RS体系结构[RFC7921]提供了每个I2RS客户端具有优先级的概念。具有最高优先级的I2RS客户端将成功写入。本文件规定了这种新的优先权概念的要求（见第4.3节）。
The opaque secondary identifier identifies an application that uses communication from the I2RS client to I2RS agent to manage the routing system. The secondary identifier is opaque to the I2RS protocol. In order to protect personal privacy, the secondary identifier should not contain identifiable personal information.
不透明的次要标识符标识使用从I2RS客户端到I2RS代理的通信来管理路由系统的应用程序。次要标识符对I2RS协议是不透明的。为了保护个人隐私，次要标识符不应包含可识别的个人信息。
The last new feature related to I2RS security is the ability to allow nonconfidential data to be transferred over a non-secure transport. It is expected that most I2RS data models will describe information that will be transferred with confidentiality. Therefore, any model that transfers data over a non-secure transport is marked. The use of a non-secure transport is optional, and an implementer SHOULD create knobs that allow data marked as nonconfidential to be sent over a secure transport.
与I2RS安全性相关的最后一个新特性是允许通过非安全传输传输非机密数据的能力。预计大多数I2RS数据模型将描述将进行保密传输的信息。因此，任何通过非安全传输传输数据的模型都会被标记。非安全传输的使用是可选的，实现者应该创建旋钮，允许标记为非机密的数据通过安全传输发送。
Nonconfidential data can only be data with read-scope or notification-scope transmission of events. Nonconfidential data cannot have write-scope or notification-scope configuration. Examples of nonconfidential data would be the telemetry information that is publicly known (e.g., BGP route-views data or website status data) or some legacy data (e.g., interface) that cannot be transported using secure transport. The IETF I2RS data models MUST indicate (in the model) the specific data that is nonconfidential.
非机密数据只能是具有事件传输的读取范围或通知范围的数据。非机密数据不能具有写入作用域或通知作用域配置。非机密数据的示例包括公众已知的遥测信息（例如，BGP路由视图数据或网站状态数据）或无法使用安全传输传输的某些遗留数据（例如，接口）。IETF I2RS数据模型必须（在模型中）指出不可信的特定数据。
Most I2RS data models will expect that the information described in the model will be transferred with confidentiality.
大多数I2RS数据模型都希望模型中描述的信息能够保密传输。
Figure 1 provides a partial list of the candidate management protocols. It also lists the secure transports each protocol supports. The column on the right of the table indicates whether or not the transport protocol will need I2RS security extensions.
图1提供了候选管理协议的部分列表。它还列出了每个协议支持的安全传输。表右侧的列指示传输协议是否需要I2RS安全扩展。
Management I2RS Security
Protocol Transport Protocol Extensions
========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2)
Management I2RS Security
Protocol Transport Protocol Extensions
========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2)
RESTCONF HTTP over TLS with None required (*2) X.509v3 certificates, certificate validation, mutual authentication: 1) authenticated server identity, 2) authenticated client identity (*1)
RESTCONF HTTP over TLS，不需要（*2）X.509v3证书、证书验证、相互身份验证：1）经过身份验证的服务器身份，2）经过身份验证的客户端身份（*1）
ForCES TML over SCTP Needs an extension to (*1) TML to run TML over TLS over SCTP, or DTLS with options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of DF bits are optional). The IPsec mechanism is not sufficient for I2RS traveling over multiple hops (router + link) (*2)
强制通过SCTP的TML需要扩展到（*1）TML才能通过SCTP的TLS运行TML，或使用重播保护和反DoS无状态cookie机制选项的DTL。（DTLS记录大小协商和DF位传输是可选的）。IPsec机制不足以让I2R在多个跃点（路由器+链路）上移动（*2）
IPFIX SCTP, TCP, UDP Needs an extension TLS or DTLS for to support TLS or DTLS with secure client (*1) options for replay protection and anti-DoS stateless cookie mechanism. (DTLS record size negotiation and conveyance of DF bits are optional)
IPFIX SCTP、TCP、UDP需要一个扩展TLS或DTLS，以支持TLS或DTLS以及用于重播保护和反DoS无状态cookie机制的安全客户端（*1）选项。（DTLS记录大小协商和DF位传输是可选的）
*1 - Key management protocols MUST support appropriate key rotation.
*1-密钥管理协议必须支持适当的密钥轮换。
*2 - Identity and role authorization distributed by Diameter or Radius MUST use Diameter over TLS or Radius over TLS.
*2-按直径或半径分布的身份和角色授权必须使用TLS上的直径或TLS上的半径。
Figure 1: Candidate Management Protocols and Their Secure Transports
图1：候选管理协议及其安全传输
This section discusses security requirements based on the following security functions:
本节讨论基于以下安全功能的安全要求：
o peer identity authentication (Section 4.1)
o 对等身份验证（第4.1节）
o Peer Identity validation before role-based message actions (Section 4.2)
o 基于角色的消息操作之前的对等身份验证（第4.2节）
o peer identity and client redundancy (Section 4.3)
o 对等身份和客户端冗余（第4.3节）
o multi-channel transport requirements: Secure transport and non-secure Transport (Section 4.4)
o 多通道传输要求：安全传输和非安全传输（第4.4节）
o management protocol security requirements (Section 4.5)
o 管理协议安全要求（第4.5节）
o role-based security (Section 4.6)
o 基于角色的安全性（第4.6节）
o security environment (Section 4.7)
o 安全环境（第4.7节）
The I2RS protocol depends upon a secure transport layer for peer authentication, data integrity, confidentiality, and replay protection. The optional non-secure transport can only be used for a restricted set of data available publicly (events or information) or a select set of legacy data. Data passed over the non-secure transport channel MUST NOT contain any data that identifies a person.
I2RS协议依赖于安全传输层进行对等身份验证、数据完整性、机密性和重播保护。可选的非安全传输只能用于公开可用的受限数据集（事件或信息）或选定的旧数据集。通过非安全传输通道传递的数据不得包含任何识别人员的数据。
Requirements:
要求：
SEC-REQ-01: All I2RS clients and agents MUST have an identity and at least one unique identifier for each party in the I2RS protocol context.
SEC-REQ-01：在I2RS协议上下文中，所有I2RS客户机和代理都必须具有标识和至少一个唯一标识符。
SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and agent.
SEC-REQ-02：I2RS协议必须利用这些标识符来相互识别I2RS客户端和代理。
SEC-REQ-03: Identifier distribution and the loading of these identifiers into the I2RS agent and client SHOULD occur outside the I2RS protocol prior to the I2RS protocol establishing a connection between I2RS client and agent. AAA protocols MAY be used to distribute these identifiers, but other mechanism can be used.
SEC-REQ-03：在I2RS协议在I2RS客户端和代理之间建立连接之前，标识符分配和将这些标识符加载到I2RS代理和客户端应在I2RS协议之外进行。AAA协议可用于分发这些标识符，但也可使用其他机制。
Explanation:
说明：
These requirements are for I2RS peer (I2RS agent and client) authentication. A secure transport (e.g., TLS) will authenticate based on these identities, but these identities are for the I2RS management layer. A AAA protocol distributing I2RS identity information SHOULD transport its information over a secure transport.
这些要求适用于I2RS对等（I2RS代理和客户端）身份验证。安全传输（如TLS）将基于这些标识进行身份验证，但这些标识用于I2RS管理层。分发I2RS身份信息的AAA协议应通过安全传输传输其信息。
Requirements:
要求：
SEC-REQ-04: An I2RS agent receiving a request from an I2RS client MUST confirm that the I2RS client has a valid identity.
SEC-REQ-04：接收I2RS客户端请求的I2RS代理必须确认I2RS客户端具有有效身份。
SEC-REQ-05: An I2RS client receiving an I2RS message over a secure transport MUST confirm that the I2RS agent has a valid identifier.
SEC-REQ-05：通过安全传输接收I2RS消息的I2RS客户端必须确认I2RS代理具有有效标识符。
SEC-REQ-06: An I2RS agent receiving an I2RS message over a non-secure transport MUST confirm that the content is suitable for transfer over such a transport.
SEC-REQ-06：通过非安全传输接收I2RS消息的I2RS代理必须确认内容适合通过此类传输传输。
Explanation:
说明：
Each I2RS client has a scope based on its identity and the security roles (read, write, or events) associated with that identity, and that scope must be considered in processing an I2RS message sent on a communication channel. An I2RS communication channel may utilize multiple transport sessions or establish a transport session and then close the transport session. Therefore, it is important that the I2RS peers operate utilizing valid peer identities when a message is processed rather than checking if a transport session exists.
每个I2RS客户端都有一个作用域，该作用域基于其标识和与该标识关联的安全角色（读、写或事件），并且在处理在通信通道上发送的I2RS消息时必须考虑该作用域。I2RS通信信道可利用多个传输会话或建立传输会话，然后关闭传输会话。因此，在处理消息时，I2RS对等机必须利用有效的对等机身份进行操作，而不是检查传输会话是否存在。
During the time period when a secure transport session is active, the I2RS agent SHOULD assume that the I2RS client's identity remains valid. Similarly, while a secure connection exists that included validating the I2RS agent's identity and a message is received via that connection, the I2RS client SHOULD assume that the I2RS agent's identity remains valid.
在安全传输会话处于活动状态期间，I2RS代理应假定I2RS客户端的标识仍然有效。类似地，虽然存在包括验证I2RS代理身份的安全连接，并且通过该连接接收消息，但I2RS客户端应假定I2RS代理的身份仍然有效。
The definition of what constitutes a valid identity or a valid identifier MUST be defined by the I2RS protocol.
构成有效标识或有效标识符的定义必须由I2RS协议定义。
Requirements:
要求：
SEC-REQ-07: Each I2RS identifier MUST be associated with just one priority.
SEC-REQ-07：每个I2RS标识符必须仅与一个优先级关联。
SEC-REQ-08: Each identifier is associated with one secondary identifier during a particular I2RS transaction (e.g., read/write sequence), but the secondary identifier may vary during the time a connection between the I2RS client and I2RS agent is active.
SEC-REQ-08：在特定I2RS事务（例如读/写序列）期间，每个标识符与一个辅助标识符相关联，但在I2RS客户端和I2RS代理之间的连接处于活动状态期间，辅助标识符可能会发生变化。
Explanation:
说明：
The I2RS architecture also allows multiple I2RS clients with unique identities to connect to an I2RS agent (see Section 7.8 of [RFC7921]). The I2RS deployment using multiple clients SHOULD coordinate this multi-headed control of I2RS agents by I2RS clients so no conflict occurs in the write scope. However, in the case of conflict on a write-scope variable, the error resolution mechanisms defined by the I2RS architecture multi-headed control (Section 7.8 of [RFC7921]) allow the I2RS agent to deterministically choose one I2RS client. The I2RS client with highest priority is given permission to write the variable, and the second client receives an error message.
I2RS体系结构还允许具有唯一身份的多个I2RS客户端连接到I2RS代理（请参阅[RFC7921]第7.8节）。使用多个客户端的I2RS部署应协调I2RS客户端对I2RS代理的多头控制，以便在写入范围内不会发生冲突。但是，在写入范围变量发生冲突的情况下，I2RS体系结构多头控制（RFC7921）定义的错误解决机制（第7.8节）允许I2RS代理决定性地选择一个I2RS客户端。具有最高优先级的I2RS客户端被授予写入变量的权限，第二个客户端收到错误消息。
A single I2RS client may be associated with multiple applications with different tasks (e.g., weekly configurations or emergency configurations). The secondary identity is an opaque value that the I2RS client passes to the I2RS agent so that this opaque value can be placed in the tracing file or event stream to identify the application using the communication from I2RS client to agent. The I2RS client is trusted to simply assert the secondary identifier.
单个I2RS客户端可能与具有不同任务（例如，每周配置或紧急配置）的多个应用程序相关联。次要标识是I2RS客户端传递给I2RS代理的不透明值，因此可以将该不透明值放置在跟踪文件或事件流中，以使用从I2RS客户端到代理的通信来标识应用程序。I2RS客户机被信任，可以简单地断言辅助标识符。
One example of the use of the secondary identity is the situation where an operator of a network has two applications that use an I2RS client. The first application is a weekly configuration application that uses the I2RS protocol to change configurations. The second application allows operators to makes emergency changes to routers in the network. Both of these applications use the same I2RS client to write to an I2RS agent. In order for traceability to determine which application (weekly configuration or emergency) wrote some configuration changes to a router, the I2RS client sends a different opaque value for each of the applications. The weekly configuration secondary opaque value could be "xzzy-splot" and the emergency secondary opaque value could be "splish-splash".
使用辅助标识的一个示例是网络运营商有两个使用I2RS客户端的应用程序的情况。第一个应用程序是每周配置应用程序，它使用I2RS协议更改配置。第二个应用程序允许运营商对网络中的路由器进行紧急更改。这两个应用程序都使用相同的I2RS客户端来写入I2RS代理。为了便于跟踪以确定哪个应用程序（每周配置或紧急情况）向路由器写入了一些配置更改，I2RS客户端为每个应用程序发送不同的不透明值。每周配置二级不透明值可以是“xzzy splot”，紧急二级不透明值可以是“splish splash”。
A second example is if the I2RS client is used for the monitoring of critical infrastructure. The operator of a network using the I2RS client may desire I2RS client redundancy where the monitoring application with the I2RS client is deployed on two different boxes with the same I2RS client identity (see Section 4.3 of [RFC7921]). These two monitoring applications pass to the I2RS client whether the application is the primary or back-up application, and the I2RS client passes this information in the I2RS secondary identifier, as the figure below shows. The primary application's secondary identifier is "primary-monitoring", and the back-up application secondary identifier is "backup-monitoring". The I2RS tracing information will include the secondary identifier information along with the transport information in the tracing file in the agent.
第二个示例是I2RS客户端是否用于监控关键基础设施。使用I2RS客户端的网络运营商可能需要I2RS客户端冗余，其中带有I2RS客户端的监控应用程序部署在具有相同I2RS客户端标识的两个不同机箱上（请参阅[RFC7921]第4.3节）。无论应用程序是主应用程序还是备份应用程序，这两个监控应用程序都会传递给I2RS客户端，I2RS客户端会在I2RS次要标识符中传递此信息，如下图所示。主应用程序的辅助标识符为“主监控”，而备份应用程序的辅助标识符为“备份监控”。I2RS跟踪信息将包括辅助标识符信息以及代理中跟踪文件中的传输信息。
Application A--I2RS client--Secure transport(#1)
[I2RS identity 1, secondary identifier: "primary-monitoring"]-->
Application A--I2RS client--Secure transport(#1)
[I2RS identity 1, secondary identifier: "primary-monitoring"]-->
Application B--I2RS client--Secure transport(#2)
[I2RS identity 1, secondary identifier: "backup-monitoring"]-->
Application B--I2RS client--Secure transport(#2)
[I2RS identity 1, secondary identifier: "backup-monitoring"]-->
Figure 2: Primary and Back-Up Application for Monitoring Identification Sent to Agent
图2：用于监视发送到代理的标识的主应用程序和备份应用程序
Requirements:
要求：
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. The default transport is a secure transport, and this secure transport is mandatory to implement in all I2RS agents and in any I2RS client that a) performs a write scope transaction that is sent to the I2RS agent or b) configures an Event Scope transaction. This secure transport is mandatory to use on any I2RS client's Write transaction or the configuration of an Event Scope transaction.
SEC-REQ-09：I2RS协议必须能够通过安全传输传输传输数据，并且可以选择通过非安全传输传输数据。默认传输是安全传输，此安全传输必须在所有I2RS代理和任何I2RS客户端中实现，这些客户端a）执行发送到I2RS代理的写入范围事务，或b）配置事件范围事务。此安全传输必须用于任何I2RS客户端的写入事务或事件范围事务的配置。
SEC-REQ-10: The secure transport MUST provide data confidentiality, data integrity, and practical replay prevention.
SEC-REQ-10：安全传输必须提供数据保密性、数据完整性和实际的重播预防。
SEC-REQ-11: The I2RS client and I2RS agent SHOULD implement mechanisms that mitigate DoS attacks. This means the secure transport must support DoS prevention. For the non-secure transport, the I2RS higher-layer protocol MUST contain a transport management layer that considers the detection of DoS attacks and provides a warning over a secure transport channel.
SEC-REQ-11:I2RS客户端和I2RS代理应实现缓解DoS攻击的机制。这意味着安全传输必须支持DoS预防。对于非安全传输，I2RS高层协议必须包含一个传输管理层，该层考虑DoS攻击的检测，并通过安全传输通道提供警告。
SEC-REQ-12: A secure transport MUST be associated with a key management solution that can guarantee that only the entities having sufficient privileges can get the keys to encrypt/decrypt the sensitive data.
SEC-REQ-12：安全传输必须与密钥管理解决方案相关联，该解决方案可以保证只有拥有足够权限的实体才能获得加密/解密敏感数据的密钥。
SEC-REQ-13: A machine-readable mechanism to indicate that a data model contains nonconfidential data MUST be provided. A non-secure transport MAY be used to publish only read-scope or notification-scope data if the associated data model indicates that the data in question is nonconfidential.
SEC-REQ-13：必须提供一种机器可读机制，用于指示数据模型包含非机密数据。如果关联的数据模型表明相关数据是非机密的，则非安全传输可用于仅发布读取范围或通知范围数据。
SEC-REQ-14: The I2RS protocol MUST be able to support multiple secure transport sessions providing protocol and data communication between an I2RS agent and client. However, a single connection between I2RS agent and client MAY elect to use a single secure transport session or a single non-secure transport session conforming to the requirements above.
SEC-REQ-14:I2RS协议必须能够支持多个安全传输会话，提供I2RS代理和客户端之间的协议和数据通信。然而，I2RS代理和客户端之间的单个连接可以选择使用符合上述要求的单个安全传输会话或单个非安全传输会话。
SEC-REQ-15: Deployment configuration knobs SHOULD be created to allow operators to send "nonconfidential" read scope (data or event streams) over a secure transport.
SEC-REQ-15：应创建部署配置旋钮，以允许操作员通过安全传输发送“非机密”读取范围（数据或事件流）。
SEC-REQ-16: The I2RS protocol makes use of both secure and non-secure transports, but this use MUST NOT be done in any way that weakens the secure transport protocol used in the I2RS protocol or other contexts that do not have this requirement for mixing secure and non-secure modes of operation.
SEC-REQ-16:I2RS协议同时使用安全和非安全传输，但不得以任何方式削弱I2RS协议中使用的安全传输协议或其他不要求混合安全和非安全操作模式的上下文中使用的安全传输协议。
Explanation:
说明：
The I2RS architecture defines three scopes: read, write, and notification. Non-secure data can only be used for read and notification scopes of "nonconfidential data". The configuration of ephemeral data in the I2RS agent uses write scope either for data or for configuration of event notification streams. The requirement to use secure transport for configuration prevents accidental or malevolent entities from altering the I2RS routing system through the I2RS agent.
I2RS体系结构定义了三个作用域：读、写和通知。非安全数据只能用于“非机密数据”的读取和通知范围。I2RS代理中临时数据的配置使用写入作用域进行数据或事件通知流的配置。使用安全传输进行配置的要求可防止意外或恶意实体通过I2RS代理更改I2RS路由系统。
It is anticipated that the passing of most I2RS ephemeral state operational statuses SHOULD be done over a secure transport.
预计大多数I2RS短暂状态运行状态的传递应通过安全传输完成。
In most circumstances, the secure transport protocol will be associated with a key management system. Most deployments of the I2RS protocol will allow for automatic key management systems. Since the data models for the I2RS protocol will control key routing functions, it is important that deployments of I2RS use automatic key management systems.
在大多数情况下，安全传输协议将与密钥管理系统相关联。I2RS协议的大多数部署将允许自动密钥管理系统。由于I2RS协议的数据模型将控制密钥路由功能，因此I2RS的部署必须使用自动密钥管理系统。
Per BCP 107 [RFC4107], while key management systems SHOULD be automatic, the systems MAY be manual in the following scenarios:
根据BCP 107[RFC4107]，虽然密钥管理系统应该是自动的，但在以下情况下，系统可以是手动的：
a) The environment has limited bandwidth or high round-trip times.
a) 该环境的带宽有限或往返时间长。
b) The information being protected has low value.
b) 受保护的信息的价值较低。
c) The total volume of traffic over the entire lifetime of the long-term session key will be very low.
c) 长期会话密钥的整个生命周期内的总通信量将非常低。
d) The scale of the deployment is limited.
d) 部署规模有限。
Operators deploying the I2RS protocol selecting manual key management SHOULD consider both short- and medium-term plans. Deploying automatic systems initially may save effort in the long term.
部署I2RS协议选择手动密钥管理的运营商应考虑短期和中期计划。从长远来看，最初部署自动系统可能会节省工作。
Requirements:
要求：
SEC-REQ-17: In a critical infrastructure, certain data within routing elements is sensitive and read/write operations on such data SHOULD be controlled in order to protect its confidentiality. To achieve this, higher-layer protocols MUST utilize a secure transport, and they SHOULD provide access-control functions to protect confidentiality of the data.
SEC-REQ-17：在关键基础设施中，路由元素中的某些数据是敏感的，应控制此类数据的读/写操作，以保护其机密性。为了实现这一点，高层协议必须利用安全传输，并且它们应该提供访问控制功能以保护数据的机密性。
SEC-REQ-18: An integrity protection mechanism for I2RS MUST be provided that will be able to ensure the following:
SEC-REQ-18：必须为I2R提供完整性保护机制，以确保以下各项：
1) the data being protected is not modified without detection during its transportation,
1) 受保护的数据在传输过程中未经检测不得修改，
2) the data is actually from where it is expected to come from, and
2) 数据实际上来自预期的来源，并且
3) the data is not repeated from some earlier interaction the higher-layer protocol (best effort).
3) 数据不会重复来自更高层协议（尽力而为）的一些早期交互。
The I2RS higher-layer protocol operating over a secure transport provides this integrity. The I2RS higher-layer protocol operating over a non-secure transport SHOULD provide some way for the client receiving nonconfidential read-scoped or event-scoped data over the non-secure connection to detect when the data integrity is questionable; and in the event of a questionable data integrity, the I2RS client should disconnect the non-secure transport connection.
通过安全传输运行的I2RS高层协议提供了这种完整性。在非安全传输上运行的I2RS高层协议应为通过非安全连接接收非机密读取范围或事件范围数据的客户端提供某种方式，以检测数据完整性是否有问题；如果数据完整性有问题，I2RS客户端应断开非安全传输连接。
SEC-REQ-19: The I2RS higher-layer protocol MUST provide a mechanism for message traceability (requirements in [RFC7922]) that supports the tracking higher-layer functions run across secure connection or a non-secure transport.
SEC-REQ-19:I2RS高层协议必须提供一种消息跟踪机制（RFC7922中的要求），该机制支持跨安全连接或非安全传输运行的跟踪高层功能。
Explanation:
说明：
Most carriers do not want a router's configuration and data-flow statistics to be known by hackers or their competitors. While carriers may share peering information, most carriers do not share configuration and traffic statistics. To achieve this, the I2RS higher-layer protocol (e.g., NETCONF) requires access control (NETCONF Access Control Model [RFC6536]) for sensitive data needs to be provided; and the confidentiality protection on such data during transportation needs to be enforced.
大多数运营商不希望黑客或其竞争对手知道路由器的配置和数据流统计数据。虽然运营商可以共享对等信息，但大多数运营商不共享配置和流量统计信息。为了实现这一点，I2RS高层协议（如NETCONF）要求提供敏感数据的访问控制（NETCONF访问控制模型[RFC6536]）；需要加强运输过程中对此类数据的保密保护。
Integrity of data is important even if the I2RS protocol is sending nonconfidential data over a non-secure connection. The ability to trace I2RS protocol messages that enact I2RS transactions provides a minimal aid to helping operators check how messages enact transactions on a secure or non-secure transport. Contextual checks on specific nonconfidential data sent over a non-secure connection may indicate the data has been modified.
即使I2RS协议通过非安全连接发送非机密数据，数据的完整性也很重要。跟踪执行I2RS事务的I2RS协议消息的能力为帮助操作员检查消息如何在安全或非安全传输上执行事务提供了最低限度的帮助。通过非安全连接发送的特定非机密数据的上下文检查可能表明数据已被修改。
In order to make access control more manageable, the I2RS architecture [RFC7921] specifies a "role" to categorize users into a group (rather than handling them individually) for access-control purposes (role-based access control). Therefore, an I2RS role specifies the access control for a group as being read, write, or notification.
为了使访问控制更易于管理，I2RS体系结构[RFC7921]指定了一个“角色”，将用户分类为一个组（而不是单独处理），以实现访问控制目的（基于角色的访问控制）。因此，I2RS角色将组的访问控制指定为读、写或通知。
SEC-REQ-20: The rules around what I2RS security role is permitted to access and manipulate what information over a secure transport (which protects the data in transit) SHOULD ensure that data of any level of sensitivity is reasonably protected from being observed by those without permission to view it, so that privacy requirements are met.
SEC-REQ-20：关于允许I2RS安全角色通过安全传输（保护传输中的数据）访问和操作哪些信息的规则应确保合理保护任何级别的敏感数据，使其不被未经允许查看的人观察，从而满足隐私要求。
SEC-REQ-21: Role security MUST work when multiple transport connections are being used between the I2RS client and agent as the I2RS architecture [RFC7921] describes.
SEC-REQ-21：如I2RS架构[RFC7921]所述，当I2RS客户端和代理之间使用多个传输连接时，角色安全性必须起作用。
Sec-REQ-22: If an I2RS agent or client is tightly correlated with a person, then the I2RS protocol and data models SHOULD provide additional security that protects the person's privacy.
Sec-REQ-22：如果I2RS代理或客户端与个人密切相关，则I2RS协议和数据模型应提供额外的安全性，以保护个人隐私。
Explanation:
说明：
An I2RS higher-layer protocol uses a management protocol (e.g., NETCONF, RESTCONF) to pass messages in order to enact I2RS transactions. Role security must secure data (sensitive and normal data) in a router even when it is operating over multiple connections at the same time. NETCONF can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP over a secure transport (TLS). SCTP [RFC4960] provides security for multiple streams plus end-to-end transport of data. Some I2RS functions may wish to operate over DTLS [RFC6347], which runs over UDP ([RFC768]) and SCTP ([RFC5764]).
I2RS高层协议使用管理协议（例如NETCONF、RESTCONF）来传递消息，以便执行I2RS事务。角色安全必须保护路由器中的数据（敏感和正常数据），即使它同时在多个连接上运行。NETCONF可以通过TLS（通过TCP或SCTP）或SSH运行。RESTCONF通过安全传输（TLS）在HTTP上运行。SCTP[RFC4960]为多个流以及数据的端到端传输提供了安全性。一些I2RS功能可能希望在DTL[RFC6347]上运行，该DTL在UDP（[RFC768]）和SCTP（[RFC5764]）上运行。
Please note the security of the connection between application and I2RS client is outside of the I2RS protocol or I2RS interface.
请注意，应用程序和I2RS客户端之间的连接的安全性不在I2RS协议或I2RS接口的范围内。
While I2RS clients are expected to be related to network devices and not individual people, if an I2RS client ran on a person's phone, then privacy protection to anonymize any data relating to a person's identity or location would be needed.
虽然I2RS客户端预期与网络设备相关，而不是与个人相关，但如果I2RS客户端在个人手机上运行，则需要隐私保护以匿名化与个人身份或位置相关的任何数据。
A variety of forms of management may set policy on roles: "operator-applied knobs", roles that restrict personal access, data models with specific "privacy roles", and access filters.
各种形式的管理可以针对角色设置策略：“操作员应用的旋钮”、限制个人访问的角色、具有特定“隐私角色”的数据模型以及访问过滤器。
The security for the implementation of a protocol also considers the protocol environment. Implementers should review the summary of the I2RS security environment in [RFC7921].
协议实现的安全性还考虑了协议环境。实施者应查看[RFC7921]中的I2RS安全环境摘要。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
This is a document about security requirements for the I2RS protocol and data models. Security considerations for the I2RS protocol include both the protocol and the security environment.
这是一份关于I2RS协议和数据模型安全要求的文档。I2RS协议的安全注意事项包括协议和安全环境。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，DOI 10.17487/RFC4107，2005年6月<https://www.rfc-editor.org/info/rfc4107>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<https://www.rfc-editor.org/info/rfc4949>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<https://www.rfc-editor.org/info/rfc7258>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <https://www.rfc-editor.org/info/rfc7921>.
[RFC7921]Atlas，A.，Halpern，J.，Hares，S.，Ward，D.，和T.Nadeau，“路由系统接口架构”，RFC 7921，DOI 10.17487/RFC7921，2016年6月<https://www.rfc-editor.org/info/rfc7921>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, <https://www.rfc-editor.org/info/rfc7922>.
[RFC7922]Clarke，J.，Salgueiro，G.，和C.Pignataro，“路由系统接口（I2RS）可追溯性：框架和信息模型”，RFC 7922，DOI 10.17487/RFC7922，2016年6月<https://www.rfc-editor.org/info/rfc7922>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, <https://www.rfc-editor.org/info/rfc7923>.
[RFC7923]Voit，E.，Clemm，A.和A.Gonzalez Prieto，“YANG数据存储订阅要求”，RFC 7923，DOI 10.17487/RFC79232016年6月<https://www.rfc-editor.org/info/rfc7923>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<https://www.rfc-editor.org/info/rfc768>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<https://www.rfc-editor.org/info/rfc2865>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，DOI 10.17487/RFC5764，2010年5月<https://www.rfc-editor.org/info/rfc5764>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <https://www.rfc-editor.org/info/rfc6536>.
[RFC6536]Bierman，A.和M.Bjorklund，“网络配置协议（NETCONF）访问控制模型”，RFC 6536，DOI 10.17487/RFC6536，2012年3月<https://www.rfc-editor.org/info/rfc6536>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<https://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<https://www.rfc-editor.org/info/rfc6733>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095]Fairhurst，G.，Ed.，Trammell，B.，Ed.，和M.Kuehlewind，Ed.，“IETF传输协议和拥塞控制机制提供的服务”，RFC 8095，DOI 10.17487/RFC8095，2017年3月<https://www.rfc-editor.org/info/rfc8095>.
[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <http://www.rfc-editor.org/info/rfc8242>.
[RFC8242]Haas，J.和S.Hares，“路由系统接口（I2RS）临时状态要求”，RFC 8242，DOI 10.17487/RFC8242，2017年9月<http://www.rfc-editor.org/info/rfc8242>.
Acknowledgements
致谢
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Alia Atlas, and Jeff Haas for their contributions to the I2RS security requirements discussion and this document. The authors would like to thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their review of these requirements.
作者要感谢Wes George、Ahmed Abro、秦武、Eric Yu、Joel Halpern、Scott Brim、Nancy Cam Winget、Dacheng Zhang、Alia Atlas和Jeff Haas对I2RS安全需求讨论和本文件的贡献。作者要感谢Bob Moskowitz、Kathleen Moriarty、Stephen Farrell、Radia Perlman、Alvaro Retana、Ben Campbell和Alissa Cooper对这些要求的审查。
Authors' Addresses
作者地址
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America
Susan Hares Huawei 7453美国密歇根州山核桃山盐碱地48176
Email: shares@ndzh.com
Email: shares@ndzh.com
Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC H4S Canada
Daniel Migault Ericsson 8275跨加拿大路线圣洛朗，加拿大QC H4S
Email: daniel.migault@ericsson.com
Email: daniel.migault@ericsson.com
Joel Halpern Ericsson United States of America
美国爱立信公司
Email: joel.halpern@ericsson.com
Email: joel.halpern@ericsson.com