Internet Engineering Task Force (IETF)                          S. Hares
Request for Comments: 8241                                        Huawei
Category: Informational                                       D. Migault
ISSN: 2070-1721                                               J. Halpern
                                                          September 2017
Internet Engineering Task Force (IETF)                          S. Hares
Request for Comments: 8241                                        Huawei
Category: Informational                                       D. Migault
ISSN: 2070-1721                                               J. Halpern
                                                          September 2017

Interface to the Routing System (I2RS) Security-Related Requirements




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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.


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.


This document is part of a suite of documents outlining requirements for the I2RS protocol, which also includes the following:


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 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.


Section 2 highlights some of the terminology and concepts that the reader is required to be familiar with.


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).


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.


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.


2. Terminology and Concepts
2. 术语和概念
2.1. Requirements Language
2.1. 需求语言

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]所述进行解释。

2.2. Security Terminology
2.2. 安全术语

This document uses the terminology found in [RFC4949] and [RFC7921]. Specifically, this document reuses the following terms from [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.


2.3. I2RS-Specific Terminology
2.3. 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 component protocols


Protocols that are reused and combined to create the I2RS higher-layer protocol.


I2RS secure transport component protocols (required)


Secure transport protocols that combine to support the I2RS higher-layer protocol.


I2RS management component protocols (required)


Management protocols that combine to provide the management-information context for the I@RS higher-layer protocol.


I2RS AAA component protocols (optional)

I2RS AAA组件协议(可选)

AAA protocols supporting the I2RS higher-layer protocol.


2.4. Concepts
2.4. 概念

The reader should be familiar with the pervasive security requirements in [RFC7258].


This document uses the following concepts from the I2RS architecture [RFC7921] listed below with their respective section numbers from said 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节)

3. Security Features and Protocols: Reused and New
3. 安全特性和协议:重复使用和新增
3.1. Security Protocols Reused by the I2RS Protocol
3.1. I2RS协议重用的安全协议

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:


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)


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):


o IP Flow Information Export (IPFIX) over SCTP, TCP, or UDP


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.


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])。

3.2. New Features Related to Security
3.2. 与安全性相关的新功能

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).


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.


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.


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.


3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols
3.3. I2RS协议安全要求与IETF管理协议

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.


     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)


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.


*2 - Identity and role authorization distributed by Diameter or Radius MUST use Diameter over TLS or Radius over TLS.


Figure 1: Candidate Management Protocols and Their Secure Transports


4. Security-Related Requirements
4. 与安全有关的要求

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.


4.1. I2RS Peer (Agent and Client) Identity Authentication
4.1. I2RS对等(代理和客户端)身份验证



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-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and agent.


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.




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.


4.2. Identity Validation before Role-Based Message Actions
4.2. 基于角色的消息操作之前的身份验证



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-05: An I2RS client receiving an I2RS message over a secure transport MUST confirm that the I2RS agent has a valid identifier.


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.




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.


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.


The definition of what constitutes a valid identity or a valid identifier MUST be defined by the I2RS protocol.


4.3. Peer Identity, Priority, and Client Redundancy
4.3. 对等身份、优先级和客户端冗余



SEC-REQ-07: Each I2RS identifier MUST be associated with just one priority.


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.




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.


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.


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.


   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


4.4. Multi-Channel Transport: Secure and Non-Secure
4.4. 多通道传输:安全和非安全



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-10: The secure transport MUST provide data confidentiality, data integrity, and practical replay prevention.


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-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-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-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-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-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.




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.


It is anticipated that the passing of most I2RS ephemeral state operational statuses SHOULD be done over a secure transport.


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.


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.


4.5. Management Protocol Security
4.5. 管理协议安全



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-18: An integrity protection mechanism for I2RS MUST be provided that will be able to ensure the following:


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.


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.




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.


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.


4.6. Role-Based Data Model Security
4.6. 基于角色的数据模型安全

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.


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-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-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.




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]).


Please note the security of the connection between application and I2RS client is outside of the I2RS protocol or I2RS interface.


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.


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.


4.7. Security of the Environment
4.7. 环境安全

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].


5. IANA Considerations
5. IANA考虑

This document does not require any IANA actions.


6. Security Considerations
6. 安全考虑

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.


7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<>.

[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <>.

[RFC4107]Bellovin,S.和R.Housley,“加密密钥管理指南”,BCP 107,RFC 4107,DOI 10.17487/RFC4107,2005年6月<>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <>.

[RFC4949]Shirey,R.,“互联网安全词汇表,第2版”,FYI 36,RFC 4949,DOI 10.17487/RFC4949,2007年8月<>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <>.

[RFC7258]Farrell,S.和H.Tschofenig,“普遍监控是一种攻击”,BCP 188,RFC 7258,DOI 10.17487/RFC7258,2014年5月<>.

[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, <>.

[RFC7921]Atlas,A.,Halpern,J.,Hares,S.,Ward,D.,和T.Nadeau,“路由系统接口架构”,RFC 7921,DOI 10.17487/RFC7921,2016年6月<>.

[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, <>.

[RFC7922]Clarke,J.,Salgueiro,G.,和C.Pignataro,“路由系统接口(I2RS)可追溯性:框架和信息模型”,RFC 7922,DOI 10.17487/RFC7922,2016年6月<>.

[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, <>.

[RFC7923]Voit,E.,Clemm,A.和A.Gonzalez Prieto,“YANG数据存储订阅要求”,RFC 7923,DOI 10.17487/RFC79232016年6月<>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<>.

7.2. Informative References
7.2. 资料性引用

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <>.

[RFC768]Postel,J.,“用户数据报协议”,STD 6,RFC 768,DOI 10.17487/RFC0768,1980年8月<>.

[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, <>.

[RFC2865]Rigney,C.,Willens,S.,Rubens,A.,和W.Simpson,“远程认证拨入用户服务(RADIUS)”,RFC 2865,DOI 10.17487/RFC2865,2000年6月<>.

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <>.

[RFC4960]Stewart,R.,Ed.“流控制传输协议”,RFC 4960,DOI 10.17487/RFC4960,2007年9月<>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <>.

[RFC5246]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,DOI 10.17487/RFC5246,2008年8月<>.

[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, <>.

[RFC5764]McGrew,D.和E.Rescorla,“为安全实时传输协议(SRTP)建立密钥的数据报传输层安全(DTLS)扩展”,RFC 5764,DOI 10.17487/RFC5764,2010年5月<>.

[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, <>.

[RFC6241]Enns,R.,Ed.,Bjorklund,M.,Ed.,Schoenwaeld,J.,Ed.,和A.Bierman,Ed.,“网络配置协议(NETCONF)”,RFC 6241,DOI 10.17487/RFC6241,2011年6月<>.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <>.

[RFC6347]Rescorla,E.和N.Modadugu,“数据报传输层安全版本1.2”,RFC 6347,DOI 10.17487/RFC6347,2012年1月<>.

[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <>.

[RFC6536]Bierman,A.和M.Bjorklund,“网络配置协议(NETCONF)访问控制模型”,RFC 6536,DOI 10.17487/RFC6536,2012年3月<>.

[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, <>.

[RFC6614]Winter,S.,McCauley,M.,Venaas,S.,和K.Wierenga,“RADIUS的传输层安全(TLS)加密”,RFC 6614,DOI 10.17487/RFC66142012年5月<>.

[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <>.

[RFC6733]Fajardo,V.,Ed.,Arkko,J.,Loughney,J.,和G.Zorn,Ed.,“直径基准协议”,RFC 6733,DOI 10.17487/RFC6733,2012年10月<>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <>.

[RFC8040]Bierman,A.,Bjorklund,M.,和K.Watsen,“RESTCONF协议”,RFC 8040,DOI 10.17487/RFC8040,2017年1月<>.

[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, <>.

[RFC8095]Fairhurst,G.,Ed.,Trammell,B.,Ed.,和M.Kuehlewind,Ed.,“IETF传输协议和拥塞控制机制提供的服务”,RFC 8095,DOI 10.17487/RFC8095,2017年3月<>.

[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <>.

[RFC8242]Haas,J.和S.Hares,“路由系统接口(I2RS)临时状态要求”,RFC 8242,DOI 10.17487/RFC8242,2017年9月<>.



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


Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC H4S Canada

Daniel Migault Ericsson 8275跨加拿大路线圣洛朗,加拿大QC H4S


Joel Halpern Ericsson United States of America