[要約] このRFCは、PCEプロトコル（PCEP）において、TLS (Transport Layer Security) を使用して通信チャネルを保護するための仕様「PCEPS」を定義しています。PCE（パス計算要素）とPCC（ルータ）間のメッセージ交換に機密性、整合性、および相互認証を提供し、外部からの不正な経路操作や情報の盗聴からトラフィックエンジニアリングインフラを保護します。
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)
PCEPS：パス計算要素通信プロトコル（PCEP）のためのセキュアトランスポートとしてのTLSの使用法
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間の通信のメカニズムを定義します。このドキュメントでは、PCEPSについて説明します。PCEPに安全なトランスポートを提供するためのトランスポート層セキュリティ（TLS）の使用法です。追加のセキュリティメカニズムは、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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）の間、または2つの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.
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].
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暗号スイート、およびセキュリティチェックでのエラーの処理が含まれます。このドキュメントの残りの部分では、PCEPに安全なトランスポートを提供するためのTLSのこの使用法を「PCEPS」と呼びます。
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 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接続のネゴシエーションと確立。
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手順を使用しています。これは、PCEPSに別のポート番号の割り当てを要求しないようにするために行われます。 StartTLSプロシージャは、希少なポート番号をより効率的に使用し、PCEPの構成をより簡単にします。
Implementations SHOULD follow the best practices and recommendations for using TLS, as per [RFC7525].
実装は、[RFC7525]に従って、TLSを使用するためのベストプラクティスと推奨事項に従うべきです (SHOULD)。
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.
この手順は、初期化フェーズとOpenメッセージの前のメッセージの処理に関して、[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 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はTLSの有無に関係なく動作できるため、PCEPスピーカーがTLS接続をセットアップするかどうかを示す必要があります。この目的のために、このドキュメントでは、「StartTLS」と呼ばれる新しいPCEPメッセージを指定します。したがって、PCEPセッションは、他のPCEPメッセージ（Openメッセージを含む）を交換する前に、TLSを介して最初から保護されます。したがって、このドキュメントは[RFC5440]を更新し、Openメッセージは交換される最初のPCEPメッセージである必要があります。 TLSを使用するPCEPセッションの場合、StartTLSメッセージが最初に送信されます。また、PCEPSをサポートするPCEPスピーカーは、TCP確立後にOpenWaitタイマーを開始してはなりません（MUST NOT）。代わりに、セクション3.3で説明されているように、StartTLSWaitタイマーを開始します。
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ピアがPCEPSをサポートしていることを発見してもよく (MAY)、あるいは特定のピアに対してPCEPSを使用するよう事前に設定されることもできます（詳細については4節を参照）。既存のPCEPセッションをTLSで保護することはできません。そのセッションは閉じなければならず (MUST)、この文書で説明する手順に従って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メッセージは、PCEPのTLS手順を開始するために、PCCからPCEに、PCEからPCCに送信されるPCEPメッセージです。 PCCはStartTLSメッセージを送信してTLSの使用を開始します。 PCEは、独自のStartTLSメッセージで応答することにより、TLSの使用に同意します。 PCEがTLSのみをサポートするように構成されている場合、TCP接続が確立されるとすぐにStartTLSメッセージを送信できます。そうでない場合は、PCCの最初のメッセージがOpenとStartTLSのどちらであるかを確認するまで待たなければなりません (MUST)。 PCEPスピーカーがStartTLSメッセージを送受信すると、TLSネゴシエーションおよび確立手順がトリガーされます。 StartTLSメッセージのPCEP共通ヘッダーのMessage-Typeフィールドは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に送信される最初のメッセージは、PCEPSのStartTLSメッセージでなければなりません (MUST)。これは、最初のPCEPメッセージがOpenメッセージである[RFC5440]からの大幅な変更であることに注意してください。
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.
StartTLSメッセージを受信するPCEPスピーカーは、他のPCEP交換が行われた後（いずれかの側から他のメッセージを受信または送信することにより）、それを予期しないメッセージとして扱い、エラータイプのPCEPエラー（PCErr）メッセージで応答しなければなりません (MUST)。 25（PCEP StartTLS失敗）に設定し、Error-valueを1（PCEP交換後のStartTLSの受信）に設定し、TCP接続を閉じなければなりません (MUST)。
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メッセージをError-Typeを25（PCEP StartTLS失敗）に設定し、Error-valueを2（他のメッセージ以外のメッセージの受信）に送信しなければなりません (MUST)StartTLS、Open、またはPCErr）。TCP接続を閉じなければなりません (MUST)。
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.
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.
（ローカルポリシーとして）PCEPS接続のみをサポートするPCEPスピーカーがOpenメッセージを受信した場合、それを予期しないメッセージとして扱い、Error-Typeを1（PCEP session establishment failure）、Error-valueを1（reception of an invalid Open message or a non Open message）に設定したPCErrメッセージで応答しなければならず (MUST)、TCP接続を閉じなければなりません (MUST)。
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の確立を試みなければならず (MUST)、PCEからPCErrメッセージを受信した場合は、Openメッセージを送信してPCEPSなしの接続の確立を再試行してもよい (MAY) です。PCEがPCEPS接続をサポートし、かつ（ローカルポリシーとして）PCEPSでない接続も許可する場合、TCPの確立後、PCCから受信したメッセージに基づいて応答するために待機しなければなりません (MUST)。StartTLSメッセージの場合、PCEは、StartTLSメッセージを送信し、この文書で説明するTLS確立の手順に移ることによって応答しなければなりません (MUST)。Openメッセージの場合、PCEはOpenメッセージで応答し、[RFC5440]に従ってPCEPセッション確立の手順に移らなければなりません (MUST)。PCEが（ローカルポリシーとして）PCEPS接続のみをサポートする場合、PCCからのStartTLSメッセージの受信を待たずにPCCにStartTLSメッセージを送信してもよい (MAY) です。
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メッセージを受信した場合、エラータイプが25（PCEP StartTLS失敗）に設定され、エラー値が次のように設定されたPCErrメッセージを（クリアテキストで）返さなければなりません (MUST)。
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セッションを閉じなければなりません (MUST)。
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セッションを閉じなければならない (MUST)場合。受信者は、次にTLSなしでPCEPセッションを再確立しようと試みることを選択してもよい（MAY）。 TLSを使用しないPCEPセッションの再確立は、1回の試行に限定すべきです（SHOULD）。
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スピーカーがPCEPSをサポートし、TLS接続を確立できる場合は、PCEP初期化手順の前にセクション3.4で説明されているTLS接続ネゴシエーションおよび確立手順を開始しなければなりません (MUST)（[RFC5440]のセクション4.2.1を参照）。
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ネゴシエーションが失敗した場合（たとえば、証明書失効チェックに必要なメカニズムが利用できない場合）は、両方のピアは直ちに接続を閉じなければなりません (MUST)。
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.
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クライアントとして動作しなければならず (SHALL)、PCEはTLSサーバーとして動作しなければなりません (SHALL)。
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]の推奨に従って、PCEPSをサポートするPCEPピアはデフォルトで厳密なTLS構成にすべきです (SHOULD)（つまり、非TLS PCEPセッションの確立を許可しない）。 PCEPS実装は、オペレーターが厳密なTLS構成を手動でオーバーライドして、保護されていない接続を許可できるようにするオプションを提供する場合があります (MAY)。このオーバーライドを実行すると、セキュリティで保護されていない接続を許可することによるセキュリティへの影響に関する警告がトリガーされます（SHOULD）。
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.
[RFC5440]で説明されているOpenメッセージの交換に関する衝突解決手順は、StartTLSメッセージの交換中にPCEPピアによって適用されなければなりません (MUST)。
The format of a StartTLS message is as follows:
StartTLSメッセージの形式は次のとおりです。
<StartTLS Message>::= <Common Header>
The StartTLS message MUST contain only the PCEP common header with the Message-Type field set to 13.
StartTLSメッセージには、Message-Typeフィールドが13に設定されたPCEP共通ヘッダーのみが含まれていなければなりません (MUST)。
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 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.
TCP接続が正常に確立されると、PCEPスピーカーは「StartTLSWaitタイマー」と呼ばれるタイマーを開始しなければなりません (MUST)。このタイマーの満了後、StartTLSメッセージもPCErr/Openメッセージ（それぞれ失敗の場合とピアがPCEPSをサポートしていない場合）も受信していなければ、PCEPスピーカーは、Error-Typeを25（PCEP StartTLS failure）、Error-valueを5（No StartTLS message (nor PCErr/Open) before StartTLSWait timer expiry）に設定したPCErrメッセージを送信しなければならず (MUST)、TCP接続を解放しなければなりません (MUST)。StartTLSWaitタイマーの推奨値 (RECOMMENDED) は60秒です。StartTLSWaitタイマーの値は、OpenWaitタイマーの値より小さくしてはなりません (MUST NOT)。
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.
次の図は、PCEPセッションの初期化中に、PCEPS機能のサポートに基づいて、PCCとPCEの間のさまざまな相互作用を示しています。
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
Figure 1: Both PCEP speakers support PCEPS (strict)
図1：両方のPCEPスピーカーがPCEPSをサポート（厳密）
+-+-+ +-+-+
|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スピーカーがPCEPS（厳密）をサポートしていますが、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 |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
Figure 3: PCE does not support connection with PCEPS, whereas PCC supports connection with or without PCEPS
図3：PCEはPCEPSとの接続をサポートしていませんが、PCCはPCEPSの有無にかかわらず接続をサポートしています
+-+-+ +-+-+
|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スピーカーがPCEPSの有無にかかわらず接続をサポート
+-+-+ +-+-+
|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スピーカーはPCEPSの有無にかかわらず接続をサポートしますが、PCEはTLSネゴシエーションを開始できません
+-+-+ +-+-+
|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はPCEPSの有無にかかわらず接続をサポートしますが、PCCはPCEPSとの接続をサポートしません
Once the establishment of TLS has been agreed upon by the PCEP peers, the connection establishment SHALL follow the following steps:
TLSの確立がPCEPピアによって合意されると、接続の確立は次の手順に従わなければなりません (SHALL)。
1. Immediately negotiate a TLS session according to [RFC5246]. The following restrictions apply:
1. [RFC5246]に従って、TLSセッションを直ちにネゴシエートします。以下の制限が適用されます。
* Support for certificate-based mutual authentication is REQUIRED.
* 証明書に基づく相互認証のサポートは必須です (REQUIRED)。
* Negotiation of a ciphersuite providing for integrity protection is REQUIRED.
* 完全性保護を提供する暗号スイートをネゴシエートすることは必須です (REQUIRED)。
* Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED.
* 機密性を提供する暗号スイートをネゴシエートすることが推奨されます (RECOMMENDED)。
* Support for and negotiation of compression is OPTIONAL.
* 圧縮のサポートとネゴシエーションはオプションです (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.
2. Peer authentication can be performed in any of the following two REQUIRED operation models:
2. ピア認証は、次の2つの必須 (REQUIRED) の運用モデルのいずれでも行えます。
* 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）のリストの構成を許可しなければなりません (MUST)。
+ Certificate validation MUST include the verification rules as per [RFC5280].
+ 証明書の検証には、[RFC5280]による検証ルールを含めなければなりません (MUST)。
+ 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）など）を組み込むべきです (SHOULD)。
+ 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]で定義されているピア検証の規則とガイドラインに従わなければなりません (MUST)。ピアについて期待されるDNS名またはIPアドレスが設定されている場合、実装はそれらを提示された証明書内の値と照合しなければなりません (MUST)。DNS名とIPアドレスは、Common Name Identifier（CN-ID）[RFC6125]またはsubjectAltNameエントリに含まれている可能性があります。検証では、これらのエントリのうち1つだけが考慮されます。次の優先順位が適用されます。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.
+ 実装は、通信のピアの承認を確認するために、証明書の追加プロパティのセットの構成を許可する場合があります (MAY)（たとえば、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 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.
*証明書のフィンガープリントを使用したX.509証明書を使用したTLS：実装は、Distinguished Encoding Rules（DER）によってエンコードされた証明書オクテットのフィンガープリントによって識別される、ピアを識別するために信頼される証明書のリストの構成を許可しなければなりません (MUST)。実装は[SHS]で定義されたSHA-256をフィンガープリントのハッシュアルゴリズムとしてサポートしなければなりません（MUST）。
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]を開始しなければなりません (MUST)。このタイマーの満了後、Openメッセージが受信されなかった場合、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.
使用中のピア認証方式に応じて、PCEPSは、ピアのアイデンティティと、そのピアが要求を行う資格を持つか、その応答を権威あるものとみなせるかを確立するための、異なる運用モードをサポートします。PCEPS実装は、ピアのアイデンティティを異なるレベルのアクセス権や権威性と関連付けるメカニズムを提供すべきであり (SHOULD)、適切に識別されたピアに対するデフォルトのレベルを確立するメカニズムを提供しなければなりません (MUST)。適切に識別できないピアと確立された接続は、PCEPの交換が行われる前に終了しなければなりません (SHALL)。
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証明書の以下のパラメーターは公開すべきです (SHOULD)。
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 All X.509 v3 Subject Alternative Name
oすべてのX.509 v3拡張キーの使用法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）を、OPENオブジェクトに含まれるオプションの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.
さらに、PCCは、「DNSベースの名前付きエンティティの認証（DANE）」[RFC6698]で説明されている手順を適用して、DNS検出を使用するときにピアのアイデンティティを検証してもよい（MAY）。詳細については、セクション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ネゴシエーションまたはピアIDチェックが失敗した場合、両方のピアは直ちに接続を閉じなければなりません (MUST)。
The initiator SHOULD follow the procedure listed in [RFC5440] to retry session setup as per the exponential back-off session establishment retry procedure.
イニシエータは、[RFC5440]に記載されている手順に従って、指数バックオフセッション確立の再試行手順に従ってセッションセットアップを再試行すべきです (SHOULD)。
This document does not specify any discovery mechanism for support of PCEPS. [PCE-DISCOVERY-PCEPS-SUPPORT] and [PCE-DISCOVERY-DNS] make the following proposals:
このドキュメントでは、PCEPSをサポートするための検出メカニズムを指定していません。 [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は、PCED情報のIGPの通知メカニズムを使用して、PCEPSをサポートする機能を通知できます。 PCE-CAP-FLAGSサブTLVは、PCE機能をアドバタイズするために使用されるオプションのサブTLVです。 OSPFまたはIS-ISによって伝送されるPCEDサブTLV内に存在します。 [RFC5088]と[RFC5089]は、それぞれOSPFとIS-IS内で伝送される場合のこのサブTLVの説明と処理ルールを提供します。 PCE機能ビットは[RFC5088]で定義されています。 [PCE-DISCOVERY-PCEPS-SUPPORT]では、PCEPセキュリティサポート情報を配布する属性としてアナウンスできるPCE-CAP-FLAGSサブTLVの新しい機能フラグビットが提案されています。
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]を使用してPCEPSをサポートする機能をアドバタイズできます。
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]は、TLSサーバーから取得した証明書をDNSを使用してドメイン名に関連付ける、つまりTLSA DNSリソースレコード（RR）を使用してTLSサーバー証明書または公開鍵をドメイン名に関連付ける安全な方法を定義していますレコードが見つかると、「TLSA証明書の関連付け」が形成されます。 DNS情報は、DNSセキュリティ（DNSSEC）で保護する必要があります。 DACを適用してサーバーのIDを確認するPCCは、[RFC6698]のセクション4で定義されたルールに準拠しなければなりません (MUST)。 [RFC6698]と[RFC7671]で説明されているように、実装はマッチングタイプ1（SHA2-256）のサービス証明書制約（TLSA証明書使用タイプ1）をサポートしなければなりません (MUST)。 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.
このドキュメントで説明する手順では、PCEPスピーカーの実装がサポートしていないPCEPスピーカーの実装に干渉しない、特定の拡張メッセージ（StartTLS）によって開始されたTLS接続によって伝送される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.
PCEPSをサポートしないPCCは、TCP確立の最初のメッセージとしてOpenメッセージを送信します。 PCEPSのみをサポートするPCEは、TCP確立時にStartTLSメッセージを送信します。 PCCは、受信したStartTLSメッセージをエラーと見なし、[RFC5440]の既存のエラーメカニズムに従って動作します。つまり、PCCは、エラータイプ1（PCEPセッション確立失敗）およびエラー値1（受信無効なOpenメッセージまたは非Openメッセージの場合）、セッションを閉じます。
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.
PCEPSをサポートするPCCは、TCP確立の最初のメッセージとしてStartTLSメッセージを送信します。 PCEPSをサポートしないPCEは、StartTLSメッセージの受信をエラーと見なし、PCErrメッセージでエラータイプ1（PCEPセッションの確立の失敗）およびエラー値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.
PCTLSを実装していないPCEPスピーカーがStartTLSメッセージを受信すると、それは不明なメッセージと見なされ、[RFC5440]の既存のエラーメカニズムに従って動作します。つまり、PCErrメッセージを送信します。エラータイプ2（機能はサポートされていません）を使用して、セッションを閉じます。
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セッションをPCEPSにアップグレードすることはできません。そのセッションは、この文書で説明する手順に従って終了させ、再確立する必要があります。段階的なアップグレードの間、PCEPスピーカーはTLSありとTLSなしの両方のセッション確立を許可すべきです (SHOULD)。両方のPCEPスピーカーがPCEPSをサポートするようにアップグレードされると、PCEPセッションはTLSで再確立され、そうでなければTLSなしのPCEPセッションが設定されます。段階的な展開の間、アップグレード中のPCEを引き継ぐために冗長なPCEを使用してもよい (MAY) です。アップグレードが完了したら、保護されていない版のサポートは削除すべきです (SHOULD)。
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.
PCEPSの有無にかかわらず接続を受け入れるPCEは、PCCから受信したメッセージに基づいて応答します。 PCEPSの有無に関係なく接続をサポートするPCCは、最初にPCEPSとの接続を試み、エラーの場合は、PCEPSなしの接続の確立を再試行する場合があります (MAY)。 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.
PCEPSをサポートするPCEP実装は、Error-Typeを25（PCEP StartTLS失敗）に設定し、Error-valueを2（StartTLS、Open、またはPCErr以外のメッセージの受信）に設定して、PCErrメッセージで応答することに注意してください。 StartTLSまたはOpenメッセージの前に他のメッセージが送信されます。無効なメッセージの送信者がPCEPSをサポートしないPCEP実装である場合、このエラーを理解できません。 PCEPS実装は、セッションを閉じる前に、[RFC5440]に従って、エラータイプ1（PCEPセッション確立失敗）およびエラー値1（無効なオープンメッセージまたは非オープンメッセージの受信）でPCErrメッセージを送信することもできます。
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
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
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：StartTLSメッセージなしこのドキュメント（またはPCErr/Open）は、StartTLSWaitタイマーが期限切れになる前に
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接続を偽造することに特に対処された攻撃に特に関連するものに、追加の保護対策を適用することをお勧めします。これは、特に長期間の接続の場合です。これらの手段の1つは、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暗号スイートは、ペイロードの完全性の検証のみを提供し、暗号化を一切提供しません。そのような暗号スイートは、デフォルトでは使用すべきではありません (SHOULD NOT)。[RFC6952]で明示的に述べられているとおり、管理者は、そのような場合に起こりうる関連する内部データの漏洩のリスクを慎重に比較検討した上で、これらの暗号スイートの使用を許可してもよい (MAY) です。
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.
証明書のフィンガープリントを使用してPCEPSピアを識別する場合、同じハッシュ値を生成する2つの証明書は同じピアと見なされます。したがって、使用されるハッシュ関数が暗号的に妥協されていないことを確認することが重要です。これにより、攻撃者が選択した証明書とのハッシュ衝突を生成する可能性は非常に低くなります。このドキュメントでは、[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なしで接続を受け入れ続けるPCEPS実装は、ダウングレード攻撃の影響を受けます。攻撃者は、回線上をクリアテキストで通過するときにTLSの使用を要求するStartTLSメッセージの使用を削除しようとする可能性があり、TLSなしでPCEP接続を試行することを示唆するPCErrメッセージを挿入しようとする可能性もあります。
The guidance given in [RFC7525] SHOULD be followed to avoid attacks on TLS.
[RFC7525]で提供されているガイダンスは、TLSへの攻撃を回避するために従うべきです (SHOULD)。
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セキュリティを構成できるべきです (SHOULD)。
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.
TLSを介してPCEPセキュリティをサポートするPCEまたはPCC実装は、[RFC5246]のように一般的なTLS構成をサポートしなければなりません (MUST)。少なくともセクション3.4および3.5で説明されているように、信頼モデルの1つとそれに対応するパラメーターの構成は、実装によってサポートされていなければなりません (MUST)。
A PCEPS implementation SHOULD allow configuring the StartTLSWait timer value.
PCEPS実装では、StartTLSWaitタイマー値を構成できるべきです (SHOULD)。
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構成をオーバーライドして、安全でない接続を許可できるようにするオプションを提供する場合があります (MAY)。このオーバーライドを実行すると、セキュリティで保護されていない接続を許可することによるセキュリティへの影響に関する警告がトリガーされます（SHOULD）。
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セッションに関して次のタスクを完了する方法を提供すべきです (SHOULD)。
o Determine if a session is protected via PCEPS.
o PCEPSを介してセッションが保護されているかどうかを確認します。
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 StartTLSの手順が、構成または機能のアドバタイズでPCEPSをサポートすることがわかっているPCEPピアで失敗した場合は、警告が表示されます。
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モジュールを拡張して、PCEPS機能、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.
さらに、オペレーターがPCEPS機能とさまざまなTLS関連パラメーターを構成し、PCEPセッションの現在のTLS状況を表示できるように、PCEP YANGモジュール[PCEP-YANG]はTLS関連情報を含むように拡張されています。
A PCEPS implementation SHOULD log error events and provide PCEPS failure statistics with reasons.
PCEPS実装は、エラーイベントをログに記録し、PCEPS障害統計に理由を提供すべきです (SHOULD)。
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に、PCEPSをサポートするための可能な検出メカニズムがリストされていることに注意してください。
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. and E. Rescorla、「The Transport Layer Security（TLS）Protocol Version 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., 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>.
[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、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、DOI 10.17487/RFC5440、March 2009、<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.、「Transport Layer Security（TLS）Extensions：Extension Definitions」、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. and J. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 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. and 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., and P. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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. and 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] National Institute of Standards and Technology、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028/NIST.FIPS.180-4、2015年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., and J. Tantsura、「ドメインネームシステム（DNS）を使用したパス計算要素（PCE）検出」、作業進行中、draft-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., and D. King, "IGP extension for PCEP security capability support in the PCE discovery"、Work in進捗、draft-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., and J. Tantsura、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、draft-ietf-pce -pcep-yang-05、2017年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., and B. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、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.、「Lightweight Directory Access Protocol（LDAP）：Authentication Methods and Security Mechanisms」、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.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、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.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、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., and R. Bonica、「The TCP Authentication Option」、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. and 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., 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>。
[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., and 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., and J. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、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., and 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., and D. Dhody、「ステートフルPCEのラベルスイッチドパス状態同期手順の最適化」、RFC 8232 、DOI 10.17487/RFC8232、2017年9月、<https://www.rfc-editor.org/info/rfc8232>。
Acknowledgements
謝辞
We would like to thank Joe Touch for his suggestions and support regarding the StartTLS mechanisms.
StartTLSメカニズムに関する提案とサポートについてJoe Touchに感謝します。
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.
初期のSECDIRレビューコメント、およびIETFの前回のコール中にさらにレビューしてくれたDavid Mandelbergに感謝します。
Thanks to Dan Frost for the RTGDIR review and comments.
RTGDIRのレビューとコメントを提供してくれたDan Frostに感謝します。
Thanks to Dale Worley for the Gen-ART review and comments.
Gen-ARTのレビューとコメントを提供してくれたDale Worleyに感謝します。
Thanks to Tianran Zhou for the OPSDIR review.
OPSDIRのレビューをしてくれたTianran Zhouに感謝します。
Thanks to Deborah Brungard for being the responsible AD and guiding the authors as needed.
責任あるADであり、必要に応じて著者を指導してくれた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のレビューとコメントを提供してくれたMirja Kuhlewind、Eric Rescorla、Warren Kumari、Kathleen Moriarty、Suresh Krishnan、Ben Campbell、Alexey Melnikovにも感謝します。
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
Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
オスカーゴンザレスデディオステレフォニカI+Dドンラモンデラクルス、82マドリード28006スペイン
Phone: +34 913 129 041
Email: oscar.gonzalezdedios@telefonica.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
Email: sunseawq@huawei.com
Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore, KA 560066 India
Dhruv Dhodoi Huawei Divyashari Techno Park、Wheatfished Bangalore、K2007インド
Email: dhruv.ietf@gmail.com