[要約] 要約：RFC 7474は、手動キー管理を使用する場合のOSPFv2のセキュリティ拡張に関するものです。 目的：このRFCの目的は、OSPFv2のセキュリティを向上させるために、手動キー管理を使用する場合の推奨事項と手順を提供することです。
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7474 Ionos Networks
Updates: 2328, 5709 S. Hartman
Category: Standards Track Painless Security
ISSN: 2070-1721 D. Zhang
Huawei Technologies Co., Ltd.
A. Lindem, Ed.
Cisco
April 2015
Security Extension for OSPFv2 When Using Manual Key Management
手動キー管理を使用する場合のOSPFv2のセキュリティ拡張
Abstract
概要
The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra-session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.
RFC 2328および5709で定義されている現在のOSPFv2暗号化認証メカニズムは、手動キーイングを使用した場合のセッション間およびセッション内のリプレイ攻撃に対して脆弱です。さらに、既存の暗号化認証メカニズムはIPヘッダーをカバーしません。この省略を悪用して、さまざまなタイプの攻撃を実行できます。
This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra-session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.
このドキュメントでは、OSPFv2プロトコルパケットをセキュリティで保護するために手動キーを使用する場合に、OSPFv2をセッション間およびセッション内のリプレイ攻撃から保護する認証シーケンス番号メカニズムの変更を定義します。さらに、IPヘッダーを保護しないOSPFv2に起因する攻撃を排除する暗号化ハッシュ計算のいくつかの変更についても説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7474.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7474で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Replay Protection Using Extended Sequence Numbers . . . . . . 4
3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . 5
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
4.1. Key Selection for Unicast OSPF Packet Transmission . . . 7
4.2. Key Selection for Multicast OSPF Packet Transmission . . 8
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP Header . . . . . . . . . . . . . . . . . . . 9
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 10
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The OSPFv2 cryptographic authentication mechanism as described in [RFC2328] uses per-packet sequence numbers to provide protection against replay attacks. The sequence numbers increase monotonically so that attempts to replay stale packets can be thwarted. The sequence number values are maintained as a part of neighbor adjacency state. Therefore, if an adjacency is taken down, the associated sequence numbers get reinitialized and neighbor adjacency formation starts over again. Additionally, the cryptographic authentication mechanism does not specify how to deal with the rollover of a sequence number when its value wraps. These omissions can be exploited by attackers to implement various replay attacks ([RFC6039]). In order to address these issues, we define extensions to the authentication sequence number mechanism.
[RFC2328]で説明されているOSPFv2暗号化認証メカニズムは、パケットごとのシーケンス番号を使用して、リプレイアタックから保護します。シーケンス番号は単調に増加するため、古いパケットを再生しようとする試みは阻止されます。シーケンス番号の値は、ネイバー隣接状態の一部として維持されます。したがって、隣接関係が停止すると、関連するシーケンス番号が再初期化され、隣接関係の形成が最初から始まります。さらに、暗号化認証メカニズムは、値が折り返されるときにシーケンス番号のロールオーバーを処理する方法を指定しません。攻撃者はこれらの省略を悪用して、さまざまなリプレイ攻撃を実装できます（[RFC6039]）。これらの問題に対処するために、認証シーケンス番号メカニズムの拡張を定義します。
The cryptographic authentication as described in [RFC2328] and later updated in [RFC5709] does not include the IP header. This omission can be exploited to launch several attacks as the source address in the IP header is not protected. The OSPF specification, for broadcast and NBMA (Non-Broadcast Multi-Access) networks, requires implementations to use the source address in the IP header to determine the neighbor from which the packet was received. Changing the IP source address of a packet to a conflicting IP address can be exploited to produce a number of denial-of-service attacks [RFC6039]. If the packet is interpreted as coming from a different neighbor, the received sequence number state for that neighbor may be incorrectly updated. This attack may disrupt communication with a legitimate neighbor. Hello packets may be reflected to cause a neighbor to appear to have one-way communication. Additionally, Database Description packets may be reflected in cases where the per-packet sequence numbers are sufficiently divergent in order to disrupt an adjacency [RFC6863]. This is the IP-layer issue described in point 18 in Section 4 of [RFC6862].
[RFC2328]で説明され、後で[RFC5709]で更新される暗号化認証には、IPヘッダーが含まれていません。 IPヘッダーの送信元アドレスが保護されていないため、この省略を悪用していくつかの攻撃を仕掛けることができます。 OSPF仕様は、ブロードキャストおよびNBMA（Non-Broadcast Multi-Access）ネットワークの場合、IPヘッダーのソースアドレスを使用して、パケットの受信元であるネイバーを特定するための実装が必要です。パケットのIP送信元アドレスを競合するIPアドレスに変更すると、多数のサービス拒否攻撃[RFC6039]が発生する可能性があります。パケットが別のネイバーから送信されたものと解釈された場合、そのネイバーの受信シーケンス番号状態が誤って更新される可能性があります。この攻撃は、正当なネイバーとの通信を妨害する可能性があります。 Helloパケットが反射されて、ネイバーが一方向の通信をしているように見える場合があります。さらに、隣接関係を混乱させるためにパケットごとのシーケンス番号が十分に異なる場合、データベース記述パケットが反映される可能性があります[RFC6863]。これは、[RFC6862]のセクション4のポイント18で説明されているIP層の問題です。
[RFC2328] states that implementations MUST offer keyed MD5 authentication. It is likely that this will be deprecated in favor of the stronger algorithms described in [RFC5709] and required in [RFC6094].
[RFC2328]は、実装はキー付きMD5認証を提供する必要があると述べています。 [RFC5709]で説明され、[RFC6094]で必要とされるより強力なアルゴリズムのために、これは非推奨になる可能性があります。
This document defines a few simple changes to the cryptographic authentication mechanism, as currently described in [RFC5709], to prevent such IP-layer attacks.
このドキュメントでは、[RFC5709]で現在説明されているように、暗号化認証メカニズムにいくつかの簡単な変更を定義して、そのようなIP層の攻撃を防ぎます。
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]で説明されているように解釈されます。
When used in lowercase, these words convey their typical use in common language, and are not to be interpreted as described in RFC 2119 [RFC2119].
小文字で使用する場合、これらの単語は一般的な言語での一般的な使用法を示しており、RFC 2119 [RFC2119]で説明されているように解釈されません。
In order to provide replay protection against both inter-session and intra-session replay attacks, 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. OSPFv2 implementations are required to retain the boot count in non-volatile storage for the deployment life of the OSPF router. The requirement to preserve the boot count is also placed on SNMP agents by the SNMPv3 security architecture (refer to snmpEngineBoots in Section 2.2 of [RFC3414]).
セッション間およびセッション内のリプレイ攻撃の両方に対するリプレイ保護を提供するために、OSPFv2シーケンス番号は64ビットに拡張され、厳密に増加するシーケンス番号を含む最下位32ビット値と、最上位32ビット値が含まれますブートカウント。 OSPFv2の実装では、OSPFルーターの展開期間中、ブートカウントを不揮発性ストレージに保持する必要があります。ブートカウントを保持する要件は、SNMPv3セキュリティアーキテクチャによってSNMPエージェントにも課せられます（[RFC3414]のセクション2.2のsnmpEngineBootsを参照）。
Since there is no room in the OSPFv2 packet for a 64-bit sequence number, it will occupy the 8 octets following the OSPFv2 packet and MUST be included when calculating the OSPFv2 packet digest. These additional 8 octets are not included in the OSPFv2 packet header length but are included in the OSPFv2 header Authentication Data length and the IPv4 packet header length.
OSPFv2パケットには64ビットのシーケンス番号用のスペースがないため、OSPFv2パケットに続く8オクテットを占有し、OSPFv2パケットダイジェストを計算するときに含める必要があります。これらの追加の8オクテットは、OSPFv2パケットヘッダー長には含まれていませんが、OSPFv2ヘッダー認証データ長およびIPv4パケットヘッダー長に含まれています。
The lower-order 32-bit sequence number MUST be incremented for every OSPF packet sent by the OSPF router. Upon reception, the sequence number MUST be greater than the sequence number in the last OSPF packet of that type accepted from the sending OSPF neighbor. Otherwise, the OSPF packet is considered a replayed packet and dropped. OSPF packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
下位32ビットのシーケンス番号は、OSPFルーターから送信されるすべてのOSPFパケットに対して増加する必要があります。シーケンス番号は、受信時に、送信OSPFネイバーから受け入れられたそのタイプの最後のOSPFパケットのシーケンス番号よりも大きい必要があります。それ以外の場合、OSPFパケットは再生されたパケットと見なされ、ドロップされます。 [RFC4222]で推奨されているように優先順位が付けられている場合、異なるタイプのOSPFパケットが順序どおりに到着しない可能性があります。
OSPF routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv2 router (including cold restarts). This is achieved by maintaining a boot count in non-volatile storage and incrementing it each time the OSPF router loses its prior sequence number state. The SNMPv3 snmpEngineBoots variable [RFC3414] MAY be used for this purpose. However, maintaining a separate boot count solely for OSPF sequence numbers has the advantage of decoupling SNMP reinitialization and OSPF reinitialization. Also, in the rare event that the lower-order 32-bit sequence number wraps, the boot count can be incremented to preserve the strictly increasing property of the aggregate sequence number. Hence, a separate OSPF boot count is RECOMMENDED.
この仕様を実装するOSPFルーターは、使用可能なメカニズムを使用して、OSPFv2ルーターのデプロイされたライフ（コールドリスタートを含む）の間、シーケンス番号の厳密に増加するプロパティを維持する必要があります。これは、ブートカウントを不揮発性ストレージに維持し、OSPFルーターが以前のシーケンス番号状態を失うたびにブートカウントを増やすことによって実現されます。 SNMPv3 snmpEngineBoots変数[RFC3414]は、この目的に使用できます。ただし、OSPFシーケンス番号専用の個別のブートカウントを維持すると、SNMP再初期化とOSPF再初期化を分離できるという利点があります。また、まれに、下位32ビットのシーケンス番号が折り返される場合は、ブートカウントを増やして、集計シーケンス番号の厳密に増加するプロパティを維持できます。したがって、別のOSPFブートカウントが推奨されます。
The OSPF packet header includes an authentication type field, and 64 bits of data for use by the appropriate authentication scheme (determined by the type field). Authentication types 0, 1, and 2 are defined [RFC2328]. This section defines Authentication type 3.
OSPFパケットヘッダーには、認証タイプフィールドと、適切な認証方式（タイプフィールドによって決定される）で使用するための64ビットのデータが含まれています。認証タイプ0、1、および2が定義されています[RFC2328]。このセクションでは、認証タイプ3を定義します。
When using this authentication scheme, the 64-bit Authentication field (as defined in Appendix D.3 of [RFC2328]) in the OSPF packet header (as defined in Appendix A.3.1 of [RFC2328] and [RFC6549]) is changed as shown in Figure 1. The sequence number is removed and the Key ID is extended to 32 bits and moved to the former position of the sequence number.
この認証方式を使用する場合、OSPFパケットヘッダー（[RFC2328]の付録A.3.1で定義）および[RFC6549]で定義される64ビット認証フィールド（[RFC2328]の付録D.3で定義）は、次のように変更されます。図1に示すように、シーケンス番号が削除され、キーIDが32ビットに拡張され、シーケンス番号の元の位置に移動します。
Additionally, the 64-bit sequence number is moved to the first 64 bits following the OSPFv2 packet and is protected by the authentication digest. These additional 64 bits or 8 octets are included in the IP header length but not the OSPF header packet length.
さらに、64ビットのシーケンス番号は、OSPFv2パケットに続く最初の64ビットに移動され、認証ダイジェストによって保護されます。これらの追加の64ビットまたは8オクテットは、IPヘッダー長に含まれますが、OSPFヘッダーパケット長には含まれません。
Finally, the 0 field at the start of the OSPFv2 header authentication is extended from 16 bits to 24 bits.
最後に、OSPFv2ヘッダー認証の開始時の0フィールドが16ビットから24ビットに拡張されました。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OSPF Protocol Packet |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Boot Count) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Strictly Increasing Packet Counter) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Sequence Number Packet Extensions
図1：拡張シーケンス番号パケット拡張
This section describes how this security solution selects long-lived keys from key tables. [RFC7210]. In this context, we are selecting the key and corresponding Security Association (SA) as defined in Section 3.2 of [RFC5709]. Generally, a key used for OSPFv2 packet authentication should satisfy the following requirements:
このセクションでは、このセキュリティソリューションがキーテーブルから長期間有効なキーを選択する方法について説明します。 [RFC7210]。このコンテキストでは、[RFC5709]のセクション3.2で定義されているように、キーと対応するセキュリティアソシエーション（SA）を選択しています。一般に、OSPFv2パケット認証に使用されるキーは、次の要件を満たす必要があります。
o For packet transmission, the key validity interval as defined by SendLifetimeStart and SendLifetimeEnd must include the current time.
o パケット送信の場合、SendLifetimeStartおよびSendLifetimeEndによって定義されるキーの有効期間には、現在の時刻が含まれている必要があります。
o For packet reception, the key validity interval as defined by AcceptLifetimeStart and AcceptLifetimeEnd must include the current time.
o パケット受信の場合、AcceptLifetimeStartおよびAcceptLifetimeEndで定義されているキーの有効期間には、現在の時刻が含まれている必要があります。
o The key must be valid for the desired security algorithm.
o キーは、目的のセキュリティアルゴリズムに対して有効である必要があります。
In the remainder of this section, additional requirements for keys are enumerated for different scenarios.
このセクションの残りの部分では、キーの追加要件がさまざまなシナリオで列挙されています。
Assume that a router R1 tries to send a unicast OSPF packet from its interface I1 to the interface I2 of a remote router R2 using security protocol P via interface I at time T. First, consider the circumstances where R1 and R2 are not connected with a virtual link. R1 then needs to select a long-lived symmetric key from its key table. Because the key should be shared by both R1 and R2 to protect the communication between I1 and I2, the key should satisfy the following requirements:
ルータR1がインターフェイスI1からリモートルータR2のインターフェイスI2にユニキャストOSPFパケットを送信しようとし、時刻TにインターフェイスIを介してセキュリティプロトコルPを使用するとします。まず、R1とR2が仮想リンク。次に、R1はキーテーブルから長期間有効な対称キーを選択する必要があります。 I1とI2間の通信を保護するために、キーはR1とR2の両方で共有する必要があるため、キーは次の要件を満たす必要があります。
o The Peers field contains the area ID or, if no key containing the area ID is present, the string "all".
o PeersフィールドにはエリアIDが含まれます。エリアIDを含むキーが存在しない場合は、文字列「all」が含まれます。
o The Direction field is either "out" or "both".
o 方向フィールドは、「アウト」または「両方」です。
o The Interfaces field matches I1 or "all".
o [インターフェース]フィールドはI1または「すべて」に一致します。
o If multiple keys match the Interface field, keys that explicitly match I1 should be preferred over keys matching "all". If there are still multiple keys that match, the key with the most recent SendLifetimeStart will be selected. This will facilitate graceful key rollover.
o 複数のキーが[インターフェース]フィールドに一致する場合、I1に明示的に一致するキーが「すべて」に一致するキーよりも優先されます。一致するキーがまだ複数ある場合は、最新のSendLifetimeStartを持つキーが選択されます。これにより、適切なキーのロールオーバーが容易になります。
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be set to the selected key's LocalKeyName.
o OSPFv2ヘッダーのキーIDフィールド（図1を参照）は、選択したキーのLocalKeyNameに設定されます。
When R1 and R2 are connected to a virtual link, the Peers field must identify the virtual endpoint rather than the virtual link. Since there may be virtual links to the same router, the transit area ID must be part of the identifier. Hence, the key should satisfy the following requirements:
R1とR2が仮想リンクに接続されている場合、ピアフィールドは仮想リンクではなく仮想エンドポイントを識別する必要があります。同じルータへの仮想リンクが存在する可能性があるため、トランジットエリアIDは識別子の一部である必要があります。したがって、キーは次の要件を満たす必要があります。
o The Peers field includes both the virtual endpoint's OSPF router ID and the transit area ID for the virtual link in the form of the transit area ID, followed by a colon, followed by the router ID. If no such key exists, then a key with the Peers field set to the transit area ID is used, followed by a key with the Peers field set to "all".
o Peersフィールドには、仮想エンドポイントのOSPFルーターIDと仮想リンクのトランジットエリアIDの両方が、トランジットエリアID、コロン、ルーターIDの形式で含まれています。そのようなキーが存在しない場合、Peersフィールドが通過エリアIDに設定されたキーが使用され、その後にPeersフィールドが "all"に設定されたキーが続きます。
o The Interfaces field is not used for key selection on virtual links.
o 「インターフェース」フィールドは、仮想リンクでのキー選択には使用されません。
o The Direction field is either "out" or "both".
o 方向フィールドは、「アウト」または「両方」です。
o If multiple keys match the Peers field, keys that explicitly match the router ID should be preferred, followed by keys with a transit area specified, followed by keys with the Peers field set to "all". If there are still multiple keys that match, the key with the most recent SendLifetimeStart will be selected. This will facilitate graceful key rollover.
o 複数のキーがピアフィールドに一致する場合は、ルーターIDに明示的に一致するキーを優先し、その後にトランジットエリアが指定されたキー、ピアフィールドが「すべて」に設定されたキーを続けます。一致するキーがまだ複数ある場合は、最新のSendLifetimeStartを持つキーが選択されます。これにより、適切なキーのロールオーバーが容易になります。
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be set to the selected key's LocalKeyName.
o OSPFv2ヘッダーのキーIDフィールド（図1を参照）は、選択したキーのLocalKeyNameに設定されます。
If a router R1 sends an OSPF packet from its interface I1 to a multicast address (i.e., AllSPFRouters or AllDRouters), it needs to select a key according to the following requirements:
ルーターR1がインターフェースI1からマルチキャストアドレス（つまり、AllSPFRoutersまたはAllDRouters）にOSPFパケットを送信する場合、次の要件に従ってキーを選択する必要があります。
o First, try a key with the Peers field containing the area ID to which the interface belongs. If no key exists, try a key with the Peers field "all".
o 最初に、インターフェースが属するエリアIDを含むPeersフィールドでキーを試してください。キーが存在しない場合は、Peersフィールドが「all」のキーを試してください。
o The Interfaces field matches the interface over which the packet is sent or "all".
o 「インターフェース」フィールドは、パケットが送信されるインターフェースまたは「すべて」と一致します。
o The Direction field is either "out" or "both".
o 方向フィールドは、「アウト」または「両方」です。
o If multiple keys match the Interface field, keys that explicitly match I1 should be preferred over keys matching "all". If there are still multiple keys that match, the key with the most resent SendLifetimeStart will be selected. This will facilitate graceful key rollover.
o 複数のキーが[インターフェース]フィールドに一致する場合、I1に明示的に一致するキーが「すべて」に一致するキーよりも優先されます。一致するキーがまだ複数ある場合は、SendLifetimeStartが最も再送されたキーが選択されます。これにより、適切なキーのロールオーバーが容易になります。
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be set to the selected key's LocalKeyName.
o OSPFv2ヘッダーのキーIDフィールド（図1を参照）は、選択したキーのLocalKeyNameに設定されます。
When cryptographic authentication is used, the ID of the authentication key is included in the authentication field of the OSPF packet header. Using this Key ID, it is straight forward for a receiver to locate the corresponding key. The simple requirements are:
暗号化認証を使用する場合、認証キーのIDはOSPFパケットヘッダーの認証フィールドに含まれます。このキーIDを使用すると、受信者が対応するキーを見つけるのは簡単です。単純な要件は次のとおりです。
o The interface on which the key was received is associated with the key's interface.
o キーを受信したインターフェイスは、キーのインターフェイスに関連付けられています。
o The Key ID obtained from the OSPFv2 packet header corresponds to the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. Hence, the Key ID will be used to select the correct local key.
o OSPFv2パケットヘッダーから取得したキーIDは、ネイバーのPeerKeyNameに対応しています。 OSPFv2キーは対称的であるため、OSPFv2キーのLocalKeyNameとPeerKeyNameは同じになります。したがって、正しいローカルキーを選択するためにキーIDが使用されます。
o The Direction field is either "in" or "both".
o 方向フィールドは「in」または「both」のいずれかです。
o The Peers field matches as described in Sections Section 4.1 and Section 4.2.
o Peersフィールドは、セクション4.1およびセクション4.2で説明されているように一致します。
This document updates the definition of the Apad constant, as it is defined in [RFC5709], to include the IP source address from the IP header of the OSPFv2 protocol packet. The overall cryptographic authentication process defined in [RFC5709] remains unchanged. To reduce the potential for confusion, this section minimizes the repetition of text from RFC 5709 [RFC5709]. The changes are:
このドキュメントは、[RFC5709]で定義されているように、Apad定数の定義を更新して、OSPFv2プロトコルパケットのIPヘッダーからのIP送信元アドレスを含めます。 [RFC5709]で定義されている全体的な暗号認証プロセスは変更されていません。混乱の可能性を減らすために、このセクションでは、RFC 5709 [RFC5709]からのテキストの繰り返しを最小限に抑えています。変更点は次のとおりです。
RFC 5709, Section 3.3 describes how the cryptographic authentication must be computed. In RFC 5709, the First-Hash includes the OSPF packet and Authentication Trailer. With this specification, the 64-bit sequence number will be included in the First-Hash along with the Authentication Trailer and OSPF packet.
RFC 5709、セクション3.3では、暗号化認証の計算方法について説明しています。 RFC 5709では、First-HashにOSPFパケットと認証トレーラーが含まれています。この仕様では、64ビットのシーケンス番号が認証トレーラーとOSPFパケットとともにFirst-Hashに含まれます。
RFC 5709, Section 3.3 also requires the OSPFv2 packet's Authentication Trailer (which is the appendage described in RFC 2328, Appendix D.4.3, page 233, items (6)(a) and (6)(d)) to be filled with the value Apad. Apad is a hexadecimal constant with the value 0x878FE1F3 repeated (L/4) times, where L is the length of the hash being used and is measured in octets rather than bits.
RFC 5709、セクション3.3では、OSPFv2パケットの認証トレーラー（RFC 2328、付録D.4.3、233ページ、項目（6）（a）および（6）（d）で説明されている付属物）に、値Apad。 Apadは、値0x878FE1F3が（L / 4）回繰り返される16進定数で、Lは使用されるハッシュの長さで、ビットではなくオクテットで測定されます。
OSPF routers sending OSPF packets must initialize the first 4 octets of Apad to the value of the IP source address that would be used when sending the OSPFv2 packet. The remainder of Apad will contain the value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of the hash, measured in octets. The basic idea is to incorporate the IP source address from the IP header in the cryptographic authentication computation so that any change of IP source address in a replayed packet can be detected.
OSPFパケットを送信するOSPFルーターは、Apadの最初の4オクテットを、OSPFv2パケットの送信時に使用されるIP送信元アドレスの値に初期化する必要があります。 Apadの残りの部分には、値0x878FE1F3が（L-4）/ 4回繰り返された値が含まれます。Lは、オクテットで測定されたハッシュの長さです。基本的な考え方は、IPヘッダーからのIP送信元アドレスを暗号化認証計算に組み込んで、再生されたパケット内のIP送信元アドレスの変更を検出できるようにすることです。
When an OSPF packet is received, implementations MUST initialize the first 4 octets of Apad to the IP source address from the IP header of the incoming OSPFv2 packet. The remainder of Apad will contain the value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of the hash, measured in octets. Besides changing the value of Apad, this document does not introduce any other changes to the authentication mechanism described in [RFC5709]. This would prevent all attacks where a rogue OSPF router changes the IP source address of an OSPFv2 packet and replays it on the same multi-access interface or another interface since the IP source address is now included in the cryptographic hash computation and modification would result in the OSPFv2 packet being dropped due to an authentication failure.
OSPFパケットが受信されると、実装はApadの最初の4オクテットを、着信OSPFv2パケットのIPヘッダーからのIP送信元アドレスに初期化する必要があります。 Apadの残りの部分には、値0x878FE1F3が（L-4）/ 4回繰り返された値が含まれます。Lは、オクテットで測定されたハッシュの長さです。このドキュメントでは、Apadの値を変更する以外に、[RFC5709]で説明されている認証メカニズムに他の変更を導入していません。これにより、不正なOSPFルーターがOSPFv2パケットのIP送信元アドレスを変更し、同じマルチアクセスインターフェイスまたは別のインターフェースで再生するすべての攻撃を防ぐことができます。これは、IP送信元アドレスが暗号化ハッシュ計算に含まれ、変更により、認証の失敗によりドロップされたOSPFv2パケット。
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv2 Cryptographic Protocol ID is appended to the authentication key prior to use. Refer to the IANA Considerations (Section 9).
共通キーを共有するプロトコルのクロスプロトコルリプレイ攻撃を防ぐために、2オクテットのOSPFv2暗号化プロトコルIDが使用前に認証キーに追加されます。 IANAの考慮事項（セクション9）を参照してください。
[RFC5709], Section 3.3 describes the mechanism to prepare the key used in the hash computation. This document updates the text under "(1) PREPARATION OF KEY" as follows:
[RFC5709]、セクション3.3では、ハッシュ計算で使用されるキーを準備するメカニズムについて説明しています。このドキュメントは、「（1）PREPARATION OF KEY」の下のテキストを次のように更新します。
The OSPFv2 Cryptographic Protocol ID is appended to the Authentication Key (K) yielding a Protocol-Specific Authentication Key (Ks). In this application, Ko is always L octets long. While [RFC2104] supports a key that is up to B octets long, this application uses L as the Ks length consistent with [RFC4822], [RFC5310], and [RFC5709]. According to [FIPS-198], Section 3, keys greater than L octets do not significantly increase the function strength. Ks is computed as follows:
OSPFv2暗号化プロトコルIDが認証キー（K）に追加され、プロトコル固有の認証キー（Ks）が生成されます。このアプリケーションでは、Koは常にLオクテットの長さです。 [RFC2104]は最大Bオクテットまでのキーをサポートしますが、このアプリケーションは[RFC4822]、[RFC5310]、および[RFC5709]と一貫したKs長としてLを使用します。 [FIPS-198]のセクション3によると、Lオクテットを超えるキーは機能強度を大幅に増加させません。 Ksは次のように計算されます。
If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to Ks. If the Protocol-Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks). If the Protocol-Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol-Specific Authentication Key (Ks) with zeros appended to the end of the Protocol-Specific Authentication Key (Ks) such that Ko is L octets long.
プロトコル固有の認証キー（Ks）がLオクテット長の場合、KoはKsと等しくなります。プロトコル固有の認証キー（Ks）がLオクテットより長い場合、KoはH（Ks）に設定されます。プロトコル固有の認証キー（Ks）がLオクテットより短い場合、Koはプロトコル固有の認証キー（Ks）に設定され、プロトコル固有の認証キー（Ks）の末尾にゼロが追加されてKo Lオクテット長です。
Once the cryptographic key (Ko) used with the hash algorithm is derived, the rest of the authentication mechanism described in [RFC5709] remains unchanged other than one detail that was unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with zeros to the length of Ipad or Opad. It is expected that implementations of [RFC5709] perform this padding implicitly.
ハッシュアルゴリズムで使用される暗号化キー（Ko）が導出されると、[RFC5709]で説明されている残りの認証メカニズムは、未指定の詳細以外は変更されません。 OpadのKoとIpadをXORするとき、IpadまたはOpadの長さに合わせてKoにゼロを埋め込む必要があります。 [RFC5709]の実装は、このパディングを暗黙的に実行することが期待されています。
This security extension uses a new authentication type, AuType in the OSPFv2 header (refer to Figure 1). When an OSPFv2 packet is received and the AuType doesn't match the configured authentication type for the interface, the OSPFv2 packet will be dropped as specified in RFC 2328 [RFC2328]. This guarantees backward-compatible behavior consistent with any other authentication type mismatch.
このセキュリティ拡張機能では、OSPFv2ヘッダーで新しい認証タイプAuTypeを使用します（図1を参照）。 OSPFv2パケットが受信され、AuTypeがインターフェイスに設定された認証タイプと一致しない場合、OSPFv2パケットはRFC 2328 [RFC2328]で指定されているようにドロップされます。これにより、他の認証タイプの不一致と一貫した下位互換性のある動作が保証されます。
This document rectifies the manual key management procedure that currently exists within OSPFv2, as part of Phase 1 of the KARP Working Group. Therefore, only the OSPFv2 manual key management mechanism is considered. Any solution that takes advantage of the automatic key management mechanism is beyond the scope of this document.
このドキュメントは、KARPワーキンググループのフェーズ1の一部として、OSPFv2内に現在存在する手動の鍵管理手順を修正します。したがって、OSPFv2手動キー管理メカニズムのみが考慮されます。自動キー管理メカニズムを利用するソリューションは、このドキュメントの範囲外です。
The described sequence number extension offers most of the benefits of more complicated mechanisms without their attendant challenges. There are, however, a couple drawbacks to this approach. First, it requires the OSPF implementation to be able to save its boot count in non-volatile storage. If the non-volatile storage is ever repaired or upgraded such that the contents are lost or the OSPFv2 router is replaced, the authentication keys MUST be changed to prevent replay attacks.
説明されているシーケンス番号の拡張は、複雑なメカニズムの利点のほとんどを、付随する課題なしに提供します。ただし、このアプローチにはいくつかの欠点があります。まず、OSPF実装がそのブートカウントを不揮発性ストレージに保存できる必要があります。不揮発性ストレージが修復またはアップグレードされて内容が失われたり、OSPFv2ルーターが交換されたりした場合は、再生攻撃を防ぐために認証キーを変更する必要があります。
Second, if a router is taken out of service completely (either intentionally or due to a persistent failure), the potential exists for reestablishment of an OSPFv2 adjacency by replaying the entire OSPFv2 session establishment. However, this scenario is extremely unlikely, since it would imply an identical OSPFv2 adjacency formation packet exchange. Without adjacency formation, the replay of OSPFv2 hello packets alone for an OSPFv2 router that has been taken out of service should not result in any serious attack, as the only consequence is superfluous processing. Of course, this attack could also be thwarted by changing the relevant manual keys.
第2に、ルーターが完全に（故意にまたは永続的な障害のために）サービスを停止した場合、OSPFv2セッション確立全体を再生することにより、OSPFv2隣接関係が再確立される可能性があります。ただし、同一のOSPFv2隣接関係形成パケット交換を意味するため、このシナリオは非常にまれです。隣接関係が形成されていない場合、サービスが停止したOSPFv2ルーターのOSPFv2 helloパケットだけを再生しても、余分な処理が発生するだけなので、深刻な攻撃は発生しません。もちろん、この攻撃は、関連する手動キーを変更することによって阻止することもできます。
This document also provides a solution to prevent certain denial-of-service attacks that can be launched by changing the source address in the IP header of an OSPFv2 protocol packet.
このドキュメントは、OSPFv2プロトコルパケットのIPヘッダーの送信元アドレスを変更することで起動される特定のサービス拒否攻撃を防ぐためのソリューションも提供します。
Using a single crypto sequence number can leave the router vulnerable to a replay attack where it uses the same source IP address on two different point-to-point unnumbered links. In such environments where an attacker can actively tap the point-to-point links, it's recommended that the user employ different keys on each of those unnumbered IP interfaces.
単一の暗号シーケンス番号を使用すると、2つの異なるポイントツーポイントの番号なしリンクで同じソースIPアドレスを使用するリプレイ攻撃に対して脆弱になる可能性があります。攻撃者がポイントツーポイントリンクをアクティブにタップできるような環境では、ユーザーはこれらの番号なしIPインターフェースのそれぞれに異なるキーを使用することをお勧めします。
This document registers a new code point from the "OSPF Shortest Path First (OSPF) Authentication Codes" registry:
このドキュメントは、「OSPF Shortest Path First（OSPF）認証コード」レジストリから新しいコードポイントを登録します。
o 3 - Cryptographic Authentication with Extended Sequence Numbers.
o 3-拡張シーケンス番号を使用した暗号化認証。
This document also registers a new code point from the "Authentication Cryptographic Protocol ID" registry defined under "Keying and Authentication for Routing Protocols (KARP) Parameters":
このドキュメントは、「ルーティングプロトコル（KARP）パラメータのキーイングと認証」で定義された「Authentication Cryptographic Protocol ID」レジストリから新しいコードポイントも登録します。
o 3 - OSPFv2.
o 3-OSPFv2。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[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, <http://www.rfc-editor.org/info/rfc5709>.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月、<http://www.rfc-editor.org/info/rfc5709>。
[FIPS-198] US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008.
[FIPS-198]米国国立標準技術研究所、「キー付きハッシュメッセージ認証コード（HMAC）」、FIPS PUB 198-1、2008年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月、<http://www.rfc-editor.org/info/ rfc2104>。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>.
[RFC3414] Blumenthal、U。およびB. Wijnen、「バージョン3の簡易ネットワーク管理プロトコル（SNMPv3）のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月、<http：// www .rfc-editor.org / info / rfc3414>。
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", BCP 112, RFC 4222, October 2005, <http://www.rfc-editor.org/info/rfc4222>.
[RFC4222] Choudhury、G。、編、「特定のOSPFバージョン2パケットの優先順位付けされた処理と輻輳回避」、BCP 112、RFC 4222、2005年10月、<http://www.rfc-editor.org/info/rfc4222 >。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007, <http://www.rfc-editor.org/info/rfc4822>.
[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月、<http://www.rfc-editor.org/info/rfc4822>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, 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、2009年2月、<http ：//www.rfc-editor.org/info/rfc5310>。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, 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、2010年10月、<http：//www.rfc- editor.org/info/rfc6039>。
[RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols", RFC 6094, February 2011, <http://www.rfc-editor.org/info/rfc6094>.
[RFC6094] Bhatia、M.、V。Manral、「Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols」、RFC 6094、2011年2月、<http://www.rfc-editor.org/info/rfc6094>。
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6549] Lindem、A.、Roy、A。、およびS. Mirtorabi、「OSPFv2 Multi-Instance Extensions」、RFC 6549、2012年3月、<http://www.rfc-editor.org/info/rfc6549>。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.
[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル（KARP）のキーイングと認証の概要、脅威、および要件」、RFC 6862、2013年3月、<http：//www.rfc -editor.org/info/rfc6862>。
[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, <http://www.rfc-editor.org/info/rfc6863>.
[RFC6863] Hartman、S。およびD. Zhang、「Analysis of OSPF Security Using the Keying and Authentication for Routing Protocols（KARP）Design Guide」、RFC 6863、2013年3月、<http：//www.rfc-editor。 org / info / rfc6863>。
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, 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、2014年4月、<http：//www.rfc-editor .org / info / rfc7210>。
Acknowledgments
謝辞
Thanks to Ran Atkinson for help in the analysis of errata for RFC 6506, which led to clarifications in this document.
このドキュメントの明確化につながったRFC 6506のエラッタの分析に協力してくれたRan Atkinsonに感謝します。
Thanks to Gabi Nakibly for pointing out a possible attack on P2P links.
P2Pリンクへの攻撃の可能性を指摘してくれたGabi Nakiblyに感謝します。
Thanks to Suresh Krishnan for comments made during the Gen-Art review. In particular, thanks for pointing out an ambiguity in the initialization of Apad.
Gen-Artレビューで行われたコメントについて、Suresh Krishnanに感謝します。特に、Apadの初期化のあいまいさを指摘してくれてありがとう。
Thanks to Shaun Cooley for the security directorate review.
セキュリティ総局のレビューをしてくれたShaun Cooleyに感謝します。
Thanks to Adrian Farrel for comments during the IESG last call.
IESGの最後の電話でのコメントを寄せてくれたAdrian Farrelに感謝します。
Authors' Addresses
著者のアドレス
Manav Bhatia Ionos Networks Bangalore India
Manav Bhatia Ionos Networks Bangaloreインド
EMail: manav@ionosnetworks.com
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Dacheng Zhang Huawei Technologies Co., Ltd. Beijing China
DAはテクノロジーズとしてZhang hu Aになりました。
EMail: dacheng.zhang@gmail.com
Acee Lindem (editor) Cisco United States
Acee Lindem（編集者）シスコアメリカ
EMail: acee@cisco.com