[要約] RFC 6506は、OSPFv3における認証トレーラーのサポートに関する仕様です。このRFCの目的は、OSPFv3パケットの認証を強化し、ネットワークのセキュリティを向上させることです。
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 6506 Alcatel-Lucent
Category: Standards Track V. Manral
ISSN: 2070-1721 Hewlett Packard
A. Lindem
Ericsson
February 2012
Supporting Authentication Trailer for OSPFv3
OSPFV3の認証トレーラーのサポート
Abstract
概要
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication.
現在、IPv6のOSPF（OSPFV3）は、プロトコルパケットを認証するための唯一のメカニズムとしてIPSECを使用しています。この動作は、他のルーティングプロトコル（OSPFV2、中間システムから中間システム（IS-IS）、RIP、およびルーティング情報プロトコル次世代（RIPNG））に存在する認証メカニズムとは異なります。一部の環境では、IPSECを構成および保守が困難であるため、使用できないことがわかっています。このドキュメントは、OSPFV3プロトコルパケットを認証するための代替メカニズムを定義して、OSPFV3が認証のためにIPSECだけに依存するだけではありません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6506.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6506で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
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.
信頼の法的規定のセクション4.Eで説明されているように、簡略化されたBSDライセンステキストを含め、簡素化されたBSDライセンスに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements ...............................................3
2. Proposed Solution ...............................................4
2.1. AT-Bit in Options Field ....................................4
2.2. Basic Operation ............................................5
2.3. IPv6 Source Address Protection .............................5
3. OSPFv3 Security Association .....................................6
4. Authentication Procedure ........................................8
4.1. Authentication Trailer .....................................8
4.1.1. Sequence Number Wrap ...............................10
4.2. OSPFv3 Header Checksum ....................................10
4.3. Cryptographic Authentication Procedure ....................10
4.4. Cross-Protocol Attack Mitigation ..........................11
4.5. Cryptographic Aspects .....................................11
4.6. Message Verification ......................................13
5. Migration and Backward Compatibility ...........................15
6. Security Considerations ........................................15
7. IANA Considerations ............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Appendix A. Acknowledgments ......................................19
Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF for IPv6 (OSPFv3) [RFC5340] does not include the AuType and Authentication fields in its headers for authenticating protocol packets. Instead, OSPFv3 relies on the IPsec protocols Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] to provide integrity, authentication, and/or confidentiality.
Open Shortest Path First Version 2（OSPFV2）[RFC2328]とは異なり、IPv6（OSPFV3）[RFC5340]のOSPFには、プロトコルパケットを認証するためのヘッダーに自己型と認証フィールドは含まれません。代わりに、OSPFV3はIPSECプロトコル認証ヘッダー（AH）[RFC4302]に依存し、セキュリティペイロード（ESP）[RFC4303]をカプセル化して、整合性、認証、および/または機密性を提供します。
[RFC4552] describes how IPv6 AH and ESP extension headers can be used to provide authentication and/or confidentiality to OSPFv3.
[RFC4552]は、IPv6 AHおよびESP拡張ヘッダーを使用して、OSPFV3に認証および/または機密性を提供する方法を説明しています。
However, there are some environments, e.g., Mobile Ad Hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used.
ただし、IPSECの構成と保守が困難であるモバイルアドホックネットワーク（MANETS）など、いくつかの環境があり、このメカニズムを使用できません。
[RFC4552] discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The primary problem is the lack of a suitable key management mechanism, as OSPFv3 adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the system administrator to use manually configured security associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services.
[RFC4552]は、インターネットキーエクスチェンジバージョン2（IKEV2）[RFC5996]などの自動化されたキー管理プロトコルではなく、手動で構成されたキーを使用する背後にある理由について、長々と説明しています。主な問題は、OSPFV3の隣接が1対多くのベースで形成され、ほとんどの重要な管理メカニズムが1対1の通信モデル向けに設計されているため、適切な主要な管理メカニズムの欠如です。これにより、システム管理者は手動で構成されたセキュリティ協会（SAS）と暗号化キーを使用して、認証を提供し、必要に応じて機密性サービスを提供します。
Regarding replay protection, [RFC4552] states that:
リプレイ保護に関して、[RFC4552]は次のように述べています。
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.
現在の標準を使用して手動キーを使用しながら完全なリプレイ保護を提供することはできないため、提案されたソリューションはリプレイ攻撃に対する保護を提供しません。
Since there is no replay protection provided there are a number of vulnerabilities in OSPFv3 that have been discussed in [RFC6039].
リプレイ保護がないため、[RFC6039]で議論されているOSPFV3には多くの脆弱性があります。
Since there is no deterministic way to differentiate between encrypted and unencrypted ESP packets by simply examining the packet, it could be difficult for some implementations to prioritize certain OSPFv3 packet types, e.g., Hello packets, over the other types.
パケットを調べるだけで暗号化されたESPパケットと非暗号化されていないESPパケットを区別する決定的な方法はないため、一部の実装では、他のタイプよりも特定のOSPFV3パケットタイプ、たとえばハローパケットタイプを優先することは困難です。
This document defines a new mechanism that works similarly to OSPFv2 [RFC5709] to provide authentication to the OSPFv3 packets and attempts to solve the problems related to replay protection and deterministically disambiguating different OSPFv3 packets as described above.
このドキュメントでは、OSPFV2 [RFC5709]と同様に機能する新しいメカニズムを定義し、OSPFV3パケットに認証を提供し、上記のように異なるOSPFV3パケットを決定的に分解し、決定論的に分解した問題を解決しようとします。
This document adds support for the Secure Hash Algorithms (SHAs) defined in the US NIST Secure Hash Standard (SHS), which is specified by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used.
このドキュメントは、NIST FIPS 180-3で指定されているUS NIST Secure Hash標準（SHS）で定義されている安全なハッシュアルゴリズム（SHA）のサポートを追加します。[FIPS-180-3]には、SHA-1、SHA-224、SHA-256、SHA-384、およびSHA-512が含まれます。NIST FIPS 198-1 [FIPS-198-1]で定義されたハッシュメッセージ認証コード（HMAC）認証モードが使用されます。
It is believed that HMAC as defined in [RFC2104] is mathematically identical to [FIPS-198-1]; it is also believed that algorithms in [RFC6234] are mathematically identical to [FIPS-198-1].
[RFC2104]で定義されているHMACは、[FIPS-198-1]と数学的に同一であると考えられています。また、[RFC6234]のアルゴリズムは[FIPS-198-1]と数学的に同一であると考えられています。
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]で説明されているように解釈されます。
To perform non-IPsec Cryptographic Authentication, OSPFv3 routers append a special data block, henceforth referred to as the Authentication Trailer, to the end of the OSPFv3 packets. The length of the Authentication Trailer is not included in the length of the OSPFv3 packet but is included in the IPv6 payload length, as shown in Figure 1.
非IPSEC暗号認証を実行するために、OSPFV3ルーターは、OSPFV3パケットの最後まで、認証トレーラーと呼ばれる特別なデータブロックを追加します。認証トレーラーの長さは、OSPFV3パケットの長さに含まれていませんが、図1に示すように、IPv6ペイロード長に含まれています。
+---------------------+ -- -- +----------------------+
| IPv6 Payload Length | ^ ^ | IPv6 Payload Length |
| PL = OL + LL | | | | PL = OL + LL + AL |
| | v v | |
+---------------------+ -- -- +----------------------+
| OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL |
| | | OSPFv3 | | |
|.....................| | Packet | |......................|
| | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | |
+---------------------+ -- -- +----------------------+
| | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS |
| LLS Block Len = LL | | Block | | LLS Block Len = LL |
| | v Length v | |
+---------------------+ -- -- +----------------------+
^ | |
AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + |
v | Digest Length |
-- +----------------------+
Figure 1: Authentication Trailer in OSPFv3
図1：OSPFV3の認証トレーラー
The presence of the Link-Local Signaling (LLS) [RFC5613] block is determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 Hello and Database Description packets. If present, the LLS data block is included along with the OSPFv3 packet in the Cryptographic Authentication computation.
Link-Local Signaling（LLS）[RFC5613]ブロックの存在は、OSPFV3 HelloおよびDatabase説明パケットのOSPFV3オプションフィールドのLビット設定によって決定されます。存在する場合、LLSデータブロックは、暗号化認証計算にOSPFV3パケットとともに含まれています。
A new AT-bit (AT stands for Authentication Trailer) is introduced into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all the packets on this link will include an Authentication Trailer. For OSPFv3 Hello and Database Description packets, the AT-bit indicates
新しいATビット（認証トレーラーのスタンド）がOSPFV3オプションフィールドに導入されます。OSPFV3ルーターは、OSPFV3 HelloおよびDatabase説明パケットにアットビットを設定して、このリンク上のすべてのパケットに認証トレーラーが含まれることを示す必要があります。OSPFV3 Hello and Database説明パケットの場合、アットビットは
the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database Description setting is preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types that don't include an OSPFv3 Options field will use the setting from the neighbor data structure to determine whether or not the AT is expected.
ATは存在します。他のOSPFV3パケットタイプの場合、OSPFV3 Hello/Database説明のOSPFV3 AT-BIT設定は、OSPFV3隣接データ構造に保存されています。OSPFV3オプションフィールドが含まれないOSPFV3パケットタイプは、隣接データ構造の設定を使用して、ATが予想されるかどうかを判断します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
Figure 2: OSPFv3 Options Field
図2：OSPFV3オプションフィールド
The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 Hello and Database Description packets that contain an Authentication Trailer.
上の図に示すように、ATビットは、認証トレーラーを含むすべてのOSPFV3 Helloおよびデータベース説明パケットに設定する必要があります。
The procedure followed for computing the Authentication Trailer is much the same as described in [RFC5709] and [RFC2328]. One difference is that the LLS data block, if present, is included in the Cryptographic Authentication computation.
認証トレーラーを計算するための手順は、[RFC5709]および[RFC2328]で説明されているものとほぼ同じです。違いの1つは、LLSデータブロックが存在する場合、暗号化認証計算に含まれていることです。
The way the authentication data is carried in the Authentication Trailer is very similar to how it is done in case of [RFC2328]. The only difference between the OSPFv2 Authentication Trailer and the OSPFv3 Authentication Trailer is that information in addition to the message digest is included. The additional information in the OSPFv3 Authentication Trailer is included in the message digest computation and is therefore protected by OSPFv3 Cryptographic Authentication as described herein.
認証データが認証トレーラーで実施される方法は、[RFC2328]の場合に行われる方法と非常に似ています。OSPFV2認証トレーラーとOSPFV3認証トレーラーの唯一の違いは、メッセージダイジェストに加えて情報が含まれていることです。OSPFV3認証トレーラーの追加情報は、Message Digest計算に含まれるため、本明細書に記載されているOSPFV3暗号認証によって保護されています。
Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used.
OSPFV2暗号認証[RFC2328]と一致して、この仕様で説明されているOSPFV3認証メカニズムを使用すると、OSPFV3ヘッダーチェックサムの計算と検証の両方が省略されます。
While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, the IPv6 source address is learned from OSPFv3 Hello packets and copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is susceptible to Man-in-the-Middle attacks where the IPv6 source address is modified. To thwart such attacks, the IPv6 source address will be included in the message digest calculation and protected by
OSPFV3は常にルーターIDを使用してOSPFV3の近隣を識別しますが、IPv6ソースアドレスはOSPFV3 helloパケットから学習され、隣接データ構造[RFC5340]にコピーされます。したがって、OSPFV3は、IPv6ソースアドレスが変更されている中間攻撃の影響を受けやすいです。このような攻撃を阻止するために、IPv6ソースアドレスはメッセージダイジェスト計算に含まれ、
OSPFv3 authentication. Refer to Section 4.5 for details. This is different than the procedure specified in [RFC5709] but consistent with [MANUAL-KEY].
OSPFV3認証。詳細については、セクション4.5を参照してください。これは、[RFC5709]で指定されている手順とは異なりますが、[Manual-Key]と一致しています。
An OSPFv3 Security Association (SA) contains a set of parameters shared between any two legitimate OSPFv3 speakers.
OSPFV3セキュリティ協会（SA）には、2つの正当なOSPFV3スピーカー間で共有される一連のパラメーターが含まれています。
Parameters associated with an OSPFv3 SA are as follows:
OSPFV3 SAに関連付けられたパラメーターは次のとおりです。
o Security Association Identifier (SA ID)
o セキュリティ協会識別子（SA ID）
This is a 16-bit unsigned integer used to uniquely identify an OSPFv3 SA, as manually configured by the network operator.
これは、ネットワークオペレーターによって手動で構成されているように、OSPFV3 SAを一意に識別するために使用される16ビットの署名整数です。
The receiver determines the active SA by looking at the SA ID field in the incoming protocol packet.
受信機は、着信プロトコルパケットのSA IDフィールドを調べることにより、アクティブSAを決定します。
The sender, based on the active configuration, selects an SA to use and puts the correct Key ID value associated with the SA in the OSPFv3 protocol packet. If multiple valid and active OSPFv3 SAs exist for a given interface, the sender may use any of those SAs to protect the packet.
送信者は、アクティブな構成に基づいて、使用するSAを選択し、OSPFV3プロトコルパケットのSAに関連付けられた正しいキーID値を配置します。特定のインターフェイスに複数の有効でアクティブなOSPFV3 SASが存在する場合、送信者はこれらのSAのいずれかを使用してパケットを保護することができます。
Using SA IDs makes changing keys while maintaining protocol operation convenient. Each SA ID specifies two independent parts, the authentication algorithm and the Authentication Key, as explained below.
SA IDを使用すると、プロトコル操作を便利に維持しながら、キーを変更することができます。各SA IDは、以下で説明するように、認証アルゴリズムと認証キーの2つの独立した部分を指定します。
Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
通常、実装により、ネットワークオペレーターはキーチェーン内のキーのセットを構成することができ、チェーン内の各キーは固定寿命があります。これらのメカニズムの実際の動作は、このドキュメントの範囲外です。
Note that each SA ID can indicate a key with a different authentication algorithm. This allows the introduction of new authentication mechanisms without disrupting existing OSPFv3 adjacencies.
各SA IDは、異なる認証アルゴリズムを持つキーを示すことができることに注意してください。これにより、既存のOSPFV3の隣接を破壊することなく、新しい認証メカニズムを導入できます。
o Authentication Algorithm
o 認証アルゴリズム
This signifies the authentication algorithm to be used with this OSPFv3 SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information.
これは、このOSPFV3 SAで使用される認証アルゴリズムを意味します。この情報は、ワイヤーの上に明確なテキストに送信されることはありません。この情報はワイヤーに送信されないため、実装者はこの情報の実装固有の表現を選択します。
Currently, the following algorithms are supported:
現在、次のアルゴリズムがサポートされています。
* HMAC-SHA-1,
* hmac-sha-1、
* HMAC-SHA-256,
* HMAC-SHA-256、
* HMAC-SHA-384, and
* HMAC-SHA-384、および
* HMAC-SHA-512.
* HMAC-SHA-512。
o Authentication Key
o 認証キー
This value denotes the Cryptographic Authentication Key associated with this OSPFv3 SA. The length of this key is variable and depends upon the authentication algorithm specified by the OSPFv3 SA.
この値は、このOSPFV3 SAに関連付けられた暗号化認証キーを示します。このキーの長さは可変であり、OSPFV3 SAで指定された認証アルゴリズムに依存します。
o KeyStartAccept
o keystartaccept
The time that this OSPFv3 router will accept packets that have been created with this OSPFv3 SA.
このOSPFV3ルーターがこのOSPFV3 SAで作成されたパケットを受け入れる時間。
o KeyStartGenerate
o KeyStartGenerate
The time that this OSPFv3 router will begin using this OSPFv3 SA for OSPFv3 packet generation.
このOSPFV3ルーターがOSPFV3パケット生成にこのOSPFV3 SAの使用を開始する時間。
o KeyStopGenerate
o keystopgenerate
The time that this OSPFv3 router will stop using this OSPFv3 SA for OSPFv3 packet generation.
このOSPFV3ルーターがOSPFV3パケット生成にこのOSPFV3 SAの使用を停止する時間。
o KeyStopAccept
o keystopaccept
The time that this OSPFv3 router will stop accepting packets generated with this OSPFv3 SA.
このOSPFV3ルーターがこのOSPFV3 SAで生成されたパケットの受け入れを停止する時間。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left unspecified, the time will default to 0, and the key will be used immediately. If KeyStopGenerate or KeyStopAccept are left unspecified, the time will default to infinity, and the key's lifetime will be infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
スムーズなキー遷移を達成するために、keystarticceptはkeystartgenerateよりも少なくなり、keystopgenerateはkeystopacceptよりも少ないはずです。KeyStartGenerateまたはKeyStartActecteが不特定のままになっている場合、時間はデフォルトで0になり、キーはすぐに使用されます。keystopgenerateまたはkeystopacceptが不特定のままにされている場合、時間はデフォルトで無限になり、キーの寿命は無限になります。新しいキーが古いキーを置き換える場合、新しいキーのキースタートの時間は、古いキーのキーストップ時刻よりも低くなければなりません。
Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition and not advisable to disrupt routing. Therefore, the router SHOULD send a "last Authentication Key expiration" notification to the network operator and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by the network operator, or a new key is configured.
運用上の問題を避けるために、キーストレージはシステムの再起動、暖かいまたは寒い状態で持続する必要があります。インターフェイスに関連付けられた最後のキーが期限切れになった場合、無知な状態に戻すことは受け入れられず、ルーティングを破壊することは勧められません。したがって、ルーターは「最後の認証キーの有効期限」通知をネットワークオペレーターに送信し、寿命が延長されるまで無限の寿命を持つようにキーを扱う必要があります。
The Authentication Trailer that is appended to the OSPFv3 protocol packet is described below:
OSPFV3プロトコルパケットに追加された認証トレーラーについては、以下に説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Authentication Trailer Format
図3：認証トレーラー形式
The various fields in the Authentication Trailer are:
認証トレーラーのさまざまなフィールドは次のとおりです。
o Authentication Type
o 認証タイプ
16-bit field identifying the type of authentication. The following values are defined in this specification:
16ビットフィールド認証のタイプを識別します。次の値は、この仕様で定義されています。
0 - Reserved. 1 - HMAC Cryptographic Authentication as described herein.
0-予約済み。1 -HMAC暗号化認証は本明細書に記載されています。
o Auth Data Len
o 認証データレン
The length in octets of the Authentication Trailer (AT) including both the 16-octet fixed header and the variable length message digest.
16オクテットの固定ヘッダーと可変長メッセージダイジェストの両方を含む、認証トレーラー（AT）のオクテットの長さ。
o Reserved
o 予約済み
This field is reserved. It SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
このフィールドは予約されています。プロトコルパケットを送信するときに0に設定する必要があり、プロトコルパケットを受信するときは無視する必要があります。
o Security Association Identifier (SA ID)
o セキュリティ協会識別子（SA ID）
16-bit field that maps to the authentication algorithm and the secret key used to create the message digest appended to the OSPFv3 protocol packet.
認証アルゴリズムにマップする16ビットフィールドと、OSPFV3プロトコルパケットに追加されたメッセージの作成に使用されるシークレットキー。
Though the SA ID implicitly implies the algorithm, the HMAC output size should not be used by implementers as an implicit hint because additional algorithms may be defined in the future that have the same output size.
SA IDは暗黙的にアルゴリズムを暗示していますが、HMAC出力サイズは、同じ出力サイズの将来に追加のアルゴリズムが定義される可能性があるため、実装者が暗黙のヒントとして使用すべきではありません。
o Cryptographic Sequence Number
o 暗号化シーケンス番号
64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. Upon reception, the sequence number MUST be greater than the sequence number in the last OSPFv3 packet accepted from the sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is considered a replayed packet and dropped.
64ビットは、リプレイ攻撃を防ぐために使用されるシーケンス番号を厳密に増加させます。64ビットシーケンス番号は、OSPFV3ルーターによって送信されるすべてのOSPFV3パケットに対してインクリメントする必要があります。受信後、シーケンス番号は、送信oSOSPFV3隣接から受け入れられた最後のOSPFV3パケットのシーケンス番号よりも大きくなければなりません。それ以外の場合、OSPFV3パケットは再生されたパケットと見なされ、ドロップされます。
OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). One mechanism for accomplishing this would be to use the high-order 32 bits of the sequence number as a wrap/boot count that is incremented anytime the OSPFv3 router loses its sequence number state. Sequence number wrap is described in Section 4.1.1.
この仕様を実装するOSPFV3ルーターは、利用可能なメカニズムを使用して、OSPFV3ルーターの展開寿命（コールド再起動を含む）のシーケンス番号の厳密に増加するプロパティを保存する必要があります。これを達成するためのメカニズムの1つは、OSPFV3ルーターがシーケンス番号状態を失うたびに、登場するラップ/ブートカウントとして、シーケンス番号の高次ビットを使用することです。シーケンス番号ラップは、セクション4.1.1で説明されています。
o Authentication Data
o 認証データ
Variable data that is carrying the digest for the protocol packet and optional LLS data block.
プロトコルパケットとオプションのLLSデータブロックのダイジェストを運ぶ変数データ。
When incrementing the sequence number for each transmitted OSPFv3 packet, the sequence number should be treated as an unsigned 64-bit value. If the lower-order 32-bit value wraps, the higher-order 32-bit value should be incremented and saved in non-volatile storage. If by some chance the OSPFv3 router is deployed long enough that there is a possibility that the 64-bit sequence number may wrap, all keys, independent of their key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. Once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage.
送信された各OSPFV3パケットのシーケンス番号を増やす場合、シーケンス番号は、署名されていない64ビット値として扱う必要があります。低次の32ビット値をラップする場合、高次の32ビット値を増分して保存して、不揮発性ストレージで保存する必要があります。偶然にも、OSPFV3ルーターが十分に長く展開されている場合、64ビットシーケンス番号が包む可能性がある場合、すべてのキーは、攻撃を再生する可能性を回避するために、すべてのキーをリセットする必要があります。キーが変更されると、高次シーケンス番号を0にリセットし、不揮発性ストレージに保存できます。
Both OSPFv3 header checksum calculation and verification are omitted when the OSPFv3 authentication mechanism described in this specification is used. This implies:
この仕様で説明されているOSPFV3認証メカニズムを使用すると、両方のOSPFV3ヘッダーチェックサムの計算と検証が省略されます。これは次のとおりです。
o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum computation is omitted, and the OSPFv3 header checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest.
o OSPFV3パケットを送信する場合、OSPFV3ヘッダーチェックサム計算は省略され、OSPFV3認証トレーラーメッセージダイジェストの計算の前にOSPFV3ヘッダーチェックサムを0に設定する必要があります。
o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. However, if the OSPFv3 packet does include a non-zero OSPFv3 header checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification.
o OSPFV3認証トレーラーを含む受信OSPFV3パケットの場合、OSPFV3ヘッダーチェックサムの確認を省略する必要があります。ただし、OSPFV3パケットにゼロ以外のOSPFV3ヘッダーチェックサムが含まれている場合、受信機によって変更されず、OSPFV3認証トレーラーメッセージダイジェスト検証に単純に含まれます。
As noted earlier, the SA ID maps to the authentication algorithm and the secret key used to generate and verify the message digest. This specification discusses the computation of OSPFv3 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode.
前述のように、SA IDは認証アルゴリズムにマップされ、秘密キーはメッセージダイジェストを生成および検証するために使用されます。この仕様では、Hashed Message Authentication Code（HMAC）モードでALGORITHMSのNIST SHSファミリーが使用されている場合、OSPFV3暗号化認証データの計算について説明します。
The currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication include:
OSPFV3暗号認証のための現在有効なアルゴリズム（モードを含む）は次のとおりです。
o HMAC-SHA-1,
o hmac-sha-1、
o HMAC-SHA-256,
o HMAC-SHA-256、
o HMAC-SHA-384, and
o HMAC-SHA-384、および
o HMAC-SHA-512.
o HMAC-SHA-512。
Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512.
上記の場合、この仕様の実装には、少なくともHMAC-SHA-256のサポートを含める必要があり、HMAC-SHA-1のサポートを含める必要があり、HMAC-SHA-384およびHMAC-SHA-512のサポートも含めることができます。
Implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm.
この仕様の実装は、hmac-sha-256をデフォルトの認証アルゴリズムとして使用する必要があります。
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key prior to use. Other protocols using Cryptographic Authentication as specified herein MUST similarly append their respective Cryptographic Protocol IDs to their keys in this step. Refer to the IANA Considerations (Section 7).
共通キーを共有するプロトコルのクロスプロトコルリプレイ攻撃を防ぐために、2オクテットのOSPFV3暗号化プロトコルIDは、使用前に認証キーに追加されます。本明細書で指定されているように暗号化認証を使用する他のプロトコルも、このステップでそれぞれの暗号化プロトコルIDをキーに追加する必要があります。IANAの考慮事項（セクション7）を参照してください。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198-1], is used:
以下のアルゴリズムの説明では、[FIPS-198-1]と一致する次の命名法が使用されます。
H is the specific hashing algorithm (e.g., SHA-256).
Hは特定のハッシュアルゴリズム（SHA-256など）です。
K is the Authentication Key from the OSPFv3 Security Association.
Kは、OSPFV3セキュリティ協会の認証キーです。
Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet OSPFv3 Cryptographic Protocol ID.
KSは、Appending Authentication Key（k）が2オクテットOSPFV3暗号化プロトコルIDを使用して得られるプロトコル固有の認証キーです。
Ko is the cryptographic key used with the hash algorithm.
KOは、ハッシュアルゴリズムで使用される暗号化キーです。
B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size.
Bは、ビットではなくオクテットで測定されたHのブロックサイズです。Bはハッシュサイズではなく、内部ブロックサイズであることに注意してください。
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
Lはハッシュの長さで、ビットではなくオクテットで測定されます。
XOR is the exclusive-or operation.
Xorは排他的または操作です。
Opad is the hexadecimal value 0x5c repeated B times.
Opadは、六量体の値0x5c繰り返しB回です。
Ipad is the hexadecimal value 0x36 repeated B times.
iPadは、16進価値0x36繰り返しB回です。
Apad is a value that is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets.
APADは、ハッシュ出力またはメッセージダイジェストと同じ長さの値です。最初の16個のオクテットには、IPv6ソースアドレスが含まれ、その後に16進数0x878fe1f3が繰り返された（L-16）/4回が含まれます。これは、ハッシュ出力が常に少なくとも16オクテットの長さであることを意味します。
1. Preparation of the Key
1. キーの準備
The OSPFv3 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 and is computed as follows:
OSPFV3暗号化プロトコルIDは、認証キー（k）に追加され、プロトコル固有の認証キー（KS）が生成されます。このアプリケーションでは、KOは常に長さの長さであり、次のように計算されます。
If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to K. 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）が長さの長さの場合、KOはKに等しくなります。プロトコル固有の認証キー（KS）が長さの長さを超える場合、KOはH（ks）に設定されます。プロトコル固有の認証キー（ks）が長さの長さ未満の場合、KOはプロトコル固有の認証キー（ks）の最後にZerosを追加してプロトコル固有の認証キー（ks）に設定されている場合、KoL Octetsの長さです。
2. First-Hash
2. 最初のハッシュ
First, the OSPFv3 packet's Authentication Data field in the Authentication Trailer is filled with the value Apad. This is very similar to the appendage described in [RFC2328], Section D.4.3, Items (6)(a) and (6)(d)).
まず、認証トレーラーのOSPFV3パケットの認証データフィールドには、値APADが入っています。これは、[RFC2328]、セクションD.4.3、項目（6）（a）および（6）（d）に記載されている付属物と非常によく似ています。
Then, a First-Hash, also known as the inner hash, is computed as follows:
次に、内側のハッシュとも呼ばれるファーストハッシュは、次のように計算されます。
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
first-hash = h（ko xor ipad ||（ospfv3 packet））
Implementation Note: The First-Hash above includes the Authentication Trailer, as well as the OSPFv3 packet, as per [RFC2328], Section D.4.3, and, if present, the LLS data block [RFC5613].
実装注：上記の最初のハッシュには、[RFC2328]、セクションD.4.3、および存在する場合、LLSデータブロック[RFC5613]によると、認証トレーラーとOSPFV3パケットが含まれます。
The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. Note that the "(OSPFv3 Packet)" referenced in the First-Hash function above includes both the optional LLS data block and the OSPFv3 Authentication Trailer.
APAD（上記）の定義により、ハッシュ出力と常に同じ長さが保証されます。これはRFC 2328と一致しています。上記のファーストハッシュ関数で参照されている「（OSPFV3パケット）」には、オプションのLLSデータブロックとOSPFV3認証トレーラーの両方が含まれていることに注意してください。
The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; for SHA-384, 48 octets; and for SHA-512, 64 octets.
SHA-1のダイジェスト長は20オクテットです。SHA-256、32オクテットの場合;SHA-384、48オクテットの場合;およびSHA-512、64オクテットの場合。
3. Second-Hash
3. セカンドハッシュ
Then a Second-Hash, also known as the outer hash, is computed as follows:
次に、外側のハッシュとも呼ばれるセカンドハッシュが次のように計算されます。
Second-Hash = H(Ko XOR Opad || First-Hash)
second-hash = h（ko xor opad || Firsth-hash）
4. Result
4. 結果
The resulting Second-Hash becomes the authentication data that is sent in the Authentication Trailer of the OSPFv3 packet. The length of the authentication data is always identical to the message digest size of the specific hash function H that is being used.
結果のセカンドハッシュは、OSPFV3パケットの認証トレーラーで送信される認証データになります。認証データの長さは、使用されている特定のハッシュ関数Hのメッセージダイジェストサイズと常に同一です。
This also means that the use of hash functions with larger output sizes will also increase the size of the OSPFv3 packet as transmitted on the wire.
これはまた、より大きな出力サイズのハッシュ関数を使用すると、ワイヤーに送信されるOSPFV3パケットのサイズも増加することを意味します。
Implementation Note: [RFC2328], Appendix D specifies that the Authentication Trailer is not counted in the OSPF packet's own Length field but is included in the packet's IP Length field. Similar to this, the Authentication Trailer is not included in the OSPFv3 header length but is included in the IPv6 header payload length.
実装注：[RFC2328]、付録Dは、認証トレーラーがOSPFパケットの独自の長さフィールドにカウントされないが、パケットのIP長フィールドに含まれていることを指定しています。これと同様に、認証トレーラーはOSPFV3ヘッダー長に含まれていませんが、IPv6ヘッダーペイロード長に含まれています。
A router would determine that OSPFv3 is using an Authentication trailer by examining the AT-bit in the Options field in the OSPFv3 header for Hello and Database Description packets. The specification in the Hello and Database Description options indicates that other OSPFv3 packets will include the Authentication Trailer.
ルーターは、HelloおよびDatabase説明パケット用のOSPFV3ヘッダーのオプションフィールドのATビットを調べることにより、OSPFV3が認証トレーラーを使用していることを判断します。Helloおよびデータベースの説明オプションの仕様は、他のOSPFV3パケットに認証トレーラーが含まれることを示しています。
The Authentication Trailer (AT) is accessed using the OSPFv3 packet header length to access the data after the OSPFv3 packet and, if an LLS data block [RFC5613] is present, using the LLS data block length to access the data after the LLS data block. The L-bit in the OSPFv3 options in Hello and Database Description packets is examined to determine if an LLS data block is present. If an LLS data block is present (as specified by the L-bit), it is included along with the OSPFv3 Hello or Database Description packet in the cryptographic authentication computation.
認証トレーラー（AT）には、OSPFV3パケットヘッダーの長さを使用してアクセスしてOSPFV3パケットの後にデータにアクセスし、LLSデータブロックの長さを使用してLLSデータブロック長さを使用してLLSデータブロックの後にデータにアクセスする場合、データにアクセスします。。HelloおよびDatabase説明パケットのOSPFV3オプションのLビットを調べて、LLSデータブロックが存在するかどうかを判断します。LLSデータブロックが存在する場合（L-BITで指定されているように）、暗号化認証計算にOSPFV3 HelloまたはDatabase説明パケットとともに含まれています。
Due to the placement of the AT following the LLS data block and the fact that the LLS data block is included in the Cryptographic Authentication computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS data block to access the AT. It is RECOMMENDED that OSPFv3 routers supporting this specification fully support OSPFv3 Link-Local Signaling [RFC5613].
ATがLLSデータブロックに従って配置され、LLSデータブロックが暗号化認証計算に含まれているという事実により、この仕様をサポートするOSPFV3ルーターは、OSPFv3オプションのLビットを調べ、長さを使用することを最小限にサポートする必要があります。LLSデータブロックは、ATにアクセスします。この仕様をサポートするOSPFV3ルーターは、OSPFV3リンクローカルシグナル伝達[RFC5613]を完全にサポートすることをお勧めします。
If usage of the Authentication Trailer (AT), as specified herein, is configured for an OSPFv3 link, OSPFv3 Hello and Database Description packets with the AT-bit clear in the options will be dropped. All OSPFv3 packet types will be dropped if AT is configured for the link and the IPv6 header length is less than the amount necessary to include an Authentication Trailer.
本明細書に指定されているように、認証トレーラー（AT）の使用がOSPFV3リンク用に構成されている場合、OSPFV3 Hello and Database説明パケットは、オプションにATビットをクリアしたパケットがドロップされます。ATがリンク用に構成されており、IPv6ヘッダーの長さが認証トレーラーを含めるために必要な量よりも少ない場合、すべてのOSPFV3パケットタイプがドロップされます。
If the cryptographic sequence number in the AT is less than or equal to the last sequence number successfully received from the neighbor, the OSPFv3 packet MUST be dropped, and an error event SHOULD be logged.
ATの暗号化シーケンス番号が近隣から正常に受信された最後のシーケンス番号以下の場合、OSPFV3パケットをドロップする必要があり、エラーイベントを記録する必要があります。
Authentication-algorithm-dependent processing needs to be performed, using the algorithm specified by the appropriate OSPFv3 SA for the received packet.
受信パケットに適切なOSPFV3 SAによって指定されたアルゴリズムを使用して、認証 - アルゴリズム依存処理を実行する必要があります。
Before an implementation performs any processing, it needs to save the values of the Authentication Data field from the Authentication Trailer appended to the OSPFv3 packet.
実装が処理を実行する前に、OSPFV3パケットに追加された認証トレーラーから認証データフィールドの値を保存する必要があります。
It should then set the Authentication Data field with Apad before the authentication data is computed (as described in Section 4.5). The calculated data is compared with the received authentication data in the Authentication Trailer. If the two do not match, the packet MUST be discarded and an error event SHOULD be logged.
次に、認証データが計算される前に、APADで認証データフィールドを設定する必要があります（セクション4.5で説明されています）。計算されたデータは、認証トレーラーの受信した認証データと比較されます。2つが一致しない場合、パケットを破棄し、エラーイベントを記録する必要があります。
After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for future replay checks.
OSPFV3パケットが正常に認証された後、実装は将来のリプレイチェックのために64ビットの暗号化シーケンス番号を保存する必要があります。
All OSPFv3 routers participating on a link SHOULD be migrated to OSPFv3 Authentication at the same time. As with OSPFv2 authentication, a mismatch in the SA ID, Authentication Type, or message digest will result in failure to form an adjacency. For multi-access links, communities of OSPFv3 routers could be migrated using different Interface Instance IDs. However, at least one router would need to form adjacencies between both the OSPFv3 routers including and not including the Authentication Trailer. This would result in sub-optimal routing as well as added complexity and is only recommended in cases where authentication is desired on the link and migrating all the routers on the link at the same time isn't feasible.
リンクに参加するすべてのOSPFV3ルーターは、同時にOSPFV3認証に移行する必要があります。OSPFV2認証と同様に、SA ID、認証タイプ、またはメッセージダイジェストの不一致により、隣接を形成できなくなります。マルチアクセスリンクの場合、OSPFV3ルーターのコミュニティは、異なるインターフェイスインスタンスIDを使用して移行できます。ただし、少なくとも1つのルーターは、認証トレーラーを含むが含まれていないOSPFV3ルーターの両方の間に隣接を形成する必要があります。これにより、最適なルーティングが発生し、複雑さが追加され、リンクで認証が望まれ、リンク上のすべてのルーターを同時に移行する場合にのみ推奨されます。
In support of uninterrupted deployment, an OSPFv3 router implementing this specification MAY implement a transition mode where it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets. This is provided as a transition aid for networks in the process of migrating to the authentication mechanism described in this specification.
途切れない展開をサポートして、この仕様を実装するOSPFV3ルーターは、送信パケットに認証トレーラーを含むが、受信したパケットでこの情報を確認しない遷移モードを実装する場合があります。これは、この仕様で説明されている認証メカニズムに移行するプロセスにおけるネットワークの遷移支援として提供されます。
The document proposes extensions to OSPFv3 that would make it more secure than [RFC5340]. It does not provide confidentiality as a routing protocol contains information that does not need to be kept secret. It does, however, provide means to authenticate the sender of the packets that are of interest. It addresses all the security issues that have been identified in [RFC6039].
このドキュメントは、[RFC5340]よりも安全になるOSPFV3への拡張を提案しています。ルーティングプロトコルには秘密を維持する必要のない情報が含まれているため、機密性は提供されません。ただし、関心のあるパケットの送信者を認証する手段を提供します。[RFC6039]で特定されたすべてのセキュリティ問題に対処します。
It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet but is rather being used to confirm that the packet has indeed been issued by a router that has access to the Authentication Key.
このドキュメントで説明されている認証方法は、パケットの特定のオリジネーターを認証するために使用されるのではなく、パケットが実際に認証キーにアクセスできるルーターによって発行されていることを確認するために使用されていることに注意してください。
Deployments SHOULD use sufficiently long and random values for the Authentication Key so that guessing and other cryptographic attacks on the key are not feasible in their environments. Furthermore, it is RECOMMENDED that Authentication Keys incorporate at least 128 pseudo-random bits to minimize the risk of such attacks. In support of these recommendations, management systems SHOULD support hexadecimal input of Authentication Keys.
展開は、認証キーに十分に長いランダムな値とランダムな値を使用して、キーに対する推測やその他の暗号攻撃が環境では実行不可能であるようにする必要があります。さらに、認証キーに少なくとも128個の擬似ランダムビットを組み込んで、そのような攻撃のリスクを最小限に抑えることをお勧めします。これらの推奨事項をサポートするために、管理システムは認証キーの16進入力をサポートする必要があります。
The mechanism described herein is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the effort required for an adversary to successfully attack the OSPFv3 protocol while not causing undue implementation, deployment, or operational complexity.
ここで説明するメカニズムは完璧ではなく、完璧である必要はありません。代わりに、このメカニズムは、敵が過度の実装、展開、または運用上の複雑さを引き起こさず、OSPFV3プロトコルをうまく攻撃するために必要な努力の大幅な増加を表しています。
Refer to [RFC4552] for additional considerations on manual keying.
手動キーイングに関する追加の考慮事項については、[RFC4552]を参照してください。
IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry as described in Section 2.1.
IANAは、セクション2.1で説明されているように、「OSPFV3オプション（24ビット）」レジストリにATビット（0x000400）を割り当てました。
IANA has created the "OSPFv3 Authentication Trailer Options" registry. This new registry initially includes the "OSPFv3 Authentication Types" registry, which defines valid values for the Authentication Type field in the OSPFv3 Authentication Trailer. The registration procedure is Standards Action.
IANAは、「OSPFV3認証トレーラーオプション」レジストリを作成しました。この新しいレジストリには、最初に「OSPFV3認証タイプ」レジストリが含まれます。これは、OSPFV3認証トレーラーの認証タイプフィールドの有効な値を定義します。登録手順は標準訴訟です。
+-------------+-----------------------------------+
| Value/Range | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
OSPFv3 Authentication Types
OSPFV3認証タイプ
Finally, IANA has created the "Keying and Authentication for Routing Protocols (KARP) Parameters" category. This new category initially includes the "Authentication Cryptographic Protocol ID" registry, which provides unique protocol-specific values for cryptographic applications, such as but not limited to, prevention of cross-protocol replay attacks. Values can be assigned for both native IPv4/IPv6 protocols and UDP/TCP protocols. The registration procedure is Standards Action.
最後に、IANAは「ルーティングプロトコル（KARP）パラメーターのキーと認証」を作成しました。この新しいカテゴリには、当初、「認証暗号化プロトコルID」レジストリが含まれます。これは、クロスプロトコルリプレイ攻撃の防止など、制限されていないなどの暗号化アプリケーションに一意のプロトコル固有の値を提供します。ネイティブIPv4/IPv6プロトコルとUDP/TCPプロトコルの両方に値を割り当てることができます。登録手順は標準訴訟です。
+-------------+----------------------+
| Value/Range | Designation |
+-------------+----------------------+
| 0 | Reserved |
| | |
| 1 | OSPFv3 |
| | |
| 2-65535 | Unassigned |
+-------------+----------------------+
Cryptographic Protocol ID
暗号化プロトコルID
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「Ospfv2 HMAC-SHA暗号認証」、RFC 5709、2009年10月。
[FIPS-180-3] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS Pub 180-3、2008年10月。
[FIPS-198-1] US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, July 2008.
[FIPS-198-1]米国国立標準技術研究所、「キードハッシュメッセージ認証コード（HMAC）」、FIPS Pub 198、2008年7月。
[MANUAL-KEY] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, October 2011.
[Manual-Key] Bhatia、M.、Hartman、S.、Zhang、D。、およびA. Lindem、「Manual Key Managementを使用する場合のOSPFV2のセキュリティ拡張」、2011年10月、進行中の作業。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5613] Zinin、A.、Roy、A.、Nguyen、L.、Friedman、B。、およびD. Yeung、「OSPF Link-Local Signaling」、RFC 5613、2009年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「ルーティングプロトコルの既存の暗号保護方法の問題」、RFC 6039、2010年10月。
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234] Eastlake、D。およびT. Hansen、「米国の安全なハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、2011年5月。
First and foremost, thanks to the authors of RFC 5709 [RFC5709], from which this work was derived.
何よりもまず、RFC 5709 [RFC5709]の著者のおかげで、この作業が導き出されました。
Thanks to Sam Hartman for discussions on replay mitigation and the use of a 64-bit strictly increasing sequence number. Also, thanks to Sam for comments during IETF last call with respect to the OSPFv3 SA and sharing of key between protocols.
リプレイの緩和と64ビットの厳密に増加したシーケンス番号の使用に関する議論をしてくれたSam Hartmanに感謝します。また、OSPFV3 SAおよびプロトコル間のキーの共有に関するIETFの最後の呼び出し中のコメントについてSAMに感謝します。
Thanks to Michael Barnes for numerous comments and strong input on the coverage of LLS by the Authentication Trailer (AT).
マイケルバーンズに、認証トレーラーによるLLSのカバレッジに関する多くのコメントと強力な入力に感謝します（AT）。
Thanks to Rajesh Shetty for numerous comments, including the suggestion to include an Authentication Type field in the Authentication Trailer for extendibility.
Rajesh Shettyは、拡張性のための認証トレーラーに認証タイプフィールドを含めるという提案を含む、多数のコメントをしてくれたことに感謝します。
Thanks to Uma Chunduri for suggesting that we may want to protect the IPv6 source address even though OSPFv3 uses the Router ID for neighbor identification.
OSPFV3がネイバーの識別にルーターIDを使用しているにもかかわらず、IPv6ソースアドレスを保護することを提案してくれたUma Chunduriに感謝します。
Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan Ratliff, and Glen Kent for their support and review comments.
Srinivasan KL、Shraddha H、Alan Davey、Russ White、Stan Ratliff、およびGlen Kentのサポートとレビューのコメントに感謝します。
Thanks to Alia Atlas for comments made under the purview of the Routing Directorate review.
ルーティングディレクターレビューの範囲内で行われたコメントについては、Alia Atlasに感謝します。
Thanks to Stephen Farrell for comments during the IESG review. Stephen was also involved in the discussion of cross-protocol attacks.
IESGレビュー中にコメントをしてくれたStephen Farrellに感謝します。スティーブンはまた、クロスプロトコル攻撃の議論に関与していました。
Authors' Addresses
著者のアドレス
Manav Bhatia Alcatel-Lucent Bangalore India
Manav Bhatia Alcatel-Lucent Bangalore India
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral Hewlett Packard USA
Vishwas Manral Hewlett Packard USA
EMail: vishwas.manral@hp.com
Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519 USA
ACEE LINDEM ERICSSON 102 CARRIC BEND COURT CARY、NC 27519 USA
EMail: acee.lindem@ericsson.com