[要約] RFC 4552は、OSPFv3における認証と機密性に関する要件を定義しています。このRFCの目的は、OSPFv3プロトコルのセキュリティを向上させ、ネットワークの安全性を確保することです。
Network Working Group M. Gupta
Request for Comments: 4552 Tropos Networks
Category: Standards Track N. Melam
Juniper Networks
June 2006
Authentication/Confidentiality for OSPFv3
OSPFV3の認証/機密性
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header.
このドキュメントは、IPv6認証ヘッダー/セキュリティペイロード（AH/ESP）拡張ヘッダーを使用してOSPFV3に認証/機密性を提供する手段とメカニズムについて説明しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Transport Mode vs. Tunnel Mode ..................................3
3. Authentication ..................................................3
4. Confidentiality .................................................3
5. Distinguishing OSPFv3 from OSPFv2 ...............................4
6. IPsec Requirements ..............................................4
7. Key Management ..................................................5
8. SA Granularity and Selectors ....................................7
9. Virtual Links ...................................................8
10. Rekeying .......................................................9
10.1. Rekeying Procedure ........................................9
10.2. KeyRolloverInterval .......................................9
10.3. Rekeying Interval ........................................10
11. IPsec Protection Barrier and SPD ..............................10
12. Entropy of Manual Keys ........................................12
13. Replay Protection .............................................12
14. Security Considerations .......................................12
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
OSPF (Open Shortest Path First) Version 2 [N1] defines the fields AuType and Authentication in its protocol header to provide security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields were removed from OSPF headers. OSPFv3 relies on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to provide integrity, authentication, and/or confidentiality.
OSPF（Open Shortest Path First）バージョン2 [N1]は、プロトコルヘッダーのフィールドの自動タイプと認証を定義して、セキュリティを提供します。IPv6（OSPFV3）[N2]のOSPFでは、両方の認証フィールドがOSPFヘッダーから削除されました。OSPFV3は、IPv6認証ヘッダー（AH）およびIPv6をカプセル化するセキュリティペイロード（ESP）に依存して、整合性、認証、および/または機密性を提供します。
This document describes how IPv6 AH/ESP extension headers can be used to provide authentication/confidentiality to OSPFv3.
このドキュメントでは、IPv6 AH/ESP拡張ヘッダーを使用してOSPFV3に認証/機密性を提供する方法について説明します。
It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], ESP [N4], the concept of security associations, tunnel and transport mode of IPsec, and the key management options available for AH and ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
読者は、OSPFV3 [N2]、AH [N5]、ESP [N4]、IPSECのセキュリティ協会、トンネルと輸送モードの概念、およびAHおよびESPで利用可能な主要な管理オプションに精通していると想定されています（Manual Keying[N3]およびインターネットキーエクスチェンジ（IKE）[I1]）。
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 [N7].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [N7]に記載されているとおりに解釈される。
The transport mode Security Association (SA) is generally used between two hosts or routers/gateways when they are acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves. OSPFv3 packets are exchanged between routers. However, since the packets are locally delivered, the routers assume the role of hosts in the context of tunnel mode SA. All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to OSPFv3 packets. They MAY also support tunnel mode SA to provide required IPsec security to OSPFv3 packets.
トランスポートモードセキュリティ協会（SA）は、通常、ホストとして機能するときに2つのホストまたはルーター/ゲートウェイの間で使用されます。セキュリティ協会のいずれかの端がルーター/ゲートウェイである場合、SAはトンネルモードSAでなければなりません。2人のホストが自分の間にトンネルモードSAを確立することができます。OSPFV3パケットはルーター間で交換されます。ただし、パケットはローカルで配信されるため、ルーターはトンネルモードSAのコンテキストでホストの役割を想定しています。この仕様に準拠するすべての実装は、輸送モードSAをサポートして、必要なIPSECセキュリティをOSPFV3パケットに提供する必要があります。また、トンネルモードSAをサポートして、必要なIPSECセキュリティをOSPFV3パケットに提供する場合があります。
Implementations conforming to this specification MUST support authentication for OSPFv3.
この仕様に準拠する実装は、OSPFV3の認証をサポートする必要があります。
In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.
OSPFV3に認証を提供するために、実装はESPをサポートし、AHをサポートする必要があります。
If ESP in transport mode is used, it will only provide authentication to OSPFv3 protocol packets excluding the IPv6 header, extension headers, and options.
輸送モードでESPを使用する場合、IPv6ヘッダー、拡張ヘッダー、およびオプションを除くOSPFV3プロトコルパケットの認証のみを提供します。
If AH in transport mode is used, it will provide authentication to OSPFv3 protocol packets, selected portions of IPv6 header, selected portions of extension headers, and selected options.
輸送モードでAHが使用される場合、OSPFV3プロトコルパケット、IPv6ヘッダーの選択された部分、拡張ヘッダーの選択部分、選択されたオプションに認証が提供されます。
When OSPFv3 authentication is enabled,
OSPFV3認証が有効になっている場合、
o OSPFv3 packets that are not protected with AH or ESP MUST be silently discarded.
o AHまたはESPで保護されていないOSPFV3パケットは、静かに破棄する必要があります。
o OSPFv3 packets that fail the authentication checks MUST be silently discarded.
o 認証チェックに失敗するOSPFV3パケットは、静かに廃棄する必要があります。
Implementations conforming to this specification SHOULD support confidentiality for OSPFv3.
この仕様に準拠する実装は、OSPFV3の機密性をサポートするはずです。
If confidentiality is provided, ESP MUST be used.
機密性が提供されている場合、ESPを使用する必要があります。
When OSPFv3 confidentiality is enabled,
OSPFV3の機密性が有効になっている場合、
o OSPFv3 packets that are not protected with ESP MUST be silently discarded.
o ESPで保護されていないOSPFV3パケットは、静かに廃棄する必要があります。
o OSPFv3 packets that fail the confidentiality checks MUST be silently discarded.
o 機密性のチェックに失敗するOSPFV3パケットは、静かに廃棄する必要があります。
The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), and OSPF distinguishes them based on the OSPF header version number. However, current IPsec standards do not allow using arbitrary protocol-specific header fields as the selectors. Therefore, the OSPF version field in the OSPF header cannot be used to distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the version field in the IP header can be used to distinguish OSPFv3 packets from OSPFv2 packets.
OSPFV2およびOSPFV3のIP/IPv6プロトコルタイプは同じであり（89）、OSPFはOSPFヘッダーバージョン番号に基づいてそれらを区別します。ただし、現在のIPSEC標準では、任意のプロトコル固有のヘッダーフィールドをセレクターとして使用することは許可されていません。したがって、OSPFヘッダーのOSPFバージョンフィールドを使用して、OSPFV2パケットとOSPFv2パケットを区別することはできません。OSPFV2はIPv4のみであり、OSPFV3はIPv6用のみであるため、IPヘッダーのバージョンフィールドを使用してOSPFV2パケットとOSPFV2パケットを区別できます。
In order to implement this specification, the following IPsec capabilities are required.
この仕様を実装するには、次のIPSEC機能が必要です。
Transport mode IPsec in transport mode MUST be supported. [N3]
トランスポートモードの輸送モードIPSECは、サポートする必要があります。[N3]
Multiple Security Policy Databases (SPDs) The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface. [N3]
複数のセキュリティポリシーデータベース（SPD）実装は、インターフェイスに基づいて特定のSPDを選択する機能を提供するSPD選択関数を備えた複数のSPDをサポートする必要があります。[N3]
Selectors The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.
セレクター実装は、SPDのセレクターとしてソースアドレス、宛先アドレス、プロトコル、および方向を使用できる必要があります。
Interface ID tagging The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived. [N3]
インターフェイスIDのタグの実装は、到着したインターフェイス（物理的または仮想）のIDでインバウンドパケットにタグを付けることができる必要があります。[N3]
Manual key support Manually configured keys MUST be able to secure the specified traffic. [N3]
手動キーサポート手動で構成されたキーは、指定されたトラフィックを保護できる必要があります。[N3]
Encryption and authentication algorithms The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing OSPFv3 packets since the stream ciphers are not suitable for manual keys.
暗号化と認証アルゴリズム実装では、ストリーム暗号が手動キーに適していないため、OSPFV3パケットを保護するための暗号化アルゴリズムとしてユーザーがストリーム暗号を選択できるようにしてはなりません。
Except when in conflict with the above statement, the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in the [N6] document for algorithms to be supported are to be interpreted as described in [N7] for OSPFv3 support as well.
上記のステートメントと競合している場合を除き、キーワードは「必須」、「必須」、「必須」、「必要」、「必要はない」、[N6]ドキュメントにサポートされるドキュメントに表示されることは、OSPFV3サポートについても[n7]で説明されているように解釈されます。
Dynamic IPsec rule configuration The routing module SHOULD be able to configure, modify, and delete IPsec rules on the fly. This is needed mainly for securing virtual links.
動的IPSECルール構成ルーティングモジュールは、その場でIPSECルールを構成、変更、および削除できる必要があります。これは、主に仮想リンクを保護するために必要です。
Encapsulation of ESP packet IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
ESPパケットのカプセル化ESPパケットのカプセル化をサポートする必要があります。簡単にするために、ESPパケットのUDPカプセル化は使用しないでください。
Different SAs for different Differentiated Services Code Points (DSCPs) As per [N3], the IPsec implementation MUST support the establishment and maintenance of multiple SAs with the same selectors between a given sender and receiver. This allows the implementation to associate different classes of traffic with the same selector values in support of Quality of Service (QoS).
[N3]に従って、異なる差別化されたサービスコードポイント（DSCP）の異なるSASは、IPSECの実装では、特定の送信者と受信機の間の同じセレクターを使用した複数のSAの確立とメンテナンスをサポートする必要があります。これにより、実装により、さまざまなクラスのトラフィックを同じセレクター値に関連付けて、サービス品質（QoS）をサポートできます。
OSPFv3 exchanges both multicast and unicast packets. While running OSPFv3 over a broadcast interface, the authentication/confidentiality required is "one to many". Since IKE is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required "one to many" authentication/confidentiality. This specification mandates the usage of Manual Keying with current IPsec implementations. Future specifications can explore the usage of protocols like Kerberized Internet Negotiation of Keys/Group Secure Association Key Management Protocol (KINK/GSAKMP) when they are widely available. In manual keying, SAs are statically installed on the routers and these static SAs are used to authenticate/encrypt packets.
OSPFV3は、マルチキャストパケットとユニキャストパケットの両方を交換します。ブロードキャストインターフェイスでOSPFV3を実行している間、必要な認証/機密性は「多くの人から」です。IkeはDiffie-Hellman Key Ambort Protocolに基づいており、2つの通信パーティーでのみ機能するため、IKEを使用して必要な「1つの」認証/機密性を提供することはできません。この仕様は、現在のIPSEC実装を使用した手動キーイングの使用を義務付けています。将来の仕様は、キー/グループセキュアーアソシエーションのキー管理プロトコル（Kink/GSAKMP）のKerberized Internet Negotiationのようなプロトコルの使用を、広く入手できる場合を調査できます。手動キーイングでは、SASがルーターに静的にインストールされ、これらの静的SASはパケットの認証/暗号化に使用されます。
The following discussion explains that it is not scalable and is practically infeasible to use different security associations for inbound and outbound traffic to provide the required "one to many" security. Therefore, the implementations MUST use manually configured keys with the same SA parameters (Security Parameter Index (SPI), keys, etc.) for both inbound and outbound SAs (as shown in Figure 3).
以下の議論では、スケーラブルではなく、インバウンドおよびアウトバウンドトラフィックに異なるセキュリティ協会を使用して、必要な「多くの」セキュリティを提供することは実質的に実行不可能です。したがって、実装は、インバウンドSAとアウトバウンドSAの両方に対して、同じSAパラメーター（セキュリティパラメーターインデックス（SPI）、キーなど）を備えた手動で構成されたキーを使用する必要があります（図3を参照）。
A |
SAa ------------>|
SAb <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 1
|
C |
SAa/SAb ------------>|
SAa/SAb <------------|
|
Broadcast
Network
If we consider communication between A and B in Figure 1, everything seems to be fine. A uses security association SAa for outbound packets and B uses the same for inbound packets and vice versa. Now if we include C in the group and C sends a packet using SAa, then only A will be able to understand it. Similarly, if C sends a packet using SAb, then only B will be able to understand it. Since the packets are multicast and they are going to be processed by both A and B, there is no SA for C to use so that both A and B can understand them.
図1のAとBの間の通信を考慮すると、すべてが問題ないようです。Aは、Autbound Packetsにセキュリティ協会のSAAを使用し、Bはインバウンドパケットに同じものを使用し、その逆も同様です。グループにCを含め、CがSAAを使用してパケットを送信する場合、Aのみがそれを理解できるようになります。同様に、CがSABを使用してパケットを送信する場合、Bのみがそれを理解することができます。パケットはマルチキャストであり、AとBの両方で処理されるため、AとBの両方がそれらを理解できるように使用するSAが使用されません。
A |
SAa ------------>|
SAb <------------|
SAc <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 2
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
SAb <------------|
|
Broadcast
Network
The problem can be solved by configuring SAs for all the nodes on every other node as shown in Figure 2. So A, B, and C will use SAa, SAb, and SAc, respectively, for outbound traffic. Each node will lookup the SA to be used based on the source (A will use SAb and SAc for packets received from B and C, respectively). This solution is not scalable and practically infeasible because a large number of SAs will need to be configured on each node. Also, the addition of a node in the broadcast network will require the addition of another SA on every other node.
この問題は、図2に示すように、他のすべてのノードのすべてのノードに対してSASを構成することで解決できます。したがって、A、B、およびCは、アウトバウンドトラフィックにそれぞれSAA、SAB、およびSACを使用します。各ノードは、ソースに基づいて使用するSAを検索します（AはそれぞれBとCから受信したパケットにSABとSACを使用します）。このソリューションは、各ノードで多数のSAを構成する必要があるため、スケーラブルで実質的に実行不可能です。また、ブロードキャストネットワークにノードを追加するには、他のすべてのノードに別のSAを追加する必要があります。
A |
SAo ------------>|
SAi <------------|
|
B |
SAo ------------>|
SAi <------------| Figure 3
|
C |
SAo ------------>|
SAi <------------|
|
Broadcast
Network
The problem can be solved by using the same SA parameters (SPI, keys, etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in Figure 3.
この問題は、図3に示すように、インバウンド（SAI）とアウトバウンド（SAO）SASの両方に対して同じSAパラメーター（SPI、キーなど）を使用することで解決できます。
The user SHOULD be given the choice of sharing the same SA among multiple interfaces or using a unique SA per interface.
ユーザーには、複数のインターフェイス間で同じSAを共有するか、インターフェイスごとに一意のSAを使用するかを選択する必要があります。
OSPFv3 supports running multiple instances over one interface using the "Instance Id" field contained in the OSPFv3 header. As IPsec does not support arbitrary fields in the protocol header to be used as the selectors, it is not possible to use different SAs for different OSPFv3 instances running over the same interface. Therefore, all OSPFv3 instances running over the same interface will have to use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not per-interface.
OSPFV3は、OSPFV3ヘッダーに含まれる「インスタンスID」フィールドを使用して、1つのインターフェイスで複数のインスタンスを実行することをサポートします。IPSECは、プロトコルヘッダーの任意のフィールドをセレクターとして使用する任意のフィールドをサポートしていないため、同じインターフェイスを実行している異なるOSPFV3インスタンスに異なるSASを使用することはできません。したがって、同じインターフェイスで実行されているすべてのOSPFV3インスタンスは、同じSAを使用する必要があります。OSPFV3 RFC用語では、SASはリンクごとであり、インターフェイスごとではありません。
A different SA than the SA of the underlying interface MUST be provided for virtual links. Packets sent on virtual links use unicast non-link local IPv6 addresses as the IPv6 source address, while packets sent on other interfaces use multicast and unicast link local addresses. This difference in the IPv6 source address differentiates the packets sent on virtual links from other OSPFv3 interface types.
仮想リンクのために、基礎となるインターフェイスのSAとは異なるSAを提供する必要があります。仮想リンクで送信されたパケットは、Unicast Non-Link Local IPv6アドレスをIPv6ソースアドレスとして使用し、他のインターフェイスで送信されるパケットはマルチキャストおよびユニキャストリンクローカルアドレスを使用します。IPv6ソースアドレスのこの違いは、他のOSPFV3インターフェイスタイプから仮想リンクで送信されたパケットを区別します。
As the virtual link end point IPv6 addresses are not known, it is not possible to install SPD/Security Association Database (SAD) entries at the time of configuration. The virtual link end point IPv6 addresses are learned during the routing table computation process. The packet exchange over the virtual links starts only after the discovery of the end point IPv6 addresses. In order to protect these exchanges, the routing module must install the corresponding SPD/SAD entries before starting these exchanges. Note that manual SA parameters are preconfigured but not installed in the SAD until the end point addresses are learned.
仮想リンクエンドポイントIPv6アドレスは不明であるため、構成時にSPD/Security Association Database（SAD）エントリをインストールすることはできません。仮想リンクエンドポイントIPv6アドレスは、ルーティングテーブル計算プロセス中に学習されます。仮想リンクを介したパケット交換は、エンドポイントIPv6アドレスの発見後にのみ始まります。これらの交換を保護するために、ルーティングモジュールは、これらの交換を開始する前に、対応するSPD/SADエントリをインストールする必要があります。手動SAパラメーターは事前に設定されていますが、エンドポイントアドレスが学習されるまでSADにインストールされていないことに注意してください。
According to the OSPFv3 RFC [N2], the virtual neighbor's IP address is set to the first prefix with the "LA-bit" set from the list of prefixes in intra-area-prefix-Link State Advertisements (LSAs) originated by the virtual neighbor. But when it comes to choosing the source address for the packets that are sent over the virtual link, the RFC [N2] simply suggests using one of the router's own global IPv6 addresses. In order to install the required security rules for virtual links, the source address also needs to be predictable. Hence, routers that implement this specification MUST change the way the source and destination addresses are chosen for packets exchanged over virtual links when IPsec is enabled.
OSPFV3 RFC [N2]によると、仮想隣接するIPアドレスは、仮想からのエリア-Prefix-Link State Advertisements（LSA）のプレフィックスのリストから「LAビット」セットから最初のプレフィックスに設定されています。近所の人。ただし、仮想リンクを介して送信されるパケットのソースアドレスを選択する場合、RFC [N2]は、ルーター独自のグローバルIPv6アドレスの1つを使用することをお勧めします。仮想リンクに必要なセキュリティルールをインストールするには、ソースアドレスも予測可能である必要があります。したがって、この仕様を実装するルーターは、IPSECが有効になったときに仮想リンクを介して交換されるパケットに対してソースと宛先アドレスの選択方法を変更する必要があります。
The first IPv6 address with the "LA-bit" set in the list of prefixes advertised in intra-area-prefix-LSAs in the transit area MUST be used as the source address for packets exchanged over the virtual link. When multiple intra-area-prefix-LSAs are originated, they are considered concatenated and are ordered by ascending Link State ID.
トランジットエリアのエリア内 - エリア-Prefix-LSASで宣伝されているプレフィックスのリストに「LA-BIT」が設定された最初のIPv6アドレスは、仮想リンクで交換されるパケットのソースアドレスとして使用する必要があります。複数のAREA内領域内型LSAが発生すると、それらは連結されていると見なされ、上昇するリンク状態IDによって順序付けられます。
The first IPv6 address with the "LA-bit" set in the list of prefixes received in intra-area-prefix-LSAs from the virtual neighbor in the transit area MUST be used as the destination address for packets exchanged over the virtual link. When multiple intra-area-prefix-LSAs are received, they are considered concatenated and are ordered by ascending Link State ID.
トランジットエリアの仮想隣接からA-AREA-PREFIX-LSAで受信されたプレフィックスのリストに設定された「LA-BIT」を備えた最初のIPv6アドレスは、仮想リンクで交換されるパケットの宛先アドレスとして使用する必要があります。複数のエリア内型-PREFIX-LSAを受信すると、それらは連結されていると見なされ、昇順リンク状態IDによって注文されます。
This makes both the source and destination addresses of packets exchanged over the virtual link predictable when IPsec is enabled.
これにより、IPSECが有効になっているときに仮想リンクを介して交換されるパケットのソースアドレスと宛先アドレスの両方が可能になります。
To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically.
リンクのセキュリティを維持するには、認証と暗号化のキー値を定期的に変更する必要があります。
The following three-step procedure SHOULD be provided to rekey the routers on a link without dropping OSPFv3 protocol packets or disrupting the adjacency.
OSPFV3プロトコルパケットを削除したり、隣接を破壊したりせずに、リンク上のルーターを再キーするには、次の3段階の手順を提供する必要があります。
(1) For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
(1) リンク上のすべてのルーターについて、新しいSPIと新しいキーを使用して再キーにされているインターフェイスの追加のインバウンドSAを作成します。
(2) For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation should be atomic with respect to sending OSPFv3 packets on the link so that no OSPFv3 packets are sent without authentication/encryption.
(2) リンク上のすべてのルーターについて、新しいSPIとキー値を使用して、元のアウトバウンドSAを使用したものに置き換えます。SA置換操作は、認証/暗号化なしでOSPFV3パケットが送信されないように、リンクにOSPFV3パケットを送信することに関してアトミックでなければなりません。
(3) For every router on the link, remove the original inbound SA.
(3) リンク上のすべてのルーターについて、元のインバウンドSAを削除します。
Note that all routers on the link must complete step 1 before any begin step 2. Likewise, all the routers on the link must complete step 2 before any begin step 3.
リンク上のすべてのルーターは、ステップ2の開始前にステップ1を完了する必要があることに注意してください。同様に、リンク上のすべてのルーターは、ステップ3の開始前にステップ2を完了する必要があります。
One way to control the progression from one step to the next is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.
あるステップから次のステップへの進行を制御する1つの方法は、各ルーターが構成可能な時期定数Keyrolovervalvalを持つことです。ルーターが特定のリンクでステップ1を開始すると、この間隔を待ってからステップ2に移動します。同様に、ステップ2に移動した後、この間隔を待ってからステップ3に移動します。
In order to achieve smooth key transition, all routers on a link should use the same value for KeyRolloverInterval and should initiate the key rollover process within this time period.
スムーズなキー遷移を達成するために、リンク上のすべてのルーターはKeyroloverIntervalに同じ値を使用し、この期間内にキーロールオーバープロセスを開始する必要があります。
At the end of this procedure, all the routers on the link will have a single inbound and outbound SA for OSPFv3 with the new SPI and key values.
この手順の最後に、リンク上のすべてのルーターには、新しいSPIとキー値を備えたOSPFV3用の単一のインバウンドSAとアウトバウンドSAがあります。
The configured value of KeyRolloverInterval should be long enough to allow the administrator to change keys on all the OSPFv3 routers. As this value can vary significantly depending upon the implementation and the deployment, it is left to the administrator to choose an appropriate value.
KeyRolloverIntervalの構成された値は、管理者がすべてのOSPFV3ルーターのキーを変更できるようにするのに十分な長さである必要があります。この値は、実装と展開によって大きく異なるため、適切な値を選択するのは管理者に任されます。
This section analyzes the security provided by manual keying and recommends that the encryption and authentication keys SHOULD be changed at least every 90 days.
このセクションでは、手動キーイングによって提供されるセキュリティを分析し、暗号化と認証キーを少なくとも90日ごとに変更することを推奨します。
The weakest security provided by the security mechanisms discussed in this specification is when NULL encryption (for ESP) or no encryption (for AH) is used with the HMAC-MD5 authentication. Any other algorithm combinations will at least be as hard to break as the ones mentioned above. This is shown by the following reasonable assumptions:
この仕様で説明されているセキュリティメカニズムによって提供される最も弱いセキュリティは、null暗号化（ESPの場合）または暗号化（AHの）がHMAC-MD5認証で使用されている場合です。他のアルゴリズムの組み合わせは、少なくとも上記のアルゴリズムの組み合わせと同じくらい壊れるのが難しいでしょう。これは、次の合理的な仮定によって示されます。
o NULL Encryption and HMAC-SHA-1 Authentication will be more secure as HMAC-SHA-1 is considered to be more secure than HMAC-MD5.
o null暗号化とHMAC-SHA-1認証は、HMAC-SHA-1がHMAC-MD5よりも安全であると考えられているため、より安全になります。
o NON-NULL Encryption and NULL Authentication combination is not applicable as this specification mandates authentication when OSPFv3 security is enabled.
o この仕様がOSPFv3セキュリティが有効になっている場合、この仕様は認証を義務付けるため、非ヌル暗号化とヌル認証の組み合わせは適用できません。
o Data Encryption Security (DES) Encryption and HMAC-MD5 Authentication will be more secure because of the additional security provided by DES.
o データ暗号化セキュリティ（DES）暗号化とHMAC-MD5認証は、DESが提供する追加のセキュリティにより、より安全になります。
o Other encryption algorithms like 3DES and the Advanced Encryption Standard (AES) will be more secure than DES.
o 3DESや高度な暗号化標準（AES）などの他の暗号化アルゴリズムは、DESよりも安全です。
RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 signature option. The analysis provided in RFC 3562 is also applicable to this specification as the analysis is independent of data patterns.
RFC 3562 [i4]は、TCP MD5署名オプションの再キーキング要件を分析します。RFC 3562で提供される分析は、分析はデータパターンに依存しないため、この仕様にも適用できます。
The IPsec protection barrier MUST be around the OSPF protocol. Therefore, all the inbound and outbound OSPF traffic goes through IPsec processing.
IPSEC保護障壁は、OSPFプロトコルの周りにある必要があります。したがって、すべてのインバウンドおよびアウトバウンドOSPFトラフィックは、IPSEC処理を通過します。
The SPD selection function MUST return an SPD with the following rule for all the interfaces that have OSPFv3 authentication/confidentiality disabled.
SPD選択関数は、OSPFV3認証/機密性を無効にしているすべてのインターフェイスについて、次のルールを使用してSPDを返す必要があります。
No. source destination protocol action
1 any any OSPF bypass
The SPD selection function MUST return an SPD with the following rules for all the interfaces that have OSPFv3 authentication/confidentiality enabled.
SPD選択関数は、OSPFV3認証/機密性を有効にしているすべてのインターフェイスの次のルールを使用してSPDを返す必要があります。
No. source destination protocol action
2 fe80::/10 any OSPF protect
3 fe80::/10 any ESP/OSPF or AH/OSPF protect
4 src/128 dst/128 OSPF protect
5 src/128 dst/128 ESP/OSPF or AH/OSPF protect
For rules 2 and 4, action "protect" means encrypting/calculating Integrity Check Value (ICV) and adding an ESP or AH header. For rules 3 and 5, action "protect" means decrypting/authenticating the packets and stripping the ESP or AH header.
ルール2および4の場合、アクション「保護」とは、整合性チェック値（ICV）を暗号化/計算し、ESPまたはAHヘッダーを追加することを意味します。ルール3と5の場合、アクション「保護」とは、パケットを復号化/認証し、ESPまたはAHヘッダーを剥がすことを意味します。
Rule 1 will bypass the OSPFv3 packets without any IPsec processing on the interfaces that have OSPFv3 authentication/confidentiality disabled.
ルール1は、OSPFV3認証/機密性を無効にしているインターフェイスでIPSEC処理なしでOSPFV3パケットをバイパスします。
Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been secured with ESP/AH headers.
ルール2および4では、ESP/AHヘッダーで固定されていないインバウンドOSPFV3パケットをドロップします。
ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet secured with ESP or AH.
ルール3および5のESP/OSPFまたはAH/OSPFは、ESPまたはAHで保護されたOSPFパケットであることを意味します。
Rules 2 and 3 are meant to secure the unicast and multicast OSPF packets that are not being exchanged over the virtual links.
ルール2と3は、仮想リンクを介して交換されていないユニキャストおよびマルチキャストのOSPFパケットを保護することを目的としています。
Rules 4 and 5 are meant to secure the packets being exchanged over virtual links. These rules are installed after learning the virtual link end point IPv6 addresses. These rules MUST be installed in the SPD for the interfaces that are connected to the transit area for the virtual link. These rules MAY alternatively be installed on all the interfaces. If these rules are not installed on all the interfaces, clear text or malicious OSPFv3 packets with the same source and destination addresses as the virtual link end point IPv6 addresses will be delivered to OSPFv3. Though OSPFv3 drops these packets as they were not received on the right interface, OSPFv3 receives some clear text or malicious packets even when the security is enabled. Installing these rules on all the interfaces ensures that OSPFv3 does not receive these clear text or malicious packets when security is enabled. On the other hand, installing these rules on all the interfaces increases the processing overhead on the interfaces where there is no other IPsec processing. The decision of whether to install these rules on all the interfaces or on just the interfaces that are connected to the transit area is a private decision and doesn't affect the interoperability in any way. Hence it is an implementation choice.
ルール4と5は、仮想リンクを介して交換されているパケットを保護することを目的としています。これらのルールは、仮想リンクエンドポイントIPv6アドレスを学習した後にインストールされます。これらのルールは、仮想リンクのトランジットエリアに接続されているインターフェイスのSPDにインストールする必要があります。これらのルールは、すべてのインターフェイスに代わりにインストールされる場合があります。これらのルールがすべてのインターフェイスにインストールされていない場合、仮想リンクエンドポイントIPv6アドレスと同じソースと宛先アドレスを持つClear Textまたは悪意のあるOSPFV3パケットがOSPFV3に配信されます。OSPFV3は適切なインターフェイスで受信されなかったためにこれらのパケットをドロップしますが、OSPFV3はセキュリティが有効になっていても、いくつかの明確なテキストまたは悪意のあるパケットを受け取ります。すべてのインターフェイスにこれらのルールをインストールすると、セキュリティが有効になったときにOSPFV3がこれらの明確なテキストまたは悪意のあるパケットを受け取らないようにします。一方、すべてのインターフェイスにこれらのルールをインストールすると、他のIPSEC処理がないインターフェイスの処理オーバーヘッドが増加します。これらのルールをすべてのインターフェイスにインストールするか、トランジットエリアに接続されているインターフェイスのみにインストールするかどうかの決定は、個人的な決定であり、相互運用性に影響を与えません。したがって、それは実装の選択です。
The implementations MUST allow the administrator to configure the cryptographic and authentication keys in hexadecimal format rather than restricting it to a subset of ASCII characters (letters, numbers, etc.). A restricted character set will reduce key entropy significantly as discussed in [I2].
実装により、管理者は、ASCII文字（文字、数字など）のサブセットに制限するのではなく、クリプトグラフィーおよび認証キーを16進形式で構成できるようにする必要があります。制限された文字セットは、[I2]で説明されているように、キーエントロピーを大幅に減らします。
Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.
現在の標準を使用して手動キーを使用しながら完全なリプレイ保護を提供することは不可能なため、提案されたソリューションはリプレイ攻撃に対する保護を提供しません。
Detailed analysis of various vulnerabilities of the routing protocols and OSPF in particular is discussed in [I3] and [I2]. The conclusion is that replay of OSPF packets can cause adjacencies to be disrupted, which can lead to a DoS attack on the network. It can also cause database exchange process to occur continuously thus causing CPU overload as well as micro loops in the network.
特にルーティングプロトコルとOSPFのさまざまな脆弱性の詳細な分析については、[i3]および[i2]で説明しています。結論は、OSPFパケットのリプレイが隣接を破壊する可能性があるため、ネットワークに対するDOS攻撃につながる可能性があるということです。また、データベース交換プロセスを継続的に発生させる可能性があります。そのため、ネットワーク内のマイクロループと同様にCPU過負荷を引き起こします。
This memo discusses the use of IPsec AH and ESP headers to provide security to OSPFv3 for IPv6. Hence, security permeates throughout this document.
このメモでは、IPV6のOSPFV3にセキュリティを提供するためのIPSEC AHおよびESPヘッダーの使用について説明します。したがって、このドキュメント全体でセキュリティが浸透します。
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF vulnerabilities in two scenarios -- one with no authentication or simple password authentication and the other with cryptographic authentication. The solution described in this specification provides protection against all the vulnerabilities identified for scenarios with cryptographic authentication with the following exceptions:
OSPFセキュリティの脆弱性分析[I2]は、2つのシナリオでOSPFの脆弱性を識別します。1つは認証または単純なパスワード認証がなく、もう1つは暗号化認証を使用しています。この仕様で説明されているソリューションは、次の例外を除き、暗号化認証を備えたシナリオで特定されたすべての脆弱性に対する保護を提供します。
Limitations of manual key:
マニュアルキーの制限：
This specification mandates the usage of manual keys. The following are the known limitations of the usage of manual keys.
この仕様には、手動キーの使用が義務付けられています。以下は、手動キーの使用法の既知の制限です。
o As the sequence numbers cannot be negotiated, replay protection cannot be provided. This leaves OSPF insecure against all the attacks that can be performed by replaying OSPF packets.
o シーケンス番号を交渉できないため、リプレイ保護は提供できません。これにより、OSPFはOSPFパケットを再生することで実行できるすべての攻撃に対して不安定になります。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
o 手動キーは通常、長生きしています（それらを変更することは退屈な作業です）。これにより、攻撃者はキーを発見するのに十分な時間を与えます。
o As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).
o 管理者はキーを手動で構成しているため、構成されたキーが弱い可能性があります（少なくともDES/3DEの弱いキーが既知のキーがあります）。
Impersonating attacks:
攻撃のなりすまし：
The usage of the same key on all the OSPF routers connected to a link leaves them all insecure against impersonating attacks if any one of the OSPF routers is compromised, malfunctioning, or misconfigured.
リンクに接続されたすべてのOSPFルーターで同じキーを使用すると、OSPFルーターのいずれかが侵害されたり、誤動作したり、誤ったりした場合、攻撃のなりすましに対して不安定になります。
Detailed analysis of various vulnerabilities of routing protocols is discussed in [I3].
ルーティングプロトコルのさまざまな脆弱性の詳細な分析については、[i3]で説明しています。
[N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[N1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[N2] Coltun、R.、Ferguson、D。、およびJ. Moy、「IPv6のOSPF」、RFC 2740、1999年12月。
[N3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[N3] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[N4] Kent、S。、「セキュリティペイロード（ESP）のIPカプセル化」、RFC 4303、2005年12月。
[N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[N5] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[N6] EastLake 3rd、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[I1] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress.
[i2]ジョーンズ、E。、およびO.モインー、「OSPFセキュリティの脆弱性分析」、作業進行中。
[I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress.
[i3] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」は、進行中の作業。
[I4] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[i4] Leech、M。、「TCP MD5署名オプションの主要な管理上の考慮事項」、RFC 3562、2003年7月。
Acknowledgements
謝辞
The authors would like to extend sincere thanks to Marc Solsona, Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas Manral, and Sam Hartman for providing useful information and critiques on this memo. The authors would like to extend special thanks to Acee Lindem for many editorial changes.
著者は、このメモに関する有用な情報と批評を提供してくれたマルク・ソルソナ、ジャンヌ・ペルトナン、ジョン・ペルトン、ダバル・シャー、ダバル・シャー、アブハイ・ロイ、ポール・ウェルズ、ヴィシュワス・マンラル、サム・ハートマンに感謝します。著者は、多くの編集上の変更についてACEE Lindemに特別な感謝を拡大したいと考えています。
We would also like to thank members of the IPsec and OSPF WG for providing valuable review comments.
また、貴重なレビューコメントを提供してくれたIPSECとOSPF WGのメンバーに感謝します。
Authors' Addresses
著者のアドレス
Mukesh Gupta Tropos Networks 555 Del Rey Ave Sunnyvale, CA 94085
Mukesh Gupta Tropos Networks 555 Del Rey Ave Sunnyvale、CA 94085
Phone: 408-331-6889 EMail: mukesh.gupta@tropos.com
電話：408-331-6889メール：mukesh.gupta@tropos.com
Nagavenkata Suresh Melam Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Nagavenkata Suresh Melam Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089
Phone: 408-505-4392 EMail: nmelam@juniper.net
電話：408-505-4392メール：nmelam@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。