[要約] 要約：RFC 7645は、IS-ISルーティングプロトコルのキー交換と認証（KARP）のセキュリティ分析に関するものである。 目的：このRFCの目的は、IS-ISプロトコルのセキュリティに関する問題を特定し、改善策を提案することで、ネットワークの安全性を向上させることである。
Internet Engineering Task Force (IETF) U. Chunduri
Request for Comments: 7645 A. Tian
Category: Informational W. Lu
ISSN: 2070-1721 Ericsson Inc.
September 2015
The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis
ルーティングプロトコルのキーイングと認証（KARP）IS-ISセキュリティ分析
Abstract
概要
This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.
このドキュメントでは、手動および自動の両方のキー管理について、「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドライン」（RFC 6518）に記載されている要件に従って、中間システム間（IS-IS）プロトコルの現在の状態を分析します。プロトコル。
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/rfc7645.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7645で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Subnetwork Independent . . . . . . . . . . . . . . . 4
2.1.2. Subnetwork dependent . . . . . . . . . . . . . . . . 4
2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5
2.3.1.1. Current Recovery Mechanism for LSPs . . . . . . . 6
2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8
3. Gap Analysis and Security Requirements . . . . . . . . . . . 8
3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8
3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" [RFC6518] for both manual and automated key management protocols.
このドキュメントでは、「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドライン」[RFC6518]に記載されている要件に従って、手動および自動の両方のキー管理プロトコルについて、中間システム間（IS-IS）プロトコルの現在の状態を分析します。 。
With currently published work, IS-IS meets some of the requirements expected from a manually keyed routing protocol. Integrity protection is expanded by allowing more cryptographic algorithms to be used [RFC5310]. However, even with this expanded protection, only limited algorithm agility (HMAC-SHA family) is possible. [RFC5310] makes possible a basic form of intra-connection rekeying, but with some gaps as analyzed in Section 3 of this document.
IS-ISは、現在公開されている作業により、手動でキー設定されたルーティングプロトコルから期待されるいくつかの要件を満たしています。完全性保護は、より多くの暗号化アルゴリズムを使用できるようにすることで拡張されます[RFC5310]。ただし、この拡張保護を使用しても、限られたアルゴリズムのアジリティ（HMAC-SHAファミリ）のみが可能です。 [RFC5310]は、基本的な形式の接続内のキー更新を可能にしますが、このドキュメントのセクション3で分析されているように、いくつかのギャップがあります。
This document summarizes the current state of cryptographic key usage in the IS-IS protocol and several previous efforts that analyze IS-IS security. This includes the base IS-IS specifications: [RFC1195], [RFC5304], [RFC5310], and [RFC6039].
このドキュメントでは、IS-ISプロトコルでの暗号化キーの使用の現在の状態と、IS-ISセキュリティを分析する以前のいくつかの取り組みを要約しています。これには、IS-ISの基本仕様である[RFC1195]、[RFC5304]、[RFC5310]、および[RFC6039]が含まれます。
This document also analyzes various threats to IS-IS (as described in [RFC6862]), lists security gaps, and provides specific recommendations to thwart the threats for both manual keying and automated key management mechanisms.
このドキュメントでは、IS-ISに対するさまざまな脅威も分析し（[RFC6862]で説明）、セキュリティギャップをリストし、手動キーイングと自動キー管理メカニズムの両方の脅威を阻止するための具体的な推奨事項を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
DoS - Denial of Service
DoS-サービス拒否
GDOI - Group Domain of Interpretation
GDOI-解釈のグループドメイン
IGP - Interior Gateway Protocol
IGP-内部ゲートウェイプロトコル
IIH - IS-IS HELLO
IIH-IS-ISハロー
IPv4 - Internet Protocol version 4
IPv4-インターネットプロトコルバージョン4
KMP - Key Management Protocol (automated key management)
KMP-キー管理プロトコル（自動キー管理）
LSP - Link State PDU
LSP-リンク状態PDU
MKM - Manual Key Management
MKM-手動キー管理
NONCE - Number Once
NONCE-ナンバーワンス
PDU - Protocol Data Unit
PDU-プロトコルデータユニット
SA - Security Association
さ ー せくりｔｙ あっそしあちおん
SNP - Sequence Number PDU
SNP-シーケンス番号PDU
IS-IS is specified in International Standards Organization (ISO) 10589 [ISO10589], with extensions to support Internet Protocol version 4 (IPv4) described in [RFC1195]. The specification includes an authentication mechanism that allows for any authentication algorithm and also specifies the algorithm for clear text passwords. Further, [RFC5304] extends the authentication mechanism to work with HMAC-MD5 and also modifies the base protocol for more effectiveness. [RFC5310] provides algorithm agility, with a new generic cryptographic authentication mechanism (CRYPTO_AUTH) for IS-IS.
IS-ISは、国際標準化機構（ISO）10589 [ISO10589]で指定されており、[RFC1195]で説明されているインターネットプロトコルバージョン4（IPv4）をサポートする拡張機能が付いています。この仕様には、認証アルゴリズムを許可する認証メカニズムが含まれており、クリアテキストパスワードのアルゴリズムも指定されています。さらに、[RFC5304]は、認証メカニズムを拡張してHMAC-MD5で動作するようにし、より効果的になるように基本プロトコルを変更します。 [RFC5310]は、IS-IS用の新しい汎用暗号化認証メカニズム（CRYPTO_AUTH）により、アルゴリズムの俊敏性を提供します。
CRYPTO_AUTH also introduces a Key ID mechanism that maps to unique IS-IS SAs.
CRYPTO_AUTHでは、一意のIS-IS SAにマップするキーIDメカニズムも導入されています。
The following sections describe the current authentication key usage for various IS-IS messages, current key change methodologies, and the various potential security threats.
次のセクションでは、さまざまなIS-ISメッセージの現在の認証キーの使用法、現在のキー変更方法、およびさまざまな潜在的なセキュリティの脅威について説明します。
IS-IS can be provisioned with a per-interface, peer-to-peer key for IIH PDUs and a group key for LSPs and SNPs. If provisioned, IIH packets can potentially use the same group key used for LSPs and SNPs.
IS-ISは、IIH PDUのインターフェイスごとのピアツーピアキーと、LSPおよびSNPのグループキーでプロビジョニングできます。プロビジョニングされている場合、IIHパケットはLSPおよびSNPに使用されているものと同じグループキーを使用する可能性があります。
Link State PDUs, Complete and partial Sequence Number PDUs come under Sub network Independent messages. For protecting Level-1 SNPs and Level-1 LSPs, provisioned Area Authentication key is used. Level-2 SNPs as well as Level-2 LSPs use the provisioned domain authentication key.
リンク状態PDU、完全および部分的なシーケンス番号PDUは、サブネットワーク独立メッセージの下にあります。レベル1 SNPおよびレベル1 LSPを保護するために、プロビジョニングされたエリア認証キーが使用されます。レベル2 SNPとレベル2 LSPは、プロビジョニングされたドメイン認証キーを使用します。
Because authentication is performed on the LSPs transmitted by an IS, rather than on the LSP packets transmitted to a specific neighbor, it is implied that all the ISes within a single flooding domain must be configured with the same key in order for authentication to work correctly. This is also true for SNP packets, though they are limited to link-local scope in broadcast networks.
認証は特定のネイバーに送信されるLSPパケットではなく、ISによって送信されるLSPで実行されるため、認証が正しく機能するためには、単一のフラッディングドメイン内のすべてのISに同じキーを設定する必要があることを意味します。これはSNPパケットにも当てはまりますが、ブロードキャストネットワークではリンクローカルスコープに限定されます。
If multiple instances share the circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect the LSPs and SNPs within an area or domain. It is important to note that [RFC6822] also allows usage of topology-specific authentication credentials within an instance for the LSPs and SNPs.
[RFC6822]で指定されているように複数のインスタンスが回線を共有している場合、インスタンス固有の認証資格情報を使用して、エリアまたはドメイン内のLSPおよびSNPを保護できます。 [RFC6822]では、LSPおよびSNPのインスタンス内でトポロジ固有の認証資格情報も使用できることに注意することが重要です。
IIH PDUs use the Link Level Authentication key, which may be different from that of LSPs and SNPs. This could be particularly true for point-to-point links. In broadcast networks, it is possible to provision the same common key used for LSPs and SNPs to protect IIH messages. This allows neighbor discovery and adjacency formation with more than one neighbor on the same physical interface. If multiple instances share the circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect Hello messages.
IIH PDUはリンクレベル認証キーを使用します。これは、LSPおよびSNPのキーとは異なる場合があります。これは、ポイントツーポイントリンクに特に当てはまる可能性があります。ブロードキャストネットワークでは、IIHメッセージを保護するためにLSPおよびSNPに使用されるものと同じ共通キーをプロビジョニングすることが可能です。これにより、同じ物理インターフェイス上の複数のネイバーとのネイバーディスカバリと隣接関係の形成が可能になります。 [RFC6822]で指定されているように複数のインスタンスが回路を共有する場合、インスタンス固有の認証資格情報を使用してHelloメッセージを保護できます。
Key roll over without effecting the routing protocols operation in general and IS-IS in particular is necessary for effective key management protocol integration.
ルーティングプロトコルの動作全般、特にIS-ISに影響を与えないキーロールオーバーは、効果的なキー管理プロトコル統合に必要です。
Current HMAC-MD5 cryptographic authentication as defined in [RFC5304], suggests a transition mode so that ISes use a set of keys when verifying the authentication value to allow key changes. This approach will allow changing the authentication key manually without bringing down the adjacency and without dropping any control packet. But, this can increase the load on the control plane for the key transition duration, as each control packet may have to be verified by more than one key, and it also allows a potential DoS attack in the transition duration.
[RFC5304]で定義されている現在のHMAC-MD5暗号化認証は、ISesが認証値を検証するときにキーのセットを使用してキーの変更を許可するように移行モードを提案します。この方法では、隣接関係を停止したり、制御パケットをドロップしたりせずに、認証キーを手動で変更できます。ただし、各制御パケットを複数のキーで検証する必要がある場合があるため、これにより、キー遷移期間のコントロールプレーンの負荷が増加する可能性があります。また、遷移期間中にDoS攻撃が発生する可能性もあります。
The above situation is improved with the introduction of the Key ID mechanism as defined in [RFC5310]. With this, the receiver determines the active SA by looking at the Key ID field in the incoming PDU and need not try with other keys when the integrity check or digest verification fails. But, neither key coordination across the group nor an exact key change mechanism is clearly defined. [RFC5310] says:
上記の状況は、[RFC5310]で定義されているキーIDメカニズムの導入により改善されています。これにより、受信者は受信PDUのキーIDフィールドを確認してアクティブなSAを決定し、整合性チェックまたはダイジェスト検証が失敗したときに他のキーを試す必要がなくなります。ただし、グループ全体のキーの調整も、正確なキー変更メカニズムも明確に定義されていません。 [RFC5310]さんのコメント：
Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
通常、実装により、ネットワークオペレーターは、キーチェーン内のキーのセットを構成できます。チェーン内の各キーは、有効期間が固定されています。これらのメカニズムの実際の操作は、このドキュメントの範囲外です。
The following section analyzes various possible security threats in the current state of the IS-IS protocol.
次のセクションでは、IS-ISプロトコルの現状におけるさまざまなセキュリティ上の脅威を分析します。
Replaying a captured protocol packet to cause damage is a common threat for any protocol. Securing the packet with cryptographic authentication information alone cannot mitigate this threat completely. Though this problem is more prevalent in broadcast networks, it is important to note that most of the IGP deployments use P2P-over-lan circuits [RFC5309], which makes it possible for an adversary to replay an IS-IS PDU more easily than the traditional P2P networks.
キャプチャしたプロトコルパケットを再生して損傷を与えることは、どのプロトコルにとっても一般的な脅威です。暗号化認証情報だけでパケットを保護しても、この脅威を完全に緩和することはできません。この問題はブロードキャストネットワークでより一般的ですが、ほとんどのIGP配置はP2P-over-lan回線[RFC5309]を使用することに注意することが重要です。これにより、攻撃者はIS-IS PDUをより簡単に再生できます。従来のP2Pネットワーク。
In intra-session replay attacks, a secured protocol packet of the current session that is replayed can cause damage, if there is no other mechanism to confirm this is a replay packet. In inter-session replay attacks, a captured packet from one of the previous sessions can be replayed to cause damage. IS-IS packets are vulnerable to both of these attacks, as there is no sequence number verification for IIH and SNP packets. Also with current manual key management, periodic key changes across the group are rarely done. Thus, the intra-connection and inter-connection replay requirements are not met.
セッション内リプレイ攻撃では、リプレイパケットであることを確認する他のメカニズムがない場合、リプレイされる現在のセッションの保護されたプロトコルパケットが損傷を引き起こす可能性があります。セッション間リプレイアタックでは、前のセッションの1つからキャプチャされたパケットがリプレイされ、損傷を引き起こす可能性があります。 IIHおよびSNPパケットのシーケンス番号検証がないため、IS-ISパケットはこれらの攻撃の両方に対して脆弱です。また、現在の手動の鍵管理では、グループ全体で定期的な鍵の変更が行われることはほとんどありません。したがって、接続内および接続間再生の要件は満たされません。
IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 family in [RFC5310] to protect IS-IS packets. An adversary could replay old IIHs or replay old SNPs that would cause churn in the network or bring down the adjacencies.
IS-ISは、IS-ISパケットを保護するための[RFC5310]のHMAC-MD5 [RFC5304]およびHMAC-SHA-1ファミリの使用を指定しています。攻撃者は古いIIHを再生したり、ネットワークでチャーンを引き起こしたり、隣接関係を停止したりする古いSNPを再生する可能性があります。
1. At the time of adjacency bring up an IS sends IIH packet with empty neighbor list (TLV 6) and with the authentication information as per the provisioned authentication mechanism. If this packet is replayed later on the broadcast network, all ISes in the broadcast network can bounce the adjacency to create a huge churn in the network.
1. 隣接の立ち上げ時に、ISは空のネイバーリスト（TLV 6）とプロビジョニングされた認証メカニズムによる認証情報を含むIIHパケットを送信します。このパケットが後でブロードキャストネットワークで再生されると、ブロードキャストネットワーク内のすべてのISが隣接関係をバウンスして、ネットワーク内に巨大なチャーンを作成できます。
2. Today, LSPs have intra-session replay protection as the LSP header contains a 32-bit sequence number, which is verified for every received packet against the local LSP database. But, if a node in the network is out of service (is undergoing some sort of high availability condition or an upgrade) for more than LSP refresh time and the rest of the network ages out the LSPs of the node under consideration, an adversary can potentially plunge in inter-session replay attacks in the network. If the key is not changed in the above circumstances, attack can be launched by replaying an old LSP with a higher sequence number and fewer prefixes or fewer adjacencies. This may force the receiver to accept and remove the routes from the routing table, which eventually causes traffic disruption to those prefixes. However, as per the IS-IS specification, there is a built-in recovery mechanism for LSPs from inter-session replay attacks and it is further discussed in Section 2.3.1.1.
2. 現在、LSPヘッダーには32ビットのシーケンス番号が含まれているため、LSPはセッション内のリプレイ保護を備えています。これは、ローカルのLSPデータベースに対して受信したすべてのパケットに対して検証されます。ただし、ネットワーク内のノードがLSP更新時間を超えてサービスを停止している（何らかの高可用性状態またはアップグレードが行われている）場合、残りのネットワークが検討中のノードのLSPを期限切れにすると、攻撃者はネットワーク内のセッション間リプレイ攻撃に突入する可能性があります。上記の状況でキーが変更されていない場合、シーケンス番号が大きく、プレフィックスが少ないか、隣接関係が少ない古いLSPを再生することにより、攻撃を仕掛けることができます。これにより、受信者がルートを受け入れてルーティングテーブルから削除し、最終的にそれらのプレフィックスへのトラフィックの中断を引き起こす可能性があります。ただし、IS-IS仕様に従って、セッション間リプレイ攻撃からのLSPの組み込みの回復メカニズムがあり、セクション2.3.1.1でさらに説明されています。
3. In any IS-IS network (broadcast or otherwise), if an old and an empty Complete Sequence Number Packet (CSNP) is replayed, this can cause LSP flood in the network. Similarly, a replayed Partial Sequence Number Packet (PSNP) can cause LSP flood in the broadcast network.
3. IS-ISネットワーク（ブロードキャストまたはその他）では、古くて空の完全シーケンス番号パケット（CSNP）が再生されると、ネットワークでLSPフラッドが発生する可能性があります。同様に、再生された部分シーケンス番号パケット（PSNP）は、ブロードキャストネットワークでLSPフラッドを引き起こす可能性があります。
In the event of inter-session replay attack by an adversary, as an LSP with a higher sequence number gets accepted, it also gets propagated until it reaches the originating node of the LSP. The originator recognizes the LSP is "newer" than in the local database, which prompts the originator to flood a newer version of the LSP with a higher sequence number than that received. This newer version can potentially replace any versions of the replayed LSP that may exist in the network.
攻撃者によるセッション間リプレイ攻撃の場合、シーケンス番号の大きいLSPが受け入れられると、LSPの発信ノードに到達するまで伝播されます。発信者は、LSPがローカルデータベースよりも「新しい」ことを認識します。これにより、発信者は、受信したシーケンス番号よりも大きいシーケンス番号を持つ新しいバージョンのLSPをフラッディングするように求められます。この新しいバージョンは、ネットワークに存在する可能性のある再生されたLSPのバージョンを置き換える可能性があります。
However, in the above process, depending on where in the network the replay is initiated, how quickly the nodes in the network react to the replayed LSP, and how different the content in the accepted LSP is determines the damage caused by the replayed LSP.
ただし、上記のプロセスでは、ネットワーク内のどこで再生が開始されるか、ネットワーク内のノードが再生されたLSPに反応する速さ、および受け入れられたLSPのコンテンツがどの程度異なるかによって、再生されたLSPによって引き起こされる損傷が決まります。
IS-IS shares the same key between all neighbors in an area or in a domain to protect the LSP, SNP packets, and in broadcast networks even IIH packets. False advertisement by a router is not within the scope of the KARP work. However, given the wide sharing of keys as described above, there is a significant risk that an attacker can compromise a key from one device and use it to falsely participate in the routing, possibly even in a very separate part of the network.
IS-ISは、エリア内またはドメイン内のすべてのネイバー間で同じキーを共有して、LSP、SNPパケット、およびブロードキャストネットワークではIIHパケットを保護します。ルーターによる偽のアドバタイズは、KARP作業の範囲外です。ただし、上記のように鍵を広く共有しているため、攻撃者が1つのデバイスからの鍵を危険にさらし、それを使用してルーティングに誤って参加したり、場合によってはネットワークの非常に別の部分に侵入したりする可能性があります。
If the same underlying topology is shared across multiple instances to transport routing/application information as defined in [RFC6822], it is necessary to use different authentication credentials for different instances. In this connection, based on the deployment considerations, if certain topologies in a particular IS-IS instance require more protection from spoofing attacks and less exposure, topology-specific authentication credentials can be used for LSPs and SNPs as facilitated in [RFC6822].
[RFC6822]で定義されているようにルーティング/アプリケーション情報を転送するために同じ基本トポロジが複数のインスタンス間で共有されている場合、インスタンスごとに異なる認証資格情報を使用する必要があります。これに関連して、展開に関する考慮事項に基づいて、特定のIS-ISインスタンスの特定のトポロジでスプーフィング攻撃からの保護を強化し、露出を少なくする必要がある場合、トポロジ固有の認証資格情報をLSPおよびSNPに使用できます[RFC6822]。
Currently, possession of the key itself is used as an authentication check and there is no identity check done separately. Spoofing occurs when an illegitimate device assumes the identity of a legitimate one. An attacker can use spoofing to launch various types of attacks, for example:
現在、キーの所有自体が認証チェックとして使用されており、個別に行われるIDチェックはありません。なりすましは、不正なデバイスが正当なデバイスのIDを装うときに発生します。攻撃者はスプーフィングを使用して、次のようなさまざまなタイプの攻撃を開始できます。
1. The attacker can send out unrealistic routing information that might cause the disruption of network services, such as block holes.
1. 攻撃者は、ブロックホールなどのネットワークサービスの中断を引き起こす可能性のある非現実的なルーティング情報を送信できます。
2. A rogue system that has access to the common key used to protect the LSP can flood an LSP by setting the Remaining Lifetime field to zero, thereby initiating a purge. Subsequently, this can cause the sequence number of all the LSPs to increase quickly to max out the sequence number space, which can cause an IS to shut down for MaxAge + ZeroAgeLifetime period to allow the old LSPs to age out in other ISes of the same flooding domain.
2. LSPを保護するために使用される共通キーにアクセスできる不正なシステムは、Remaining Lifetimeフィールドをゼロに設定してLSPをフラッディングし、それによってパージを開始できます。その後、これにより、すべてのLSPのシーケンス番号が急速に増加してシーケンス番号スペースが最大になるため、ISがMaxAge + ZeroAgeLifetime期間シャットダウンし、古いLSPが同じ他のISで期限切れになる可能性があります。フラッディングドメイン。
DoS attacks using the authentication mechanism is possible and an attacker can send packets that can overwhelm the security mechanism itself. An example is initiating an overwhelming load of spoofed but integrity-protected protocol packets, so that the receiver needs to process the integrity check, only to discard the packet. This can cause significant CPU usage. DoS attacks are not generally preventable within the routing protocol. As the attackers are often remote, the DoS attacks are more damaging to area-scoped or domain-scoped packet receivers than link-local-scoped packet receivers.
認証メカニズムを使用したDoS攻撃が可能であり、攻撃者はセキュリティメカニズム自体を圧倒するパケットを送信できます。例としては、スプーフィングされているが整合性は保護されているプロトコルパケットの圧倒的な負荷を開始しているため、受信者は整合性チェックを処理し、パケットを破棄するだけで済みます。これにより、CPU使用率が大幅に増加する可能性があります。 DoS攻撃は通常、ルーティングプロトコル内では防止できません。攻撃者はしばしばリモートであるため、DoS攻撃は、リンクローカルスコープのパケットレシーバーよりも、エリアスコープまたはドメインスコープのパケットレシーバーに大きな損害を与えます。
This section outlines the differences between the current state of the IS-IS routing protocol and the desired state as specified in the KARP Design Guidelines [RFC6518]. This section focuses on where the IS-IS protocol fails to meet general requirements as specified in the threats and requirements document [RFC6862].
このセクションでは、IS-ISルーティングプロトコルの現在の状態と、KARP設計ガイドライン[RFC6518]で指定されている望ましい状態の違いについて概説します。このセクションでは、脅威と要件のドキュメント[RFC6862]で指定されている一般的な要件をIS-ISプロトコルが満たしていない場合に焦点を当てています。
This section also describes security requirements that should be met by IS-IS implementations that are secured by manual as well as automated key management protocols.
このセクションでは、手動および自動のキー管理プロトコルによって保護されるIS-IS実装が満たすべきセキュリティ要件についても説明します。
1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be protected with the HMAC-SHA family of cryptographic algorithms. The specification provides limited algorithm agility (SHA family). By using Key IDs, it also conceals the algorithm information from the protected control messages.
1. CRYPTO_AUTH仕様[RFC5310]を使用すると、IS-ISパケットを暗号化アルゴリズムのHMAC-SHAファミリで保護できます。この仕様では、アルゴリズムの俊敏性が制限されています（SHAファミリー）。また、キーIDを使用することで、保護された制御メッセージからアルゴリズム情報を隠します。
2. Even though both intra- and inter-session replay attacks are best prevented by deploying key management protocols with frequent key change capability, basic constructs for the sequence number should be in the protocol messages. So, some basic or extended sequence number mechanism should be in place to protect IIH packets and SNP packets. The sequence number should be increased for each protocol packet. This allows mitigation of some of the replay threats as mentioned in Section 2.3.1.
2. 頻繁なキー変更機能を備えたキー管理プロトコルを導入することで、セッション内およびセッション間のリプレイ攻撃の両方を防ぐのが最善ですが、シーケンス番号の基本的な構成はプロトコルメッセージに含める必要があります。したがって、IIHパケットとSNPパケットを保護するために、いくつかの基本または拡張シーケンス番号メカニズムを導入する必要があります。シーケンス番号は、プロトコルパケットごとに増やす必要があります。これにより、2.3.1項で説明したように、一部のリプレイ脅威を軽減できます。
3. Any common key mechanism with keys shared across a group of routers is susceptible to spoofing attacks caused by a malicious router. A separate authentication check (apart from the integrity check to verify the digest) with digital signatures as described in [RFC2154] can effectively nullify this attack. But this approach was never deployed, which we assume is due to operational considerations at that time. The alternative approach to thwart this threat would be to use the keys from the group key management protocol. As the group key(s) are generated by authenticating the member ISes in the group first and are then periodically rekeyed, per-packet identity or authentication checks may not be needed.
3.ルーターのグループ間でキーを共有する一般的なキーメカニズムは、悪意のあるルーターによって引き起こされるスプーフィング攻撃を受けやすいです。 [RFC2154]で説明されているように、デジタル署名を使用した個別の認証チェック（ダイジェストを検証するための整合性チェックを除く）は、この攻撃を効果的に無効にすることができます。しかし、このアプローチは展開されたことはありません。これは、当時の運用上の考慮事項によるものと思われます。この脅威を阻止する別のアプローチは、グループキー管理プロトコルのキーを使用することです。最初にグループのメンバーISesを認証することによってグループキーが生成され、次に定期的にキーが再生成されるため、パケットごとのIDまたは認証チェックは必要ない場合があります。
4. In general, DoS attacks may not be preventable with the mechanism from the routing protocol itself. But some form of admin-controlled lists at the forwarding plane can reduce the damage. There are some other forms of DoS attacks common to any protocol that are not in scope per Section 3.3 of [RFC6862].
4. 一般に、DoS攻撃はルーティングプロトコル自体のメカニズムでは防止できない場合があります。ただし、フォワーディングプレーンに管理者が管理するリストの形式を使用すると、被害を軽減できます。 [RFC6862]のセクション3.3に記載されていない、プロトコルに共通する他の形式のDoS攻撃がいくつかあります。
As discussed in Section 2.2, though the Key ID mechanism described in [RFC5310] helps, a better key coordination mechanism for key roll over is desirable even with manual key management. But, [RFC5310] does not specify the exact mechanism other than requiring use of key chains. The specific requirements are as follows:
セクション2.2で説明したように、[RFC5310]で説明されているキーIDメカニズムは役立ちますが、手動のキー管理でも、キーロールオーバーのより良いキー調整メカニズムが望ましいです。しかし、[RFC5310]は、キーチェーンの使用を要求する以外の正確なメカニズムを指定していません。具体的な要件は次のとおりです。
a. Keys SHOULD be able to change without effecting the established adjacency, ideally without any control packet loss.
a. キーは、確立された隣接に影響を与えずに、理想的には制御パケットの損失なしに変更できる必要があります（SHOULD）。
b. Keys SHOULD be able to change without effecting the protocol operations; for example, LSP flooding should not be held for a specific Key ID availability.
b. キーは、プロトコル操作に影響を与えずに変更できる必要があります（SHOULD）。たとえば、LSPフラッディングは、特定のキーIDが利用可能になるまで保持されるべきではありません。
c. Any proposed mechanism SHOULD also be incrementally deployable with key management protocols.
c. 提案されているメカニズムは、キー管理プロトコルを使用して段階的に展開できる必要があります（SHOULD）。
In broadcast deployments, the keys used for protecting IS-IS protocols messages can, in particular, be group keys. A mechanism is needed to distribute group keys to a group of ISes in a Level-1 area or Level-2 domain, using the Group Domain of Interpretation (GDOI) protocol as specified in [RFC6407]. An example policy and payload format is described in [GDOI].
ブロードキャスト展開では、IS-ISプロトコルメッセージの保護に使用されるキーは、特にグループキーにすることができます。 [RFC6407]で指定されているGroup Domain of Interpretation（GDOI）プロトコルを使用して、レベル1エリアまたはレベル2ドメインのISesのグループにグループキーを配布するメカニズムが必要です。ポリシーとペイロードの形式の例は、[GDOI]で説明されています。
If a group key is used, the authentication granularity becomes group membership of devices, not peer authentication between devices. The deployed group key management protocol SHOULD support rekeying.
グループキーが使用される場合、認証の細分性は、デバイス間のピア認証ではなく、デバイスのグループメンバーシップになります。デプロイされたグループキー管理プロトコルは、キー更新をサポートする必要があります（SHOULD）。
In some deployments, where IS-IS point-to-point (P2P) mode is used for adjacency bring-up, subnetwork-dependent messages (e.g., IIHs) can use a different key shared between the two P2P peers, while all other messages use a group key. When a group keying mechanism is deployed, even the P2P IIHs can be protected with the common group keys. This approach facilitates one key management mechanism instead of both pair-wise keying and group keying protocols being deployed together. If the same circuits are shared across multiple instances, the granularity of the group can become per instance for IIHs and per instance/topology for LSPs and SNPs as specified in [RFC6822].
IS-ISポイントツーポイント（P2P）モードが隣接関係の立ち上げに使用される一部の展開では、サブネットワーク依存メッセージ（IIHなど）は、2つのP2Pピア間で共有される異なるキーを使用できますが、他のすべてのメッセージグループキーを使用します。グループキーイングメカニズムが展開されている場合、P2P IIHも共通のグループキーで保護できます。このアプローチは、ペアワイズキーイングとグループキーイングの両方のプロトコルを一緒に展開する代わりに、1つのキー管理メカニズムを促進します。 [RFC6822]で指定されているように、同じ回線が複数のインスタンスで共有されている場合、グループの粒度は、IIHのインスタンスごと、LSPおよびSNPのインスタンス/トポロジごとになる可能性があります。
Effective key change capability within the routing protocol that allows key roll over without impacting the routing protocol operation is one of the requirements for deploying any group key mechanism. Once such mechanism is in place with the deployment of group key management protocol; IS-IS can be protected from various threats and is not limited to intra- and inter-session replay attacks and spoofing attacks.
ルーティングプロトコルの動作に影響を与えずにキーのロールオーバーを可能にするルーティングプロトコル内の効果的なキー変更機能は、グループキーメカニズムを展開するための要件の1つです。グループキー管理プロトコルの導入により、このようなメカニズムが導入されたら、 IS-ISはさまざまな脅威から保護でき、セッション内およびセッション間のリプレイ攻撃やスプーフィング攻撃に限定されません。
Specific use of cryptographic tables [RFC7210] should be defined for the IS-IS protocol.
IS-ISプロトコルでは、暗号化テーブル[RFC7210]の特定の使用を定義する必要があります。
This document is mostly about security considerations of the IS-IS protocol, and it lists potential threats and security requirements for mitigating these threats. This document does not introduce any new security threats for the IS-IS protocol. In view of openly published attack vectors, as noted in Section 1 of [RFC5310] on HMAC-MD5 cryptographic authentication mechanism, IS-IS deployments SHOULD use the HMAC-SHA family [RFC5310] instead of HMAC-MD5 [RFC5304] to protect IS-IS PDUs. For more detailed security considerations, please refer the Security Considerations section of the IS-IS Generic Cryptographic Authentication [RFC5310], the KARP Design Guide [RFC6518] document, as well as the KARP threat document [RFC6862].
このドキュメントは、主にIS-ISプロトコルのセキュリティに関する考慮事項に関するものであり、潜在的な脅威とこれらの脅威を軽減するためのセキュリティ要件を示しています。このドキュメントでは、IS-ISプロトコルの新しいセキュリティの脅威は紹介していません。 HMAC-MD5暗号化認証メカニズムに関する[RFC5310]のセクション1に記載されているように、公開されている攻撃ベクトルを考慮して、IS-IS展開では、HMAC-MD5 [RFC5304]ではなくHMAC-SHAファミリ[RFC5310]を使用してISを保護する必要があります-IS PDU。セキュリティに関する考慮事項の詳細については、IS-IS Generic Cryptographic Authentication [RFC5310]、KARP設計ガイド[RFC6518]、およびKARP脅威ドキュメント[RFC6862]のセキュリティに関する考慮事項のセクションを参照してください。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<http://www.rfc-editor.org/ info / rfc1195>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://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, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[GDOI] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, draft-weis-gdoi-mac-tek-03, September 2011.
[GDOI] Weis、B。およびS. Rowles、「GDOI Generic Message Authentication Code Policy」、Work in Progress、draft-weis-gdoi-mac-tek-03、2011年9月。
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「中間システムから中間システムへのドメイン間ルーティング情報交換プロトコル、コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と共に使用」、ISO / IEC 10589：2002、第2版、2002年11月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June 1997, <http://www.rfc-editor.org/info/rfc2154>.
[RFC2154]マーフィー、S。、バジャー、M。、およびB.ウェリントン、「OSPF with Digital Signatures」、RFC 2154、DOI 10.17487 / RFC2154、1997年6月、<http://www.rfc-editor.org/info / rfc2154>。
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.
[RFC5309] Shen、N。、編、およびA. Zinin、編、「リンクステートルーティングプロトコルにおけるLAN経由のポイントツーポイント操作」、RFC 5309、DOI 10.17487 / RFC5309、2008年10月、<http：/ /www.rfc-editor.org/info/rfc5309>。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, <http://www.rfc-editor.org/info/rfc6039>.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、DOI 10.17487 / RFC6039、2010年10月、<http：/ /www.rfc-editor.org/info/rfc6039>。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <http://www.rfc-editor.org/info/rfc6407>.
[RFC6407] Weis、B.、Rowles、S。、およびT. Hardjono、「The Group Domain of Interpretation」、RFC 6407、DOI 10.17487 / RFC6407、2011年10月、<http://www.rfc-editor.org/ info / rfc6407>。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, DOI 10.17487/RFC6518, February 2012, <http://www.rfc-editor.org/info/rfc6518>.
[RFC6518] Lebovitz、G.およびM. Bhatia、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」、RFC 6518、DOI 10.17487 / RFC6518、February 2012、<http://www.rfc-editor.org/ info / rfc6518>。
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>.
[RFC6822] Previdi、S.、Ed。、Ginsberg、L.、Shand、M.、Roy、A。、およびD. Ward、「IS-IS Multi-Instance」、RFC 6822、DOI 10.17487 / RFC6822、2012年12月、<http://www.rfc-editor.org/info/rfc6822>。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, DOI 10.17487/RFC6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.
[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル（KARP）のキーイングと認証の概要、脅威、および要件」、RFC 6862、DOI 10.17487 / RFC6862、2013年3月、<http： //www.rfc-editor.org/info/rfc6862>。
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, DOI 10.17487/RFC7210, April 2014, <http://www.rfc-editor.org/info/rfc7210>.
[RFC7210] Housley、R.、Polk、T.、Hartman、S.、D。Zhang、「Database of Long-Lived Symmetric Cryptographic Keys」、RFC 7210、DOI 10.17487 / RFC7210、2014年4月、<http：// www.rfc-editor.org/info/rfc7210>。
Acknowledgements
謝辞
Authors would like to thank Joel Halpern for initial discussions on this document and for giving valuable review comments. The authors would like to acknowledge Naiming Shen for reviewing and providing feedback on this document. Thanks to Russ White, Brian Carpenter, and Amanda Barber for reviewing the document during the IESG review process.
著者は、この文書に関する最初の議論と貴重なレビューコメントを提供してくれたJoel Halpernに感謝します。著者は、このドキュメントのレビューとフィードバックを提供してくれたNaiming Shenに感謝します。 IESGレビュープロセス中にドキュメントをレビューしてくれたRuss White、Brian Carpenter、およびAmanda Barberに感謝します。
Authors' Addresses
著者のアドレス
Uma Chunduri Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Phone: 408 750-5678 Email: uma.chunduri@ericsson.com
Uma Chunduri Ericsson Inc. 300 Holger Way、San Jose、California 95134 United States電話：408750-5678メール：uma.chunduri@ericsson.com
Albert Tian Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Phone: 408 750-5210 Email: albert.tian@ericsson.com
Albert Tian Ericsson Inc. 300 Holger Way、San Jose、California 95134 United States電話：408 750-5210メール：albert.tian@ericsson.com
Wenhu Lu Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Email: wenhu.lu@ericsson.com
Wenhu Lu Ericsson Inc. 300 Holger Way、San Jose、California 95134 United States Email：wenhu.lu@ericsson.com