[要約] RFC 7166は、OSPFv3における認証トレーラーのサポートに関する仕様です。このRFCの目的は、OSPFv3パケットの認証を強化し、ネットワークのセキュリティを向上させることです。
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7166 Alcatel-Lucent
Obsoletes: 6506 V. Manral
Category: Standards Track Ionos Corp.
ISSN: 2070-1721 A. Lindem
Ericsson
March 2014
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 depend only upon IPsec for authentication.
現在、OSPF for IPv6（OSPFv3）は、プロトコルパケットを認証するための唯一のメカニズムとしてIPsecを使用しています。この動作は、他のルーティングプロトコル（OSPFv2、中間システム間（IS-IS）、RIP、およびルーティング情報プロトコル次世代（RIPng））に存在する認証メカニズムとは異なります。一部の環境では、IPsecの構成と保守が難しく、使用できないことが判明しています。このドキュメントでは、OSPFv3が認証のためにIPsecだけに依存しないように、OSPFv3プロトコルパケットを認証する代替メカニズムを定義しています。
The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.
OSPFv3 Authentication Trailerは元々RFC 6506で定義されていました。このドキュメントは、手順の明確化と改良を含む改訂された定義を提供することにより、RFC 6506を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7166.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7166で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements ...............................................4
1.2. Summary of Changes from RFC 6506 ...........................4
2. Proposed Solution ...............................................5
2.1. AT-Bit in Options Field ....................................5
2.2. Basic Operation ............................................6
2.3. IPv6 Source Address Protection .............................6
3. OSPFv3 Security Association .....................................7
4. Authentication Procedure ........................................9
4.1. Authentication Trailer .....................................9
4.1.1. Sequence Number Wrap ...............................11
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
4.3. Cryptographic Authentication Procedure ....................12
4.4. Cross-Protocol Attack Mitigation ..........................12
4.5. Cryptographic Aspects .....................................12
4.6. Message Verification ......................................15
5. Migration and Backward Compatibility ...........................16
6. Security Considerations ........................................17
7. IANA Considerations ............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................19
Appendix A. Acknowledgments .......................................22
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バージョン2（OSPFv2）[RFC2328]とは異なり、OSPF for IPv6（OSPFv3）[RFC5340]は、プロトコルパケットを認証するためのヘッダーにAuTypeおよびAuthenticationフィールドを含みません。代わりに、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; this mechanism cannot be used in such environments.
ただし、モバイルアドホックネットワーク（MANET）などの一部の環境では、IPsecの構成と保守が困難です。このメカニズムは、このような環境では使用できません。
[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の通信モデル用に設計されているため、主な問題は適切なキー管理メカニズムの欠如です。これにより、システム管理者は手動で構成されたセキュリティアソシエーション（SA）と暗号化キーを使用して、認証と、必要に応じて機密サービスを提供する必要があります。
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には多くの脆弱性があります。
While techniques exist to identify ESP-NULL packets [RFC5879], these techniques are generally not implemented in the data planes of OSPFv3 routers. This makes it very difficult for implementations to examine OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g., Hello packets, over the other types.
ESP-NULLパケットを識別する手法は存在しますが[RFC5879]、これらの手法は通常、OSPFv3ルーターのデータプレーンには実装されていません。これにより、実装でOSPFv3パケットを調べ、特定のOSPFv3パケットタイプ（Helloパケットなど）を他のタイプよりも優先させることが非常に難しくなります。
This document defines a mechanism that works similarly to OSPFv2 [RFC5709] to provide authentication to OSPFv3 packets and solves 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-4. [FIPS-180-4] 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-4で指定されているUS NISTセキュアハッシュ標準（SHS）で定義されているセキュアハッシュアルゴリズム（SHA）のサポートを追加します。 [FIPS-180-4]には、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512が含まれています。 NIST FIPS 198-1 [FIPS-198-1]で定義されているハッシュメッセージ認証コード（HMAC）認証モードが使用されます。
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]で説明されているように解釈されます。
This document includes the following changes from RFC 6506 [RFC6506]:
このドキュメントには、RFC 6506 [RFC6506]からの次の変更が含まれています。
1. Sections 2.2 and 4.2 explicitly state that the Link-Local Signaling (LLS) block checksum calculation is omitted when an OSPFv3 Authentication Trailer is used for OSPFv3 authentication. The LLS data block is included in the authentication digest calculation, and computation of a checksum is unnecessary. Clarification of this issue was documented in an erratum.
1. セクション2.2と4.2では、OSPFv3認証にOSPFv3認証トレーラーが使用されている場合、Link-Local Signaling（LLS）ブロックチェックサム計算が省略されることを明示的に述べています。 LLSデータブロックは認証ダイジェストの計算に含まれ、チェックサムの計算は不要です。この問題の説明は正誤表に記載されていました。
2. Section 3 previously recommended usage of an expired key for transmitted OSPFv3 packets when no valid keys existed. This statement has been removed.
2. セクション3では、有効なキーが存在しない場合に、送信されたOSPFv3パケットの期限切れのキーの使用を以前推奨していました。このステートメントは削除されました。
3. Section 4.5 includes a correction to the key preparation to use the Protocol-Specific Authentication Key (Ks) rather than the Authentication Key (K) as the initial key (Ko). This problem was also documented in an erratum.
3. セクション4.5には、初期キー（Ko）として認証キー（K）ではなく、プロトコル固有の認証キー（Ks）を使用するためのキー準備の修正が含まれています。この問題は、エラッタにも記載されています。
4. Section 4.5 also includes a discussion of the choice of key length to be the hash length (L) rather than the block size (B). The discussion of this choice was included to clarify an issue raised in a rejected erratum.
4. セクション4.5には、ブロック長（B）ではなくハッシュ長（L）となるキー長の選択に関する説明も含まれています。この選択の説明は、拒否されたエラッタで発生した問題を明確にするために含まれていました。
5. Sections 4.1 and 4.6 indicate that sequence number checking is dependent on OSPFv3 packet type in order to account for packet prioritization as specified in [RFC4222]. This was an omission from RFC 6506 [RFC6506].
5. セクション4.1と4.6は、[RFC4222]で指定されているパケットの優先順位付けを説明するために、シーケンス番号チェックがOSPFv3パケットタイプに依存していることを示しています。これはRFC 6506 [RFC6506]からの脱落でした。
6. Section 4.6 explicitly states that OSPFv3 packets with a nonexistent or expired Security Association (SA) will be dropped.
6. セクション4.6には、存在しない、または期限切れのセキュリティアソシエーション（SA）を持つOSPFv3パケットがドロップされることが明記されています。
7. Section 5 includes guidance on the precise actions required for an OSPFv3 router providing a backward-compatible transition mode.
7. セクション5には、後方互換の移行モードを提供するOSPFv3ルーターに必要な正確なアクションに関するガイダンスが含まれています。
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パケットの最後に追加します。図1に示すように、認証トレーラーの長さはOSPFv3パケットの長さに含まれていませんが、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 |
| LL = LLS Data | | Block | | LL = LLS Data |
| Block Length | v Length v | Block Length |
+---------------------+ -- -- +----------------------+
^ | |
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 DescriptionパケットのOSPFv3 OptionsフィールドのLビット設定によって決まります。 LLSデータブロックが存在する場合、暗号化認証の計算にOSPFv3パケットとともに含まれます。
RFC 6506 introduced the AT-bit ("AT" stands for "Authentication Trailer") 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 that 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.
RFC 6506では、OSPFv3オプションフィールドにATビット（「AT」は「Authentication Trailer」の略）が導入されました。 OSPFv3ルーターは、このリンク上のすべてのパケットに認証トレーラーが含まれることを示すために、OSPFv3 Helloおよびデータベース記述パケットのATビットを設定する必要があります。 OSPFv3 HelloおよびDatabase Descriptionパケットの場合、ATビットはATが存在することを示します。その他のOSPFv3パケットタイプの場合、OSPFv3 Hello / Database Description設定のOSPFv3 ATビット設定は、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およびDatabase Descriptionパケットで設定する必要があります。
The procedure followed for computing the Authentication Trailer is much the same as those 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 the 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認証トレーラーの追加情報はメッセージダイジェストの計算に含まれるため、ここで説明するように、OSPFv3暗号化認証によって保護されます。
Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and Link-Local Signaling Cryptographic Authentication [RFC5613], checksum calculation and verification are omitted for both the OSPFv3 header checksum and the LLS data block when the OSPFv3 authentication mechanism described in this specification is used.
OSPFv2暗号化認証[RFC2328]およびリンクローカルシグナリング暗号化認証[RFC5613]と一致して、この仕様で説明されているOSPFv3認証メカニズムが使用される場合、OSPFv3ヘッダーチェックサムとLLSデータブロックの両方のチェックサム計算と検証が省略されます。
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 authentication. Refer to Section 4.5 for details. This is different than the procedure specified in [RFC5709] but consistent with [MANUAL-KEY].
OSPFv3は常にルーターIDを使用してOSPFv3ネイバーを識別しますが、IPv6送信元アドレスはOSPFv3 Helloパケットから学習され、ネイバーデータ構造[RFC5340]にコピーされます。したがって、OSPFv3は、IPv6送信元アドレスが変更される中間者攻撃の影響を受けやすくなっています。このような攻撃を阻止するために、IPv6送信元アドレスはメッセージダイジェストの計算に含まれ、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 せくりｔｙ あっそしあちおん いでんちふぃえｒ （さ いＤ）
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を選択し、SAに関連付けられた正しいキーID値をOSPFv3プロトコルパケットに入れます。特定のインターフェイスに複数の有効でアクティブなOSPFv3 SAが存在する場合、送信者はそれらの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-256,
* ＨまＣーしゃー２５６、
* HMAC-SHA-384, and
* HMAC-SHA-384、および
* 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
This value indicates the time that this OSPFv3 router will accept packets that have been created with this OSPFv3 SA.
この値は、このOSPFv3ルーターがこのOSPFv3 SAで作成されたパケットを受け入れる時間を示します。
o KeyStartGenerate
o KeyStartGenerate
This value indicates the time that this OSPFv3 router will begin using this OSPFv3 SA for OSPFv3 packet generation.
この値は、このOSPFv3ルーターがOSPFv3パケットの生成にこのOSPFv3 SAを使用し始める時間を示します。
o KeyStopGenerate
o KeyStopGenerate
This value indicates the time that this OSPFv3 router will stop using this OSPFv3 SA for OSPFv3 packet generation.
この値は、このOSPFv3ルーターがOSPFv3パケットの生成にこのOSPFv3 SAを使用するのを停止する時間を示します。
o KeyStopAccept
o KeyStopAccept
This value indicates 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 is left unspecified, the time will default to 0, and the key will be used immediately. If KeyStopGenerate or KeyStopAccept is left unspecified, the time will default to infinity, and the key's lifetime will be infinite. When a new key replaces an old key, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
スムーズなキーの移行を実現するために、KeyStartAcceptはKeyStartGenerate未満である必要があり、KeyStopGenerateはKeyStopAccept未満である必要があります。 KeyStartGenerateまたはKeyStartAcceptを指定しない場合、時間はデフォルトで0になり、キーはすぐに使用されます。 KeyStopGenerateまたはKeyStopAcceptを指定しない場合、時間はデフォルトで無限大になり、キーの有効期間は無限になります。新しいキーが古いキーを置き換える場合、新しいキーのKeyStartGenerate時間は、古いキーのKeyStopGenerate時間以下でなければなりません。
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, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated.
運用上の問題を回避するために、キーストレージは、システムの再起動（ウォームまたはコールド）を通じて維持する必要があります。インターフェイスに関連付けられた最後のキーの有効期限が切れた場合、ネットワークオペレーターに通知する必要があり（SHOULD）、OSPFv3パケットを認証なしで送信してはなりません（MUST NOT）。
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 as follows:
Authentication Trailerのさまざまなフィールドは次のとおりです。
o Authentication Type
o 認証タイプ
This 16-bit field identifies 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 データを取る
This is the length in octets of the Authentication Trailer (AT), including both the 16-octet fixed header and the variable-length message digest.
これは認証トレーラー（AT）のオクテット単位の長さで、16オクテットの固定ヘッダーと可変長メッセージダイジェストの両方を含みます。
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に設定し、プロトコルパケットを受信する場合は無視する必要があります（SHOULD）。
o Security Association Identifier (SA ID)
o せくりｔｙ あっそしあちおん いでんちふぃえｒ （さ いＤ）
This 16-bit field 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 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 暗号シーケンス番号
This is a 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 accepted OSPFv3 packet of the same OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is considered a replayed packet and dropped. OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
これは、64ビットの厳密に増加するシーケンス番号であり、リプレイアタックから保護するために使用されます。 OSPFv3ルーターから送信されるすべてのOSPFv3パケットに対して、64ビットのシーケンス番号をインクリメントする必要があります。受信時に、シーケンス番号は、送信側OSPFv3ネイバーから同じOSPFv3パケットタイプの最後に受け入れられたOSPFv3パケットのシーケンス番号よりも大きい必要があります。それ以外の場合、OSPFv3パケットは再生されたパケットと見なされ、ドロップされます。 [RFC4222]で推奨されているように優先順位が付けられている場合、異なるタイプの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ルーターがシーケンス番号の状態を失うたびにインクリメントされるラップ/ブートカウントとしてシーケンス番号の上位32ビットを使用することです。シーケンス番号のラップについては、セクション4.1.1で説明します。
o Authentication Data
o 認証データ
This field contains 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 the checksum calculation and verification are omitted for the OSPFv3 header checksum and the LLS data block checksum [RFC5613] when the OSPFv3 authentication mechanism described in this specification is used. This implies the following:
この仕様で説明されているOSPFv3認証メカニズムが使用されている場合、OSPFv3ヘッダーチェックサムとLLSデータブロックチェックサム[RFC5613]では、チェックサムの計算と検証の両方が省略されます。これは次のことを意味します。
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 OSPFv3 packets including an LLS data block to be transmitted, the OSPFv3 LLS data block checksum computation is omitted, and the OSPFv3 LLS data block checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest.
o 送信するLLSデータブロックを含むOSPFv3パケットの場合、OSPFv3 LLSデータブロックチェックサムの計算は省略され、OSPFv3 LLSデータブロックチェックサムは、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 Authentication Trailerを含む受信したOSPFv3パケットの場合、OSPFv3ヘッダーチェックサム検証を省略しなければなりません（MUST）。ただし、OSPFv3パケットにゼロ以外のOSPFv3ヘッダーチェックサムが含まれている場合、それはレシーバーによって変更されず、単にOSPFv3認証トレーラーメッセージダイジェスト検証に含まれます。
o For received OSPFv3 packets including an LLS data block and OSPFv3 Authentication Trailer, LLS data block checksum verification MUST be omitted. However, if the OSPFv3 packet does include an LLS data block with a non-zero checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification.
o LLSデータブロックとOSPFv3認証トレーラーを含む受信したOSPFv3パケットの場合、LLSデータブロックのチェックサム検証を省略しなければなりません（MUST）。ただし、OSPFv3パケットにゼロ以外のチェックサムを持つLLSデータブロックが含まれている場合、それは受信者によって変更されず、単に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は、メッセージダイジェストの生成と検証に使用される認証アルゴリズムと秘密鍵にマップされます。この仕様では、NIST SHSアルゴリズムファミリーのいずれかがハッシュメッセージ認証コード（HMAC）モードで使用される場合のOSPFv3暗号化認証データの計算について説明します。
The currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication include:
OSPFv3暗号化認証に現在有効なアルゴリズム（モードを含む）は次のとおりです。
o HMAC-SHA-1,
o ＨまＣーしゃー１、
o HMAC-SHA-256,
o ＨまＣーしゃー２５６、
o HMAC-SHA-384, and
o HMAC-SHA-384、および
o HMAC-SHA-512.
o ＨまＣーしゃー５１２。
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 Security Associationからの認証キーです。
Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet OSPFv3 Cryptographic Protocol ID.
Ksは、認証キー（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は、16進値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. While [RFC2104] supports a key that is up to B octets long, this application uses L as the Ks length consistent with [RFC4822], [RFC5310], and [RFC5709]. According to [FIPS-198-1], Section 3, keys greater than L octets do not significantly increase the function strength. Ks is computed as follows:
OSPFv3暗号化プロトコルIDが認証キー（K）に追加され、プロトコル固有の認証キー（Ks）が生成されます。このアプリケーションでは、Koは常にLオクテットの長さです。 [RFC2104]は最大Bオクテットまでのキーをサポートしますが、このアプリケーションは[RFC4822]、[RFC5310]、および[RFC5709]と一貫したKs長としてLを使用します。 [FIPS-198-1]のセクション3によれば、Lオクテットを超えるキーは機能強度を大幅に増加させません。 Ksは次のように計算されます。
If Ks is L octets long, then Ko is equal to Ks. If Ks is more than L octets long, then Ko is set to H(Ks). If Ks is less than L octets long, then Ko is set to the value of Ks, with zeros appended to the end of Ks such that Ko is L octets long.
KsがLオクテット長の場合、KoはKsと等しくなります。 KsがLオクテットより長い場合、KoはH（Ks）に設定されます。 KsがLオクテット長より短い場合、KoはKsの値に設定され、Kの末尾にゼロが追加されて、KoはLオクテット長になります。
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], Appendix 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が次のように計算されます。
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
First-Hash = H（Ko XOR Ipad ||（OSPFv3パケット））
When XORing Ko and Ipad, Ko will be padded with zeros to the length of Ipad.
KoとIpadをXORするとき、KoはIpadの長さにゼロで埋められます。
Implementation Note: The First-Hash above includes the Authentication Trailer as well as the OSPFv3 packet as per [RFC2328], Appendix D.4.3, and the LLS data block, if present [RFC5613].
実装メモ：上記の最初のハッシュには、認証トレーラーと[RFC2328]のOSPFv3パケット、付録D.4.3、およびLLSデータブロック（存在する場合）[RFC5613]が含まれます。
The definition of Apad (above) ensures that 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と一致しています。上記のFirst-Hash関数で参照されている「（OSPFv3 Packet）」には、オプションのLLSデータブロックとOSPFv3 Authentication Trailerの両方が含まれています。
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. 2番目のハッシュ
Then a Second-Hash, also known as the outer hash, is computed as follows:
次に、Second-Hashは外部ハッシュとも呼ばれ、次のように計算されます。
Second-Hash = H(Ko XOR Opad || First-Hash)
2番目のハッシュ= H（Ko XOR Opad || First-Hash）
When XORing Ko and Opad, Ko will be padded with zeros to the length of Opad.
KoとOpadをXORするとき、KoはOpadの長さにゼロで埋められます。
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.
結果のSecond-Hashは、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 (AT) 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.
ルータは、OSPFv3がAuthentication Trailer（AT）を使用していることを、HelloパケットとDatabase DescriptionパケットのOSPFv3ヘッダーのOptionsフィールドにあるATビットを調べて判別します。 HelloおよびDatabase Descriptionオプションの指定は、他のOSPFv3パケットに認証トレーラーが含まれることを示しています。
The 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.
OSPFv3パケットヘッダー長を使用してATにアクセスし、OSPFv3パケットの後のデータにアクセスします。LLSデータブロック[RFC5613]が存在する場合、LLSデータブロック長を使用してLLSデータブロックの後のデータにアクセスします。 HelloおよびDatabase DescriptionパケットのOSPFv3オプションのLビットを調べて、LLSデータブロックが存在するかどうかを判断します。 LLSデータブロックが存在する場合（Lビットで指定）、暗号認証計算にOSPFv3 Helloまたはデータベース記述パケットと共に含まれます。
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].
LLSデータブロックに続くATの配置と、LLSデータブロックが暗号化認証の計算に含まれるという事実により、この仕様をサポートするOSPFv3ルーターは、OSPFv3オプションでのLビットの検査と、 ATにアクセスするためのLLSデータブロック。この仕様をサポートするOSPFv3ルーターがOSPFv3リンクローカルシグナリング[RFC5613]を完全にサポートすることが推奨されます。
If usage of the 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 the AT is configured for the link and the IPv6 header length is less than the amount necessary to include an Authentication Trailer.
ここで指定されているATの使用がOSPFv3リンク用に構成されている場合、オプションにATビットがクリアされているOSPFv3 Helloおよびデータベース記述パケットがドロップされます。 ATがリンクに構成されていて、IPv6ヘッダーの長さが認証トレーラーを含めるのに必要な長さより短い場合、すべてのOSPFv3パケットタイプがドロップされます。
The receiving interface's OSPFv3 SA is located using the SA ID in the received AT. If the SA is not found, or if the SA is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPFv3 packet is dropped.
受信インターフェイスのOSPFv3 SAは、受信したATのSA IDを使用して配置されます。 SAが見つからない場合、またはSAが受信に有効でない場合（つまり、現在の時刻<KeyStartAcceptまたは現在の時刻> = KeyStopAccept）の場合、OSPFv3パケットはドロップされます。
If the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
ATの暗号化シーケンス番号が、ネイバーから正常に受信された同じOSPFv3タイプの最後のOSPFv3パケットの最後のシーケンス番号以下である場合、OSPFv3パケットをドロップする必要があり、エラーイベントをログに記録する必要があります。 [RFC4222]で推奨されているように優先順位が付けられている場合、異なるタイプの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で説明）。計算されたデータは、Authentication Trailerで受信した認証データと比較されます。 2つが一致しない場合は、パケットを破棄する必要があり、エラーイベントをログに記録する必要があります（SHOULD）。
After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for each OSPFv3 packet type received from the neighbor. The saved cryptographic sequence numbers will be used for replay checking for subsequent packets received from the neighbor.
OSPFv3パケットが正常に認証された後、実装はネイバーから受信した各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認証に移行する必要があります（SHOULD）。 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. More specifically:
中断のない展開をサポートするために、この仕様を実装するOSPFv3ルーターは、送信パケットに認証トレーラーを含め、受信パケットのこの情報を検証しない遷移モードを実装する場合があります。これは、この仕様で説明されている認証メカニズムへの移行プロセスにおけるネットワークの移行支援として提供されます。すなわち：
1. OSPFv3 routers in transition mode will include the OSPFv3 Authentication Trailer in transmitted packets and set the AT-bit in the Options field of transmitted Hello and Database Description packets. OSPFv3 routers receiving these packets and not having authentication configured will ignore the Authentication Trailer and AT-bit.
1. 移行モードのOSPFv3ルーターは、送信パケットにOSPFv3認証トレーラーを含め、送信されたHelloパケットとデータベース記述パケットのオプションフィールドにATビットを設定します。これらのパケットを受信し、認証が構成されていないOSPFv3ルーターは、認証トレーラーとATビットを無視します。
2. OSPFv3 routers in transition mode will also calculate and set the OSPFv3 header checksum and the LLS data block checksum in transmitted packets so that they will not be dropped by OSPFv3 routers without authentication configured.
2. 移行モードのOSPFv3ルーターは、送信パケットのOSPFv3ヘッダーチェックサムとLLSデータブロックチェックサムも計算して設定するため、認証が設定されていないOSPFv3ルーターによってドロップされることはありません。
3. OSPFv3 routers in transition mode will authenticate received packets that either have the AT-bit set in the Options field for Hello or Database Description packets or are from a neighbor that previously set the AT-bit in the Options field of successfully authenticated Hello and Database Description packets.
3. 遷移モードのOSPFv3ルーターは、HelloまたはDatabase DescriptionパケットのOptionsフィールドにATビットが設定されているか、以前に正常に認証されたHelloおよびDatabase DescriptionのOptionsフィールドにATビットを設定したネイバーからの受信パケットを認証しますパケット。
4. OSPFv3 routers in transition mode will also accept packets without the Options field AT-bit set in Hello and Database Description packets. These packets will be assumed to be from OSPFv3 routers without authentication configured, and they will not be authenticated. Additionally, the OSPFv3 header checksum and LLS data block checksum will be validated.
4. 移行モードのOSPFv3ルーターは、Helloパケットとデータベース記述パケットで設定されたオプションフィールドATビットのないパケットも受け入れます。これらのパケットは、認証が構成されていないOSPFv3ルーターからのパケットであると想定され、認証されません。さらに、OSPFv3ヘッダーチェックサムとLLSデータブロックチェックサムが検証されます。
This document proposes extensions to OSPFv3 that would make it more secure than OSPFv3 as defined in [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 packets that are of interest. It addresses all the security issues that have been identified in [RFC6039] and [RFC6506].
このドキュメントは、[RFC5340]で定義されているように、OSPFv3よりも安全にするOSPFv3への拡張を提案します。ルーティングプロトコルには秘密にする必要のない情報が含まれているため、機密性は提供されません。ただし、対象のパケットの送信者を認証する手段は提供します。 [RFC6039]と[RFC6506]で特定されたすべてのセキュリティ問題に対処します。
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 rather is 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 pseudorandom bits to minimize the risk of such attacks. In support of these recommendations, management systems SHOULD support hexadecimal input of Authentication Keys.
デプロイメントでは、認証キーに十分に長いランダムな値を使用する必要があります。これにより、キーに対する推測やその他の暗号化攻撃が環境で実行できなくなります。さらに、このような攻撃のリスクを最小限に抑えるために、認証キーには少なくとも128の疑似ランダムビットを組み込むことをお勧めします。これらの推奨事項をサポートするために、管理システムは認証キーの16進数入力をサポートする必要があります（SHOULD）。
Deployments that support a transitionary state but interoperate with routers that do not support this authentication method may be exposed to unauthenticated data during the transition period.
移行状態をサポートするが、この認証方法をサポートしないルーターと相互運用する展開は、移行期間中に認証されていないデータに公開される可能性があります。
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]を参照してください。
This document obsoletes RFC 6506; thus, IANA has updated the references in existing registries that pointed to RFC 6506 to point to this document. This is the only IANA action requested by this document.
このドキュメントはRFC 6506を廃止しました。したがって、IANAは、このドキュメントを指すようにRFC 6506を指す既存のレジストリの参照を更新しました。これは、このドキュメントで要求されている唯一のIANAアクションです。
IANA previously allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry as described in Section 2.1.
セクション2.1で説明されているように、IANAは以前に「OSPFv3オプション（24ビット）」レジストリでATビット（0x000400）を割り当てていました。
IANA previously created the "Open Shortest Path First v3 (OSPFv3) Authentication Trailer Options" registry. This registry 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 [RFC5226].
IANAは、以前に「Open Shortest Path First v3（OSPFv3）Authentication Trailer Options」レジストリを作成しました。このレジストリには、OSPFv3 Authentication TrailerのAuthentication Typeフィールドの有効な値を定義する「OSPFv3 Authentication Types」レジストリが含まれています。登録手続きは、Standards Action [RFC5226]です。
+-------------+-----------------------------------+
|Value | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
OSPFv3 Authentication Types
OSPFv3認証タイプ
Finally, IANA previously created the "Keying and Authentication for Routing Protocols (KARP) Parameters" registry. This registry includes the "Cryptographic Protocol ID" registry, which provides unique protocol-specific values for cryptographic applications, including 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 Cryptographic Authentication」、RFC 5709、 2009年10月。
[FIPS-180-4] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS-180-4]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、2012年3月。
[FIPS-198-1] US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008.
[FIPS-198-1]米国国立標準技術研究所、「キー付きハッシュメッセージ認証コード（HMAC）」、FIPS PUB 198-1、2008年7月。
[MANUAL-KEY] Bhatia, M., Hartman, S., and D. Zhang, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, February 2011.
[MANUAL-KEY] Bhatia、M.、Hartman、S。、およびD. Zhang、「手動によるキー管理を使用する場合のOSPFv2のセキュリティ拡張」、Work in Progress、2011年2月。
[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：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", BCP 112, RFC 4222, October 2005.
[RFC4222] Choudhury、G。、編、「特定のOSPFバージョン2パケットの優先順位付けされた処理と輻輳回避」、BCP 112、RFC 4222、2005年10月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[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月。
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
[RFC5879] Kivinen、T。およびD.マクドナルド、「ESP-NULLパケットを検出するためのヒューリスティック」、RFC 5879、2010年5月。
[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、「インターネットキーエクスチェンジプロトコルバージョン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、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、2010年10月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 6506、2012年2月。
First and foremost, thanks to the US National Institute of Standards and Technology for their work on the SHA [FIPS-180-4] and HMAC [FIPS-198-1].
何よりもまず、SHA [FIPS-180-4]およびHMAC [FIPS-198-1]に関する作業を行ってくれた米国国立標準技術研究所に感謝します。
Thanks also need to go to the authors of the HMAC-SHA authentication RFCs, including [RFC4822], [RFC5310], and [RFC5709]. The basic HMAC-SHA procedures were originally described by Ran Atkinson in [RFC4822].
[RFC4822]、[RFC5310]、および[RFC5709]を含むHMAC-SHA認証RFCの作成者にも感謝します。基本的なHMAC-SHA手順は、もともと[RFC4822]でRan Atkinsonによって記述されました。
Also, thanks to Ran Atkinson for help in the analysis of RFC 6506 errata.
また、RFC 6506エラッタの分析に協力してくれたRan Atkinsonに感謝します。
Thanks to Srinivasan K L and Marek Karasek for their identification and submission of RFC 6506 errata.
RFC 6506エラッタの識別と提出をしてくれたSrinivasan K LとMarek Karasekに感謝します。
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 the sharing of keys 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).
認証トレーラー（AT）によるLLSの報道について多くのコメントと強力な意見を提供してくれたMichael Barnesに感謝します。
Thanks to Marek Karasek for providing the specifics with respect to backward-compatible transition mode.
後方互換の移行モードに関する詳細を提供してくれたMarek Karasekに感謝します。
Thanks to Michael Dubrovskiy and Anton Smirnov for comments on document revisions.
ドキュメントの改訂に関するコメントを提供してくれたMichael DubrovskiyとAnton Smirnovに感謝します。
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 K L, Shraddha H, Alan Davey, Russ White, Stan Ratliff, and Glen Kent for their support and review comments.
Srinivasan K L、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.
Routing Directorateレビューの範囲内で行われたコメントについて、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に感謝します。スティーブンはまた、クロスプロトコル攻撃の議論に関与しました。
Thanks to Brian Carpenter for comments made during the Gen-ART review.
Gen-ARTレビュー中に行われたコメントについて、Brian Carpenterに感謝します。
Thanks to Victor Kuarsingh for the OPS-DIR review.
OPS-DIRのレビューをしてくれたVictor Kuarsinghに感謝します。
Thanks to Brian Weis for the SEC-DIR review.
SEC-DIRのレビューをしてくれたBrian Weisに感謝します。
Authors' Addresses
著者のアドレス
Manav Bhatia Alcatel-Lucent Bangalore India
Manav Bhatiaアルカテルルーセントバンガロールインド
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 95117彼
EMail: vishwas@ionosnetworks.com
Acee Lindem Ericsson 301 Midenhall Way Cary, NC 27513 USA
Acee Lindem Ericsson 301 Midenhall Way Cary、NC 27513 USA
EMail: acee.lindem@ericsson.com