Network Working Group M. Gupta
Request for Comments: 4552 Tropos Networks
Category: Standards Track N. Melam
Juniper Networks
June 2006
Authentication/Confidentiality for 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).
著作権（C）インターネット協会（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（オープンショーテストパスファースト）バージョン2 [N1]セキュリティを提供するために、そのプロトコルヘッダ内のフィールドAuTypeと認証を定義します。 IPv6のためのOSPF（OSPFv3の）[N2]において、認証フィールドの両方が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のために利用可能な鍵管理オプション（手動キーに精通していると仮定されます[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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）は、一般的に二つのホストまたはルータ/ゲートウェイ間で使用されています。セキュリティアソシエーションの両端は、ルータ/ゲートウェイである場合、SAはトンネルモードSAでなければなりません。二つのホストは、それらの間のトンネルモードSAを確立することができます。 OSPFv3のパケットは、ルータ間で交換されています。パケットは局所的に送達されているので、ルータは、トンネルモードSAの文脈におけるホストの役割を担います。この仕様に準拠するすべての実装は、OSPFv3のパケットに必要なIPsecセキュリティを提供するために、トランスポートモードSAをサポートしなければなりません。彼らはまた、OSPFv3のパケットに必要なIPsecセキュリティを提供するために、トンネルモードSAをサポートするかもしれません。
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のパケットからのOSPFv3パケットを区別するために使用することができません。 OSPFv2のがIPv4のみのためであり、OSPFv3はIPv6のためだけであるように、IPヘッダ内のバージョンフィールドはOSPFv2のパケットからのOSPFv3パケットを区別するために使用することができます。
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.
べきであり、上記の文と矛盾する場合を除き、キーワード「MUST」、「MUST NOT」、「REQUIRED」「SHOULD」、および「SHOULD NOT」そのサポートするアルゴリズムのための[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パケットのIPカプセル化のカプセル化をサポートしなければなりません。簡単にするために、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を）のための異なるSAは、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の実行中に、必要な認証/機密性は、「多くの1つ」です。 IKEは、ディフィー・ヘルマン鍵合意プロトコルに基づいており、2人の通信当事者のためにのみ動作しているので、認証/機密性「多くの1つ、」必要なを提供するためのIKEを使用することはできません。この仕様は、現在のIPsec実装と手動キーイングの使用を義務付け。将来の仕様は、彼らが広く入手可能であるとき、協会の鍵管理プロトコル（KINK / GSAKMP）をセキュアキー/グループのKerberos対応のインターネット交渉などのプロトコルの使用を探索することができます。手動キー入力では、SAは静的にルータにインストールされており、これらの静的SAが/暗号化パケットを認証するために使用されています。
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).
以下の議論では、それはスケーラブルではないとセキュリティ「の多くに1」必要なを提供するために、インバウンドとアウトバウンドのトラフィックに対して異なるセキュリティアソシエーションを使用することは現実的に実行不可能であることを説明しています。 （図3に示すように）したがって、実装は、インバウンドとアウトバウンドの両方のSAの手動で設定同じSAパラメータで鍵（セキュリティパラメータインデックス（SPI）、キー、等）を使用する必要があります。
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の間の通信を考慮すれば、すべてがうまくなるようです。アウトバウンドパケットのセキュリティアソシエーションSAaにを使用し、Bは、着信パケットおよびその逆のために同じものを使用します。私たちはグループにCが含まれ、CはSAaにを使用してパケットを送信する場合さて、それからだけそれを理解することができるようになります。 Cは、SAbをを使用してパケットを送信する場合、同様に、その唯一Bはそれを理解することができるであろう。パケットがマルチキャストであり、彼らはAとBの両方によって処理されようとしているので、Cは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.
問題は、そこでAが、B、及びCは、アウトバウンドトラフィックのために、それぞれSAaに、SAbを、およびSACを使用する図2に示すように、他のすべてのノード上のすべてのノードのためのSAを設定することによって解決することができます。各ノードは、ソース（Aは、それぞれ、B及びCから受信したパケットに対してたSAbとSACを使用する）に基づいて、使用すべきSAを検索します。 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）のSAの両方に同じ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」フィールドを使用して、一つのインタフェース上に複数のインスタンスを実行してサポート。 IPsecがセレクタとして使用されるプロトコルヘッダ内の任意のフィールドをサポートしていないように、同じインターフェイス上で動作する別のOSPFv3インスタンスの異なるSAを使用することは不可能です。そのため、同じインターフェイス上で実行されているすべてのOSPFv3インスタンスは、同じSAを使用する必要があります。 OSPFv3 RFCの用語では、SAは、リンクごとではなくインターフェイス単位です。
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は、仮想リンクのために提供されなければなりません。他のインターフェイス上で送信されるパケットは、マルチキャストおよびユニキャストリンクローカルアドレスを使用しながら、仮想リンク上で送信されるパケットは、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 /セキュリティアソシエーションデータベース（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アドレスが仮想によって発信エリア内プレフィックスリンクステートアドバタイズメント（LSA）における接頭辞のリストから設定した「LA-ビット」で最初の接頭辞に設定されています隣人。しかし、それは仮想リンクを介して送信されるパケットの送信元アドレスを選択することになると、RFC [N2]単にルータ自身のグローバルIPv6アドレスのいずれかを使用することを提案しています。仮想リンクのために必要なセキュリティルールをインストールするためには、送信元アドレスも予測可能である必要があります。したがって、この仕様を実装するルータは、送信元アドレス、宛先アドレスが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.
パケットは、仮想リンクを介して交換するための通過領域にエリア内プレフィックスのLSAでアドバタイズされたプレフィクスのリストに設定されている「LA-ビット」の最初のIPv6アドレスを送信元アドレスとして使用されなければなりません。複数のエリア内プレフィックス-の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.
プレフィックスのリストに設定されている「LA-ビット」の最初のIPv6アドレスは、通過エリア内の仮想ネイバーからエリア内プレフィックスLSAの中で受信したパケットの宛先アドレスが仮想リンク上で交換として使用されなければなりません。複数のエリア内プレフィックス-の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のプロトコルパケットをドロップまたは隣接を中断することなく、リンク上のルータをリキーするために提供されるべきです。
(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およびキー値を使用して1で、元の発信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.
各ルータは、設定時定数KeyRolloverIntervalを持っているため、次の一歩から進行を制御するための1つの方法です。ルータが所与のリンク上でステップ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.
滑らかなキー移行を達成するために、リンク上のすべてのルータがKeyRolloverIntervalに同じ値を使用する必要があり、この時間内にキーロールオーバプロセスを開始すべきです。
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を持っています。
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.
HMAC-SHA-1 HMAC-MD5よりも安全であると考えられるように、O NULL暗号化およびHMAC-SHA-1認証は、より安全であろう。
o NON-NULL Encryption and NULL Authentication combination is not applicable as this specification mandates authentication when OSPFv3 security is enabled.
OSPFv3のセキュリティが有効になっている場合、O NON-NULL暗号化およびNULL認証の組み合わせは、この仕様書の義務付け認証として適用されていません。
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とのAdvanced Encryption Standard（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
いいえソース宛先プロトコルアクション1いかなる任意OSPFバイパス
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
いいえソース宛先プロトコルアクション2 FE80 :: / 10の任意のOSPF保護3 FE80 :: / 10の任意のESP / OSPFまたはAH / OSPF守る4 SRC / 128 DST / 128 OSPF守る5 SRC / 128 DST / 128 ESP / OSPFまたはAH / OSPF守ります
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.
ESP /ルール3と5で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にインストールする必要があります。これらのルールは、代わりに、すべてのインターフェイスに設置してもよいです。これらのルールは、すべてのインターフェイスにインストールされていない場合は、仮想リンクのエンドポイントと同じ送信元と宛先アドレスを持つクリアテキストまたは悪意のあるたOSPFv3パケットのIPv6アドレスは、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].
実装では、管理者が16進形式で暗号化し、認証キーを設定するのではなく、ASCII文字（文字、数字、等）のサブセットにそれを制限することを可能にしなければなりません。 [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:
暗号認証と認証なしまたは単純なパスワード認証と他のと1 - OSPFセキュリティの脆弱性分析[I2]は2つのシナリオでOSPFの脆弱性を識別します。本明細書に記載された解決策は、次の例外を除いて暗号化認証とシナリオのために識別されたすべての脆弱性に対する保護を提供します。
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 / 3DESのための既知の弱いキーが少なくとも存在する）弱い可能性があります。
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]モイ、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[N3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[N3]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[N4]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[N5]ケント、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]イーストレイク3日、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N7]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[I1]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress.
[I2]ジョーンズ、E.およびO. Moigne、 "OSPFセキュリティの脆弱性分析"、進行中の作業。
[I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress.
【I3] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、ProgressのWork。
[I4] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[I4]リーチ、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.
作者はこのメモに便利な情報や批評を提供するためのマーク・ソルソナ、ヤンネPeltonenの、ジョン・クルーズ、Dhavalシャー、アブヘイロイ、ポール・ウェルズ、Vishwas Manral、そしてサム・ハートマンに心からの感謝を拡張したいと思います。著者は、多くの編集上の変更のための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
ムケシュ・グプタTropos Networksの94085の555デルレイアベニューサニーベール、
Phone: 408-331-6889 EMail: mukesh.gupta@tropos.com
電話：408-331-6889 Eメール：mukesh.gupta@tropos.com
Nagavenkata Suresh Melam Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Nagvenktaスレシュメラムジュニパーネットワークスの1194年ではありません。 94089のマチルダアベニューサニーベール、
Phone: 408-505-4392 EMail: nmelam@juniper.net
電話：408-505-4392 Eメール：nmelam@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。