Internet Engineering Task Force (IETF) D. Lopez
Request for Comments: 8253 O. Gonzalez de Dios
Updates: 5440 Telefonica I+D
Category: Standards Track Q. Wu
ISSN: 2070-1721 D. Dhody
Huawei
October 2017
Internet Engineering Task Force (IETF) D. Lopez
Request for Comments: 8253 O. Gonzalez de Dios
Updates: 5440 Telefonica I+D
Category: Standards Track Q. Wu
ISSN: 2070-1721 D. Dhody
Huawei
October 2017
PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)
PCEP：使用TLS为路径计算元素通信协议（PCEP）提供安全传输
Abstract
摘要
The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.
路径计算元件通信协议（PCEP）定义了路径计算客户端（PCC）和路径计算元件（PCE）之间或PCE之间的通信机制。本文档介绍PCEP——使用传输层安全性（TLS）为PCEP提供安全传输。额外的安全机制由支持PCEP的传输协议提供；因此，它们不会影响PCEP的灵活性和可扩展性。
This document updates RFC 5440 in regards to the PCEP initialization phase procedures.
本文件更新了关于PCEP初始化阶段程序的RFC 5440。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc8253.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8253.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Initiating TLS Procedures . . . . . . . . . . . . . . . . 5
3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 8
3.4. TLS Connection Establishment . . . . . . . . . . . . . . 13
3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 15
3.6. Connection Establishment Failure . . . . . . . . . . . . 16
4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 16
4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 17
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 18
6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Manageability Considerations . . . . . . . . . . . . . . . . 20
8.1. Control of Function and Policy . . . . . . . . . . . . . 20
8.2. Information and Data Models . . . . . . . . . . . . . . . 21
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
8.4. Verifying Correct Operations . . . . . . . . . . . . . . 21
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 22
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Initiating TLS Procedures . . . . . . . . . . . . . . . . 5
3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 8
3.4. TLS Connection Establishment . . . . . . . . . . . . . . 13
3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 15
3.6. Connection Establishment Failure . . . . . . . . . . . . 16
4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 16
4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 17
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 18
6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Manageability Considerations . . . . . . . . . . . . . . . . 20
8.1. Control of Function and Policy . . . . . . . . . . . . . 20
8.2. Information and Data Models . . . . . . . . . . . . . . . 21
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
8.4. Verifying Correct Operations . . . . . . . . . . . . . . 21
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 22
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The Path Computation Element Communication Protocol (PCEP) [RFC5440] defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. These interactions include requests and replies that can be critical for a sustainable network operation and adequate resource allocation; therefore, appropriate security becomes a key element in the PCE infrastructure. As the applications of the PCE framework evolve and more complex service patterns emerge, the definition of a secure mode of operation becomes more relevant.
路径计算元件通信协议（PCEP）[RFC5440]定义了路径计算客户端（PCC）和路径计算元件（PCE）之间或两个PCE之间的通信机制。这些互动包括对可持续网络运行和充分资源分配至关重要的请求和回复；因此，适当的安全性成为PCE基础设施中的关键要素。随着PCE框架应用的发展和更复杂的服务模式的出现，安全操作模式的定义变得更加重要。
The Security Considerations section of [RFC5440] analyzes the potential threats to PCEP and their consequences; it also discusses several mechanisms for protecting PCEP against security attacks, without making a specific recommendation on a particular one or defining their application in depth. Moreover, [RFC6952] states the importance of ensuring PCEP communication confidentiality, especially when PCEP communication endpoints do not reside in the same Autonomous System (AS), as the interception of PCEP messages could leak sensitive information related to computed paths and resources.
[RFC5440]的安全注意事项部分分析了对PCEP的潜在威胁及其后果；本文还讨论了保护PCEP免受安全攻击的几种机制，但没有对特定机制提出具体建议或深入定义其应用。此外，[RFC6952]指出了确保PCEP通信保密性的重要性，特别是当PCEP通信端点不在同一自治系统（AS）中时，因为PCEP消息的拦截可能泄漏与计算路径和资源相关的敏感信息。
Transport Layer Security (TLS) [RFC5246] is one of the solutions that seems most adequate among those mentioned in these documents, as it provides support for peer authentication, message encryption, and integrity. TLS provides well-known mechanisms to support key configuration and exchange, as well as means to perform security checks on the results of PCE Discovery (PCED) procedures via the Interior Gateway Protocol (IGP) [RFC5088] [RFC5089].
传输层安全性（TLS）[RFC5246]是这些文档中提到的解决方案中最合适的解决方案之一，因为它支持对等身份验证、消息加密和完整性。TLS提供了众所周知的机制来支持密钥配置和交换，以及通过内部网关协议（IGP）[RFC5088][RFC5089]对PCE发现（PCED）过程的结果执行安全检查的方法。
This document describes a security container for the transport of PCEP messages; therefore, it does not affect the flexibility and extensibility of PCEP.
本文档描述了用于传输PCEP消息的安全容器；因此，它不会影响PCEP的灵活性和可扩展性。
This document describes how to apply TLS to secure interactions with PCE, including initiation of the TLS procedures, the TLS handshake mechanism, the TLS methods for peer authentication, the applicable TLS ciphersuites for data exchange, and the handling of errors in the security checks. In the rest of this document, we refer to this usage of TLS to provide a secure transport for PCEP as "PCEPS".
本文档描述了如何将TLS应用于与PCE的安全交互，包括启动TLS过程、TLS握手机制、对等身份验证的TLS方法、适用于数据交换的TLS密码套件以及安全检查中的错误处理。在本文档的其余部分中，我们将TLS用于为PCEP提供安全传输称为“PCEP”。
Within this document, PCEP communications are described through a PCC-PCE relationship. The PCE architecture also supports PCE-PCE communication; this is achieved by requesting the PCE to fill the role of a PCC, as usual. Thus, in this document, the PCC refers to a PCC or a PCE initiating the PCEP session and acting as a client.
在本文件中，PCEP通信通过PCC-PCE关系进行描述。PCE架构还支持PCE-PCE通信；这是通过请求PCE像往常一样担任PCC的角色来实现的。因此，在本文档中，PCC是指发起PCEP会话并充当客户端的PCC或PCE。
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]所述进行解释。
The steps involved in establishing a PCEPS session are as follows:
建立PCEPS会话所涉及的步骤如下：
1. Establishment of a TCP connection.
1. 建立TCP连接。
2. Initiation of the TLS procedures by the StartTLS message from PCE to PCC and from PCC to PCE.
2. 通过从PCE到PCC以及从PCC到PCE的StartTLS消息启动TLS程序。
3. Negotiation and establishment of a TLS connection.
3. 协商和建立TLS连接。
4. Start exchange of PCEP messages as per [RFC5440].
4. 根据[RFC5440]开始交换PCEP消息。
This document uses the standard StartTLS procedure in PCEP instead of using a different port for the secured session. This is done to avoid requesting allocation of another port number for PCEPS. The StartTLS procedure makes more efficient use of scarce port numbers and allows simpler configuration of PCEP.
本文档使用PCEP中的标准StartTLS过程，而不是为安全会话使用其他端口。这样做是为了避免请求为PCEP分配另一个端口号。StartTLS过程可以更有效地利用稀缺的端口号，并允许更简单地配置PCEP。
Implementations SHOULD follow the best practices and recommendations for using TLS, as per [RFC7525].
实施应遵循[RFC7525]中关于使用TLS的最佳实践和建议。
It should be noted that this procedure updates what is defined in Sections 4.2.1 and 6.7 of [RFC5440] regarding the initialization phase and the processing of messages prior to the Open message. The details of processing, including backward compatibility, are discussed in the following sections.
应注意，本程序更新了[RFC5440]第4.2.1节和第6.7节中关于初始化阶段和打开消息之前消息处理的定义。以下各节将讨论处理的细节，包括向后兼容性。
Since PCEP can operate either with or without TLS, it is necessary for a PCEP speaker to indicate whether it wants to set up a TLS connection or not. For this purpose, this document specifies a new PCEP message called "StartTLS". Thus, the PCEP session is secured via TLS from the start, before the exchange of any other PCEP message (including the Open message). This document thus updates [RFC5440], which requires the Open message to be the first PCEP message that is exchanged. In the case of a PCEP session using TLS, the StartTLS
由于PCEP可在有或无TLS的情况下运行，因此PCEP扬声器必须指示是否要建立TLS连接。为此，本文件规定了一条名为“StartTLS”的新PCEP消息。因此，在交换任何其他PCEP消息（包括Open消息）之前，从一开始就通过TLS保护PCEP会话。因此，本文件更新了[RFC5440]，要求Open消息是交换的第一条PCEP消息。对于使用TLS的PCEP会话，StartTLS
message will be sent first. Also, a PCEP speaker that supports PCEPS MUST NOT start the OpenWait timer after the TCP establishment; instead, it starts a StartTLSWait timer as described in Section 3.3.
消息将首先发送。此外，支持PCEP的PCEP扬声器不得在TCP建立后启动OpenWait定时器；相反，它会启动一个StartTLSWait计时器，如第3.3节所述。
The PCEP speaker MAY discover that the PCEP peer supports PCEPS or can be preconfigured to use PCEPS for a given peer (see Section 4 for more details). An existing PCEP session cannot be secured via TLS; the session MUST be closed and re-established with TLS as per the procedure described in this document.
PCEP扬声器可能会发现PCEP对等机支持PCEP，或者可以预配置为对给定对等机使用PCEP（有关更多详细信息，请参阅第4节）。无法通过TLS保护现有PCEP会话；必须按照本文件中所述的程序结束会话并与TLS重新建立会话。
The StartTLS message is a PCEP message sent by a PCC to a PCE and by a PCE to a PCC in order to initiate the TLS procedure for PCEP. The PCC initiates the use of TLS by sending a StartTLS message. The PCE agrees to the use of TLS by responding with its own StartTLS message. If the PCE is configured to only support TLS, it may send the StartTLS message immediately upon TCP connection establishment; otherwise, it MUST wait to see if the PCC's first message is an Open or a StartTLS message. The TLS negotiation and establishment procedures are triggered once the PCEP speaker has sent and received the StartTLS message. The Message-Type field of the PCEP common header for the StartTLS message is set to 13.
StartTLS消息是PCC发送给PCE和PCE发送给PCC的PCEP消息，用于启动PCEP的TLS过程。PCC通过发送StartTLS消息来启动TLS的使用。PCE通过自己的StartTLS消息响应，同意使用TLS。如果PCE配置为仅支持TLS，则在TCP连接建立后，可立即发送StartTLS消息；否则，它必须等待PCC的第一条消息是Open消息还是StartTLS消息。一旦PCEP扬声器发送和接收StartTLS消息，就会触发TLS协商和建立程序。StartTLS消息的PCEP公共头的消息类型字段设置为13。
Once the TCP connection has been successfully established, the first message sent by the PCC to the PCE and by the PCE to the PCC MUST be a StartTLS message for PCEPS. Note that this is a significant change from [RFC5440], where the first PCEP message is the Open message.
一旦TCP连接成功建立，PCC发送给PCE和PCE发送给PCC的第一条消息必须是PCEP的StartTLS消息。请注意，这与[RFC5440]相比是一个重大变化，其中第一条PCEP消息是开放消息。
A PCEP speaker receiving a StartTLS message, after any other PCEP exchange has taken place (by receiving or sending any other messages from either side), MUST treat it as an unexpected message and reply with a PCEP Error (PCErr) message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 1 (Reception of StartTLS after any PCEP exchange), and it MUST close the TCP connection.
在进行任何其他PCEP交换（通过从任何一方接收或发送任何其他消息）后，接收StartTLS消息的PCEP扬声器必须将其视为意外消息，并使用错误类型设置为25（PCEP StartTLS failure）且错误值设置为1的PCEP Error（PCErr）消息进行回复（在任何PCEP交换后接收StartTLS），并且必须关闭TCP连接。
Any message received prior to the StartTLS or Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 2 (Reception of any other message apart from StartTLS, Open, or PCErr), and it MUST close the TCP connection.
在StartTLS或Open消息之前收到的任何消息都必须触发协议错误条件，导致发送PCErr消息时错误类型设置为25（PCEP StartTLS failure），错误值设置为2（接收除StartTLS、Open或PCErr之外的任何其他消息），并且必须关闭TCP连接。
If the PCEP speaker that does not support PCEPS receives a StartTLS message, it will behave according to the existing error mechanism described in Section 6.2 of [RFC5440] (if the message is received prior to an Open message) or Section 6.9 of [RFC5440] (if an unknown message is received). See Section 5 for more details.
如果不支持PCEP的PCEP扬声器接收到StartTLS消息，它将根据[RFC5440]第6.2节（如果在打开消息之前接收到消息）或[RFC5440]第6.9节（如果接收到未知消息）中描述的现有错误机制运行。详见第5节。
If the PCEP speaker that only supports PCEPS connections (as a local policy) receives an Open message, it MUST treat it as an unexpected message and reply with a PCErr message with Error-Type set to 1 (PCEP session establishment failure) and Error-value set to 1 (reception of an invalid Open message or a non Open message), and it MUST close the TCP connection.
如果仅支持PCEP连接（作为本地策略）的PCEP扬声器接收到打开的消息，则必须将其视为意外消息，并回复PCErr消息，错误类型设置为1（PCEP会话建立失败），错误值设置为1（接收无效的打开消息或非打开消息），它必须关闭TCP连接。
If a PCC supports PCEPS connections and allows non-PCEPS connections (as a local policy), it MUST first try to establish PCEPS by sending a StartTLS message, and in case it receives a PCErr message from the PCE, it MAY retry to establish a connection without PCEPS by sending an Open message. If a PCE supports PCEPS connections and allows non-PCEPS connections (as a local policy), it MUST wait to respond after TCP establishment, based on the message received from the PCC. In case of a StartTLS message, the PCE MUST respond by sending a StartTLS message and moving to TLS establishment procedures as described in this document. In case of an Open message, the PCE MUST respond with an Open message and move to the PCEP session establishment procedure as per [RFC5440]. If a PCE supports PCEPS connections only (as a local policy), it MAY send a StartTLS message to the PCC without waiting to receive a StartTLS message from the PCC.
如果PCC支持PCEPS连接并允许非PCEPS连接（作为本地策略），则它必须首先通过发送StartTLS消息尝试建立PCEPS，如果它从PCE接收到PCErr消息，它可以通过发送Open消息尝试建立没有PCEPS的连接。如果PCE支持PCEPS连接并允许非PCEPS连接（作为本地策略），则它必须根据从PCC接收的消息在TCP建立后等待响应。如果是StartTLS消息，PCE必须通过发送StartTLS消息并转至本文件所述的TLS建立程序进行响应。如果是开放消息，PCE必须响应开放消息，并按照[RFC5440]移动到PCEP会话建立程序。如果PCE仅支持PCEPS连接（作为本地策略），则它可以向PCC发送StartTLS消息，而无需等待从PCC接收StartTLS消息。
If a PCEP speaker that is unwilling or unable to negotiate TLS receives a StartTLS message, it MUST return a PCErr message (in the clear) with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to:
如果不愿意或无法协商TLS的PCEP扬声器收到StartTLS消息，则必须返回PCErr消息（清除），错误类型设置为25（PCEP StartTLS failure），错误值设置为：
o 3 (Failure, connection without TLS is not possible) if it is not willing to exchange PCEP messages without the solicited TLS connection, and it MUST close the TCP session.
o 3（失败，没有TLS的连接是不可能的）如果它不愿意在没有请求的TLS连接的情况下交换PCEP消息，它必须关闭TCP会话。
o 4 (Failure, connection without TLS is possible) if it is willing to exchange PCEP messages without the solicited TLS connection, and it MUST close the TCP session. The receiver MAY choose to attempt to re-establish the PCEP session without TLS next. Re-establishing the PCEP session without TLS SHOULD be limited to only one attempt.
o 4（失败，无TLS连接是可能的）如果它愿意在没有请求的TLS连接的情况下交换PCEP消息，并且它必须关闭TCP会话。接收机可以选择尝试在没有TLS next的情况下重新建立PCEP会话。在没有TLS的情况下重新建立PCEP会话应仅限于一次尝试。
If the PCEP speaker supports PCEPS and can establish a TLS connection, it MUST start the TLS connection negotiation and establishment steps described in Section 3.4 before the PCEP initialization procedure (see Section 4.2.1 of [RFC5440]).
如果PCEP扬声器支持PCEP并能够建立TLS连接，则必须在PCEP初始化程序（参见[RFC5440]第4.2.1节）之前启动第3.4节中所述的TLS连接协商和建立步骤。
After the exchange of StartTLS messages, if the TLS negotiation fails for some reason (e.g., the required mechanisms for certificate revocation checking are not available), both peers MUST immediately close the connection.
交换StartTLS消息后，如果TLS协商因某种原因失败（例如，所需的证书吊销检查机制不可用），则两个对等方必须立即关闭连接。
A PCEP speaker that does not support PCEPS sends the Open message directly, as per [RFC5440]. A PCEP speaker that supports PCEPS, but has learned in the last exchange the peer's willingness to re-establish the session without TLS, MAY send the Open message directly, as per [RFC5440]. Re-establishing the PCEP session without TLS SHOULD be limited to only one attempt.
根据[RFC5440]，不支持PCEP的PCEP扬声器直接发送打开消息。根据[RFC5440]，支持PCEP但在上次交换中了解到对等方愿意在没有TLS的情况下重新建立会话的PCEP演讲者可以直接发送开放消息。在没有TLS的情况下重新建立PCEP会话应仅限于一次尝试。
Given the asymmetric nature of TLS for connection establishment, it is relevant to identify the roles of each of the PCEP peers in it. The PCC SHALL act as the TLS client, and the PCE SHALL act as the TLS server as per [RFC5246].
鉴于TLS对于连接建立的不对称性质，确定每个PCEP对等点在其中的角色是相关的。根据[RFC5246]，PCC应充当TLS客户端，PCE应充当TLS服务器。
As per the recommendation from [RFC7525] to avoid downgrade attacks, PCEP peers that support PCEPS SHOULD default to strict TLS configuration, i.e., not allowing non-TLS PCEP sessions to be established. PCEPS implementations MAY provide an option to allow the operator to manually override strict TLS configuration and allow unsecured connections. Execution of this override SHOULD trigger a warning about the security implications of permitting unsecured connections.
根据[RFC7525]的建议，为避免降级攻击，支持PCEP的PCEP对等方应默认为严格的TLS配置，即不允许建立非TLS PCEP会话。PCEPS实施可提供一个选项，允许操作员手动覆盖严格的TLS配置并允许不安全的连接。执行此覆盖将触发关于允许不安全连接的安全影响的警告。
The StartTLS message is used to initiate the TLS procedure for a PCEPS session between the PCEP peers. A PCEP speaker sends the StartTLS message to request negotiation and establishment of a TLS connection for PCEP. On receiving a StartTLS message from the PCEP peer (i.e., when the PCEP speaker has sent and received the StartTLS message), it is ready to start the negotiation and establishment of TLS and move to the steps described in Section 3.4.
StartTLS消息用于为PCEP对等方之间的PCEPS会话启动TLS过程。PCEP扬声器发送StartTLS消息，请求协商和建立PCEP的TLS连接。在接收到来自PCEP对等方的StartTLS消息后（即，当PCEP扬声器已发送和接收StartTLS消息时），即可开始协商和建立TLS，并进入第3.4节所述步骤。
The collision resolution procedures described in [RFC5440] for the exchange of Open messages MUST be applied by the PCEP peers during the exchange of StartTLS messages.
在交换StartTLS消息期间，PCEP对等方必须应用[RFC5440]中描述的开放消息交换冲突解决程序。
The format of a StartTLS message is as follows:
StartTLS消息的格式如下：
<StartTLS Message>::= <Common Header>
<StartTLS Message>::= <Common Header>
The StartTLS message MUST contain only the PCEP common header with the Message-Type field set to 13.
StartTLS消息必须仅包含消息类型字段设置为13的PCEP公用标头。
Once the TCP connection has been successfully established, the PCEP speaker MUST start a timer called the "StartTLSWait timer". After the expiration of this timer, if neither the StartTLS message nor a PCErr/Open message (in case of failure and PCEPS not being supported by the peer, respectively) has been received, the PCEP speaker MUST send a PCErr message with Error-Type set to 25 (PCEP StartTLS
一旦TCP连接成功建立，PCEP扬声器必须启动一个称为“StartTLSWait定时器”的定时器。此计时器过期后，如果既没有收到StartTLS消息，也没有收到PCErr/Open消息（分别在对等方不支持故障和PCEP的情况下），PCEP扬声器必须发送错误类型设置为25（PCEP StartTLS）的PCErr消息
failure) and Error-value set to 5 (No StartTLS message (nor PCErr/ Open) before StartTLSWait timer expiry), and it MUST release the TCP connection. A RECOMMENDED value for the StartTLSWait timer is 60 seconds. The value of the StartTLSWait timer MUST NOT be less than that of the OpenWait timer.
失败），并且错误值设置为5（在StartTLSWait计时器到期之前没有StartTLS消息（也没有PCErr/Open），并且必须释放TCP连接。StartTLSWait计时器的建议值为60秒。StartTLSWait计时器的值不得小于OpenWait计时器的值。
The following figures illustrate the various interactions between a PCC and a PCE, based on the support for the PCEPS capability, during the PCEP session initialization.
下图说明了PCC和PCE之间在PCEP会话初始化期间基于对PCEPS功能的支持的各种交互。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
Figure 1: Both PCEP speakers support PCEPS (strict)
图1：两个PCEP扬声器都支持PCEP（严格）
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::| TLS Establishment
|:::::Establishment:::| Failure; both
| | peers close
the session
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::| TLS Establishment
|:::::Establishment:::| Failure; both
| | peers close
the session
Figure 2: Both PCEP speakers support PCEPS (strict) but cannot establish TLS
图2：两个PCEP扬声器都支持PCEP（严格），但无法建立TLS
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| | Does not support
| StartTLS | PCEPS and thus
| msg | sends Open
|------- |
| \ Open |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
| |
|<--------------------| Send Error
| PCErr | Type=1,Value=1
| | (non-Open message
|<--------------------| received)
| Close |
///////// TCP /////////
//////re-establish/////
Send Open | Open |
this time | msg |
|------- |
| \ Open |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| | Does not support
| StartTLS | PCEPS and thus
| msg | sends Open
|------- |
| \ Open |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
| |
|<--------------------| Send Error
| PCErr | Type=1,Value=1
| | (non-Open message
|<--------------------| received)
| Close |
///////// TCP /////////
//////re-establish/////
Send Open | Open |
this time | msg |
|------- |
| \ Open |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
Figure 3: PCE does not support connection with PCEPS, whereas PCC supports connection with or without PCEPS
图3:PCE不支持与PCEP的连接，而PCC支持与或不与PCEP的连接
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg | PCE waits
|-------------------->| for PCC and
| StartTLS | responds with
|<--------------------| Start TLS
| |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg | PCE waits
|-------------------->| for PCC and
| StartTLS | responds with
|<--------------------| Start TLS
| |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
Figure 4: Both PCEP speakers support connection with or without PCEPS
图4：两个PCEP扬声器都支持带或不带PCEP的连接
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg | PCE waits
|-------------------->| for PCC
| PCErr |
|<--------------------| Send Error
| | Type=25,Value=3
| | (Failure, connection
|<--------------------| without TLS is not
| Close | possible)
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg | PCE waits
|-------------------->| for PCC
| PCErr |
|<--------------------| Send Error
| | Type=25,Value=3
| | (Failure, connection
|<--------------------| without TLS is not
| Close | possible)
Figure 5: Both PCEP speakers support connection with or without PCEPS, but PCE cannot start TLS negotiation
图5：两个PCEP扬声器都支持带或不带PCEP的连接，但PCE无法启动TLS协商
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open |
| msg | PCE waits
|-------------------->| for PCC and
| Open | responds with
|<--------------------| Open
| |
|:::::::PCEP::::::::::|
| |
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open |
| msg | PCE waits
|-------------------->| for PCC and
| Open | responds with
|<--------------------| Open
| |
|:::::::PCEP::::::::::|
| |
Figure 6: PCE supports connection with or without PCEPS, whereas PCC does not support connection with PCEPS
图6:PCE支持带或不带PCEP的连接，而PCC不支持带PCEP的连接
Once the establishment of TLS has been agreed upon by the PCEP peers, the connection establishment SHALL follow the following steps:
一旦PCEP对等方同意建立TLS，连接建立应遵循以下步骤：
1. Immediately negotiate a TLS session according to [RFC5246]. The following restrictions apply:
1. 根据[RFC5246]立即协商TLS会话。以下限制适用：
* Support for TLS v1.2 [RFC5246] or later is REQUIRED.
* 需要支持TLS v1.2[RFC5246]或更高版本。
* Support for certificate-based mutual authentication is REQUIRED.
* 需要支持基于证书的相互身份验证。
* Negotiation of a ciphersuite providing for integrity protection is REQUIRED.
* 需要协商提供完整性保护的密码套件。
* Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED.
* 建议协商提供保密性的密码套件。
* Support for and negotiation of compression is OPTIONAL.
* 对压缩的支持和协商是可选的。
* PCEPS implementations MUST, at a minimum, support negotiation of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460] and SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as well. Implementations SHOULD support the NIST P-256 (secp256r1) curve [RFC4492]. In addition, PCEPS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support from TLS 1.3 onwards.
* PCEP实施必须至少支持TLS_ECDHE_ECDSA_与_AES_128_GCM_SHA256[RFC6460]的协商，并应支持TLS_ECDHE_ECDSA_与_AES_256_GCM_SHA384的协商。实施应支持NIST P-256（secp256r1）曲线[RFC4492]。此外，PCEPS实施必须支持强制协商，以实现从TLS 1.3开始支持的TLS版本所需的密码套件。
2. Peer authentication can be performed in any of the following two REQUIRED operation models:
2. 对等身份验证可以在以下两种必需的操作模型中的任意一种中执行：
* TLS with X.509 certificates using Public-Key Infrastructure Exchange (PKIX) trust models:
* 使用公钥基础结构交换（PKIX）信任模型的具有X.509证书的TLS：
+ Implementations MUST allow the configuration of a list of trusted Certification Authorities (CAs) for incoming connections.
+ 实现必须允许为传入连接配置受信任的证书颁发机构（CA）列表。
+ Certificate validation MUST include the verification rules as per [RFC5280].
+ 证书验证必须包括[RFC5280]规定的验证规则。
+ PCEPS implementations SHOULD incorporate revocation methods (Certificate Revocation List (CRL) downloading, Online Certificate Status Protocol (OCSP), etc.) according to the trusted CA policies.
+ PCEPS实现应根据可信CA策略合并撤销方法（证书撤销列表（CRL）下载、在线证书状态协议（OCSP）等）。
+ Implementations SHOULD indicate their trusted CAs. For TLS 1.2, this is done using "certificate_authorities" on the server side (see Section 7.4.4 of [RFC5246]) and the "TrustedAuthorities" extension on the client side (see Section 6 of [RFC6066]).
+ 实现应指明其受信任的CA。对于TLS 1.2，这是使用服务器端的“证书授权”（参见[RFC5246]第7.4.4节）和客户端的“信任授权”扩展（参见[RFC6066]第6节）来完成的。
+ Implementations MUST follow the rules and guidelines for peer validation as defined in [RFC6125]. If an expected DNS name or IP address for the peer is configured, then the implementations MUST check them against the values in the presented certificate. The DNS names and the IP addresses can be contained in the Common Name Identifier (CN-ID) [RFC6125] or the subjectAltName entries. For verification, only one of these entries is considered. The following precedence applies: for DNS name validation, DNS-ID [RFC6125] has precedence over CN-ID, and for IP address validation, subjectAltName:iPAddr has precedence over CN-ID.
+ 实施必须遵循[RFC6125]中定义的对等验证规则和指南。如果为对等方配置了预期的DNS名称或IP地址，则实现必须根据提供的证书中的值检查它们。DNS名称和IP地址可以包含在公共名称标识符（CN-ID）[RFC6125]或subjectAltName条目中。为了验证，只考虑其中一个条目。以下优先级适用：对于DNS名称验证，DNS-ID[RFC6125]优先于CN-ID；对于IP地址验证，subjectAltName:iPAddr优先于CN-ID。
+ Implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in URI-ID [RFC6125] or a set of allowed X.509 v3 Certificate Policies). The definitions of these properties are out of scope of this document.
+ 实现可允许配置证书的一组附加属性以检查对等方的通信授权（例如，URI-ID[RFC6125]中的一组允许值或一组允许的X.509 v3证书策略）。这些属性的定义超出了本文档的范围。
* TLS with X.509 certificates using certificate fingerprints: Implementations MUST allow the configuration of a list of certificates that are trusted to identify peers, identified via the fingerprint of certificate octets encoded by the
* 使用证书指纹的带有X.509证书的TLS：实现必须允许配置可信任的证书列表，以识别对等方，通过由
Distinguished Encoding Rules (DER). Implementations MUST support SHA-256 as defined by [SHS] as the hash algorithm for the fingerprint, but a later revision may demand support for a stronger hash function.
区分编码规则（DER）。实现必须支持[SHS]定义的SHA-256作为指纹的哈希算法，但以后的版本可能要求支持更强的哈希函数。
3. Start exchanging PCEP messages.
3. 开始交换PCEP消息。
* Once the TLS connection has been successfully established, the PCEP speaker MUST start the OpenWait timer [RFC5440]; after the expiration of this timer, if no Open message has been received, the PCEP speaker sends a PCErr message and releases the TCP/TLS connection.
* 一旦TLS连接成功建立，PCEP扬声器必须启动OpenWait定时器[RFC5440]；此计时器过期后，如果未收到打开消息，PCEP扬声器将发送PCErr消息并释放TCP/TLS连接。
Depending on the peer authentication method in use, PCEPS supports different operation modes to establish a peer's identity and whether it is entitled to perform requests or can be considered authoritative in its replies. PCEPS implementations SHOULD provide mechanisms for associating peer identities with different levels of access and/or authoritativeness, and they MUST provide a mechanism for establishing a default level for properly identified peers. Any connection established with a peer that cannot be properly identified SHALL be terminated before any PCEP exchange takes place.
根据使用的对等身份验证方法，PCEP支持不同的操作模式来建立对等身份，以及它是否有权执行请求或在其答复中被视为权威。PCEP实现应提供将对等身份与不同访问和/或授权级别关联的机制，并且必须提供为正确识别的对等身份建立默认级别的机制。在任何PCEP交换发生之前，应终止与无法正确识别的对等方建立的任何连接。
In TLS X.509 mode using fingerprints, a peer is uniquely identified by the fingerprint of the presented certificate.
在使用指纹的TLS X.509模式中，对等方通过所提供证书的指纹进行唯一标识。
There are numerous trust models in PKIX environments, and it is beyond the scope of this document to define how a particular deployment determines whether a peer is trustworthy. Implementations that want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. At least the following parameters of the X.509 certificate SHOULD be exposed:
PKIX环境中有许多信任模型，定义特定部署如何确定对等方是否可信超出了本文档的范围。希望支持多种信任模型的实现应该向管理员公开所提供证书的尽可能多的详细信息，以便管理员可以实现信任模型。应至少公开X.509证书的以下参数：
o Peer's IP Address
o 对等方的IP地址
o Peer's Fully Qualified Domain Name (FQDN)
o 对等方的完全限定域名（FQDN）
o Certificate Fingerprint
o 证书指纹
o Issuer
o 发行人
o Subject
o 主题
o All X.509 v3 Extended Key Usage
o 所有X.509 v3扩展密钥的使用
o All X.509 v3 Subject Alternative Name
o 所有X.509 v3主题备选名称
o All X.509 v3 Certificate Policies
o 所有X.509 v3证书策略
Note that the remote IP address used for the TCP session establishment is also exposed.
请注意，用于TCP会话建立的远程IP地址也是公开的。
[RFC8232] specifies a Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) as an optional TLV that is included in the OPEN object. It contains a unique identifier for the node that does not change during the lifetime of the PCEP speaker. An implementation would thus expose the speaker entity identifier as part of the X.509 v3 certificate's subjectAltName:otherName, so that an implementation could use this identifier for the peer identification trust model.
[RFC8232]将说话人实体标识符TLV（Speaker-Entity-ID）指定为开放对象中包含的可选TLV。它包含节点的唯一标识符，该标识符在PCEP扬声器的使用寿命期间不会更改。因此，一个实现将把说话人实体标识符作为X.509 v3证书的subjectAltName:otherName的一部分公开，以便一个实现可以将该标识符用于对等身份验证信任模型。
In addition, a PCC MAY apply the procedures described in "DNS-Based Authentication of Named Entities (DANE)" [RFC6698] to verify its peer identity when using DNS discovery. See Section 4.1 for further details.
此外，当使用DNS发现时，PCC可以应用“基于DNS的命名实体认证（DANE）”[RFC6698]中描述的过程来验证其对等身份。详见第4.1节。
In case the initial TLS negotiation or the peer identity check fails, according to the procedures listed in this document, both peers MUST immediately close the connection.
如果初始TLS协商或对等身份检查失败，根据本文档中列出的程序，两个对等方必须立即关闭连接。
The initiator SHOULD follow the procedure listed in [RFC5440] to retry session setup as per the exponential back-off session establishment retry procedure.
发起者应按照[RFC5440]中列出的程序，按照指数退避会话建立重试程序重试会话设置。
This document does not specify any discovery mechanism for support of PCEPS. [PCE-DISCOVERY-PCEPS-SUPPORT] and [PCE-DISCOVERY-DNS] make the following proposals:
本文档未指定任何支持PCEP的发现机制。[PCE-DISCOVERY-PCEPS-SUPPORT]和[PCE-DISCOVERY-DNS]提出以下建议：
o A PCE can advertise its capability to support PCEPS using the IGP's advertisement mechanism of the PCED information. The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise PCE capabilities. It is present within the PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively. PCE capability bits are defined in [RFC5088]. A new capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute to distribute PCEP security support information is proposed in [PCE-DISCOVERY-PCEPS-SUPPORT].
o PCE可以使用IGP的PCED信息发布机制发布其支持PCEP的能力。PCE-CAP-FLAGS子TLV是用于公布PCE功能的可选子TLV。它存在于OSPF或is-is携带的PCED子TLV内。[RFC5088]和[RFC5089]分别为OSPF和IS-IS中携带的子TLV提供描述和处理规则。PCE能力位在[RFC5088]中定义。[PCE-DISCOVERY-PCEPS-support]中提出了PCE-CAP-FLAGS子TLV的新功能标志位，该标志位可作为分发PCEP安全支持信息的属性发布。
o A PCE can advertise its capability to support PCEPS using DNS [PCE-DISCOVERY-DNS] by identifying the support of TLS.
o PCE可以通过识别TLS的支持来宣传其使用DNS[PCE-DISCOVERY-DNS]支持PCEP的能力。
DANE [RFC6698] defines a secure method to associate the certificate that is obtained from a TLS server with a domain name using DNS, i.e., using the TLSA DNS resource record (RR) to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". The DNS information needs to be protected by DNS Security (DNSSEC). A PCC willing to apply DANE to verify server identity MUST conform to the rules defined in Section 4 of [RFC6698]. The implementation MUST support service certificate constraint (TLSA certificate usages type 1) with Matching type 1 (SHA2-256) as described in [RFC6698] and [RFC7671]. The server's domain name must be authorized separately, as TLSA does not provide any useful authorization guarantees.
DANE[RFC6698]定义了一种安全方法，使用DNS将从TLS服务器获得的证书与域名相关联，即使用TLSA DNS资源记录（RR）将TLS服务器证书或公钥与找到记录的域名相关联，从而形成“TLSA证书关联”。DNS信息需要由DNS安全性（DNSSEC）保护。愿意应用DANE验证服务器身份的PCC必须符合[RFC6698]第4节中定义的规则。如[RFC6698]和[RFC7671]中所述，实现必须支持具有匹配类型1（SHA2-256）的服务证书约束（TLSA证书使用类型1）。服务器的域名必须单独授权，因为TLSA不提供任何有用的授权保证。
The procedures described in this document define a security container for the transport of PCEP requests and replies carried by a TLS connection initiated by means of a specific extended message (StartTLS) that does not interfere with PCEP speaker implementations not supporting it.
本文档中描述的过程定义了一个安全容器，用于传输通过特定扩展消息（StartTLS）启动的TLS连接承载的PCEP请求和应答，该扩展消息不会干扰不支持PCEP的扬声器实现。
A PCC that does not support PCEPS will send an Open message as the first message on TCP establishment. A PCE that only supports PCEPS will send a StartTLS message on TCP establishment. The PCC would consider the received StartTLS message as an error and behave according to the existing error mechanism of [RFC5440], i.e., it would send a PCErr message with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message) and close the session.
不支持PCEP的PCC将发送一条开放消息作为TCP建立时的第一条消息。仅支持PCEP的PCE将在TCP建立时发送StartTLS消息。PCC将接收的STARTTLS消息视为错误并根据[RCFC4040]的现有错误机制进行行为，即，它将发送具有错误类型1（PCEP会话建立失败）的PCRR消息和错误值1（接收无效的打开消息或非打开消息）并关闭会话。
A PCC that support PCEPS will send a StartTLS message as the first message on TCP establishment. A PCE that does not support PCEPS would consider receiving a StartTLS message as an error, respond with a PCErr message with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message), and close the session.
支持PCEP的PCC将发送StartTLS消息作为TCP建立时的第一条消息。不支持PCEPS的PCE将考虑接收STARTTLS消息作为错误，响应具有错误类型1（PCEP会话建立失败）的PCRR消息和错误值1（接收无效的打开消息或非打开消息），并关闭会话。
If a StartTLS message is received at any other time by a PCEP speaker that does not implement PCEPS, it would consider it as an unknown message and would behave according to the existing error mechanism of [RFC5440], i.e., it would send a PCErr message with Error-Type 2 (Capability not supported) and close the session.
如果在任何其他时间由不执行PCEPS的PCEP扬声器接收STARTTLS消息，它会认为它是未知消息，并且将根据[RCFC4040]的现有错误机制来执行，即，它将发送具有错误类型2（不支持的能力）的PCRR消息并关闭会话。
An existing PCEP session cannot be upgraded to PCEPS; the session needs to be terminated and re-established as per the procedure described in this document. During the incremental upgrade, the PCEP speaker SHOULD allow session establishment with and without TLS. Once both PCEP speakers are upgraded to support PCEPS, the PCEP session is re-established with TLS; otherwise, a PCEP session without TLS is set up. A redundant PCE MAY also be used during the incremental deployment to take over the PCE undergoing upgrade. Once the upgrade is completed, support for the unsecured version SHOULD be removed.
现有PCEP会话无法升级为PCEP；需要根据本文件中描述的程序终止和重新建立会话。在增量升级过程中，PCEP扬声器应允许在有TLS和无TLS的情况下建立会话。一旦两个PCEP扬声器都升级为支持PCEP，则会与TLS重新建立PCEP会话；否则，将设置没有TLS的PCEP会话。在增量部署期间，也可以使用冗余PCE来接管正在升级的PCE。升级完成后，应删除对不安全版本的支持。
A PCE that accepts connections with or without PCEPS would respond based on the message received from the PCC. A PCC that supports connection with or without PCEPS would first attempt to connect with PCEPS, and in case of error, it MAY retry to establish connection without PCEPS. For successful TLS operations with PCEP, both PCEP peers in the network would need to be upgraded to support this document.
接受带或不带PCEP连接的PCE将根据从PCC接收的消息进行响应。支持使用或不使用PCEP连接的PCC将首先尝试使用PCEP连接，如果出现错误，它可能会尝试在不使用PCEP的情况下建立连接。为了使用PCEP成功运行TLS，需要升级网络中的两个PCEP对等方以支持本文档。
Note that a PCEP implementation that supports PCEPS would respond with a PCErr message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 2 (Reception of any other message apart from StartTLS, Open, or PCErr) if any other message is sent before a StartTLS or Open message. If the sender of the invalid message is a PCEP implementation that does not support PCEPS, it will not be able to understand this error. A PCEPS implementation could also send the PCErr message as per [RFC5440] with Error-Type 1 (PCEP session establishment failure) and Error-value 1 (reception of an invalid Open message or a non Open message) before closing the session.
请注意，支持PCEP的PCEP实现将响应PCErr消息，错误类型设置为25（PCEP StartTLS failure），错误值设置为2（接收StartTLS、Open或PCErr之外的任何其他消息），前提是在StartTLS或Open消息之前发送任何其他消息。如果无效消息的发送方是不支持PCEP的PCEP实现，它将无法理解此错误。PCEPS实现还可以根据[RFC5440]发送PCErr消息，错误类型为1（PCEP会话建立失败），错误值为1（接收无效的打开消息或非打开消息），然后关闭会话。
The following new message type has been allocated within the "PCEP Messages" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
已在“路径计算元素协议（PCEP）编号”注册表的“PCEP消息”子注册表中分配了以下新消息类型：
Value Description Reference
-------------------------------------------------------
13 StartTLS This document
Value Description Reference
-------------------------------------------------------
13 StartTLS This document
The following new error types and error values have been allocated within the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
在“路径计算元素协议（PCEP）编号”注册表的“PCEP-error对象错误类型和值”子注册表中分配了以下新的错误类型和错误值：
Error-Type Meaning Error-value Reference
---------------------------------------------------------------------
25 PCEP StartTLS 0: Unassigned This document
failure
1: Reception of This document
StartTLS after
any PCEP exchange
Error-Type Meaning Error-value Reference
---------------------------------------------------------------------
25 PCEP StartTLS 0: Unassigned This document
failure
1: Reception of This document
StartTLS after
any PCEP exchange
2: Reception of This document any other message apart from StartTLS, Open, or PCErr
2：接收本文件除StartTLS、Open或PCErr之外的任何其他信息
3: Failure, connection This document without TLS is not possible
3：连接失败，不使用TLS无法连接本文件
4: Failure, connection This document without TLS is possible
4：连接失败，无TLS的本文件是可能的
5: No StartTLS message This document (nor PCErr/Open) before StartTLSWait timer expiry
5:StartTLSWait计时器到期前，此文档没有StartTLS消息（也没有PCErr/Open）
While the application of TLS satisfies the requirement on confidentiality as well as fine-grained, policy-based peer authentication, there are security threats that it cannot address. It may be advisable to apply additional protection measures, in particular in what relates to attacks specifically addressed to forging the TCP connection underpinning TLS, especially in the case of long-lived connections. One of these measures is the application of the TCP Authentication Option (TCP-AO) [RFC5925], which is fully compatible with and deemed as complementary to TLS. The mechanisms to configure the requirements to use TCP-AO and other lower-layer protection measures with a particular peer are outside the scope of this document.
虽然TLS的应用程序满足保密性以及细粒度、基于策略的对等身份验证的要求，但也存在它无法解决的安全威胁。可能建议应用额外的保护措施，特别是在与攻击相关的情况下，特别是在长寿命连接的情况下，特别是针对构建作为TLS基础的TCP连接的攻击。这些措施之一是应用TCP认证选项（TCP-AO）[RFC5925]，该选项与TLS完全兼容，并被视为TLS的补充。对特定对等机配置使用TCP-AO和其他低层保护措施的要求的机制不在本文档的范围内。
Since computational resources required by the TLS handshake and ciphersuite are higher than unencrypted TCP, clients connecting to a PCEPS server can more easily create high-load conditions, and a malicious client might create a denial-of-service attack more easily.
由于TLS握手和密码套件所需的计算资源高于未加密的TCP，因此连接到PCEPS服务器的客户端更容易造成高负载情况，恶意客户端可能更容易造成拒绝服务攻击。
Some TLS ciphersuites only provide integrity validation of their payload and provide no encryption; such ciphersuites SHOULD NOT be used by default. Administrators MAY allow the usage of these ciphersuites after careful weighting of the risk of relevant internal data leakage that can occur in such a case, as explicitly stated by [RFC6952].
一些TLS密码套件只提供有效负载的完整性验证，不提供加密；默认情况下不应使用此类密码套件。如[RFC6952]明确规定，管理员可在仔细权衡在这种情况下可能发生的相关内部数据泄漏风险后，允许使用这些密码套件。
When using certificate fingerprints to identify PCEPS peers, any two certificates that produce the same hash value will be considered the same peer. Therefore, it is important to make sure that the hash function used is cryptographically uncompromised, so that attackers are very unlikely to be able to produce a hash collision with a certificate of their choice. This document mandates support for SHA-256 as defined by [SHS], but a later revision may demand support for stronger functions if suitable attacks on it are known.
当使用证书指纹识别PCEP对等方时，产生相同哈希值的任何两个证书都将被视为同一对等方。因此，重要的是要确保所使用的哈希函数是加密的，这样攻击者就不太可能与他们选择的证书产生哈希冲突。本文档要求支持[SHS]定义的SHA-256，但如果已知对其进行适当的攻击，则更高版本可能要求支持更强大的功能。
PCEPS implementations that continue to accept connections without TLS are susceptible to downgrade attacks as described in [RFC7457]. An attacker could attempt to remove the use of StartTLS messages that request the use of TLS as it pass on the wire in clear and could also attempt to inject a PCErr message that suggests attempting PCEP connection without TLS.
如[RFC7457]所述，继续接受无TLS连接的PCEP实现容易受到降级攻击。攻击者可以尝试删除StartTLS消息的使用，该消息在TLS通过线路时请求使用TLS，还可以尝试注入PCErr消息，该消息建议尝试在没有TLS的情况下进行PCEP连接。
The guidance given in [RFC7525] SHOULD be followed to avoid attacks on TLS.
应遵循[RFC7525]中给出的指南，以避免对TLS的攻击。
All manageability requirements and considerations listed in [RFC5440] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.
[RFC5440]中列出的所有可管理性要求和注意事项适用于本文件中定义的PCEP协议扩展。此外，本节中列出的要求和注意事项也适用。
A PCE or PCC implementation SHOULD allow configuring the PCEP security via TLS capabilities as described in this document.
PCE或PCC实施应允许通过本文件所述的TLS功能配置PCEP安全性。
A PCE or PCC implementation supporting PCEP security via TLS MUST support general TLS configuration as per [RFC5246]. At least the configuration of one of the trust models and its corresponding parameters, as described in Sections 3.4 and 3.5, MUST be supported by the implementation.
根据[RFC5246]，通过TLS支持PCEP安全的PCE或PCC实现必须支持一般TLS配置。如第3.4节和第3.5节所述，实施必须至少支持一个信任模型及其相应参数的配置。
A PCEPS implementation SHOULD allow configuring the StartTLSWait timer value.
PCEPS实现应允许配置StartTLSWait计时器值。
PCEPS implementations MAY provide an option to allow the operator to manually override strict TLS configuration and allow unsecure connections. Execution of this override SHOULD trigger a warning about the security implications of permitting unsecure connections.
PCEPS实施可提供一个选项，允许操作员手动覆盖严格的TLS配置，并允许不安全的连接。执行此重写将触发关于允许不安全连接的安全影响的警告。
Further, the operator needs to develop suitable security policies around PCEP within his network. The PCEP peers SHOULD provide ways for the operator to complete the following tasks in regards to a PCEP session:
此外，运营商需要在其网络内围绕PCEP制定适当的安全策略。PCEP对等方应为操作员提供方法，以完成与PCEP会话相关的以下任务：
o Determine if a session is protected via PCEPS.
o 确定会话是否通过PCEP受到保护。
o Determine the version of TLS, the mechanism used for authentication, and the ciphersuite in use.
o 确定TLS的版本、用于身份验证的机制以及正在使用的密码套件。
o Determine if the certificate could not be verified and the reason for this circumstance.
o 确定证书是否无法验证以及出现这种情况的原因。
o Inspect the certificate offered by the PCEP peer.
o 检查PCEP同行提供的证书。
o Be warned if the StartTLS procedure fails for the PCEP peers that are known to support PCEPS via configurations or capability advertisements.
o 如果已知通过配置或功能公告支持PCEP的PCEP对等方的StartTLS过程失败，请发出警告。
The PCEP MIB module is defined in [RFC7420]. The MIB module could be extended to include the ability to view the PCEPS capability, TLS-related information, and the TLS status for each PCEP peer.
PCEP MIB模块在[RFC7420]中定义。MIB模块可以扩展，以包括查看PCEP能力、TLS相关信息以及每个PCEP对等机的TLS状态的能力。
Further, to allow the operator to configure the PCEPS capability and various TLS-related parameters as well as to view the current TLS status for a PCEP session, the PCEP YANG module [PCEP-YANG] is extended to include TLS-related information.
此外，为了允许操作员配置PCEP能力和各种TLS相关参数以及查看PCEP会话的当前TLS状态，PCEP YANG模块[PCEP-YANG]被扩展以包括TLS相关信息。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440] and [RFC5246].
除了[RFC5440]和[RFC5246]中已经列出的机制外，本文件中定义的机制并不意味着任何新的活性检测和监控要求。
A PCEPS implementation SHOULD log error events and provide PCEPS failure statistics with reasons.
PCEPS实现应记录错误事件，并提供PCEPS故障统计信息和原因。
Mechanisms defined in this document do not imply any new requirements on other protocols. Note that Section 4 lists possible discovery mechanisms for support of PCEPS.
本文件中定义的机制并不意味着对其他协议有任何新的要求。请注意，第4节列出了支持PCEP的可能发现机制。
Mechanisms defined in this document do not have any significant impact on network operations in addition to those already listed in [RFC5440] and on the policy and management implications discussed above.
除[RFC5440]中已列出的机制外，本文件中定义的机制对网络运营以及上述政策和管理影响没有任何重大影响。
[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>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<https://www.rfc-editor.org/info/rfc7671>.
[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>.
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[SHS]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[PCE-DISCOVERY-DNS] Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, "Path Computation Element (PCE) Discovery using Domain Name System(DNS)", Work in Progress, draft-wu-pce-dns-pce-discovery-10, March 2017.
[PCE-DISCOVERY-DNS]Wu，Q.，Dhody，D.，King，D.，Lopez，D.，和J.Tantsura，“使用域名系统（DNS）的路径计算元素（PCE）发现”，正在进行的工作，草稿-Wu-PCE-DNS-PCE-DISCOVERY-10，2017年3月。
[PCE-DISCOVERY-PCEPS-SUPPORT] Lopez, D., Wu, Q., Dhody, D., Wang, Z., and D. King, "IGP extension for PCEP security capability support in the PCE discovery", Work in Progress, draft-wu-pce-discovery-pceps-support-07, March 2017.
[PCE-DISCOVERY-PCEPS-SUPPORT]Lopez，D.，Wu，Q.，Dhody，D.，Wang，Z.，和D.King，“PCE发现中PCEP安全能力支持的IGP扩展”，正在进行的工作，草稿-Wu-PCE-DISCOVERY-PCEPS-SUPPORT-07，2017年3月。
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017.
[PCEP-YANG]Dhody，D.，Hardwick，J.，Beeram，V.，和J.Tantsura，“路径计算元素通信协议（PCEP）的YANG数据模型”，正在进行的工作，草稿-ietf-pce-PCEP-YANG-052017年7月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <https://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<https://www.rfc-editor.org/info/rfc4492>.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, DOI 10.17487/RFC4513, June 2006, <https://www.rfc-editor.org/info/rfc4513>.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC 4513，DOI 10.17487/RFC4513，2006年6月<https://www.rfc-editor.org/info/rfc4513>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5088]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，DOI 10.17487/RFC5088，2008年1月<https://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5089]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，DOI 10.17487/RFC5089，2008年1月<https://www.rfc-editor.org/info/rfc5089>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, January 2012, <https://www.rfc-editor.org/info/rfc6460>.
[RFC6460]Salter，M.和R.Housley，“传输层安全（TLS）的套件B配置文件”，RFC 6460，DOI 10.17487/RFC6460，2012年1月<https://www.rfc-editor.org/info/rfc6460>.
[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>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，DOI 10.17487/RFC6952，2013年5月<https://www.rfc-editor.org/info/rfc6952>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素通信协议（PCEP）管理信息库（MIB）模块”，RFC 7420，DOI 10.17487/RFC7420，2014年12月<https://www.rfc-editor.org/info/rfc7420>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457]Sheffer，Y.，Holz，R.，和P.Saint Andre，“总结对传输层安全（TLS）和数据报TLS（DTLS）的已知攻击”，RFC 7457，DOI 10.17487/RFC7457，2015年2月<https://www.rfc-editor.org/info/rfc7457>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>.
[RFC8232]Crabbe，E.，Minei，I.，Medved，J.，Varga，R.，Zhang，X.，和D.Dhody，“有状态PCE标签交换路径状态同步程序的优化”，RFC 8232，DOI 10.17487/RFC8232，2017年9月<https://www.rfc-editor.org/info/rfc8232>.
Acknowledgements
致谢
This specification relies on the analysis and profiling of TLS included in [RFC6614] and the procedures described for the StartTLS command in [RFC4513].
本规范依赖于[RFC6614]中包含的TLS分析和评测，以及[RFC4513]中描述的StartTLS命令程序。
We would like to thank Joe Touch for his suggestions and support regarding the StartTLS mechanisms.
我们要感谢Joe Touch对StartTLS机制的建议和支持。
Thanks to Daniel King for reminding the authors about manageability considerations.
感谢Daniel King提醒作者关于可管理性的注意事项。
Thanks to Cyril Margaria for shepherding this document.
感谢Cyril Margaria指导这份文件。
Thanks to David Mandelberg for early SECDIR review comments as well as further review during IETF last call.
感谢David Mandelberg提供早期SECDIR审查意见，以及IETF最后一次通话期间的进一步审查。
Thanks to Dan Frost for the RTGDIR review and comments.
感谢Dan Frost对RTGDIR的评论和评论。
Thanks to Dale Worley for the Gen-ART review and comments.
感谢Dale Worley对Gen ART的评论和评论。
Thanks to Tianran Zhou for the OPSDIR review.
感谢周天然的OPSDIR审查。
Thanks to Deborah Brungard for being the responsible AD and guiding the authors as needed.
感谢Deborah Brungard作为负责任的广告，并根据需要指导作者。
Also, thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen Moriarty, Suresh Krishnan, Ben Campbell, and Alexey Melnikov for the IESG review and comments.
此外，感谢米尔贾·库莱温德、埃里克·雷斯科拉、沃伦·库马里、凯瑟琳·莫里亚蒂、苏雷什·克里希南、本·坎贝尔和阿列克谢·梅尔尼科夫对IESG的评论和评论。
Authors' Addresses
作者地址
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
Diego R.Lopez Telefonica I+D Don Ramon de la Cruz，82马德里28006西班牙
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
奥斯卡·冈萨雷斯（Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz），82马德里28006西班牙
Phone: +34 913 129 041
Email: oscar.gonzalezdedios@telefonica.com
Phone: +34 913 129 041
Email: oscar.gonzalezdedios@telefonica.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
Email: sunseawq@huawei.com
Email: sunseawq@huawei.com
Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore, KA 560066 India
Dhruv Dhody华为Divyashree技术园，印度卡州班加罗尔怀特菲尔德，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com