[要約] 要約：RFC 6863は、OSPFセキュリティの分析を提供し、KARPデザインガイドに基づいています。 目的：OSPFのセキュリティに関する問題を特定し、KARPデザインガイドに従って解決策を提案することです。
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 6863 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
March 2013
Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
ルーティングプロトコルのキーイングと認証（KARP）設計ガイドに従ったOSPFセキュリティの分析
Abstract
概要
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
このドキュメントでは、「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドライン」（RFC 6518）のセクション4.2に記載されているガイドラインに従って、OSPFv2とOSPFv3を分析しています。このドキュメントで特定されたギャップの解決策の主要なコンポーネントはすでに進行中です。
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/rfc6863.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6863で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 6
4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 7
5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
This document analyzes the current state of OSPFv2 and OSPFv3 according to the requirements of [RFC6518]. It builds on several previous analysis efforts regarding routing security. The OPSEC working group put together an analysis of cryptographic issues with routing protocols [RFC6039]. Earlier, the RPSEC working group put together a detailed analysis of OSPF vulnerabilities [OSPF-SEC]. Work on solutions to address gaps identified in this analysis is underway [OSPF-MANKEY] [RFC6506].
このドキュメントは、[RFC6518]の要件に従って、OSPFv2およびOSPFv3の現在の状態を分析します。これは、ルーティングセキュリティに関する以前のいくつかの分析作業に基づいています。 OPSECワーキンググループは、ルーティングプロトコルを使用した暗号化の問題の分析をまとめました[RFC6039]。以前、RPSECワーキンググループは、OSPF脆弱性の詳細な分析をまとめました[OSPF-SEC]。この分析で特定されたギャップに対処するためのソリューションに取り組んでいます[OSPF-MANKEY] [RFC6506]。
OSPF meets many of the requirements expected from a manually keyed routing protocol. Integrity protection is provided with modern cryptographic algorithms. Algorithm agility is provided: the algorithm can be changed as part of rekeying an interface or peer. Intra-connection rekeying is provided by the specifications, although apparently some implementations have trouble with this in practice. OSPFv2 security does not interfere with prioritization of packets.
OSPFは、手動でキー設定されたルーティングプロトコルから期待される多くの要件を満たしています。完全性保護は、最新の暗号化アルゴリズムで提供されます。アルゴリズムの俊敏性が提供されます。インターフェイスまたはピアのキー再生成の一部としてアルゴリズムを変更できます。一部の実装ではこれが実際に問題があるようですが、接続内のキー更新は仕様で提供されています。 OSPFv2セキュリティは、パケットの優先順位付けを妨げません。
However, some gaps remain between the current state and the requirements for manually keyed routing security expressed in [RFC6862]. This document explores these gaps and proposes directions for addressing the gaps.
ただし、現在の状態と、[RFC6862]で表現されている手動でキーを設定したルーティングセキュリティの要件の間には、いくつかのギャップが残っています。このドキュメントでは、これらのギャップを調査し、ギャップに対処するための指示を提案します。
There are a number of requirements described in Section 3 of [RFC6862] that OSPF does not currently meet. The gaps are as follows:
[RFC6862]のセクション3で説明されているように、OSPFが現在満たしていない要件は多数あります。ギャップは次のとおりです。
o Secure Simple Pre-Shared Keys (PSKs): Today, OSPF directly uses the key as specified. Related key attacks, such as those described in Section 4.1 of [OPS-MODEL], are possible.
o Secure Simple Pre-Shared Keys（PSK）：今日、OSPFは指定されたキーを直接使用します。 [OPS-MODEL]のセクション4.1で説明されているような関連するキー攻撃が可能です。
o Replay Protection: The requirements document addresses requirements for both inter-connection replay protection and intra-connection replay protection. OSPFv3 has no replay protection at all. OSPFv2 has most of the mechanisms necessary for intra-connection replay protection. Unfortunately, OSPFv2 does not securely identify the neighbor with whom replay protection state is associated in all cases. This weakness can be used to create significant denial-of-service issues using intra-connection replays. OSPFv2 has no inter-connection replay protection; this creates significant denial-of-service opportunities.
o リプレイ保護：要件ドキュメントは、接続間リプレイ保護と接続内リプレイ保護の両方の要件に対応しています。 OSPFv3には、リプレイ保護がまったくありません。 OSPFv2には、接続内のリプレイ保護に必要なほとんどのメカニズムがあります。残念ながら、OSPFv2は、すべての場合にリプレイ保護状態が関連付けられているネイバーを安全に識別しません。この弱点は、接続内リプレイを使用して重大なサービス拒否の問題を作成するために使用できます。 OSPFv2には、接続間再生保護機能がありません。これにより、サービス拒否の大きな機会が生まれます。
o Packet Prioritization: OSPFv3 uses IPsec [RFC4301] to process packets. This complicates implementations that wish to process some packets, such as Hellos and Acknowledgements, above others. In addition, if IPsec replay mechanisms were used, packets would need to be processed at least by IPsec even if they were low priority.
o パケットの優先順位付け：OSPFv3はIPsec [RFC4301]を使用してパケットを処理します。これにより、HelloやAcknowledgementsなどの一部のパケットを他のパケットよりも処理したい実装が複雑になります。さらに、IPsecリプレイメカニズムが使用されている場合、たとえ優先度が低くても、パケットは少なくともIPsecで処理される必要があります。
o Neighbor Identification: In some cases, OSPF identifies a neighbor based on the IP address. This operation is never protected with OSPFv2 and is not typically protected with OSPFv3.
o ネイバー識別：場合によっては、OSPFはIPアドレスに基づいてネイバーを識別します。この操作はOSPFv2では保護されず、通常、OSPFv3では保護されません。
The remainder of this document explains how OSPF fails to meet these requirements, and it proposes mechanisms for addressing them.
このドキュメントの残りの部分では、OSPFがこれらの要件をどのように満たすことができないかを説明し、それらに対処するメカニズムを提案します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section describes the security mechanisms built into OSPFv2 and OSPFv3. There are two goals to this section. First, this section gives a brief explanation of the OSPF security mechanisms to those familiar with connectionless integrity mechanisms but not with OSPF.
このセクションでは、OSPFv2およびOSPFv3に組み込まれたセキュリティメカニズムについて説明します。このセクションには2つの目標があります。最初に、このセクションでは、OSPFのセキュリティメカニズムについて、コネクションレスの整合性メカニズムに精通しているがOSPFには精通していない人に簡単に説明します。
Second, this section provides the background necessary to understand how OSPF fails to meet some of the requirements proposed for routing security.
第2に、このセクションでは、OSPFがルーティングセキュリティに提案されている要件の一部をどのように満たすことができないかを理解するために必要な背景を提供します。
Appendix D of [RFC2328] describes the basic procedure for cryptographic authentication in OSPFv2. An authentication data field in the OSPF packet header contains a key ID, the length of the authentication data, and a sequence number. A Message Authentication Code (MAC) is appended to the OSPF packet. This code protects all fields of the packet including the sequence number but not the IP header.
[RFC2328]の付録Dでは、OSPFv2での暗号化認証の基本的な手順について説明しています。 OSPFパケットヘッダーの認証データフィールドには、キーID、認証データの長さ、およびシーケンス番号が含まれています。メッセージ認証コード（MAC）がOSPFパケットに追加されます。このコードは、シーケンス番号を含むパケットのすべてのフィールドを保護しますが、IPヘッダーは保護しません。
RFC 2328 defines the use of a keyed-MD5 MAC. While MD5 has not been broken as a MAC, it is not the algorithm of choice for new MACs.
RFC 2328は、キー付きMD5 MACの使用を定義しています。 MD5はMACとしては機能していませんが、新しいMACに適したアルゴリズムではありません。
However, RFC 5709 [RFC5709] adds support for the SHA family of hashes [FIPS180] to OSPFv2. The cryptographic authentication described in RFC 5709 meets modern standards for per-packet integrity protection. Thus, OSPFv2 meets the requirement for strong algorithms. Since multiple algorithms are defined and a new algorithm can be selected with each key, OSPFv2 meets the requirement for algorithm agility. In order to provide cryptographic algorithms believed to have a relatively long useful life, RFC 5709 mandates support for SHA-2 rather than SHA-1.
ただし、RFC 5709 [RFC5709]では、SSHファミリーのハッシュ[FIPS180]のサポートがOSPFv2に追加されています。 RFC 5709で説明されている暗号化認証は、パケット単位の整合性保護に関する最新の標準を満たしています。したがって、OSPFv2は強力なアルゴリズムの要件を満たしています。複数のアルゴリズムが定義され、各キーで新しいアルゴリズムを選択できるため、OSPFv2はアルゴリズムの俊敏性の要件を満たします。比較的長い耐用年数があると考えられている暗号アルゴリズムを提供するために、RFC 5709はSHA-1ではなくSHA-2のサポートを義務付けています。
These security services provide integrity protection on each packet. In addition, limited replay detection is provided. The sequence number is non-decreasing. So, once a router has increased its sequence number, an attacker cannot replay an old packet. Unfortunately, sequence numbers are not required to increase for each packet. For instance, because existing OSPF security solutions do not specify how to set the sequence number, it is possible that some implementations use, for example, "seconds since reboot" as their sequence numbers. The sequence numbers are thus increased only every second, permitting an opportunity for intra-connection replay. Also, no mechanism is provided to deal with the loss of anti-replay state; if sequence numbers are reused when a router reboots, then inter-connection replays are straight forward. In [OSPF-MANKEY], the OSPFv2 sequence number is expanded to 64 bits, with the least significant 32-bit value containing a strictly increasing sequence number and the most significant 32-bit value containing the boot count. The boot count is retained in non-volatile storage for the deployment life of an OSPF router. Therefore, the sequence number will never decrease, even after a cold reboot.
これらのセキュリティサービスは、各パケットの整合性保護を提供します。さらに、限定されたリプレイ検出が提供されます。シーケンス番号は減少しません。したがって、ルーターのシーケンス番号が増加すると、攻撃者は古いパケットを再生できなくなります。残念ながら、シーケンス番号はパケットごとに増やす必要はありません。たとえば、既存のOSPFセキュリティソリューションではシーケンス番号の設定方法が指定されていないため、実装によっては、たとえば「再起動からの秒数」をシーケンス番号として使用する可能性があります。したがって、シーケンス番号は1秒ごとにのみ増加し、接続内の再生の機会が与えられます。また、リプレイ防止状態の喪失に対処するメカニズムは提供されていません。ルーターの再起動時にシーケンス番号が再利用される場合、接続間の再生は簡単です。 [OSPF-MANKEY]では、OSPFv2シーケンス番号は64ビットに拡張され、最下位の32ビット値には厳密に増加するシーケンス番号が含まれ、最上位の32ビット値にはブートカウントが含まれます。ブートカウントは、OSPFルーターの展開期間中、不揮発性ストレージに保持されます。したがって、コールドリブート後でも、シーケンス番号が減少することはありません。
Also, because the IP header is not protected, the sequence number may not be associated with the correct neighbor, a situation that opens up opportunities for outsiders to perform replay attacks. See Section 3 for analysis of these attacks. In [OSPF-MANKEY], this issue is addressed by changing the definition of Apad from a constant defined in [RFC5709] to the source address in the IP header of the OSPFv2 protocol packet. In this way, the source address from the IP header is incorporated in the cryptographic authentication computation, and any change of the IP source address will be detected.
また、IPヘッダーが保護されていないため、シーケンス番号が正しいネイバーに関連付けられていない可能性があり、この状況では、部外者がリプレイアタックを実行する機会が開かれます。これらの攻撃の分析については、セクション3を参照してください。 [OSPF-MANKEY]では、Apadの定義を[RFC5709]で定義された定数からOSPFv2プロトコルパケットのIPヘッダーの送信元アドレスに変更することで、この問題に対処しています。このようにして、IPヘッダーからの送信元アドレスが暗号化認証計算に組み込まれ、IP送信元アドレスの変更が検出されます。
The mechanism provides good support for key rollover. There is a key ID. In addition, mechanisms are described for managing key lifetimes and starting the use of a new key in an orderly manner. Performing orderly key rollover requires that implementations support accepting a new key for received packets before using that key to generate packets. Section D.3 of RFC 2328 requires this support in the form of four configurable lifetimes for each key: two lifetimes control the beginning and ending period for acceptance, while two other lifetimes control the beginning and ending period for generation. These lifetimes provide a superset of the functionality in the key table [CRYPTO-KEYS] regarding lifetime.
このメカニズムは、キーのロールオーバーを適切にサポートします。キーIDがあります。さらに、キーの有効期間を管理し、新しいキーの使用を整然と開始するためのメカニズムについても説明します。秩序だったキーロールオーバーを実行するには、実装がそのキーを使用してパケットを生成する前に、受信したパケットの新しいキーの受け入れをサポートする必要があります。 RFC 2328のセクションD.3では、キーごとに4つの構成可能なライフタイムの形式でこのサポートが必要です。2つのライフタイムは受け入れの開始期間と終了期間を制御し、他の2つのライフタイムは生成の開始期間と終了期間を制御します。これらのライフタイムは、ライフタイムに関するキーテーブル[CRYPTO-KEYS]の機能のスーパーセットを提供します。
The OSPFv2 replay mechanism does not handle prioritized transmission of OSPF Hello and Link State Acknowledgement (LSA) packets as recommended in [RFC4222]. When OSPF packets are transmitted with varied prioritization, they can arrive out of order, which results in packets with lower prioritization being discarded.
[RFC4222]で推奨されているように、OSPFv2リプレイメカニズムは、OSPF Helloおよびリンク状態確認（LSA）パケットの優先送信を処理しません。 OSPFパケットがさまざまな優先順位で送信されると、順序が狂って到着する可能性があり、その結果、優先順位の低いパケットが破棄されます。
"Authentication/Confidentiality for OSPFv3" [RFC4552] describes how the IPsec authentication header and encapsulating security payload mechanism can be used to protect OSPFv3 packets. This mechanism provides per-packet integrity and optional confidentiality using a wide variety of cryptographic algorithms. Because OSPF uses multicast traffic, only manual key management is supported. This mechanism meets requirements related to algorithm selection and agility.
「OSPFv3の認証/機密保持」[RFC4552]では、IPsec認証ヘッダーとカプセル化セキュリティペイロードメカニズムを使用してOSPFv3パケットを保護する方法について説明しています。このメカニズムは、さまざまな暗号化アルゴリズムを使用して、パケットごとの整合性とオプションの機密性を提供します。 OSPFはマルチキャストトラフィックを使用するため、サポートされるのは手動のキー管理のみです。このメカニズムは、アルゴリズムの選択と俊敏性に関連する要件を満たします。
The Security Parameter Index (SPI) [RFC4301] provides an identifier for the security association. This identifier, along with other IPsec facilities, provides a mechanism for moving from one key to another, meeting the key rollover requirements.
セキュリティパラメータインデックス（SPI）[RFC4301]は、セキュリティアソシエーションの識別子を提供します。この識別子は、他のIPsec機能とともに、あるキーから別のキーに移動するメカニズムを提供し、キーのロールオーバー要件を満たします。
Because manual keying is used, no replay protection is provided for OSPFv3. Thus, the intra-connection and inter-connection replay requirements are not met.
手動キーイングが使用されるため、OSPFv3にはリプレイ保護は提供されません。したがって、接続内および接続間再生の要件は満たされません。
There is another serious problem with the OSPFv3 security: rather than being integrated into OSPF, it is based on IPsec. In practice, this has lead to deployment problems.
OSPFv3セキュリティには別の深刻な問題があります。OSPFに統合されるのではなく、IPsecに基づいています。実際には、これはデプロイメントの問題につながります。
OSPF implementations generally prioritize packets in order to minimize disruption when router resources such as CPU or memory experience contention. When IPsec is used with OSPFv3, the offset of the packet type, which is used to prioritize packets, depends on which integrity transform is used. For this reason, prioritizing packets may be more complex for OSPFv3. One approach is to establish per-SPI filters to find the packet type and then act accordingly.
OSPFの実装では、通常、CPUやメモリなどのルーターリソースで競合が発生した場合の中断を最小限に抑えるために、パケットに優先順位を付けます。 OSPFv3でIPsecを使用する場合、パケットの優先順位付けに使用されるパケットタイプのオフセットは、使用される整合性変換によって異なります。このため、OSPFv3では、パケットの優先順位付けがより複雑になる場合があります。 1つのアプローチは、SPIごとのフィルターを確立してパケットタイプを見つけ、それに応じて動作することです。
As discussed, neither version of OSPF meets the requirements of inter-connection or intra-connection replay protection. In order to mount a replay, an attacker needs some mechanism to inject a packet. Physical security can limit a particular deployment's vulnerability to replay attacks. This section discusses the impacts of OSPF replays.
説明したように、どちらのバージョンのOSPFも、相互接続または接続内のリプレイ保護の要件を満たしていません。リプレイをマウントするために、攻撃者はパケットを挿入する何らかのメカニズムを必要とします。物理的なセキュリティにより、特定のデプロイメントの脆弱性を制限して、リプレイ攻撃を防ぐことができます。このセクションでは、OSPFリプレイの影響について説明します。
In OSPFv2, two facilities limit the scope of replay attacks. First, when cryptographic authentication is used, each packet includes a sequence number that is non-decreasing. In the current specifications, the sequence number is remembered as part of an adjacency: if an attacker can cause an adjacency to go down, then replay state is lost. Database Description packets also include a per-LSA sequence number that is part of the information that is flooded. Even if a packet is replayed, the per-LSA sequence number will prevent an old LSA from being installed. Unlike the per-packet sequence number, the per-LSA sequence number must increase when an LSA is changed. As a result, replays cannot be used to install old routing information.
OSPFv2では、2つの機能がリプレイ攻撃の範囲を制限します。まず、暗号化認証が使用される場合、各パケットには減少しないシーケンス番号が含まれます。現在の仕様では、シーケンス番号は隣接関係の一部として記憶されています。攻撃者が隣接関係を停止させると、再生状態は失われます。データベース記述パケットには、フラッディングされる情報の一部であるLSAごとのシーケンス番号も含まれます。パケットが再生される場合でも、LSAごとのシーケンス番号により、古いLSAがインストールされなくなります。パケットごとのシーケンス番号とは異なり、LSAごとのシーケンス番号は、LSAが変更されたときに増やす必要があります。その結果、リプレイを使用して古いルーティング情報をインストールすることはできません。
While the LSA sequence number provides some defense, the Routing Protocol Security Requirements (RPSEC) analysis [OSPF-SEC] describes a number of attacks that are possible because of per-packet replays. The most serious appear to be attacks against Hello packets, which may cause an adjacency to fail. Other attacks may cause excessive flooding or excessive use of CPU.
LSAシーケンス番号はある程度の防御を提供しますが、ルーティングプロトコルセキュリティ要件（RPSEC）分析[OSPF-SEC]は、パケットごとのリプレイが原因で発生する可能性のある多くの攻撃について説明しています。最も深刻なのは、Helloパケットに対する攻撃で、隣接の障害を引き起こす可能性があります。他の攻撃は、過度のフラッディングまたはCPUの過度の使用を引き起こす可能性があります。
Another serious attack concerns Database Description packets. In addition to the per-packet sequence number that is part of cryptographic authentication for OSPFv2 and the per-LSA sequence numbers, Database Description packets also include a Database Description sequence number. If a Database Description packet with the incorrect sequence number is received, then the database exchange process will be restarted.
別の深刻な攻撃は、データベース記述パケットに関係しています。 OSPFv2の暗号化認証の一部であるパケットごとのシーケンス番号とLSAごとのシーケンス番号に加えて、データベース記述パケットにはデータベース記述シーケンス番号も含まれます。シーケンス番号が正しくないデータベース記述パケットを受信すると、データベース交換プロセスが再開されます。
The per-packet OSPFv2 sequence number can be used to reduce the window in which a replay is valid. A receiver will harmlessly reject a packet whose per-packet sequence number is older than the one most recently received from a neighbor. Replaying the most recent packet from a neighbor does not appear to create problems. So, if the per-packet sequence number is incremented on every packet sent, then replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does not have a procedure for dealing with sequence numbers reaching the maximum value. It may be possible to figure out a set of rules sufficient to disrupt the damage of packet replays while minimizing the use of the sequence number space.
パケットごとのOSPFv2シーケンス番号を使用して、リプレイが有効なウィンドウを減らすことができます。レシーバーは、パケットごとのシーケンス番号がネイバーから最後に受信したものより古いパケットを無害に拒否します。ネイバーからの最新のパケットを再生しても問題は発生しないようです。したがって、パケットごとのシーケンス番号が送信されるすべてのパケットで増加する場合、リプレイ攻撃はOSPFv2を妨害しないはずです。残念ながら、OSPFv2には、最大値に達するシーケンス番号を処理するための手順がありません。シーケンス番号スペースの使用を最小限に抑えながら、パケット再生の損傷を破壊するのに十分な一連のルールを理解することが可能になる場合があります。
As mentioned previously, when an adjacency is dropped, replay state is lost. So, after rebooting or when all adjacencies are lost, a router may allow its sequence number to decrease. An attacker can cause significant damage by replaying a packet captured before the sequence number decrease at a time after the sequence number decrease. If this happens, then the replayed packet will be accepted and the sequence number will be updated. However, the legitimate sender will be using a lower sequence number, so legitimate packets will be rejected. A similar attack is possible in cases where OSPF identifies a neighbor based on source address. An attacker can change the source address of a captured packet and replay it. If the attacker causes a replay from a neighbor with a high sequence number to appear to be from a neighbor with a low sequence number, then connectivity with that neighbor will be disrupted until the adjacency fails.
前述したように、隣接関係がドロップされると、再生状態は失われます。したがって、再起動後、またはすべての隣接関係が失われた場合、ルーターはシーケンス番号を減らすことができます。攻撃者は、シーケンス番号が減少した後、一度にシーケンス番号が減少する前にキャプチャされたパケットを再生することにより、重大なダメージを与える可能性があります。これが発生した場合、再生されたパケットが受け入れられ、シーケンス番号が更新されます。ただし、正当な送信者はより小さなシーケンス番号を使用するため、正当なパケットは拒否されます。 OSPFが送信元アドレスに基づいてネイバーを識別する場合にも、同様の攻撃が可能です。攻撃者は、キャプチャしたパケットの送信元アドレスを変更し、それを再生できます。攻撃者がシーケンス番号の大きいネイバーからのリプレイをシーケンス番号の小さいネイバーからのように見せかけた場合、隣接が失敗するまで、そのネイバーとの接続は中断されます。
OSPFv3 lacks the per-packet sequence number but has the per-LSA sequence number. As such, OSPFv3 has no defense against denial-of-service attacks that exploit replay.
OSPFv3には、パケットごとのシーケンス番号がありませんが、LSAごとのシーケンス番号があります。そのため、OSPFv3には、リプレイを悪用するサービス拒否攻撃に対する防御機能がありません。
The design guide requires each design team to enumerate a set of requirements for the routing protocol. The only concerns identified with OSPF are areas in which it fails to meet the general requirements outlined in the threats and requirements document. This section explains how some of these general requirements map specifically onto the OSPF protocol and enumerates the specific gaps that need to be addressed.
設計ガイドでは、各設計チームがルーティングプロトコルの一連の要件を列挙する必要があります。 OSPFで識別される唯一の懸念事項は、脅威と要件のドキュメントで概説されている一般的な要件を満たさない領域です。このセクションでは、これらの一般的な要件の一部がOSPFプロトコルに具体的にどのようにマッピングされ、対処する必要がある特定のギャップを列挙する方法について説明します。
There is a general requirement for inter-connection replay protection. In the context of OSPF, this means that if an adjacency goes down between two neighbors and later is re-established, replaying packets from before the adjacency went down cannot disrupt the adjacency. In the context of OSPF, intra-connection replay protection means that replaying a packet cannot prevent an adjacency from forming or cannot disrupt an existing adjacency. In terms of meeting the requirements for intra-connection and inter-connection replay protection, a significant gap exists between the optimal state and where OSPF is today.
接続間再生保護には一般的な要件があります。 OSPFのコンテキストでは、これは、隣接関係が2つのネイバー間でダウンし、後で再確立された場合、隣接関係がダウンする前からパケットを再生しても、隣接関係を中断できないことを意味します。 OSPFのコンテキストでは、接続内リプレイ保護とは、パケットをリプレイしても隣接関係の形成を妨げたり、既存の隣接関係を妨害したりできないことを意味します。接続内および接続間再生保護の要件を満たすという点では、最適な状態と現在のOSPFの位置との間に大きなギャップがあります。
Since OSPF uses fields in the IP header, the general requirement to protect the IP header and handle neighbor identification applies. This is another gap that needs to be addressed. Because the replay protection will depend on neighbor identification, the replay protection cannot be adequately addressed without handling this issue as well.
OSPFはIPヘッダーのフィールドを使用するため、IPヘッダーを保護し、ネイバーIDを処理するための一般的な要件が適用されます。これは、対処する必要があるもう1つのギャップです。再生保護はネイバーIDに依存するため、この問題にも対処しないと再生保護に適切に対処できません。
In order to encourage deployment of OSPFv3 security, an authentication option is required that does not have the deployment challenges of IPsec.
OSPFv3セキュリティの展開を促進するには、IPsecの展開の課題がない認証オプションが必要です。
In order to support the requirement for simple pre-shared keys, OSPF needs to make sure that when the same key is used for two different purposes, no problems result.
単純な事前共有キーの要件をサポートするために、OSPFは、同じキーが2つの異なる目的に使用される場合に問題が発生しないことを確認する必要があります。
In order to support packet prioritization, it is desirable for the information needed to prioritize OSPF packets (the packet type) to be at a constant location in the packet.
パケットの優先順位付けをサポートするには、OSPFパケットの優先順位付けに必要な情報（パケットタイプ）がパケット内の一定の場所にあることが望ましいです。
It is recommended that the OSPF Working Group develop a solution for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. This solution would have the following improvements over the existing OSPFv2 option:
OSPFワーキンググループは、OSPFv2暗号化認証オプションに基づいて、OSPFv2およびOSPFv3のソリューションを開発することをお勧めします。このソリューションには、既存のOSPFv2オプションに比べて次の改善点があります。
Address most inter-connection replay attacks by splitting the sequence number and requiring preservation of state so that the sequence number increases on every packet.
シーケンス番号を分割し、すべてのパケットでシーケンス番号が増加するように状態の保持を要求することにより、ほとんどの相互接続リプレイ攻撃に対処します。
Add a form of simple key derivation so that if the same pre-shared key is used for OSPF and other purposes, cross-protocol attacks do not result.
OSPFやその他の目的で同じ事前共有キーが使用された場合に、クロスプロトコル攻撃が発生しないように、単純なキー派生の形式を追加します。
Support OSPFv3 authentication without use of IPsec.
IPsecを使用せずにOSPFv3認証をサポートします。
Specify processing rules sufficient to permit replay detection and packet prioritization.
リプレイの検出とパケットの優先順位付けを可能にするのに十分な処理ルールを指定します。
Emphasize requirements already present in the OSPF specification sufficient to permit key migration without disrupting adjacencies.
OSPF仕様にすでに存在する要件を強調して、隣接関係を中断することなくキーの移行を許可します。
Specify the proper use of the key table for OSPF.
OSPFのキーテーブルの適切な使用を指定します。
Protect the source IP address.
送信元IPアドレスを保護します。
Require that sequence numbers be incremented on each packet.
各パケットでシーケンス番号を増分する必要があります。
The key components of this solution work are already underway. OSPFv3 now supports an authentication option [RFC6506] that meets the requirements of this section; however, this document does not describe how the key tables are used for OSPF. OSPFv2 is being enhanced [OSPF-MANKEY] to protect the source address, provide inter-connection replay and describe how to use the key table.
このソリューション作業の主要コンポーネントはすでに進行中です。 OSPFv3は、このセクションの要件を満たす認証オプション[RFC6506]をサポートするようになりました。ただし、このドキュメントでは、OSPFでのキーテーブルの使用方法については説明していません。 OSPFv2は、[OSPF-MANKEY]を拡張して送信元アドレスを保護し、接続間再生を提供し、キーテーブルの使用方法を説明しています。
This memo discusses and compiles vulnerabilities in the existing OSPF cryptographic handling.
このメモは、既存のOSPF暗号処理の脆弱性について説明し、まとめています。
In analyzing proposed improvements to OSPF per-packet security, it is desirable to consider how these improvements interact with potential improvements in overall routing security. For example, the impact of replay attacks currently depends on the LSA sequence number mechanism. If cryptographic protections against insider attackers are considered by future work, then that work will need to provide a solution that meets the needs of the per-packet replay defense as well as protects routing data from insider attack. An experimental solution is discussed in [RFC2154] that explores end-to-end protection of routing data in OSPF. It may be beneficial to consider how improvements to the per-packet protections would interact with such a mechanism to future-proof these mechanisms.
OSPFのパケットごとのセキュリティの改善案を分析する際には、これらの改善がルーティングセキュリティ全体の潜在的な改善とどのように相互作用するかを検討することが望ましいです。たとえば、リプレイ攻撃の影響は現在、LSAシーケンス番号メカニズムに依存しています。内部の攻撃者に対する暗号化による保護が今後の作業で検討される場合、その作業では、パケットごとのリプレイ防御のニーズを満たし、内部の攻撃からルーティングデータを保護するソリューションを提供する必要があります。 [RFC2154]では、OSPFでのルーティングデータのエンドツーエンドの保護を検討する実験的なソリューションについて説明しています。パケットごとの保護の改善がこのようなメカニズムとどのように相互作用して、これらのメカニズムを将来にわたって保証するかを検討することは有益かもしれません。
Implementations have a number of options in minimizing the potential denial-of-service impact of OSPF cryptographic authentication. The Generalized TTL Security Mechanism (GTSM) [RFC5082] might be appropriate for OSPF packets except for those traversing virtual links. Using this mechanism requires support of the sender; new OSPF cryptographic authentication could specify this behavior if desired. Alternatively, implementations can limit the source addresses from which they accept packets. Non-Hello packets need only be accepted from existing neighbors. If a system is under attack, Hello packets from existing neighbors could be prioritized over Hello packets from new neighbors. These mechanisms can be considered to limit the potential impact of denial-of-service attacks on the cryptographic authentication mechanism itself.
実装には、OSPF暗号化認証の潜在的なサービス拒否の影響を最小限に抑えるための多くのオプションがあります。 Generalized TTL Security Mechanism（GTSM）[RFC5082]は、仮想リンクを通過するものを除いて、OSPFパケットに適している場合があります。このメカニズムを使用するには、送信者のサポートが必要です。新しいOSPF暗号化認証では、必要に応じてこの動作を指定できます。あるいは、実装は、パケットを受け入れる送信元アドレスを制限できます。 Hello以外のパケットは、既存のネイバーからのみ受け入れる必要があります。システムが攻撃を受けている場合、既存のネイバーからのHelloパケットが新しいネイバーからのHelloパケットよりも優先される可能性があります。これらのメカニズムは、暗号化認証メカニズム自体に対するサービス拒否攻撃の潜在的な影響を制限すると見なすことができます。
Funding for Sam Hartman's work on this memo was provided by Huawei.
このメモに関するSam Hartmanの作業への資金提供は、Huaweiから提供されました。
The authors would like to thank Ran Atkinson, Michael Barnes, and Manav Bhatia for valuable comments.
著者は、貴重なコメントを提供してくれたRan Atkinson、Michael Barnes、およびManav Bhatiaに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年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月。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013.
[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコルのキーイングおよび認証（KARP）の概要、脅威、および要件」、RFC 6862、2013年3月。
[CRYPTO-KEYS] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2012.
[暗号鍵] Housley、R.、Polk、T.、Hartman、S。、およびD. Zhang、「長寿命の対称暗号鍵のデータベース」、作業中、2012年10月。
[FIPS180] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2002.
[FIPS180]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、2002年8月。
[OPS-MODEL] Hartman, S. and D. Zhang, "Operations Model for Router Keying", Work in Progress, October 2012.
[OPS-MODEL] Hartman、S. and D. Zhang、 "Operations Model for Router Keying"、Work in Progress、2012年10月。
[OSPF-MANKEY] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, October 2012.
[OSPF-MANKEY] Bhatia、M.、Hartman、S.、Zhang、D。、およびA. Lindem、「手動のキー管理を使用する場合のOSPFv2のセキュリティ拡張」、作業中、2012年10月。
[OSPF-SEC] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress, June 2006.
[OSPF-SEC]ジョーンズ、E。およびO.モリーン、「OSPFセキュリティ脆弱性分析」、進行中の作業、2006年6月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154] Murphy、S.、Badger、M。、およびB. Wellington、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", BCP 112, RFC 4222, October 2005.
[RFC4222] Choudhury、G.、「特定のOSPFバージョン2パケットの優先順位付けされた処理と輻輳回避」、BCP 112、RFC 4222、2005年10月。
[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月。
[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月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月。
[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月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 6506、2012年2月。
Authors' Addresses
著者のアドレス
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
URI: http://www.painless-security.com/
Dacheng Zhang Huawei Technologies Co., Ltd. Huawei Building No. 3 Xinxi Rd. Shang-Di Information Industrial Base Hai-Dian District, Beijing China
DAは、テクノロジー株式会社の張胡Aです。胡Aは、建物番号3です。Xは、RDです。
EMail: zhangdacheng@huawei.com