[要約] RFC 8253は、PCEP（Path Computation Element Communication Protocol）の安全な通信を提供するためにTLSを使用する方法について説明しています。このRFCの目的は、PCEPの通信を保護し、セキュリティを向上させることです。
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.
[RFC5440]のセキュリティに関する考慮事項のセクションでは、PCEPに対する潜在的な脅威とその結果を分析しています。また、PCEPをセキュリティ攻撃から保護するためのメカニズムについても説明します。特定のメカニズムについて特定の推奨を行ったり、アプリケーションを詳細に定義したりすることはありません。さらに、[RFC6952]は、特に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]は、ピア認証、メッセージ暗号化、および整合性のサポートを提供するため、これらのドキュメントで言及されているソリューションの中で最も適切と思われるソリューションの1つです。 TLSは、キーの構成と交換をサポートする既知のメカニズム、およびInterior Gateway Protocol（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暗号スイート、およびセキュリティチェックでのエラーの処理が含まれます。このドキュメントの残りの部分では、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 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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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手順を使用しています。これは、PCEPSに別のポート番号の割り当てを要求しないようにするために行われます。 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.
この手順は、初期化フェーズと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をサポートしていること、または特定のピアにPCEPSを使用するように事前構成できることを検出できます（詳細については、セクション4を参照）。既存のPCEPセッションはTLSを介して保護できません。このドキュメントで説明されている手順に従って、セッションを閉じ、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メッセージであるかどうかを確認するために待機する必要があります。 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メッセージでなければなりません。これは、最初の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）メッセージで応答する必要があります。 25（PCEP StartTLS失敗）に設定し、Error-valueを1（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メッセージをError-Typeを25（PCEP StartTLS失敗）に設定し、Error-valueを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.
PCEPSをサポートしていないPCEPスピーカーがStartTLSメッセージを受信した場合、[RFC5440]のセクション6.2で説明されている既存のエラーメカニズム（メッセージがOpenメッセージの前に受信された場合）または[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.
（ローカルポリシーとして）PCEPS接続のみをサポートするPCEPスピーカーがOpenメッセージを受信した場合、それを予期しないメッセージとして扱い、Error-Typeを1（PCEPセッション確立失敗）に設定したPCErrメッセージで応答し、エラー値は1（無効なOpenメッセージまたは非Openメッセージの受信）に設定され、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接続を許可する場合（ローカルポリシーとして）、PCEは、PCCから受信したメッセージに基づいて、TCP確立後に応答を待機する必要があります。 StartTLSメッセージの場合、PCEは、このドキュメントで説明されているように、StartTLSメッセージを送信し、TLS確立手順に移行することによって応答する必要があります。 Openメッセージの場合、PCEはOpenメッセージで応答し、[RFC5440]に従ってPCEPセッション確立手順に移動する必要があります。 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メッセージを（クリアテキストで）返す必要があります。
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なしで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接続ネゴシエーションおよび確立手順を開始する必要があります（[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ネゴシエーションが失敗した場合（たとえば、証明書失効チェックに必要なメカニズムが利用できない場合）は、両方のピアが直ちに接続を閉じる必要があります。
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.
PCEPSをサポートしないPCEPスピーカーは、[RFC5440]のように、Openメッセージを直接送信します。 PCEPSをサポートするPCEPスピーカーですが、最後の交換で、TLSなしでセッションを再確立するピアの意思を学習しました。[RFC5440]のように、Openメッセージを直接送信できます（MAY）。 TLSを使用しないPCEPセッションの再確立は、1回の試行に限定する必要があります（SHOULD）。
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]の推奨に従って、PCEPSをサポートするPCEPピアはデフォルトで厳密なTLS構成にする必要があります（つまり、非TLS PCEPセッションの確立を許可しない）。 PCEPS実装は、オペレーターが厳密なTLS構成を手動でオーバーライドして、保護されていない接続を許可できるようにするオプションを提供する場合があります。このオーバーライドを実行すると、セキュリティで保護されていない接続を許可することによるセキュリティへの影響に関する警告がトリガーされます（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ピアによって適用される必要があります。
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共通ヘッダーのみが含まれている必要があります。
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タイマー」と呼ばれるタイマーを開始する必要があります。このタイマーの期限が切れた後、StartTLSメッセージもPCErr / Openメッセージ（障害が発生し、PCEPSがピアでサポートされていない場合）も受信されなかった場合、PCEPスピーカーはエラータイプのPCErrメッセージを送信する必要があります25（PCEP StartTLS失敗）に設定し、Error-valueを5（StartTLSWaitタイマーの有効期限が切れる前にStartTLSメッセージなし（またはPCErr / Open）なし）に設定し、TCP接続を解放する必要があります。 StartTLSWaitタイマーのRECOMMENDED値は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.
次の図は、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ピアによって合意されると、接続の確立は次の手順に従う必要があります。
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.
* PCEPS実装は、少なくともTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460]のネゴシエーションをサポートする必要があり、またTLS_ECDHE_ECDSA_WITH_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. ピア認証は、次の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）など）を組み込む必要があります（SHOULD）。
+ 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を示す必要があります（SHOULD）。 TLS 1.2の場合、これはサーバー側の「certificate_authorities」（[RFC5246]のセクション7.4.4を参照）とクライアント側の「TrustedAuthorities」拡張機能（[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エントリに含めることができます。確認のために、これらのエントリの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.
+ 実装は、通信のピアの承認を確認するために、証明書の追加プロパティのセットの構成を許可する場合があります（たとえば、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）によってエンコードされた証明書オクテットのフィンガープリントによって識別される、ピアを識別するために信頼される証明書のリストの構成を許可する必要があります。実装は[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]を開始する必要があります。このタイマーの満了後、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はさまざまな操作モードをサポートして、ピアのIDを確立し、要求を実行する資格があるか、または応答で信頼できると見なすことができるかを確立します。 PCEPS実装は、ピアIDをさまざまなレベルのアクセスや権限と関連付けるメカニズムを提供する必要があり（SHOULD）、適切に識別されたピアのデフォルトレベルを確立するメカニズムを提供する必要があります。適切に識別できないピアとの接続は、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 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チェックが失敗した場合、両方のピアは直ちに接続を閉じる必要があります。
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で定義されたルールに準拠する必要があります。 [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.
このドキュメントで説明する手順では、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の有無にかかわらずセッション確立を許可する必要があります（SHOULD）。両方のPCEPスピーカーがPCEPSをサポートするようにアップグレードされると、PCEPセッションはTLSで再確立されます。それ以外の場合は、TLSを使用しないPCEPセッションがセットアップされます。アップグレード中のPCEを引き継ぐために、増分展開中に冗長PCEを使用することもできます（MAY）。アップグレードが完了すると、セキュリティで保護されていないバージョンのサポートを削除する必要があります。
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なしの接続の確立を再試行する場合があります。 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暗号スイートは、ペイロードの整合性検証のみを提供し、暗号化を提供しません。そのような暗号スイートはデフォルトでは使用すべきではありません。 [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.
証明書のフィンガープリントを使用して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への攻撃を回避するために従う必要があります。
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構成をサポートする必要があります。少なくともセクション3.4および3.5で説明されているように、信頼モデルの1つとそれに対応するパラメーターの構成は、実装によってサポートされている必要があります。
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構成をオーバーライドして、安全でない接続を許可できるようにするオプションを提供する場合があります。このオーバーライドを実行すると、セキュリティで保護されていない接続を許可することによるセキュリティへの影響に関する警告がトリガーされます（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関連情報を含むように拡張されています。
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障害統計に理由を提供する必要があります（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。および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。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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、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。および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。および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、「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。および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]米国国立標準技術研究所、「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.、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。、および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。、および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。、編、「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。、および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]ソルター、M。およびR.ハウズリー、「トランスポート層セキュリティ（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。、および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、「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。、および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.
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