[要約] RFC 9353 は、PCE Discovery (PCED) におけるPCEPセキュリティ機能サポートの広告方法を定義し、IGP経由でPCEの存在と経路計算能力を通知することを目的としています。
Internet Engineering Task Force (IETF) D. Lopez
Request for Comments: 9353 Telefonica I+D
Updates: 5088, 5089, 8231, 8306 Q. Wu
Category: Standards Track D. Dhody
ISSN: 2070-1721 Q. Ma
Huawei
D. King
Old Dog Consulting
January 2023
When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO)) support capability.
パス計算要素（PCE）がラベルスイッチングルーター（LSR）またはインテリアゲートウェイプロトコル（IGP）に参加するサーバーである場合、IGP洪水を使用してその存在とパス計算機能を宣伝できます。PCE Discovery（PCED）（RFCS 5088および5089のIGP拡張機能は、それぞれOSPFおよびIS-ISのIGPフラッドを使用してパス計算機能を宣伝する方法を定義します。ただし、これらの仕様には、パス計算要素通信プロトコル（PCEP）セキュリティ（たとえば、トランスポートレイヤーセキュリティ（TLS）およびTCP認証オプション（TCP-AO））サポート機能を宣伝する方法がありません。
This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a Key ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability. This document also updates RFCs 8231 and 8306.
このドキュメントでは、PCEPセキュリティサポート情報を配布するためにIGP広告の属性として発表できるPCE-CAP-Flags Sub-TLVの機能フラグビットを定義します。さらに、このドキュメントはRFCS 5088および5089を更新して、キーIDまたはキーチェーン名サブTLVの広告を可能にして、TCP-AOセキュリティ機能をサポートします。このドキュメントは、RFCS 8231および8306も更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9353.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9353で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions Used in This Document
3. IGP Extension for PCEP Security Capability Support
3.1. Use of PCEP Security Capability Support for PCED
3.2. KEY-ID Sub-TLV
3.2.1. IS-IS
3.2.2. OSPF
3.3. KEY-CHAIN-NAME Sub-TLV
3.3.1. IS-IS
3.3.2. OSPF
4. Updates to RFCs
5. Backward Compatibility Considerations
6. Management Considerations
6.1. Control of Policy and Functions
6.2. Information and Data Model
6.3. Liveness Detection and Monitoring
6.4. Verification of Correct Operations
6.5. Requirements on Other Protocols and Functional Components
6.6. Impact on Network Operations
7. Security Considerations
8. IANA Considerations
8.1. PCE Capability Flags
8.2. PCED Sub-TLV Type Indicators
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
As described in [RFC5440], privacy and integrity are important issues for communication using the Path Computation Element Communication Protocol (PCEP); an attacker that intercepts a PCEP message could obtain sensitive information related to computed paths and resources. Authentication and integrity checks allow the receiver of a PCEP message to know that the message genuinely comes from the node that purports to have sent it and whether the message has been modified.
[RFC5440]で説明されているように、プライバシーと整合性は、パス計算要素通信プロトコル（PCEP）を使用した通信の重要な問題です。PCEPメッセージを傍受する攻撃者は、計算されたパスとリソースに関連する機密情報を取得できます。認証と整合性のチェックにより、PCEPメッセージの受信者は、メッセージがそれを送信すると主張するノードから真に届くこと、およびメッセージが変更されたかどうかを知ることができます。
Among the possible solutions mentioned in [RFC5440], Transport Layer Security (TLS) [RFC8446] provides support for peer authentication, message encryption, and integrity while TCP-AO) [RFC5925] and Cryptographic Algorithms for TCP-AO [RFC5926] offer significantly improved security for applications using TCP. As specified in Section 4 of [RFC8253], the PCC needs to know whether the PCE server supports TLS or TCP-AO as a secure transport in order for a Path Computation Client (PCC) to establish a connection with a PCE server using TLS or TCP-AO.
[RFC5440]で言及されている可能なソリューションの中で、輸送層のセキュリティ（TLS）[RFC8446]はピア認証、メッセージ暗号化、および完全性をサポートし、TCP-AO）[RFC5925]およびTCP-AO [RFC5926]の暗号化アルゴリズムを提供します。TCPを使用したアプリケーションのセキュリティの改善。[RFC8253]のセクション4で指定されているように、PCCは、PCHサーバーがTLSまたはTCP-AOを安全なトランスポートとしてサポートしているかどうかを知る必要があります。TCP-AO。
[RFC5088] and [RFC5089] define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise PCEP security (e.g., TLS and TCP-AO) support capability.
[RFC5088]および[RFC5089]は、それぞれOSPFおよびIS-ISのIGP洪水を使用してパス計算機能を宣伝する方法を定義します。ただし、これらの仕様には、PCEPセキュリティ（TLSやTCP-AOなど）を宣伝する方法がサポート機能を宣伝しています。
This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as attributes in the IGP advertisement to distribute PCEP security support information. In addition, this document updates [RFC5088] and [RFC5089] to allow advertisement of a KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.
このドキュメントでは、PCEPセキュリティサポート情報を配布するためにIGP広告の属性として発表できるPCE-CAP-Flags Sub-TLVの機能フラグビットを定義します。さらに、このドキュメントは[RFC5088]および[RFC5089]を更新して、KeyIDまたはキーチェーン名のサブTLVの広告を可能にしてTCP-AOセキュリティ機能をサポートします。
IANA created a top-level registry titled "Path Computation Element (PCE) Capability Flags" per [RFC5088]. This document updates [RFC5088] and moves it to follow the heading of the "Interior Gateway Protocol (IGP) Parameters" registry. [RFC5089] states that the IS-IS PCE-CAP-FLAGS sub-TLV uses the same registry as OSPF. This document updates [RFC5089] to refer to the new IGP registry. Further, this document updates [RFC8231] where it references the registry location as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry to the "Interior Gateway Protocol (IGP) Parameters" registry. This document also updates [RFC8306] by changing the term "OSPF PCE Capability Flag" to read as "Path Computation Element (PCE) Capability Flags" and to note the corresponding registry now exists in the "Interior Gateway Protocol (IGP) Parameters" registry.
IANAは、[RFC5088]ごとに「パス計算要素（PCE）機能フラグ」というタイトルのトップレベルレジストリを作成しました。このドキュメントは[RFC5088]を更新し、「Interior Gateway Protocol（IGP）パラメーター」レジストリの見出しに従うように移動します。[RFC5089]は、IS-IS PCE-CAP-FLAGS SUB-TLVがOSPFと同じレジストリを使用することを述べています。このドキュメントは[RFC5089]を更新して、新しいIGPレジストリを参照します。さらに、このドキュメントは[RFC8231]を更新し、レジストリの場所を「オープン最短パスファーストV2（OSPFV2）パラメーター」と呼び、「インテリアゲートウェイプロトコル（IGP）パラメーター」レジストリにレジストリを参照します。このドキュメントは、「OSPF PCE機能フラグ」という用語を変更して「パス計算要素（PCE）機能フラグ」として読み取り、対応するレジストリが「インテリアゲートウェイプロトコル（IGP）パラメーター」レジストリに存在するようになることにより、[RFC8306]を更新します。。
Note that [RFC5557] uses the term "OSPF registry" instead of the "IGP registry", whereas [RFC8623] and [RFC9168] use the term "OSPF Parameters" instead of "IGP Parameters".
[RFC5557]は「IGPレジストリ」の代わりに「OSPFレジストリ」という用語を使用し、[RFC8623]と[RFC9168]は「IGPパラメーター」の代わりに「OSPFパラメーター」という用語を使用することに注意してください。
Note that the PCEP Open message exchange is another way to discover PCE capabilities information; however, in this instance, the TCP-security-related key parameters need to be known before the PCEP session is established and the PCEP Open messages are exchanged. Thus, the IGP advertisement and flooding mechanisms need to be leveraged for PCE discovery and capabilities advertisement.
PCEPオープンメッセージ交換は、PCE機能情報を発見する別の方法であることに注意してください。ただし、この例では、PCEPセッションが確立され、PCEPオープンメッセージが交換される前に、TCPセキュリティ関連のキーパラメーターを把握する必要があります。したがって、IGPの広告と洪水メカニズムは、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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router Information Link State Advertisement (LSA) as defined in [RFC7770] to facilitate PCED using OSPF. This document defines two capability flag bits in the OSPF PCE Capability Flags to indicate TCP-AO support [RFC5925] [RFC5926] and PCEP over TLS support [RFC8253], respectively.
[RFC5088]は、OSPFを使用してPCEDを促進するために[RFC7770]で定義されているように、OSPFルーター情報リンク状態広告（LSA）に搭載されているPCE発見（PCED）TLVを定義します。このドキュメントでは、OSPF PCE機能フラグの2つの機能フラグビットを定義して、TCP-AOサポート[RFC5925] [RFC5926]とPCEP上のTLSサポート[RFC8253]をそれぞれ示します。
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCED using IS-IS. This document will use the same flag for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP-AO support and PCEP over TLS support, respectively.
同様に、[RFC5089]は、IS-ISを使用してPCEDで使用するPCED SUB-TLVを定義します。このドキュメントは、OSPF PCE機能フラグSub-TLVに同じフラグを使用して、IS-ISがそれぞれTLSサポートよりもTCP-AOサポートとPCEPを示すことを可能にします。
The IANA assignments for shared OSPF and IS-IS Security Capability Flags are documented in Section 8.1 of this document.
共有OSPFおよびIS-ISセキュリティ機能フラグのIANA割り当ては、このドキュメントのセクション8.1に記載されています。
TCP-AO and PCEP over TLS support flag bits are advertised using IGP flooding.
TCP-AOおよびTLSサポートサポートフラグビットを介したPCEPは、IGP洪水を使用して宣伝されています。
* PCE supports TCP-AO: IGP advertisement SHOULD include a TCP-AO support flag bit.
* PCEサポートTCP-AO：IGP広告には、TCP-AOサポートフラグビットを含める必要があります。
* PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS support flag bit.
* PCEサポートTLS：IGP広告には、TLSサポートフラグビットを介してPCEPを含める必要があります。
If the PCE supports multiple security mechanisms, it SHOULD include all corresponding flag bits in its IGP advertisement.
PCEが複数のセキュリティメカニズムをサポートする場合、IGP広告に対応するすべてのフラグビットを含める必要があります。
A client's configuration MAY indicate that support for a given security capability is required. If a client is configured to require that its PCE server supports TCP-AO, the client MUST verify that the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a connection to that server. Similarly, if the client is configured to require that its PCE server supports TLS, the client MUST verify that the PCEP over TLS support flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a connection to that server.
クライアントの構成は、特定のセキュリティ機能のサポートが必要であることを示している場合があります。クライアントがPCEサーバーがTCP-AOをサポートすることを要求するように構成されている場合、クライアントは、特定のサーバーのPCE-CAP-FlagsサブTLVのTCP-AOフラグビットが、それに接続する前に設定されることを確認する必要がありますサーバ。同様に、クライアントがPCEサーバーがTLSをサポートすることを要求するように構成されている場合、クライアントは、特定のサーバーのPCE-CAP-FlagsサブTLVのTLS上のPCEPがフラグビットをサポートしていることを確認する必要があります。そのサーバー。
The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to identify the TCP-AO key (referred to as "KeyID" in [RFC5925]).
Key-ID Sub-TLVは、PCCがTCP-AOキー（[RFC5925]の「keyID」と呼ぶ）を識別するために使用できる識別子を指定します。
The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within the IS-IS Router CAPABILITY TLV when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO support.
Key-ID Sub-TLVは、IS-ISルーター機能TLV内に運ばれるPCED Sub-TLVに存在する場合があります。AOサポート。
The KEY-ID sub-TLV has the following format:
Key-ID Sub-TLVには次の形式があります。
Type:
タイプ：
6
6
Length:
長さ：
1
1
KeyID:
KeyID：
The one-octet KeyID as per [RFC5925] to uniquely identify the Master Key Tuple (MKT).
[RFC5925]に従ってOne-OCTET KeyIDは、マスターキータプル（MKT）を一意に識別します。
Similarly, this sub-TLV MAY be present in the PCED TLV carried within the OSPF Router Information LSA when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.
同様に、このサブTLVは、OSPFのPCE-CAP-FLAGS SUB-TLVの機能フラグがTCP-AOサポートを示すように設定されている場合、OSPFルーター情報LSA内に運ばれるPCED TLVに存在する場合があります。
The format of the KEY-ID sub-TLV is as follows:
Key-ID Sub-TLVの形式は次のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
6
6
Length:
長さ：
4
4
KeyID:
KeyID：
The one octet KeyID as per [RFC5925] to uniquely identify the MKT.
[RFC5925]に従って、MKTを一意に識別するための1つのOctet keyID。
Reserved:
予約済み：
MUST be set to zero while sending and ignored on receipt.
送信中にゼロに設定する必要があります。
The KEY-CHAIN-NAME sub-TLV specifies a key chain name that can be used by the PCC to identify the key chain. The key chain name could be manually configured via command-line interface (CLI) or installed in the YANG datastore (see [RFC8177]) at the PCC.
キーチェーン名サブTLVは、PCCが使用してキーチェーンを識別できるキーチェーン名を指定します。キーチェーン名は、コマンドラインインターフェイス（CLI）を介して手動で構成するか、PCCのYang Datastore（[RFC8177]を参照）にインストールできます。
The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried within the IS-IS Router CAPABILITY TLV when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO support.
キーチェーン名サブTLVは、IS-ISのPCE-CAP-FlagsサブTLVの機能フラグビットがIS-ISのSub-TLVのビットを示すように設定されている場合、IS-ISルーター機能TLV内に運ばれるPCEDサブTLVに存在する場合があります。TCP-AOサポート。
The KEY-CHAIN-NAME sub-TLV has the following format:
キーチェーン名サブTLVには、次の形式があります。
Type:
タイプ：
7
7
Length:
長さ：
Variable, encodes the length of the value field.
変数は、値フィールドの長さをエンコードします。
Key Chain Name:
キーチェーン名：
The Key Chain Name contains a string of 1 to 255 octets to be used to identify the key chain. It MUST be encoded using UTF-8. A receiving entity MUST NOT interpret invalid UTF-8 sequences and ignore them. This field is not NULL terminated. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36].
キーチェーン名には、キーチェーンを識別するために使用する1〜255オクテットの文字列が含まれています。UTF-8を使用してエンコードする必要があります。受信エンティティは、無効なUTF-8シーケンスを解釈してはならず、それらを無視してはなりません。このフィールドは終了しません。[UTR36]で概説されている技術的な問題を防ぐには、UTF-8「最短のフォーム」エンコードが必要です。
Similarly, this sub-TLV MAY be present in the PCED TLV carried within the OSPF Router Information LSA when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support. The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned.
同様に、このサブTLVは、OSPFのPCE-CAP-FLAGS SUB-TLVの機能フラグがTCP-AOサポートを示すように設定されている場合、OSPFルーター情報LSA内に運ばれるPCED TLVに存在する場合があります。サブTLVは、サブTLVが4-OCTETアライメントされるように、ゼロパッドにする必要があります。
The format of KEY-CHAIN-NAME sub-TLV is as follows:
キーチェーン名サブTLVの形式は次のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Key Chain Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
7
7
Length:
長さ：
Variable, padding is not included in the Length field.
変数、パディングは長さフィールドに含まれていません。
Key Chain Name:
キーチェーン名：
The Key Chain Name contains a string of 1 to 255 octets to be used to identify the key chain. It MUST be encoded using UTF-8. A receiving entity MUST NOT interpret invalid UTF-8 sequences and ignore them. This field is not NULL terminated. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36]. The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned.
キーチェーン名には、キーチェーンを識別するために使用する1〜255オクテットの文字列が含まれています。UTF-8を使用してエンコードする必要があります。受信エンティティは、無効なUTF-8シーケンスを解釈してはならず、それらを無視してはなりません。このフィールドは終了しません。[UTR36]で概説されている技術的な問題を防ぐには、UTF-8「最短のフォーム」エンコードが必要です。サブTLVは、サブTLVが4-OCTETアライメントされるように、ゼロパッドにする必要があります。
Section 4 of [RFC5088] states that no new sub-TLVs will be added to the PCED TLV and no new PCE information will be carried in the Router Information LSA. This document updates [RFC5088] by allowing the two sub-TLVs defined in this document to be carried in the PCED TLV advertised in the Router Information LSA.
[RFC5088]のセクション4は、新しいサブTLVがPCED TLVに追加されず、ルーター情報LSAに新しいPCE情報が伝達されないことを述べています。このドキュメントは、このドキュメントで定義されている2つのサブTLVを、ルーター情報LSAに宣伝されているPCED TLVに携帯できるようにすることにより、[RFC5088]を更新します。
Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED TLV and no new PCE information will be carried in the Router CAPABILITY TLV. This document updates [RFC5089] by allowing the two sub-TLVs defined in this document to be carried in the PCED TLV advertised in the Router CAPABILITY TLV.
[RFC5089]のセクション4は、新しいサブTLVがPCED TLVに追加されず、ルーター機能TLVに新しいPCE情報が伝達されないことを述べています。このドキュメントは、このドキュメントで定義されている2つのサブTLVを、ルーター機能TLVで宣伝されているPCED TLVに携帯することを許可することにより、[RFC5089]を更新します。
This introduction of additional sub-TLVs should be viewed as an exception to the policies in [RFC5088] and [RFC5089], which is justified by the requirement to discover the PCEP security support prior to establishing a PCEP session. The restrictions defined in [RFC5088] and [RFC5089] should still be considered to be in place. If new advertisements are required in the future, alternative mechanisms such as using [RFC6823] or [LSR-OSPF-TRANSPORT-INSTANCE] should be considered.
追加のサブTLVのこの導入は、[RFC5088]および[RFC5089]のポリシーの例外と見なされる必要があります。これは、PCEPセッションを確立する前にPCEPセキュリティサポートを発見する要件によって正当化されます。[RFC5088]および[RFC5089]で定義されている制限は、まだ整っていると見なされるべきです。将来、新しい広告が必要な場合は、[RFC6823]や[LSR-OSPF-Transport-Instance]の使用などの代替メカニズムを考慮する必要があります。
The registry for the PCE Capability Flags assigned in Section 8.3 of [RFC5557], Section 8.1 of [RFC8231], Section 6.9 of [RFC8306], Section 11.1 of [RFC8623], and Section 10.5 of [RFC9168] has changed to the IGP Parameters "Path Computation Element (PCE) Capability Flags" registry created in this document.
[RFC557]のセクション8.3に割り当てられたPCE機能フラグのレジストリ、[RFC8231]のセクション8.1、[RFC8306]のセクション6.9、[RFC8623]のセクション11.1、および[RFC9168]のセクション10.5のレジストリは、IGPパラメータに変更されました。このドキュメントで作成された「PATH計算要素（PCE）機能フラグ」レジストリ。
An LSR that does not support the IGP PCE capability bits specified in this document silently ignores those bits.
このドキュメントで指定されたIGP PCE機能ビットをサポートしていないLSRは、これらのビットを静かに無視します。
An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs specified in this document silently ignores those sub-TLVs.
このドキュメントで指定されたキーIDおよびキーチェーン名のサブTLVをサポートしていないLSRは、これらのサブTLVを静かに無視します。
IGP extensions defined in this document do not introduce any new interoperability issues.
このドキュメントで定義されているIGP拡張機能は、新しい相互運用性の問題を導入しません。
Manageability considerations for PCED are addressed in Section 4.10 of [RFC4674], Section 9 of [RFC5088], and Section 9 of [RFC5089].
PCEDの管理可能性の考慮事項は、[RFC4674]のセクション4.10、[RFC5088]のセクション9、および[RFC5089]のセクション9で説明されています。
A PCE implementation SHOULD allow the following parameters to be configured on the PCE:
PCE実装により、PCEで次のパラメーターを構成できるようにする必要があります。
* support for TCP-AO
* TCP-AOのサポート
* the KeyID used by TCP-AO
* TCP-AOが使用するKeyID
* Key Chain Name
* キーチェーン名
* support for TLS
* TLSのサポート
The YANG module for PCEP [PCE-PCEP-YANG] supports PCEP security parameters (key, key chain, and TLS).
PCEP [PCE-PCEP-Yang]のYangモジュールは、PCEPセキュリティパラメーター（キー、キーチェーン、およびTLS）をサポートしています。
Normal operations of the IGP meet the requirements for liveness detection and monitoring.
IGPの通常の操作は、活性検出と監視の要件を満たしています。
The correlation of PCEP security information advertised against information received can be achieved by comparing the information in the PCED sub-TLV received by the PCC with that stored at the PCE using the PCEP YANG.
受け取った情報に対して宣伝されているPCEPセキュリティ情報の相関は、PCCが受け取ったPCESサブTLVの情報をPCEP Yangを使用してPCEに保存した情報と比較することで実現できます。
There are no new requirements on other protocols.
他のプロトコルには新しい要件はありません。
Frequent changes in PCEP security information advertised in the PCED sub-TLV may have a significant impact on IGP and might destabilize the operation of the network by causing the PCCs to reconnect sessions with PCEs. Section 4.10.4 of [RFC4674], Section 9.6 of [RFC5088], and Section 9.6 of [RFC5089] list techniques that are applicable to this document as well.
PCED SUB-TLVで宣伝されているPCEPセキュリティ情報の頻繁な変更は、IGPに大きな影響を与える可能性があり、PCCがPCSとセッションを再接続することにより、ネットワークの動作を不安定にする可能性があります。[RFC4674]のセクション4.10.4、[RFC5088]のセクション9.6、および[RFC5089]のセクション9.6は、このドキュメントにも適用できる手法をリストします。
Security considerations as specified by [RFC5088] and [RFC5089] are applicable to this document.
[RFC5088]および[RFC5089]で指定されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
As described in Section 10.2 of [RFC5440], a PCEP speaker MUST support TCP MD5 [RFC2385], so no capability advertisement is needed to indicate support. However, as noted in [RFC6952], TCP MD5 has been obsoleted by TCP-AO [RFC5925] because of security concerns. TCP-AO is not widely implemented; therefore, it is RECOMMENDED that PCEP be secured using TLS per [RFC8253] (which updates [RFC5440]). An implementation SHOULD offer at least one of the two security capabilities defined in this document.
[RFC5440]のセクション10.2で説明されているように、PCEPスピーカーはTCP MD5 [RFC2385]をサポートする必要があるため、サポートを示す能力広告は必要ありません。ただし、[RFC6952]に記載されているように、TCP MD5はセキュリティの懸念のためにTCP-AO [RFC5925]によって廃止されています。TCP-AOは広く実装されていません。したがって、[RFC8253]あたりのTLSを使用してPCEPを保護することをお勧めします（[RFC5440]を更新します）。実装は、このドキュメントで定義されている2つのセキュリティ機能のうち少なくとも1つを提供する必要があります。
The information related to PCEP security is sensitive and due care needs to be taken by the operator. This document defines new capability bits that are susceptible to a downgrade attack by setting them to zero. The content of the Key-ID or KEY-CHAIN-NAME sub-TLV can be altered to enable an on-path attack. Thus, before advertising the PCEP security parameters by using the mechanism described in this document, the IGP MUST be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in [RFC5304], [RFC5310], or [RFC5709].
PCEPセキュリティに関連する情報は敏感であり、オペレーターが適切な注意を払う必要があります。このドキュメントでは、それらをゼロに設定することにより、ダウングレード攻撃の影響を受けやすい新しい機能ビットを定義します。キーIDまたはキーチェーン名のサブTLVの内容を変更して、パスオンパス攻撃を可能にすることができます。したがって、このドキュメントで説明したメカニズムを使用してPCEPセキュリティパラメーターを宣伝する前に、[RFC5304]、[RFC5310]、または[RFC5709]で定義されたメカニズムを使用して、PCED TLVの認証と完全性を提供することをIGPが知られている必要があります。
Moreover, as stated in the security considerations of [RFC5088] and [RFC5089], there are no mechanisms defined in OSPF or IS-IS to protect the confidentiality of the PCED TLV. For this reason, the operator must ensure that no private data is carried in the TLV. For example, the operator must ensure that KeyIDs or key chain names do not reveal sensitive information about the network.
さらに、[RFC5088]および[RFC5089]のセキュリティ上の考慮事項で述べられているように、PCED TLVの機密性を保護するためのOSPFまたはIS-ISで定義されたメカニズムはありません。このため、オペレーターは、TLVにプライベートデータが掲載されていないことを確認する必要があります。たとえば、オペレーターは、KeyIDSまたはキーチェーン名がネットワークに関する機密情報を明らかにしないようにする必要があります。
IANA has moved the "Path Computation Element (PCE) Capability Flags" registry from the "Open Shortest Path First v2 (OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP) Parameters" grouping.
IANAは、「PATH最短パスFirst V2（OSPFV2）パラメーター」から「PATH COMPUTATION ELEMENT（PCE）機能フラグ」レジストリを「インテリアゲートウェイプロトコル（IGP）パラメーター」グループにグループ化しました。
IANA has made the following additional assignments from the "Path Computation Element (PCE) Capability Flags" registry:
IANAは、「Path Computation Element（PCE）機能フラグ」レジストリから次の追加の割り当てを作成しました。
+=====+========================+===========+
| Bit | Capability Description | Reference |
+=====+========================+===========+
| 17 | TCP-AO Support | RFC 9353 |
+-----+------------------------+-----------+
| 18 | PCEP over TLS support | RFC 9353 |
+-----+------------------------+-----------+
Table 1: Path Computation Element (PCE) Capability Flags Registrations
表1：パス計算要素（PCE）機能フラグの登録
The grouping is located at: <https://www.iana.org/assignments/igp-parameters/>.
グループは、<https://www.iana.org/assignments/igp-parameters/>にあります。
The PCED sub-TLVs are defined in [RFC5088] and [RFC5089], but a corresponding IANA registry was not created. IANA has created a new registry called "PCE Discovery (PCED) Sub-TLV Type Indicators" under the "Interior Gateway Protocol (IGP) Parameters" registry. The registration policy for this registry is "Standards Action" [RFC8126]. Values in this registry come from the range 0-65535.
PCEDサブTLVは[RFC5088]および[RFC5089]で定義されていますが、対応するIANAレジストリは作成されませんでした。IANAは、「インテリアゲートウェイプロトコル（IGP）パラメーター」レジストリの下に「PCE Discovery（PCED）Sub-TLVタイプインジケーター」と呼ばれる新しいレジストリを作成しました。このレジストリの登録ポリシーは「標準アクション」[RFC8126]です。このレジストリの値は、0-65535の範囲からのものです。
This registry is initially populated as follows:
このレジストリは最初に次のように入力されます。
+=======+=================+====================+
| Value | Description | Reference |
+=======+=================+====================+
| 0 | Reserved | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 1 | PCE-ADDRESS | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 2 | PATH-SCOPE | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 3 | PCE-DOMAIN | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 4 | NEIG-PCE-DOMAIN | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 5 | PCE-CAP-FLAGS | RFC 9353, RFC 5088 |
+-------+-----------------+--------------------+
| 6 | KEY-ID | RFC 9353 |
+-------+-----------------+--------------------+
| 7 | KEY-CHAIN-NAME | RFC 9353 |
+-------+-----------------+--------------------+
Table 2: Initial Contents of the PCED Sub-TLV Type Indicators Registry
表2：PCED Sub-TLVタイプインジケーターレジストリの初期内容
This registry is used by both the OSPF PCED TLV and the IS-IS PCED sub-TLV.
このレジストリは、OSPF PCED TLVとIS-IS PCED SUB-TLVの両方で使用されます。
This grouping is located at: <https://www.iana.org/assignments/igp-parameters/>.
このグループは、<https://www.iana.org/assignments/igp-parameters/>にあります。
[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>.
[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>.
[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>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <https://www.rfc-editor.org/info/rfc5557>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
[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>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
Element Communication Protocol (PCEP) Extension for Flow
Specification", RFC 9168, DOI 10.17487/RFC9168, January
2022, <https://www.rfc-editor.org/info/rfc9168>.
[LSR-OSPF-TRANSPORT-INSTANCE]
Lindem, A., Qu, Y., Roy, A., and S. Mirtorabi, "OSPF-GT
(Generalized Transport)", Work in Progress, Internet-
Draft, draft-ietf-lsr-ospf-transport-instance-04, 3
January 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lsr-ospf-transport-instance-04>.
[PCE-PCEP-YANG]
Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-20>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC4674] Le Roux, J.L., Ed., "Requirements for Path Computation
Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,
October 2006, <https://www.rfc-editor.org/info/rfc4674>.
[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>.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
DOI 10.17487/RFC5926, June 2010,
<https://www.rfc-editor.org/info/rfc5926>.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823,
DOI 10.17487/RFC6823, December 2012,
<https://www.rfc-editor.org/info/rfc6823>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security
Considerations", Unicode Technical Report #36, August
2010, <https://www.unicode.org/unicode/reports/tr36/>.
The authors of this document would like to thank Acee Lindem, Julien Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch, Aijun Wang, and Adrian Farrel for the review and comments.
この文書の著者は、レビューとコメントをしてくれたエイシー・リンデム、ジュリエン・ムリック、レス・ギンズバーグ、ケタン・タライカー、トム・ペッチ、アイジュン・ワン、エイドリアン・ファレルに感謝します。
The authors would also like to give special thanks to Michale Wang for his major contributions to the initial draft version.
著者はまた、最初のドラフトバージョンへの主要な貢献に対して、マイケル・ワンに特別な感謝を捧げたいと思います。
Thanks to John Scudder for providing an excellent AD review. Thanks to Carlos Pignataro, Yaron Sheffer, Ron Bonica, and Will (Shucheng) LIU for directorate reviews.
優れた広告レビューを提供してくれたJohn Scudderに感謝します。Carlos Pignataro、Yaron Sheffer、Ron Bonica、およびWill（Shucheng）Liuに感謝します。
Thanks to Lars Eggert, Robert Wilton, Roman Danyliw, Éric Vyncke, Paul Wouters, Murray Kucherawy, and Warren Kumari for IESG reviews.
Lars Eggert、Robert Wilton、Roman Danyliw、éricvyncke、Paul Wouters、Murray Kucherawy、Warren Kumariに感謝します。
Diego R. Lopez
Telefonica I+D
Spain
Email: diego.r.lopez@telefonica.com
Qin Wu
Huawei Technologies
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560037
Karnataka
India
Email: dhruv.ietf@gmail.com
Qiufang Ma
Huawei Technologies
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: maqiufang1@huawei.com
Daniel King
Old Dog Consulting
United Kingdom
Email: daniel@olddog.co.uk