[要約] 要約：RFC 6952は、KARPデザインガイドに基づいてBGP、LDP、PCEP、およびMSDPの問題を分析するものです。 目的：このRFCの目的は、キーリングと認証のためのルーティングプロトコル（KARP）デザインガイドに従って、これらのプロトコルのセキュリティ上の問題を特定し、解決策を提案することです。
Internet Engineering Task Force (IETF) M. Jethanandani
Request for Comments: 6952 Ciena Corporation
Category: Informational K. Patel
ISSN: 2070-1721 Cisco Systems, Inc
L. Zheng
Huawei Technologies
May 2013
Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
Keying and Authentication for Routing Protocols（KARP）Design GuideによるBGP、LDP、PCEP、MSDPの問題の分析
Abstract
概要
This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.
このドキュメントでは、以下のガイドラインに従って、TCPベースのルーティングプロトコル、ボーダーゲートウェイプロトコル（BGP）、ラベル配布プロトコル（LDP）、パス計算要素通信プロトコル（PCEP）、およびマルチキャストソース配布プロトコル（MSDP）を分析しますRFC 6518の「ルーティングプロトコル設計ガイドラインのキーイングと認証」のセクション4.2。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6952.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6952で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Current Assessment of BGP, LDP, PCEP, and MSDP . . . . . . . 5
2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying Mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.4.2. Denial-of-Service Attacks . . . . . . . . . . . . . . 8
2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transition and Deployment Considerations . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
In their "Report from the IAB Workshop on Unwanted Traffic March 9-10, 2006" [RFC4948], the Internet Architecture Board (IAB) described an attack on core routing infrastructure as an ideal attack that would inflict the greatest amount of damage and suggested steps to tighten the infrastructure against the attack. Four main steps were identified for that tightening:
2006年3月9〜10日の「不要なトラフィックに関するIABワークショップの報告」[RFC4948]で、インターネットアーキテクチャボード（IAB）は、コアルーティングインフラストラクチャへの攻撃を、最大の被害を与える理想的な攻撃であると説明し、攻撃に対するインフラストラクチャを強化する手順。その引き締めのために4つの主要なステップが確認されました。
1. Create secure mechanisms and practices for operating routers.
1. ルーターを操作するための安全なメカニズムとプラクティスを作成します。
2. Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access, so that it can be used for routing verifications.
2. インターネットルーティングレジストリ（IRR）リポジトリをクリーンアップし、データベースとアクセスの両方を保護して、ルーティング検証に使用できるようにします。
3. Create specifications for cryptographic validation of routing message content.
3. ルーティングメッセージコンテンツの暗号検証の仕様を作成します。
4. Secure the routing protocols' packets on the wire.
4. ルーティングプロトコルのパケットをネットワーク上で保護します。
In order to secure the routing protocols, this document performs an initial analysis of the current state of four TCP-based protocols -- BGP [RFC4271], LDP [RFC5036], PCEP [RFC5440], and MSDP [RFC3618] -- according to the requirements of the KARP Design Guidelines [RFC6518]. Section 4.2 of that document uses the term "state", which will be referred to as the "state of the security method". Thus, a term like "Define Optimal State" would be referred to as "Define Optimal State of the Security Method".
ルーティングプロトコルを保護するために、このドキュメントでは、4つのTCPベースのプロトコル（BGP [RFC4271]、LDP [RFC5036]、PCEP [RFC5440]、およびMSDP [RFC3618]）の現在の状態の初期分析を実行します。 KARP設計ガイドライン[RFC6518]の要件。そのドキュメントのセクション4.2では、「セキュリティメソッドの状態」と呼ばれる「状態」という用語を使用しています。したがって、「最適状態の定義」のような用語は、「セキュリティメソッドの最適状態の定義」と呼ばれます。
This document builds on several previous efforts into routing security:
このドキュメントは、ルーティングセキュリティに関するこれまでのいくつかの取り組みに基づいています。
o "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039], describes issues with existing cryptographic protection methods for routing protocols.
o 「ルーティングプロトコルの既存の暗号化保護方式の問題」[RFC6039]では、ルーティングプロトコルの既存の暗号化保護方式の問題について説明しています。
o Analysis of OSPF Security According to the KARP Design Guide [RFC6863] analyzes Open Shortest Path First (OSPF) security according to the KARP Design Guide.
o KARP設計ガイド[RFC6863]によるOSPFセキュリティの分析は、KARP設計ガイドによるOpen Shortest Path First（OSPF）セキュリティを分析します。
Section 2 of this document looks at the current state of the security method for the four routing protocols: BGP, LDP, PCEP, and MSDP. Section 3 examines what the optimal state of the security method would be for the four routing protocols according to the KARP Design Guidelines [RFC6518], and Section 4 does an analysis of the gap between the existing state of the security method and the optimal state of the security method for the protocols and suggests some areas where improvement is needed.
このドキュメントのセクション2では、4つのルーティングプロトコル（BGP、LDP、PCEP、MSDP）のセキュリティメソッドの現在の状態について説明します。セクション3では、KARP設計ガイドライン[RFC6518]に従って、4つのルーティングプロトコルに対するセキュリティメソッドの最適な状態を検討し、セクション4では、セキュリティメソッドの既存の状態と最適な状態のギャップを分析します。プロトコルのセキュリティメソッドであり、改善が必要ないくつかの領域を提案します。
AES - Advanced Encryption Standard
AES-Advanced Encryption Standard
AO - Authentication Option
AO-認証オプション
AS - Autonomous System
AS-自律システム
BGP - Border Gateway Protocol
BGP-ボーダーゲートウェイプロトコル
CMAC - Cipher-Based Message Authentication Code
CMAC-暗号ベースのメッセージ認証コード
DoS - Denial of Service
DoS-サービス拒否
GTSM - Generalized Time-to-Live (TTL) Security Mechanism
GTSM-一般化された存続時間（TTL）セキュリティメカニズム
HMAC - Hash-Based MAC
HMAC-ハッシュベースのMAC
KARP - Key and Authentication for Routing Protocols
KARP-ルーティングプロトコルのキーと認証
KDF - Key Derivation Function
KDF-鍵導出関数
KEK - Key Encrypting Key
ケーキ-何を暗号化するか
KMP - Key Management Protocol
KMP-キー管理プロトコル
LDP - Label Distribution Protocol
LDP-ラベル配布プロトコル
LSR - Label Switching Routers
LSR-ラベルスイッチングルーター
MAC - Message Authentication Code
MAC-メッセージ認証コード
MKT - Master Key Table
MKT-マスターキーテーブル
MSDP - Multicast Source Distribution Protocol
MSDP-マルチキャストソース配布プロトコル
MD5 - Message Digest Algorithm 5
MD5-メッセージダイジェストアルゴリズム5
OSPF - Open Shortest Path First
OSPF-Open Shortest Path First
PCEP - Path Computation Element Communication Protocol
PCEP-パス計算要素通信プロトコル
PCC - Path Computation Client
PCC-パス計算クライアント
PCE - Path Computation Element
PCE-パス計算要素
SHA - Secure Hash Algorithm TCP - Transmission Control Protocol
SHA-セキュアハッシュアルゴリズムTCP-伝送制御プロトコル
TTL - Time-to-Live
TTL-存続時間
UDP - User Datagram Protocol
UDP-ユーザーデータグラムプロトコル
WG - Working Group
WG-ワーキンググループ
This section assesses the transport protocols for any authentication or integrity mechanisms used by the protocol. It describes the current security mechanisms, if any, used by BGP, LDP, PCEP, and MSDP.
このセクションでは、プロトコルで使用される認証または整合性メカニズムのトランスポートプロトコルを評価します。 BGP、LDP、PCEP、およびMSDPで使用されている現在のセキュリティメカニズムがあれば説明します。
At the transport layer, routing protocols are subject to a variety of DoS attacks, as outlined in "Internet Denial-of-Service Considerations" [RFC4732]. Such attacks can cause the routing protocol to become congested, resulting in the routing updates being supplied too slowly to be useful. In extreme cases, these attacks prevent routers from converging after a change.
トランスポート層では、「インターネットのサービス拒否に関する考慮事項」[RFC4732]で概説されているように、ルーティングプロトコルはさまざまなDoS攻撃の影響を受けます。このような攻撃により、ルーティングプロトコルが輻輳し、ルーティングアップデートの提供が遅すぎて役に立たなくなる可能性があります。極端な場合、これらの攻撃により、変更後のルーターの収束が妨げられます。
Routing protocols use several methods to protect themselves. Those that use TCP as a transport protocol use access lists to accept packets only from known sources. These access lists also help protect edge routers from attacks originating outside the protected domain. In addition, for edge routers running the External Border Gateway Protocol (eBGP), TCP LISTEN is run only on interfaces on which its peers have been discovered or via which routing sessions are expected (as specified in router configuration databases).
ルーティングプロトコルは、いくつかの方法を使用して自身を保護します。トランスポートプロトコルとしてTCPを使用するものは、アクセスリストを使用して、既知のソースからのパケットのみを受け入れます。これらのアクセスリストは、保護されたドメインの外部からの攻撃からエッジルーターを保護するのにも役立ちます。さらに、外部ボーダーゲートウェイプロトコル（eBGP）を実行しているエッジルーターの場合、TCP LISTENは、そのピアが検出されたインターフェイスまたはルーティングセッションが予想されるインターフェイス（ルーター構成データベースで指定されている）でのみ実行されます。
"Generalized TTL Security Mechanism (GTSM)" [RFC5082] describes a generalized Time-to-Live (TTL) security mechanism to protect a protocol stack from CPU-utilization-based attacks. TCP Robustness [RFC5961] recommends some TCP-level mitigations against spoofing attacks targeted towards long-lived routing protocol sessions.
「一般化されたTTLセキュリティメカニズム（GTSM）」[RFC5082]では、CPU使用率ベースの攻撃からプロトコルスタックを保護するための一般化された存続時間（TTL）セキュリティメカニズムについて説明しています。 TCPの堅牢性[RFC5961]は、長命のルーティングプロトコルセッションを対象としたスプーフィング攻撃に対するTCPレベルの緩和策を推奨しています。
Even when BGP, LDP, PCEP, and MSDP sessions use access lists, they are vulnerable to spoofing and man-in-the-middle attacks. Authentication and integrity checks allow the receiver of a routing protocol update to know that the message genuinely comes from the node that claims to have sent it and to know whether the message has been modified. Sometimes routers can be subjected to a large number of authentication and integrity requests, exhausting connection resources on the router in a way that could lead to the denial of genuine requests.
BGP、LDP、PCEP、およびMSDPセッションがアクセスリストを使用する場合でも、それらはスプーフィングおよび中間者攻撃に対して脆弱です。認証と整合性のチェックにより、ルーティングプロトコルの更新の受信者は、メッセージが本当に送信したと主張するノードから送信されたものであること、およびメッセージが変更されているかどうかを知ることができます。ルーターは、大量の認証要求と整合性要求の対象となる場合があり、真の要求の拒否につながる可能性のある方法で、ルーターの接続リソースを使い果たします。
TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However, it is still widely used to authenticate TCP-based routing protocols such as BGP. It provides a way for carrying a MD5 digest in a TCP segment. This digest is computed using information known only to the endpoints, and this ensures authenticity and integrity of messages. The MD5 key used to compute the digest is stored locally on the router. This option is used by routing protocols to provide for session-level protection against the introduction of spoofed TCP segments into any existing TCP streams, in particular, TCP Reset segments. TCP MD5 does not provide a generic mechanism to support key rollover. It also does not support algorithm agility.
TCP MD5 [RFC2385]は、TCP-AO [RFC5925]によって廃止されました。ただし、BGPなどのTCPベースのルーティングプロトコルを認証するために依然として広く使用されています。 TCPセグメントでMD5ダイジェストを伝送する方法を提供します。このダイジェストはエンドポイントだけが知っている情報を使用して計算され、これによりメッセージの信頼性と整合性が保証されます。ダイジェストの計算に使用されるMD5キーは、ルーターのローカルに保存されます。このオプションはルーティングプロトコルによって使用され、既存のTCPストリーム、特にTCPリセットセグメントへのなりすましTCPセグメントの導入に対するセッションレベルの保護を提供します。 TCP MD5は、キーのロールオーバーをサポートする一般的なメカニズムを提供していません。また、アルゴリズムの俊敏性もサポートしていません。
The Message Authentication Codes (MACs) used by TCP MD5 are considered too weak both because of the use of the hash function and because of the way the secret key used by TCP MD5 is managed. Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO [RFC5925] and its companion document Cryptographic Algorithms for TCP-AO [RFC5926], describe steps towards correcting both the MAC weakness and the management of secret keys. Those steps require that two MAC algorithms be supported. They are HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that both these MAC algorithms are fairly secure. By supporting multiple MAC algorithms, TCP-AO supports algorithm agility. TCP-AO also allows additional MACs to be added in the future.
TCP MD5で使用されるメッセージ認証コード（MAC）は、ハッシュ関数の使用とTCP MD5で使用される秘密鍵の管理方法の両方が原因で、弱すぎると見なされています。さらに、TCP MD5はアルゴリズムの俊敏性をサポートしていません。 TCP-AO [RFC5925]とその関連ドキュメントであるTCP-AOの暗号化アルゴリズム[RFC5926]では、MACの脆弱性と秘密鍵の管理の両方を修正するための手順について説明しています。これらの手順では、2つのMACアルゴリズムがサポートされている必要があります。それらは、HMAC [RFC2104]で指定されているHMAC-SHA-1-96、およびNIST-SP800-38B [NIST-SP800-38B]で指定されているAES-128-CMAC-96です。暗号化の研究は、これらのMACアルゴリズムはどちらもかなり安全であることを示唆しています。複数のMACアルゴリズムをサポートすることにより、TCP-AOはアルゴリズムの俊敏性をサポートします。 TCP-AOでは、将来的に追加のMACを追加することもできます。
For TCP-AO [RFC5925], there is no Key Management Protocol (KMP) used to manage the keys that are employed to generate the MAC. TCP-AO talks about coordinating keys derived from the Master Key Table (MKT) between endpoints and allows for a master key to be configured manually or for it to be managed via an out-of-band mechanism.
TCP-AO [RFC5925]の場合、MACの生成に使用されるキーの管理に使用されるキー管理プロトコル（KMP）はありません。 TCP-AOは、エンドポイント間のマスターキーテーブル（MKT）から派生したキーの調整について話し、マスターキーを手動で構成したり、帯域外メカニズムを介して管理したりできるようにします。
It should be noted that most routers configured with static keys have not seen the key changed ever. The common reason given for not changing the key is the difficulty in coordinating the change between pairs of routers when using TCP MD5. It is well known that the longer the same key is used, the greater the chance that it can be guessed or exposed, e.g., when an administrator with knowledge of the keys leaves the company.
静的キーで構成されたほとんどのルーターでは、キーが変更されたことはありません。キーを変更しない一般的な理由は、TCP MD5を使用する場合に、ルーターのペア間の変更を調整するのが難しいことです。同じキーが長く使用されるほど、たとえばキーの知識を持つ管理者が退職した場合などに、そのキーが推測または公開される可能性が高くなることはよく知られています。
For point-to-point key management, the IKEv2 protocol [RFC5996] provides for automated key exchange under a Security Association (SA) and can be used for a comprehensive KMP solution for routers. IKEv2 can be used for both IPsec SAs [RFC4301] and other types of SAs. For example, Fibre Channel SAs [RFC4595] are currently negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a possible option.
ポイントツーポイントキー管理の場合、IKEv2プロトコル[RFC5996]は、セキュリティアソシエーション（SA）での自動キー交換を提供し、ルーターの包括的なKMPソリューションに使用できます。 IKEv2は、IPsec SA [RFC4301]と他のタイプのSAの両方に使用できます。たとえば、ファイバチャネルSA [RFC4595]は現在、IKEv2とネゴシエートされています。 IKEv2を使用してTCP-AOをネゴシエートすることは、可能なオプションです。
All BGP communications take place over TCP. Therefore, all security vulnerabilities for BGP can be categorized as relating to the security of the transport protocol itself, or to the compromising of individual routers and the data they handle. This document examines the issues for the transport protocol, while the SIDR Working Group (WG) looks at ways to sign and secure the data exchanged in BGP as described in "An Infrastructure to Support Secure Internet Protocol" [RFC6480].
すべてのBGP通信はTCPを介して行われます。したがって、BGPのすべてのセキュリティ脆弱性は、トランスポートプロトコル自体のセキュリティ、または個々のルーターとそれらが処理するデータの侵害に関連するものとして分類できます。このドキュメントでは、トランスポートプロトコルの問題を検討し、SIDRワーキンググループ（WG）は、「安全なインターネットプロトコルをサポートするインフラストラクチャ」[RFC6480]で説明されているように、BGPで交換されるデータに署名して保護する方法を検討します。
"Security Framework for MPLS and GMPLS Networks" [RFC5920] outlines security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanism for detection and reporting.
「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]は、MPLSおよびGMPLSのコンテキストに関連するセキュリティの側面を概説しています。セキュリティの脅威、関連する防御技術、および検出とレポートのメカニズムについて説明します。
Section 5 of LDP [RFC5036] states that LDP is subject to two different types of attacks: spoofing and denial-of-service attacks.
LDP [RFC5036]のセクション5には、LDPが2つの異なるタイプの攻撃、つまり、なりすまし攻撃とサービス拒否攻撃の影響を受けると述べています。
A spoofing attack against LDP can occur both during the discovery phase and during the session communication phase.
LDPに対するスプーフィング攻撃は、検出フェーズとセッション通信フェーズの両方で発生する可能性があります。
Label Switching Routers (LSRs) indicate their willingness to establish and maintain LDP sessions by periodically sending Hello messages. Reception of a Hello message serves to create a new "Hello adjacency", if one does not already exist, or to refresh an existing one.
ラベルスイッチングルーター（LSR）は、定期的にHelloメッセージを送信することにより、LDPセッションを確立および維持する意欲を示します。 Helloメッセージを受信すると、新しい「Hello隣接関係」がまだ存在しない場合は作成されるか、既存のものが更新されます。
There are two variants of the discovery mechanism. A Basic Discovery mechanism is used to discover LSR neighbors that are directly connected at the link level, and an Extended Discovery mechanism is used by LSRs that are more than one hop away.
検出メカニズムには2つのバリアントがあります。基本検出メカニズムは、リンクレベルで直接接続されているLSRネイバーを検出するために使用され、拡張検出メカニズムは、1ホップ以上離れたLSRによって使用されます。
Unlike all other LDP messages, the Hello messages are sent using UDP. This means that they cannot benefit from the security mechanisms available with TCP. LDP [RFC5036] does not provide any security mechanisms for use with Hello messages except for some configuration that may help protect against bogus discovery events. These configurations include directly connected links and interfaces. Routers that do not use directly connected links have to use the Extended Discovery mechanism and will not be able to use configuration to protect against bogus discovery events.
他のすべてのLDPメッセージとは異なり、HelloメッセージはUDPを使用して送信されます。つまり、TCPで利用可能なセキュリティメカニズムを利用することはできません。 LDP [RFC5036]は、Helloメッセージで使用するセキュリティメカニズムを提供していません。ただし、偽の検出イベントからの保護に役立つ可能性があるいくつかの構成は除きます。これらの構成には、直接接続されたリンクとインターフェースが含まれます。直接接続されたリンクを使用しないルーターは、拡張検出メカニズムを使用する必要があり、構成を使用して偽の検出イベントから保護することはできません。
Spoofing a Hello packet for an existing adjacency can cause the adjacency to time out and result in termination of the associated session. This can occur when the spoofed Hello message specifies a small Hold Time, causing the receiver to expect Hello messages within this interval, while the true neighbor continues sending Hello messages at the lower, previously agreed to frequency.
既存の隣接関係のHelloパケットをスプーフィングすると、隣接関係がタイムアウトし、関連するセッションが終了する可能性があります。これは、スプーフィングされたHelloメッセージが小さなホールドタイムを指定し、受信者がこの間隔内にHelloメッセージを予期するときに発生しますが、真のネイバーは、以前に同意された低い頻度でHelloメッセージを送信し続けます。
Spoofing a Hello packet can also cause the LDP session to be terminated. This can occur when the spoofed Hello specifies a different Transport Address from the previously agreed one between neighbors. Spoofed Hello messages are observed and reported as a real problem in production networks.
Helloパケットをスプーフィングすると、LDPセッションが終了することもあります。これは、スプーフィングされたHelloが、以前にネイバー間で合意したものとは異なるトランスポートアドレスを指定した場合に発生する可能性があります。スプーフィングされたHelloメッセージが観察され、実稼働ネットワークの実際の問題として報告されます。
LDP, like other TCP-based routing protocols, specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages. As stated in Section 2.1 of this document and in Section 2.9 of LDP [RFC5036], MD5 authentication is considered too weak for this application as outlined in MD5 and HMAC-MD5 Security Considerations [RFC6151]. It also does not support algorithm agility. A stronger hashing algorithm, e.g., SHA1, which is supported by TCP-AO [RFC5925], could be deployed to take care of the weakness.
LDPは、他のTCPベースのルーティングプロトコルと同様に、セッションメッセージの信頼性と整合性を提供するために、TCP MD5署名オプションの使用を指定します。このドキュメントのセクション2.1およびLDP [RFC5036]のセクション2.9で述べられているように、MD5およびHMAC-MD5のセキュリティに関する考慮事項[RFC6151]で概説されているように、MD5認証はこのアプリケーションには弱すぎると見なされています。また、アルゴリズムの俊敏性もサポートしていません。 TCP-AO [RFC5925]でサポートされているSHA1などのより強力なハッシュアルゴリズムをデプロイして、弱点を処理できます。
Alternatively, one could move to using TCP-AO, which provides for stronger MAC algorithms, makes it easier to set up manual keys, and protects against replay attacks.
または、より強力なMACアルゴリズムを提供し、手動キーのセットアップを容易にし、リプレイ攻撃から保護するTCP-AOの使用に移行することもできます。
LDP is subject to Denial-of-Service (DoS) attacks both in discovery mode and session mode. The potential targets are documented in Section 5.3 of LDP [RFC5036].
LDPは、検出モードとセッションモードの両方でサービス拒否（DoS）攻撃の影響を受けます。潜在的な目標は、LDP [RFC5036]のセクション5.3に文書化されています。
For effective selection by Path Computation Clients (PCCs), a PCC needs to know the location of Path Computation Elements (PCEs) in its domain along with some information relevant for PCE selection. Such PCE information could be learned through manual configuration, on each PCC, along with the capabilities of the PCE or automatically through a PCE discovery mechanism as outlined in Requirements for PCE Discovery [RFC4674].
パス計算クライアント（PCC）による効果的な選択のために、PCCは、ドメイン内のパス計算要素（PCE）の場所と、PCE選択に関連するいくつかの情報を知る必要があります。このようなPCE情報は、PCEの機能と共に、各PCCでの手動構成を通じて、またはPCE検出の要件[RFC4674]で概説されているPCE検出メカニズムを通じて自動的に学習できます。
Attacks on PCEP [RFC5440] may result in damage to active networks. These include computation responses, which if changed can cause protocols like RSVP-TE [RFC3209] to set up suboptimal or inappropriate LSPs. In addition, PCE itself can be a target for a variety of DoS attacks. Such attacks can cause path computations to be supplied too slowly to be of any value, particularly as it relates to recovery or establishment of LSPs.
PCEP [RFC5440]への攻撃は、アクティブなネットワークに損害を与える可能性があります。これらには、変更された場合にRSVP-TE [RFC3209]などのプロトコルが最適以下または不適切なLSPをセットアップする原因となる計算応答が含まれます。さらに、PCE自体がさまざまなDoS攻撃の標的になる可能性があります。このような攻撃は、特にLSPの回復または確立に関連する場合、パス計算の供給が遅すぎて価値がなくなる可能性があります。
Finally, PCE discovery, as outlined in OSPF Protocol Extensions for PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE Discovery [RFC5089], is a significant feature for the successful deployment of PCEP in large networks. These mechanisms allow PCC to discover the existence of PCEs within the network. If the discovery mechanism is compromised, it will impair the ability of the nodes to function as described below.
最後に、PCEディスカバリーのOSPFプロトコル拡張[RFC5088]およびPCEディスカバリーのIS-ISプロトコル拡張[RFC5089]で概説されているPCEディスカバリーは、大規模ネットワークでPCEPを正常に展開するための重要な機能です。これらのメカニズムにより、PCCはネットワーク内のPCEの存在を検出できます。検出メカニズムが危険にさらされると、以下で説明するように機能するノードの機能が損なわれます。
As RFC 5440 states, PCEP (which makes use of TCP as a transport) could be the target of the following attacks:
RFC 5440に記載されているように、PCEP（トランスポートとしてTCPを使用）は、次の攻撃の標的になる可能性があります。
o Spoofing (PCC or PCE implementation)
o なりすまし（PCCまたはPCE実装）
o Snooping (message interception)
o スヌーピング（メッセージ傍受）
o Falsification
o 改ざん
o Denial of Service
o サービス拒否
In inter-Autonomous System (inter-AS) scenarios where PCE-to-PCE communication is required, attacks may be particularly significant with commercial implications as well as service-level agreement implications.
PCEからPCEへの通信が必要な自律システム間（AS間）のシナリオでは、攻撃は、サービスレベルの合意の影響だけでなく、商業的な影響も伴い、特に重大になる可能性があります。
Additionally, snooping of PCEP requests and responses may give an attacker information about the operation of the network. By viewing the PCEP messages, an attacker can determine the pattern of service establishment in the network and can know where traffic is being routed, thereby making the network susceptible to targeted attacks and the data within specific LSPs vulnerable.
さらに、PCEP要求と応答のスヌーピングは、攻撃者にネットワークの操作に関する情報を提供する可能性があります。攻撃者はPCEPメッセージを表示することで、ネットワーク内のサービス確立のパターンを特定し、トラフィックがルーティングされている場所を知ることができるため、ネットワークが標的型攻撃や特定のLSP内のデータの影響を受けやすくなります。
Ensuring PCEP communication privacy is of key importance, especially in an inter-AS context, where PCEP communication endpoints do not reside in the same AS. An attacker that intercepts a PCE message could obtain sensitive information related to computed paths and resources.
PCEP通信のプライバシーを確保することは、特にPCEP通信エンドポイントが同じAS内に存在しないAS間コンテキストにおいて、非常に重要です。 PCEメッセージを傍受する攻撃者は、計算されたパスとリソースに関連する機密情報を入手する可能性があります。
At the time PCEP was documented in [RFC5440], TCP-AO had not been fully specified. Therefore, [RFC5440] mandates that PCEP implementations include support for TCP MD5 and that use of the function should be configurable by the operator. [RFC5440] also describes the vulnerabilities and weaknesses of TCP MD5 as noted in this document. [RFC5440] goes on to state that PCEP implementations should include support for TCP-AO as soon as that specification is complete. Since TCP-AO [RFC5925] has now been published, new PCEP implementations should fully support TCP-AO.
PCEPが[RFC5440]で文書化された時点では、TCP-AOは完全には指定されていませんでした。したがって、[RFC5440]では、PCEP実装にTCP MD5のサポートが含まれ、関数の使用はオペレーターが構成できるようにする必要があります。 [RFC5440]は、このドキュメントに記載されているTCP MD5の脆弱性と弱点についても説明しています。 [RFC5440]はさらに、PCEPの実装には、その仕様が完成したらすぐにTCP-AOのサポートを含める必要があると述べています。 TCP-AO [RFC5925]が公開されたので、新しいPCEP実装はTCP-AOを完全にサポートするはずです。
Similar to BGP and LDP, the Multicast Source Distribution Protocol (MSDP) uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 option. But with a weak MD5 authentication, TCP MD5 is not considered strong enough for this application. It also does not support algorithm agility.
BGPおよびLDPと同様に、マルチキャストソース配布プロトコル（MSDP）はTCP MD5 [RFC2385]を使用して、TCP MD5オプションを介してTCPセッションを保護します。しかし、弱いMD5認証では、TCP MD5はこのアプリケーションには十分強力とは見なされません。また、アルゴリズムの俊敏性もサポートしていません。
MSDP advocates imposing a limit on the number of source address and group addresses (S,G) that can be cached within the protocol in order to mitigate state explosion due to any denial of service and other attacks.
MSDPは、サービス拒否やその他の攻撃による状態の爆発を緩和するために、プロトコル内にキャッシュできるソースアドレスとグループアドレス（S、G）の数に制限を課すことを提唱しています。
The ideal state of the security method for BGP, LDP, PCEP, and MSDP protocols is when they can withstand any of the known types of attacks. The protocols also need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm.
BGP、LDP、PCEP、およびMSDPプロトコルのセキュリティ方式の理想的な状態は、既知のタイプの攻撃に耐えられる場合です。プロトコルは、アルゴリズムの俊敏性もサポートする必要があります。つまり、プロトコルを1つのアルゴリズムに固定することはできません。
Additionally, the KMP for the routing sessions should help negotiate unique, pair-wise random keys without administrator involvement. It should also negotiate Security Association (SA) parameters required for the session connection, including key lifetimes. It should keep track of those lifetimes and negotiate new keys and parameters before they expire and do so without administrator involvement. In the event of a breach, including when an administrator with knowledge of the keys leaves the company, the keys should be changed immediately.
さらに、ルーティングセッションのKMPは、管理者の介入なしに、一意のペアワイズランダムキーをネゴシエートするのに役立ちます。また、キーの有効期間など、セッション接続に必要なセキュリティアソシエーション（SA）パラメータについてもネゴシエートする必要があります。これらのライフタイムを追跡し、新しいキーとパラメータが期限切れになる前にネゴシエートし、管理者の関与なしに行う必要があります。キーの知識を持つ管理者が退職した場合など、違反が発生した場合は、キーをすぐに変更する必要があります。
The DoS attacks for BGP, LDP, PCEP, and MSDP are attacks to the transport protocol -- TCP for the most part, and UDP in case of the discovery phase of LDP. TCP and UDP should be able to withstand any of the DoS scenarios by dropping packets that are attack packets in a way that does not impact legitimate packets.
BGP、LDP、PCEP、およびMSDPに対するDoS攻撃は、トランスポートプロトコルに対する攻撃です。大部分はTCPであり、LDPの検出フェーズの場合はUDPです。 TCPおよびUDPは、正当なパケットに影響を与えない方法で攻撃パケットであるパケットをドロップすることにより、あらゆるDoSシナリオに耐えることができる必要があります。
The routing protocols should provide a mechanism to authenticate the routing information carried within the payload, and administrators should enable it.
ルーティングプロトコルは、ペイロード内で運ばれるルーティング情報を認証するメカニズムを提供し、管理者はそれを有効にする必要があります。
To mitigate LDP's current vulnerability to spoofing attacks, LDP needs to be upgraded such that an implementation is able to determine the authenticity of the neighbors sending the Hello message.
LDPのスプーフィング攻撃に対する現在の脆弱性を緩和するには、LDPをアップグレードして、Helloメッセージを送信するネイバーの信頼性を実装が判別できるようにする必要があります。
Labels are similar to routing information, which is distributed in the clear. However, there is currently no requirement that the labels be encrypted. Such a requirement is out of scope for this document.
ラベルは、平文で配布されるルーティング情報に似ています。ただし、現在のところ、ラベルを暗号化する必要はありません。このような要件は、このドキュメントの範囲外です。
Similarly, it is important to ensure that routers exchanging labels are mutually authenticated, and that there are no rogue peers or unauthenticated peers that can compromise the stability of the network.
同様に、ラベルを交換するルーターが相互に認証されていること、およびネットワークの安定性を損なう可能性のある不正なピアや認証されていないピアがないことを確認することが重要です。
This section outlines the differences between the current state of the security methods for routing protocols and the desired state of the security methods as outlined in Section 4.2 of the KARP Design Guidelines [RFC6518]. As that document states, these routing protocols fall into the category of one-to-one peering messages and will use peer keying protocols. This section covers issues that are common to the four protocols, leaving protocol-specific issues to sub-sections.
このセクションでは、ルーティングプロトコルのセキュリティメソッドの現在の状態と、KARP設計ガイドライン[RFC6518]のセクション4.2で説明されているセキュリティメソッドの望ましい状態の違いについて概説します。そのドキュメントに記載されているように、これらのルーティングプロトコルは1対1のピアリングメッセージのカテゴリに分類され、ピアキーイングプロトコルを使用します。このセクションでは、4つのプロトコルに共通する問題について説明し、プロトコル固有の問題はサブセクションに残します。
At a transport level, these routing protocols are subject to some of the same attacks that TCP applications are subject to. These include DoS and spoofing attacks. "Internet Denial-of-Service Considerations" [RFC4732] outlines some solutions. "Defending TCP Against Spoofing Attacks" [RFC4953] recommends ways to prevent spoofing attacks. In addition, the recommendations in [RFC5961] should also be followed and implemented to strengthen TCP.
トランスポートレベルでは、これらのルーティングプロトコルは、TCPアプリケーションが受けるのと同じ攻撃の一部を受けます。これには、DoSおよびスプーフィング攻撃が含まれます。 「インターネットのサービス拒否の考慮事項」[RFC4732]はいくつかの解決策を概説しています。 「なりすまし攻撃に対するTCPの防御」[RFC4953]は、なりすまし攻撃を防ぐ方法を推奨しています。さらに、[RFC5961]の推奨事項にも従い、TCPを強化するために実装する必要があります。
Routers lack comprehensive key management and keys derived that they can use to authenticate data. As an example, TCP-AO [RFC5925], talks about coordinating keys derived from the Master Key Table (MKT) between endpoints, but the MKT itself has to be configured manually or through an out-of-band mechanism. Also, TCP-AO does not address the issue of connectionless reset, as it applies to routers that do not store MKT across reboots.
ルーターには、包括的なキー管理と、データの認証に使用できる派生キーがありません。例として、TCP-AO [RFC5925]は、エンドポイント間のマスターキーテーブル（MKT）から派生したキーの調整について話しますが、MKT自体は手動で、またはアウトオブバンドメカニズムを介して構成する必要があります。また、TCP-AOは、再起動後にMKTを保存しないルーターに適用されるため、コネクションレスリセットの問題には対応していません。
Authentication, integrity protection, and encryption all require the use of keys by sender and receiver. An automated KMP, therefore has to include a way to distribute key material between two endpoints with little or no administrative overhead. It has to cover automatic key rollover. It is expected that authentication will cover the packet, i.e., the payload and the TCP header, and will not cover the frame, i.e., the layer 2 header.
認証、整合性保護、および暗号化はすべて、送信者と受信者による鍵の使用を必要とします。したがって、自動化されたKMPには、管理オーバーヘッドがほとんどないかまったくない2つのエンドポイント間で鍵素材を配布する方法を含める必要があります。自動キーロールオーバーをカバーする必要があります。認証はパケット（ペイロードとTCPヘッダー）をカバーし、フレーム（レイヤー2ヘッダー）をカバーしないことが予想されます。
There are two methods of automatic key rollover. Implicit key rollover can be initiated after a certain volume of data gets exchanged or when a certain time has elapsed. This does not require explicit signaling nor should it result in a reset of the TCP connection in a way that the links/adjacencies are affected. On the other hand, explicit key rollover requires an out-of-band key signaling mechanism. It can be triggered by either side and can be done anytime a security parameter changes, e.g., an attack has happened, or a system administrator with access to the keys has left the company. An example of this is IKEv2 [RFC5996], but it could be any other new mechanisms also.
自動キーロールオーバーには2つの方法があります。暗黙的なキーのロールオーバーは、特定の量のデータが交換された後、または特定の時間が経過したときに開始できます。これは明示的なシグナリングを必要とせず、リンク/隣接が影響を受けるような方法でTCP接続をリセットする必要もありません。一方、明示的なキーロールオーバーには、帯域外キーシグナリングメカニズムが必要です。これはどちらの側からもトリガーでき、攻撃などのセキュリティパラメータの変更や、キーへのアクセス権を持つシステム管理者が会社を辞めたときにいつでも実行できます。この例はIKEv2 [RFC5996]ですが、他の新しいメカニズムも考えられます。
As stated earlier, TCP-AO [RFC5925] and its accompanying document, Cryptographic Algorithms for TCP-AO [RFC5926], require that two MAC algorithms be supported, and they are HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility requirement.
前述のように、TCP-AO [RFC5925]とそれに付随するドキュメント、TCP-AOの暗号化アルゴリズム[RFC5926]では、2つのMACアルゴリズムがサポートされている必要があり、HMAC [RFC2104で指定されているように、それらはHMAC-SHA-1-96です。 ]、およびNIST-SP800-38B [NIST-SP800-38B]で指定されているAES-128-CMAC-96。したがって、TCP-AOはアルゴリズムの俊敏性要件を満たします。
There is a need to protect authenticity and validity of the routing/ label information that is carried in the payload of the sessions. However, that is outside the scope of this document and is being addressed by the SIDR WG. Similar mechanisms could be used for intra-domain protocols.
セッションのペイロードで運ばれるルーティング/ラベル情報の信頼性と有効性を保護する必要があります。ただし、これはこのドキュメントの範囲外であり、SIDR WGによって対処されています。同様のメカニズムをドメイン内プロトコルに使用できます。
Finally, replay protection is required. The replay mechanism needs to be sufficient to prevent an attacker from creating a denial of service or disrupting the integrity of the routing protocol by replaying packets. It is important that an attacker not be able to disrupt service by capturing packets and waiting for replay state to be lost.
最後に、リプレイ保護が必要です。攻撃者がサービス拒否を作成したり、パケットを再生してルーティングプロトコルの整合性を妨害したりしないように、再生メカニズムは十分である必要があります。攻撃者がパケットをキャプチャし、再生状態が失われるのを待つことでサービスを妨害できないことが重要です。
As described in LDP [RFC5036], the threat of spoofed Basic Hellos can be reduced by only accepting Basic Hellos on interfaces that LSRs trust, employing GTSM [RFC5082], and ignoring Basic Hellos not addressed to the "all routers on this subnet" multicast group. Spoofing attacks via Targeted Hellos are potentially a more serious threat. An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting Hellos from sources permitted by access lists. However, performing the filtering using access lists requires LSR resources, and the LSR is still vulnerable to the IP source address spoofing. Spoofing attacks can be solved by being able to authenticate the Hello messages, and an LSR can be configured to only accept Hello messages from specific peers when authentication is in use.
LDP [RFC5036]で説明されているように、LSRが信頼するインターフェイスでBasic Helloのみを受け入れ、GTSM [RFC5082]を採用し、「このサブネット上のすべてのルーター」マルチキャストにアドレス指定されていないBasic Helloを無視することで、なりすましのBasic Helloの脅威を軽減できます。グループ。 Targeted Helloを介したスプーフィング攻撃は、より深刻な脅威になる可能性があります。 LSRは、フィルタリングして、アクセスリストで許可されているソースからのHelloを受け入れることにより、スプーフィングされたExtended Helloの脅威を軽減できます。ただし、アクセスリストを使用してフィルタリングを実行するにはLSRリソースが必要であり、LSRは依然としてIP送信元アドレスのスプーフィングに対して脆弱です。スプーフィング攻撃は、Helloメッセージを認証できるようにすることで解決でき、LSRは、認証が使用されているときに特定のピアからのHelloメッセージのみを受け入れるように構成できます。
LDP Hello Cryptographic Authentication [HELLO-CRYPTO] suggest a new Cryptographic Authentication TLV that can be used as an authentication mechanism to secure Hello messages.
LDP Hello暗号認証[HELLO-CRYPTO]は、Helloメッセージを保護する認証メカニズムとして使用できる新しい暗号認証TLVを提案しています。
Path Computation Element (PCE) discovery, according to [RFC5440], is a significant feature for the successful deployment of PCEP in large networks. This mechanism allows a Path Computation Client (PCC) to discover the existence of suitable PCEs within the network without the necessity of configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC cannot know the correct key to use. There are different approaches to retain some aspect of security, but all of them require use of a keys and a keying mechanism, the need for which has been discussed above.
[RFC5440]によると、経路計算要素（PCE）の発見は、大規模ネットワークでのPCEPの展開を成功させるための重要な機能です。このメカニズムにより、パス計算クライアント（PCC）は、構成を必要とせずに、ネットワーク内の適切なPCEの存在を検出できます。 PCEが検出されて構成されていない場合、PCCが使用する正しいキーを認識できないことは明らかです。セキュリティのいくつかの側面を保持するためのさまざまなアプローチがありますが、それらのすべては、キーとキーイングメカニズムの使用を必要とします。
As stated in the KARP Design Guidelines [RFC6518], it is imperative that the new authentication, security mechanisms, and key management protocol support incremental deployment, as it is not feasible to deploy the new routing protocol authentication mechanism overnight.
KARP設計ガイドライン[RFC6518]で述べられているように、新しい認証、セキュリティメカニズム、およびキー管理プロトコルは、新しいルーティングプロトコル認証メカニズムを夜間に展開することができないため、増分展開をサポートすることが不可欠です。
Typically, authentication and security in a peer-to-peer protocol requires that both parties agree to the mechanisms that will be used. If an agreement is not reached, the setup of the new mechanism will fail or will be deferred. Upon failure, the routing protocols can fall back to the mechanisms that were already in place, e.g., use static keys if that was the mechanism in place. The fallback should be configurable on a per-node or per-interface basis. It is usually not possible for one end to use the new mechanism while the other end uses the old. Policies can be put in place to retry upgrading after a said period of time, so that manual coordination is not required.
通常、ピアツーピアプロトコルの認証とセキュリティでは、使用されるメカニズムに双方が同意する必要があります。合意に達しない場合、新しいメカニズムのセットアップは失敗するか、延期されます。障害が発生すると、ルーティングプロトコルは、すでに配置されていたメカニズムにフォールバックできます。たとえば、メカニズムが配置されていた場合は、静的キーを使用します。フォールバックは、ノードごとまたはインターフェイスごとに構成可能である必要があります。通常、一方の端で新しいメカニズムを使用し、もう一方の端で古いメカニズムを使用することはできません。一定期間後にアップグレードを再試行するポリシーを設定できるため、手動で調整する必要はありません。
If the automatic KMP requires use of Public Key Infrastructure Certificates [RFC5280] to exchange key material, the required Certificate Authority (CA) root certificates may need to be installed to verify the authenticity of requests initiated by a peer. Such a step does not require coordination with the peer, except to decide which CA authority will be used.
自動KMPが公開鍵インフラストラクチャ証明書[RFC5280]を使用して鍵素材を交換する必要がある場合、必要な認証局（CA）ルート証明書をインストールして、ピアによって開始された要求の信頼性を確認する必要があります。このような手順では、使用するCA権限を決定する場合を除いて、ピアとの調整は必要ありません。
This section describes security considerations that BGP, LDP, PCEP, and MSDP should try to meet.
このセクションでは、BGP、LDP、PCEP、およびMSDPが満たす必要のあるセキュリティの考慮事項について説明します。
As with all routing protocols, they need protection from both on-path and off-path blind attacks. A better way to protect them would be with per-packet protection using a cryptographic MAC. In order to provide for the MAC, keys are needed.
すべてのルーティングプロトコルと同様に、オンパスとオフパスの両方のブラインド攻撃からの保護が必要です。それらを保護するより良い方法は、暗号化MACを使用したパケットごとの保護です。 MACを提供するには、キーが必要です。
The routing protocols need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm.
ルーティングプロトコルは、アルゴリズムの俊敏性をサポートする必要があります。つまり、ルーティングプロトコルは、1つのアルゴリズムに組み込まれていてはなりません。
Once keys are used, mechanisms are required to support key rollover. They should cover both manual and automatic key rollover. Multiple approaches could be used. However, since the existing mechanisms provide a protocol field to identify the key as well as management mechanisms to introduce and retire new keys, focusing on the existing mechanism as a starting point is prudent.
キーが使用されると、キーのロールオーバーをサポートするメカニズムが必要になります。手動と自動の両方のキーロールオーバーをカバーする必要があります。複数のアプローチを使用できます。ただし、既存のメカニズムには、キーを識別するためのプロトコルフィールドと、新しいキーを導入および廃止するための管理メカニズムが用意されているため、既存のメカニズムを開始点として焦点を合わせることが賢明です。
Furthermore, it is strongly suggested that these routing protocols support algorithm agility. It has been proven that algorithms weaken over time. Supporting algorithm agility assists in smooth transitions from old to new algorithms.
さらに、これらのルーティングプロトコルがアルゴリズムの俊敏性をサポートすることを強くお勧めします。アルゴリズムは時間とともに弱くなることが証明されています。アルゴリズムの俊敏性をサポートすることで、古いアルゴリズムから新しいアルゴリズムへのスムーズな移行を支援します。
We would like to thank Brian Weis for encouraging us to write this document, and thanks to Anantha Ramaiah and Mach Chen for providing comments on it.
このドキュメントの作成を奨励してくれたBrian Weisに感謝します。また、コメントを提供してくれたAnantha RamaiahとMach Chenに感謝します。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926] Lebovitz、G.およびE. Rescorla、「TCP Authentication Option（TCP-AO）の暗号化アルゴリズム」、RFC 5926、2010年6月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518] Lebovitz、G。およびM. Bhatia、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」、RFC 6518、2012年2月。
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6863] Hartman、S。およびD. Zhang、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるOSPFセキュリティの分析」、RFC 6863、2013年3月。
[HELLO-CRYPTO] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, January 2013.
[HELLO-CRYPTO] Zheng、L.、Chen、M。、およびM. Bhatia、「LDP Hello Cryptographic Authentication」、Work in Progress、2013年1月。
[NIST-SP800-38B] Dworking, , "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005.
[NIST-SP 800-38B] Dworkin、「ブロック暗号モードの動作の推奨：認証のCMACモード」、2005年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
[RFC4595] Maino、F。およびD. Black、「ファイバーチャネルセキュリティアソシエーション管理プロトコルでのIKEv2の使用」、RFC 4595、2006年7月。
[RFC4674] Le Roux, J.L., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J.L。、「Requires for Path Computation Element（PCE）Discovery」、RFC 4674、2006年10月。
[RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E.、IAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日のIABワークショップからの不要なトラフィックに関するレポート」、RFC 4948、2007年8月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「なりすまし攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088] Le Roux、JL。、Vasseur、JP。、Ikejiri、Y.、and R. Zhang、 "OSPF Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5088、January 2008。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089] Le Roux、JL。、Vasseur、JP。、Ikejiri、Y.、and R. Zhang、 "IS-IS Protocol Extensions for Path Computation Element（PCE）Discovery"、RFC 5089、January 2008。
[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, May 2008.
[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、2008年5月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。とJL。 Le Roux、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]ラマイア、A。、スチュワート、R。、およびM.ダラル、「ウィンドウ内のブラインド攻撃に対するTCPの堅牢性の向上」、RFC 5961、2010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、2010年10月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
Authors' Addresses
著者のアドレス
Mahesh Jethanandani Ciena Corporation 1741 Technology Drive San Jose, CA 95110 USA
Mahesh Jethanandani Ina Corporation 1741 Technology Drive San Jose、CA 95110彼
Phone: +1 (408) 436-3313
EMail: mjethanandani@gmail.com
Keyur Patel Cisco Systems, Inc 170 Tasman Drive San Jose, CA 95134 USA
Keyur Patel Cisco Systems、Inc 170 Tasman Drive San Jose、CA 95134 USA
Phone: +1 (408) 526-7183
EMail: keyupate@cisco.com
Lianshu Zheng Huawei Technologies China
lイアン番号Zは非常にGH UAは技術中国
Phone: +86 (10) 82882008
EMail: vero.zheng@huawei.com