[要約] RFC 7298は、Babelルーティングプロトコルで使用されるHMAC暗号化認証の仕様を定義しています。目的は、メッセージの整合性と認証を確保し、Babelネットワークのセキュリティを向上させることです。
Independent Submission D. Ovsienko
Request for Comments: 7298 Yandex
Updates: 6126 July 2014
Category: Experimental
ISSN: 2070-1721
Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
Babel Hashed Message Authentication Code（HMAC）暗号化認証
Abstract
概要
This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.
このドキュメントでは、Babelルーティングプロトコルの暗号化認証メカニズムについて説明します。このドキュメントはRFC 6126を更新します。このメカニズムは、認証データに2つの新しいTLVタイプを割り当て、ハッシュメッセージ認証コード（HMAC）を使用し、オプションであり、下位互換性があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7298.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7298で入手できます。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Cryptographic Aspects ...........................................5
2.1. Mandatory-to-Implement and Optional Hash Algorithms ........5
2.2. Definition of Padding ......................................6
2.3. Cryptographic Sequence Number Specifics ....................8
2.4. Definition of HMAC .........................................9
3. Updates to Protocol Data Structures ............................11
3.1. RxAuthRequired ............................................11
3.2. LocalTS ...................................................11
3.3. LocalPC ...................................................11
3.4. MaxDigestsIn ..............................................11
3.5. MaxDigestsOut .............................................12
3.6. ANM Table .................................................12
3.7. ANM Timeout ...............................................13
3.8. Configured Security Associations ..........................14
3.9. Effective Security Associations ...........................16
4. Updates to Protocol Encoding ...................................17
4.1. Justification .............................................17
4.2. TS/PC TLV .................................................19
4.3. HMAC TLV ..................................................20
5. Updates to Protocol Operation ..................................21
5.1. Per-Interface TS/PC Number Updates ........................21
5.2. Deriving ESAs from CSAs ...................................23
5.3. Updates to Packet Sending .................................25
5.4. Updates to Packet Receiving ...............................28
5.5. Authentication-Specific Statistics Maintenance ............30
6. Implementation Notes ...........................................31
6.1. Source Address Selection for Sending ......................31
6.2. Output Buffer Management ..................................31
6.3. Optimizations of Deriving Procedure for ESAs ..............32
6.4. Duplication of Security Associations ......................33
7. Network Management Aspects .....................................34
7.1. Backward Compatibility ....................................34
7.2. Multi-Domain Authentication ...............................35
7.3. Migration to and from Authenticated Exchange ..............36
7.4. Handling of Authentication Key Exhaustion .................37
8. Security Considerations ........................................38
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................43
11. References ....................................................44
11.1. Normative References .....................................44
11.2. Informative References ...................................44
Appendix A. Figures and Tables ....................................47
Appendix B. Test Vectors ..........................................52
Authentication of routing protocol exchanges is a common means of securing computer networks. The use of protocol authentication mechanisms helps in ascertaining that only the intended routers participate in routing information exchange and that the exchanged routing information is not modified by a third party.
ルーティングプロトコル交換の認証は、コンピュータネットワークを保護する一般的な方法です。プロトコル認証メカニズムを使用すると、意図したルーターのみがルーティング情報の交換に参加し、交換されたルーティング情報が第三者によって変更されていないことを確認するのに役立ちます。
[BABEL] ("the original specification") defines data structures, encoding, and the operation of a basic Babel routing protocol instance ("instance of the original protocol"). This document ("this specification") defines data structures, encoding, and the operation of an extension to the Babel protocol -- an authentication mechanism ("this mechanism"). Both the instance of the original protocol and this mechanism are mostly self-contained and interact only at coupling points defined in this specification.
[BABEL]（「元の仕様」）は、データ構造、エンコード、および基本的なBabelルーティングプロトコルインスタンス（「元のプロトコルのインスタンス」）の操作を定義します。このドキュメント（「この仕様」）は、データ構造、エンコーディング、およびBabelプロトコルの拡張機能である認証メカニズム（「このメカニズム」）の動作を定義しています。元のプロトコルのインスタンスとこのメカニズムの両方は、ほとんどが自己完結型であり、この仕様で定義されている結合点でのみ相互作用します。
A major design goal of this mechanism is transparency to operators that is not affected by implementation and configuration specifics. A complying implementation makes all meaningful details of authentication-specific processing clear to the operator, even when some of the operational parameters cannot be changed.
このメカニズムの主な設計目標は、実装および構成の詳細に影響されないオペレーターへの透過性です。準拠する実装により、一部の操作パラメーターを変更できない場合でも、認証固有の処理のすべての意味のある詳細がオペレーターに明確になります。
The currently established (see [RIP2-AUTH], [OSPF2-AUTH], [ISIS-AUTH-A], [RFC6039], and [OSPF3-AUTH-BIS]) approach to an authentication mechanism design for datagram-based routing protocols such as Babel relies on two principal data items embedded into protocol packets, typically as two integral parts of a single data structure:
データグラムベースのルーティングプロトコルの認証メカニズム設計に対する現在確立されている（[RIP2-AUTH]、[OSPF2-AUTH]、[ISIS-AUTH-A]、[RFC6039]、および[OSPF3-AUTH-BIS]を参照）アプローチBabelなどは、通常、単一のデータ構造の2つの不可欠な部分として、プロトコルパケットに埋め込まれた2つの主要なデータ項目に依存しています。
o A fixed-length unsigned integer, typically called a cryptographic sequence number, used in replay attack protection.
o 通常、暗号シーケンス番号と呼ばれる固定長の符号なし整数。リプレイアタック保護で使用されます。
o A variable-length sequence of octets, a result of the Hashed Message Authentication Code (HMAC) construction (see [RFC2104]) computed on meaningful data items of the packet (including the cryptographic sequence number) on one hand and a secret key on the other, used in proving that both the sender and the receiver share the same secret key and that the meaningful data was not changed in transmission.
o オクテットの可変長シーケンス、一方では（暗号シーケンス番号を含む）パケットの意味のあるデータアイテムに対して計算されたHashed Message Authentication Code（HMAC）構築（[RFC2104]を参照）の結果、およびその他、送信者と受信者の両方が同じ秘密鍵を共有し、意味のあるデータが送信中に変更されなかったことを証明するために使用されます。
Depending on the design specifics, either all protocol packets or only those packets protecting the integrity of protocol exchange are authenticated. This mechanism authenticates all protocol packets.
設計仕様に応じて、すべてのプロトコルパケットまたはプロトコル交換の整合性を保護するパケットのみが認証されます。このメカニズムは、すべてのプロトコルパケットを認証します。
Although the HMAC construction is just one of many possible approaches to cryptographic authentication of packets, this mechanism makes use of relevant prior experience by using HMAC as well, and its solution space correlates with the solution spaces of the mechanisms above. At the same time, it allows for a future extension that treats HMAC as a particular case of a more generic mechanism. Practical experience with the mechanism defined herein should be useful in designing such a future extension.
HMACの構築は、パケットの暗号化認証に対する多くの可能なアプローチの1つにすぎませんが、このメカニズムはHMACを使用することで関連する以前の経験を利用し、そのソリューションスペースは上記のメカニズムのソリューションスペースと相関しています。同時に、HMACをより一般的なメカニズムの特定のケースとして扱う将来の拡張が可能になります。ここで定義されたメカニズムの実際の経験は、そのような将来の拡張を設計する際に役立つはずです。
This specification defines the use of the cryptographic sequence number in detail sufficient to make replay attack protection strength predictable. That is, an operator can tell the strength from the declared characteristics of an implementation and, if the implementation allows the changing of relevant parameters, the effect of a reconfiguration as well.
この仕様は、暗号化シーケンス番号の使用を詳細に定義しており、リプレイアタック保護の強度を予測可能にするのに十分です。つまり、オペレーターは実装の宣言された特性から強さを知ることができ、実装が関連するパラメーターの変更を許可する場合は、再構成の効果もわかります。
This mechanism explicitly allows for multiple HMAC results per authenticated packet. Since meaningful data items of a given packet remain the same, each such HMAC result stands for a different secret key and/or a different hash algorithm. This enables a simultaneous, independent authentication within multiple domains. This specification is not novel in this regard; for example, the Layer 2 Tunneling Protocol (L2TPv3) allows for one or two results per authenticated packet ([RFC3931] Section 5.4.1), and Mobile Ad Hoc Network (MANET) protocols allow for several ([RFC7183] Section 6.1).
このメカニズムは、認証されたパケットごとに複数のHMAC結果を明示的に許可します。所定のパケットの意味のあるデータ項目は同じままであるため、そのような各HMAC結果は、異なる秘密鍵および/または異なるハッシュアルゴリズムを表します。これにより、複数のドメイン内で同時に独立した認証が可能になります。この仕様は、この点で新規ではありません。たとえば、レイヤ2トンネリングプロトコル（L2TPv3）では認証済みパケットごとに1つまたは2つの結果が許可され（[RFC3931]セクション5.4.1）、モバイルアドホックネットワーク（MANET）プロトコルでは複数の結果が許可されます（[RFC7183]セクション6.1）。
An important concern addressed by this mechanism is limiting the amount of HMAC computations done per authenticated packet, independently for sending and receiving. Without these limits, the number of computations per packet could be as high as the number of configured authentication keys (in the sending case) or as high as the number of keys multiplied by the number of supplied HMAC results (in the receiving case).
このメカニズムで対処される重要な問題は、認証されたパケットごとに実行されるHMAC計算の量を、送信と受信に個別に制限することです。これらの制限がない場合、パケットあたりの計算数は、構成された認証キーの数（送信の場合）またはキーの数に提供されたHMAC結果の数（受信の場合）を掛けた数と同じくらい高くなる可能性があります。
These limits establish a basic competition between the configured keys and (in the receiving case) an additional competition between the supplied HMAC results. This specification defines related data structures and procedures in a way to make such competition transparent and predictable for an operator.
これらの制限により、構成されたキー間の基本的な競合と、（受信の場合）提供されたHMAC結果間の追加の競合が確立されます。この仕様は、関連するデータ構造と手順を定義して、そのような競争をオペレーターに透過的かつ予測可能にする方法を示しています。
Wherever this specification mentions the operator reading or changing a particular data structure, variable, parameter, or event counter "at runtime", it is up to the implementor how this is to be done. For example, the implementation can employ an interactive command line interface (CLI), a management protocol such as the Simple Network Management Protocol (SNMP), a means of inter-process communication such as a local socket, or a combination of these.
この仕様で「実行時」に特定のデータ構造、変数、パラメーター、またはイベントカウンターを読み取るまたは変更するオペレーターについて言及している場合は、これをどのように行うかは実装者次第です。たとえば、実装では、対話型のコマンドラインインターフェイス（CLI）、簡易ネットワーク管理プロトコル（SNMP）などの管理プロトコル、ローカルソケットなどのプロセス間通信の手段、またはこれらの組み合わせを使用できます。
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 BCP 14 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈されます。
[RFC2104] defines HMAC as a construction that can use any cryptographic hash algorithm with a known digest length and internal block size. This specification preserves this property of HMAC by defining data processing that itself does not depend on any particular hash algorithm either. However, since this mechanism is a protocol extension case, there are relevant design considerations to take into account.
[RFC2104]は、既知のダイジェスト長と内部ブロックサイズで任意の暗号化ハッシュアルゴリズムを使用できる構造としてHMACを定義しています。この仕様は、特定のハッシュアルゴリズムにも依存しないデータ処理を定義することにより、HMACのこのプロパティを保持します。ただし、このメカニズムはプロトコル拡張のケースであるため、考慮すべき設計上の考慮事項があります。
Section 4.5 of [RFC6709] suggests selecting one hash algorithm as mandatory to implement for the purpose of global interoperability (Section 3.2 of [RFC6709]) and selecting another of distinct lineage as recommended for implementation for the purpose of cryptographic agility. This specification makes the latter property guaranteed, rather than probable, through an elevation of the requirement level. There are two mandatory-to-implement hash algorithms; each is unambiguously defined and generally available in multiple implementations.
[RFC6709]のセクション4.5は、グローバルな相互運用性の目的で実装するために必須として1つのハッシュアルゴリズムを選択し（[RFC6709]のセクション3.2）、暗号の俊敏性の目的で実装に推奨される別の系統を選択することを提案しています。この仕様により、後者のプロパティは、要件レベルの昇格を通じて、確率ではなく保証されます。実装に必須の2つのハッシュアルゴリズムがあります。それぞれが明確に定義されており、一般に複数の実装で使用できます。
An implementation of this mechanism MUST include support for two hash algorithms:
このメカニズムの実装には、2つのハッシュアルゴリズムのサポートが含まれている必要があります。
o RIPEMD-160 (160-bit digest)
o RIPEMD-160（160ビットダイジェスト）
o SHA-1 (160-bit digest)
o SHA-1（160ビットのダイジェスト）
Besides that, an implementation of this mechanism MAY include support for additional hash algorithms, provided each such algorithm is publicly and openly specified and its digest length is 128 bits or more (to meet the constraint implied in Section 2.2). Implementors SHOULD consider strong, well-known hash algorithms as additional implementation options and MUST NOT consider a hash algorithm if meaningful attacks exist for it or it is commonly viewed as deprecated.
その上、このメカニズムの実装には、追加のハッシュアルゴリズムのサポートが含まれる場合があります。ただし、そのような各アルゴリズムが公開され、オープンに指定され、そのダイジェスト長が128ビット以上である場合（セクション2.2に含まれる制約を満たすため）。実装者は、強力な既知のハッシュアルゴリズムを追加の実装オプションと見なすべきであり、意味のある攻撃が存在する場合、または非推奨と一般的に見なされている場合は、ハッシュアルゴリズムを考慮してはなりません。
In the latter case, it is important to take into account considerations both common (such as those made in [RFC4270]) and specific to the HMAC application of the hash algorithm. For example, [RFC6151] considers MD5 collisions and concludes that new protocol designs should not use HMAC-MD5, while [RFC6194] includes a comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the same purpose.
後者の場合、一般的な考慮事項（[RFC4270]で作成されたものなど）と、ハッシュアルゴリズムのHMACアプリケーションに固有の考慮事項を考慮することが重要です。たとえば、[RFC6151]はMD5衝突を考慮し、新しいプロトコル設計ではHMAC-MD5を使用すべきではないと結論付けていますが、[RFC6194]には、同じ目的でHMAC-SHA-1が安全であることがわかるSHA-1の比較分析が含まれています。
For example, the following hash algorithms meet these requirements at the time of this writing (in alphabetical order):
たとえば、次のハッシュアルゴリズムは、この記事の執筆時点でこれらの要件を満たしています（アルファベット順）。
o GOST R 34.11-94 (256-bit digest)
o GOST R 34.11-94（256ビットダイジェスト）
o SHA-224 (224-bit digest, SHA-2 family)
o SHA-224（224ビットダイジェスト、SHA-2ファミリー）
o SHA-256 (256-bit digest, SHA-2 family)
o SHA-256（256ビットダイジェスト、SHA-2ファミリー）
o SHA-384 (384-bit digest, SHA-2 family)
o SHA-384（384ビットダイジェスト、SHA-2ファミリー）
o SHA-512 (512-bit digest, SHA-2 family)
o SHA-512（512ビットダイジェスト、SHA-2ファミリー）
o Tiger (192-bit digest)
o タイガー（192ビットダイジェスト）
o Whirlpool (512-bit digest, 2nd rev., 2003)
o ワールプール（512ビットダイジェスト、第2改訂、2003）
The set of hash algorithms available in an implementation MUST be clearly stated. When known weak authentication keys exist for a hash algorithm used in the HMAC construction, an implementation MUST deny the use of such keys.
実装で利用可能なハッシュアルゴリズムのセットは明確に述べられなければなりません。 HMAC構築で使用されるハッシュアルゴリズムに既知の弱い認証キーが存在する場合、実装はそのようなキーの使用を拒否する必要があります。
Many practical applications of HMAC for authentication of datagram-based network protocols (including routing protocols) involve the padding procedure, a design-specific conditioning of the message that both the sender and the receiver perform before the HMAC computation. The specific padding procedure of this mechanism addresses the following needs:
データグラムベースのネットワークプロトコル（ルーティングプロトコルを含む）の認証のためのHMACの多くの実用的なアプリケーションには、HMAC計算の前に送信者と受信者の両方が実行するメッセージの設計固有の調整であるパディング手順が含まれます。このメカニズムの特定のパディング手順は、次のニーズに対応します。
o Data Initialization
o データの初期化
A design that places the HMAC result(s) computed for a message inside that same message after the computation has to have previously (i.e., before the computation) allocated in that message some data unit(s) purposed specifically for those HMAC result(s) (in this mechanism, it is the HMAC TLV(s); see Section 4.3). The padding procedure sets the respective octets of the data unit(s), in the simplest case to a fixed value known as the padding constant.
計算後、同じメッセージ内にメッセージに対して計算されたHMAC結果を配置する設計。以前に（つまり、計算の前に）そのメッセージに、それらのHMAC結果専用のデータユニットをいくつか割り当てる必要があります。 ）（このメカニズムでは、HMAC TLVです。セクション4.3を参照）。パディングプロシージャは、データユニットのそれぞれのオクテットを、最も単純なケースでは、パディング定数と呼ばれる固定値に設定します。
The particular value of the constant is specific to each design. For instance, in [RIP2-AUTH] as well as works derived from it ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS]), the value is 0x878FE1F3. In many other designs (for instance, [RFC3315], [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]), the value is 0x00.
定数の特定の値は、各設計に固有です。たとえば、[RIP2-AUTH]とそれから派生した作品（[ISIS-AUTH-B]、[OSPF2-AUTH]、および[OSPF3-AUTH-BIS]）では、値は0x878FE1F3です。他の多くの設計（たとえば、[RFC3315]、[RFC3931]、[RFC4030]、[RFC4302]、[RFC5176]、および[ISIS-AUTH-A]）では、値は0x00です。
However, the HMAC construction is defined on the basis of a cryptographic hash algorithm, that is, an algorithm meeting a particular set of requirements made for any input message. Thus, any padding constant values, whether single- or multiple-octet, as well as any other message-conditioning methods, don't affect cryptographic characteristics of the hash algorithm and the HMAC construction, respectively.
ただし、HMACの構築は、暗号化ハッシュアルゴリズム、つまり、入力メッセージに対して行われた特定の要件セットを満たすアルゴリズムに基づいて定義されます。したがって、単一または複数オクテットのパディング定数値、およびその他のメッセージ調整方法は、それぞれハッシュアルゴリズムの暗号特性およびHMAC構造に影響を与えません。
o Source Address Protection
o 送信元アドレス保護
In the specific case of datagram-based routing protocols, the protocol packet (that is, the message being authenticated) often does not include network-layer addresses, although the source and (to a lesser extent) the destination address of the datagram may be meaningful in the scope of the protocol instance.
データグラムベースのルーティングプロトコルの特定のケースでは、プロトコルパケット（つまり、認証されるメッセージ）にネットワーク層アドレスが含まれていないことがよくありますが、データグラムの送信元および（それほどではないが）宛先アドレスはプロトコルインスタンスのスコープで意味があります。
In Babel, the source address may be used as a prefix next hop (see Section 3.5.3 of [BABEL]). A well-known (see Section 2.3 of [OSPF3-AUTH-BIS]) solution to the source address protection problem is to set the first respective octets of the data unit(s) above to the source address (yet setting the rest of the octets to the padding constant). This procedure adapts this solution to the specifics of Babel, which allows for the exchange of protocol packets using both IPv4 and IPv6 datagrams (see Section 4 of [BABEL]). Even though in the case of IPv6 exchange a Babel speaker currently uses only link-local source addresses (Section 3.1 of [BABEL]), this procedure protects all octets of an arbitrary given source address for the reasons of future extensibility. The procedure implies that future Babel extensions will never use an IPv4-mapped IPv6 address as a packet source address.
Babelでは、送信元アドレスをプレフィックスのネクストホップとして使用できます（[BABEL]のセクション3.5.3を参照）。送信元アドレス保護の問題に対するよく知られている（[OSPF3-AUTH-BIS]のセクション2.3を参照）解決策は、上記のデータユニットの最初のそれぞれのオクテットを送信元アドレスに設定することです（まだ残りのパディング定数へのオクテット）。この手順は、このソリューションをBabelの仕様に適合させ、IPv4とIPv6の両方のデータグラムを使用してプロトコルパケットを交換できるようにします（[BABEL]のセクション4を参照）。 IPv6交換の場合、バベルスピーカーは現在リンクローカルソースアドレスのみを使用していますが（[BABEL]のセクション3.1）、この手順は、将来の拡張性の理由から、任意の特定のソースアドレスのすべてのオクテットを保護します。この手順は、将来のBabel拡張機能がIPv4にマップされたIPv6アドレスをパケットの送信元アドレスとして使用しないことを意味します。
This procedure does not protect the destination address, which is currently considered meaningless (Section 3.1 of [BABEL]) in the same scope. A future extension that looks to add such protection would likely use a new TLV or sub-TLV to include the destination address in the protocol packet (see Section 4.1).
この手順は、同じスコープでは現在無意味であると見なされている宛先アドレス（[BABEL]のセクション3.1）を保護しません。このような保護を追加しようとする将来の拡張では、新しいTLVまたはサブTLVを使用して、プロトコルパケットに宛先アドレスを含める可能性があります（セクション4.1を参照）。
Description of the padding procedure:
パディング手順の説明：
1. Set the first 16 octets of the Digest field of the given HMAC TLV to:
1. 指定されたHMAC TLVのダイジェストフィールドの最初の16オクテットを次のように設定します。
* the given source address, if it is an IPv6 address, or
* 指定された送信元アドレス（IPv6アドレスの場合）、または
* the IPv4-mapped IPv6 address (per Section 2.5.5.2 of [RFC4291]) holding the given source address, if it is an IPv4 address.
* 特定の送信元アドレスを保持するIPv4にマップされたIPv6アドレス（[RFC4291]のセクション2.5.5.2に従って）（IPv4アドレスの場合）。
2. Set the remaining (TLV Length - 18) octets of the Digest field of the given HMAC TLV to 0x00 each.
2. 指定されたHMAC TLVのダイジェストフィールドの残りの（TLV長さ-18）オクテットをそれぞれ0x00に設定します。
For an example of a Babel packet with padded HMAC TLVs, see Table 3 in Appendix A.
HMAC TLVが埋め込まれたBabelパケットの例については、付録Aの表3を参照してください。
The operation of this mechanism may involve multiple local and multiple remote cryptographic sequence numbers, each essentially being a 48-bit unsigned integer. This specification uses the term "TS/PC number" to avoid confusion with the route's (Section 2.5 of [BABEL]) or node's (Section 3.2.1 of [BABEL]) sequence numbers of the original Babel specification and to stress the fact that there are two distinguished parts of this 48-bit number, each handled in its specific way (see Section 5.1):
このメカニズムの動作には、複数のローカルおよび複数のリモート暗号シーケンス番号が含まれる場合があり、それぞれが本質的に48ビットの符号なし整数です。この仕様では「TS / PC番号」という用語を使用して、元のBabel仕様のルート（[BABEL]のセクション2.5）またはノード（[BABEL]のセクション3.2.1）のシーケンス番号との混同を回避し、この48ビットの数値には2つの異なる部分があり、それぞれが特定の方法で処理されます（セクション5.1を参照）。
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS // | PC |
+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
The high-order 32 bits are called "timestamp" (TS), and the low-order 16 bits are called "packet counter" (PC).
上位32ビットは「タイムスタンプ」（TS）と呼ばれ、下位16ビットは「パケットカウンタ」（PC）と呼ばれます。
This mechanism stores, updates, compares, and encodes each TS/PC number as two independent unsigned integers -- TS and PC, respectively. Such a comparison of TS/PC numbers, as performed in item 3 of Section 5.4, is algebraically equivalent to a comparison of the respective 48-bit unsigned integers. Any byte order conversion, when required, is performed on TS and PC parts independently.
このメカニズムは、各TS / PC番号を2つの独立した符号なし整数（それぞれTSとPC）として保存、更新、比較、およびエンコードします。セクション5.4の項目3で実行されるTS / PC番号のこのような比較は、それぞれの48ビット符号なし整数の比較と代数的に同等です。バイトオーダー変換は、必要に応じて、TSとPCのパーツで個別に実行されます。
The algorithm description below uses the following nomenclature, which is consistent with [FIPS-198]:
以下のアルゴリズムの説明では、[FIPS-198]と一致する次の命名法を使用しています。
Text The data on which the HMAC is calculated (note item (b) of Section 8). In this specification, it is the contents of a Babel packet ranging from the beginning of the Magic field of the Babel packet header to the end of the last octet of the Packet Body field, as defined in Section 4.2 of [BABEL] (see Figure 2 in Appendix A).
テキストHMACが計算されるデータ（セクション8の項目（b）に注意）。この仕様では、[BABEL]のセクション4.2で定義されているように、BabelパケットヘッダーのMagicフィールドの先頭からPacket Bodyフィールドの最後のオクテットの終わりまでの範囲のBabelパケットの内容です（図を参照）。付録Aの2）。
H The specific hash algorithm (see Section 2.1).
H特定のハッシュアルゴリズム（セクション2.1を参照）。
K A sequence of octets of an arbitrary, known length.
K任意の既知の長さのオクテットのシーケンス。
Ko The cryptographic key used with the hash algorithm.
Koハッシュアルゴリズムで使用される暗号化キー。
B The block size of H, measured in octets rather than bits. Note that B is the internal block size, not the digest length.
Bビットではなくオクテットで測定されたHのブロックサイズ。 Bは内部ブロックサイズであり、ダイジェストの長さではないことに注意してください。
L The digest length of H, measured in octets rather than bits.
L Hのダイジェスト長。ビットではなくオクテットで測定されます。
XOR The bitwise exclusive-or operation.
XORビット単位の排他的論理和演算。
Opad The hexadecimal value 0x5C repeated B times.
Opad 16進値0x5CがB回繰り返されました。
Ipad The hexadecimal value 0x36 repeated B times.
Ipad 16進値0x36がB回繰り返されました。
The algorithm below is the original, unmodified HMAC construction as defined in both [RFC2104] and [FIPS-198]; hence, it is different from the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS] in exactly two regards:
以下のアルゴリズムは、[RFC2104]と[FIPS-198]の両方で定義されている、変更されていない元のHMAC構成です。したがって、2つの点で[RIP2-AUTH]、[ISIS-AUTH-B]、[OSPF2-AUTH]、および[OSPF3-AUTH-BIS]で定義されたアルゴリズムとは異なります。
o The algorithm below sets the size of Ko to B, not to L (L is not greater than B). This resolves both ambiguity in XOR expressions and incompatibility in the handling of keys that have length greater than L but not greater than B.
o 以下のアルゴリズムは、KoのサイズをLではなくBに設定します（LはBより大きくありません）。これにより、XOR式のあいまいさ、および長さがLより大きくB以下のキーの処理における非互換性の両方が解決されます。
o The algorithm below does not change the value of Text before or after the computation. Padding a Babel packet before the computation and placing the result inside the packet are both performed elsewhere.
o 以下のアルゴリズムは、計算の前後にテキストの値を変更しません。計算の前にBabelパケットをパディングすることと、結果をパケット内に配置することは、どちらも別の場所で実行されます。
The intent of this is to enable the most straightforward use of cryptographic libraries by implementations of this specification. At the time of this writing, implementations of the original HMAC construction coupled with hash algorithms of choice are generally available.
これの目的は、この仕様の実装によって暗号化ライブラリを最も簡単に使用できるようにすることです。この記事の執筆時点では、選択したハッシュアルゴリズムと組み合わせた元のHMAC構成の実装が一般に利用可能です。
Description of the algorithm:
アルゴリズムの説明：
1. Preparation of the Key
1. キーの準備
In this application, Ko is always B octets long. If K is B octets long, then Ko is set to K. If K is more than B octets long, then Ko is set to H(K) with the necessary amount of zeroes appended to the end of H(K), such that Ko is B octets long. If K is less than B octets long, then Ko is set to K with zeroes appended to the end of K, such that Ko is B octets long.
このアプリケーションでは、Koは常にBオクテット長です。 KがBオクテット長の場合、KoはKに設定されます。KがBオクテットより長い場合、KoはH（K）に設定され、必要な量のゼロがH（K）の末尾に追加されます。 KoはBオクテット長です。 KがBオクテットよりも短い場合、KはKに設定され、Kの末尾にゼロが追加されて、KはBオクテットの長さになります。
2. First-Hash
2. 最初のハッシュ
A First-Hash, also known as the inner hash, is computed as follows:
内部ハッシュとも呼ばれる最初のハッシュは、次のように計算されます。
First-Hash = H(Ko XOR Ipad || Text)
First-Hash = H（Ko XOR Ipad ||テキスト）
3. Second-Hash
3. 2番目のハッシュ
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）
4. Result
4. 結果
The resulting Second-Hash becomes the authentication data that is returned as the result of HMAC calculation.
結果のSecond-Hashは、HMAC計算の結果として返される認証データになります。
Note that in the case of Babel the Text parameter will never exceed a few thousand octets in length. In this specific case, the optimization discussed in Section 6 of [FIPS-198] applies, namely, for a given K that is more than B octets long, the following associated intermediate results may be precomputed only once: Ko, (Ko XOR Ipad), and (Ko XOR Opad).
Babelの場合、Textパラメータの長さが数千オクテットを超えることはありません。この特定のケースでは、[FIPS-198]のセクション6で説明されている最適化が適用されます。つまり、Bオクテットより長い特定のKの場合、次の関連する中間結果は一度だけ事前計算されます：Ko、（Ko XOR Ipad ）、および（Ko XOR Opad）。
RxAuthRequired is a boolean parameter. Its default value MUST be TRUE. An implementation SHOULD make RxAuthRequired a per-interface parameter but MAY make it specific to the whole protocol instance. The conceptual purpose of RxAuthRequired is to enable a smooth migration from an unauthenticated Babel packet exchange to an authenticated Babel packet exchange and back (see Section 7.3). The current value of RxAuthRequired directly affects the receiving procedure defined in Section 5.4. An implementation SHOULD allow the operator to change the RxAuthRequired value at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of RxAuthRequired at runtime or from the system documentation.
RxAuthRequiredはブールパラメータです。デフォルト値はTRUEでなければなりません。実装は、RxAuthRequiredをインターフェイスごとのパラメーターにする必要がありますが、プロトコルインスタンス全体に固有にする必要があります。 RxAuthRequiredの概念的な目的は、認証されていないBabelパケット交換から認証されたBabelパケット交換へのスムーズな移行を可能にすることです（セクション7.3を参照）。 RxAuthRequiredの現在の値は、セクション5.4で定義された受信手順に直接影響します。実装では、オペレーターが実行時またはBabelスピーカーの再起動によってRxAuthRequired値を変更できるようにする必要があります（SHOULD）。実装では、オペレーターが実行時またはシステムのドキュメントからRxAuthRequiredの有効な値を検出できるようにする必要があります。
LocalTS is a 32-bit unsigned integer variable. It is the TS part of a per-interface TS/PC number. LocalTS is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
LocalTSは32ビットの符号なし整数変数です。これは、インターフェイスごとのTS / PC番号のTS部分です。 LocalTSは、オペレーターが変更することを意図していない、厳密にインターフェースごとの変数です。その初期化については、セクション5.1で説明します。
LocalPC is a 16-bit unsigned integer variable. It is the PC part of a per-interface TS/PC number. LocalPC is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
LocalPCは、16ビットの符号なし整数変数です。これは、インターフェイスごとのTS / PC番号のPC部分です。 LocalPCは、オペレーターが変更することを意図していない、厳密にインターフェースごとの変数です。その初期化については、セクション5.1で説明します。
MaxDigestsIn is an unsigned integer parameter conceptually purposed for limiting the amount of CPU time spent processing a received authenticated packet. The receiving procedure performs the most CPU-intensive operation -- the HMAC computation -- only at most MaxDigestsIn (Section 5.4 item 7) times for a given packet.
MaxDigestsInは、受信した認証済みパケットの処理に費やされるCPU時間の量を制限することを概念的に目的とした符号なし整数パラメーターです。受信手順は、特定のパケットに対して最大CPU集中型の操作（HMAC計算）を最大でMaxDigestsIn（セクション5.4の項目7）の回数だけ実行します。
The MaxDigestsIn value MUST be at least 2. An implementation SHOULD make MaxDigestsIn a per-interface parameter but MAY make it specific to the whole protocol instance. An implementation SHOULD allow the operator to change the value of MaxDigestsIn at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of MaxDigestsIn at runtime or from the system documentation.
MaxDigestsIn値は少なくとも2である必要があります。実装では、MaxDigestsInをインターフェイスごとのパラメーターにする必要がありますが、プロトコルインスタンス全体に固有にする必要があります。実装では、オペレーターが実行時またはBabelスピーカーの再起動によってMaxDigestsInの値を変更できるようにする必要があります（SHOULD）。実装では、オペレーターが実行時またはシステムのドキュメントからMaxDigestsInの有効な値を検出できるようにする必要があります。
MaxDigestsOut is an unsigned integer parameter conceptually purposed for limiting the amount of a sent authenticated packet's space spent on authentication data. The sending procedure adds at most MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet.
MaxDigestsOutは、認証データに費やされる送信済み認証済みパケットのスペースの量を制限することを概念的に目的とした符号なし整数パラメーターです。送信手順では、最大でMaxDigestsOut（セクション5.3アイテム5）のHMAC結果が指定されたパケットに追加されます。
The MaxDigestsOut value MUST be at least 2. An implementation SHOULD make MaxDigestsOut a per-interface parameter but MAY make it specific to the whole protocol instance. An implementation SHOULD allow the operator to change the value of MaxDigestsOut at runtime or by means of a Babel speaker restart, in a safe range. The maximum safe value of MaxDigestsOut is implementation specific (see Section 6.2). An implementation MUST allow the operator to discover the effective value of MaxDigestsOut at runtime or from the system documentation.
MaxDigestsOut値は少なくとも2である必要があります。実装では、MaxDigestsOutをインターフェイスごとのパラメーターにする必要がありますが、プロトコルインスタンス全体に固有にする必要があります（MAY）。実装は、オペレーターが実行時にMaxDigestsOutの値を変更できるようにするか、安全な範囲でBabelスピーカーを再起動できるようにする必要があります（SHOULD）。 MaxDigestsOutの最大安全値は実装固有です（セクション6.2を参照）。実装では、オペレーターが実行時またはシステムのドキュメントからMaxDigestsOutの有効な値を検出できるようにする必要があります。
The ANM (Authentic Neighbours Memory) table resembles the neighbour table defined in Section 3.2.3 of [BABEL]. Note that the term "neighbour table" means the neighbour table of the original Babel specification, and the term "ANM table" means the table defined herein. Indexing of the ANM table is done in exactly the same way as indexing of the neighbour table, but its purpose, field set, and associated procedures are different.
ANM（Authentic Neighbors Memory）テーブルは、[BABEL]のセクション3.2.3で定義されたネイバーテーブルに似ています。 「隣接テーブル」という用語は、元のバベル仕様の隣接テーブルを意味し、「ANMテーブル」という用語は、ここで定義されているテーブルを意味することに注意してください。 ANMテーブルのインデックス付けは、ネイバーテーブルのインデックス付けとまったく同じ方法で行われますが、その目的、フィールドセット、および関連する手順が異なります。
The conceptual purpose of the ANM table is to provide longer-term replay attack protection than would be possible using the neighbour table. Expiry of an inactive entry in the neighbour table depends on the last received Hello Interval of the neighbour and typically stands for tens to hundreds of seconds (see Appendixes A and B of [BABEL]). Expiry of an inactive entry in the ANM table depends only on the local speaker's configuration. The ANM table retains (for at least the amount of seconds set by the ANM timeout parameter as defined in Section 3.7) a copy of the TS/PC number advertised in authentic packets by each remote Babel speaker.
ANMテーブルの概念的な目的は、ネイバーテーブルを使用する場合よりも長期間のリプレイアタック保護を提供することです。ネイバーテーブルの非アクティブなエントリの有効期限は、ネイバーの最後に受信したHelloインターバルによって異なり、通常は数十秒から数百秒です（[BABEL]の付録AおよびBを参照）。 ANMテーブルの非アクティブなエントリの有効期限は、ローカルスピーカーの設定にのみ依存します。 ANMテーブルは（少なくともセクション3.7で定義されているANMタイムアウトパラメータで設定された秒数の間）、各リモートBabelスピーカーによって認証パケットで通知されたTS / PC番号のコピーを保持します。
The ANM table is indexed by pairs of the form (Interface, Source). Every table entry consists of the following fields:
ANMテーブルは、フォーム（インターフェース、ソース）のペアでインデックスが付けられます。すべてのテーブルエントリは、次のフィールドで構成されています。
o Interface
o インターフェース
An implementation-specific reference to the local node's interface through which the authentic packet was received.
本物のパケットが受信されたローカルノードのインターフェースへの実装固有の参照。
o Source
o ソース
The source address of the Babel speaker from which the authentic packet was received.
本物のパケットを受信したBabelスピーカーの送信元アドレス。
o LastTS
o LastTS
A 32-bit unsigned integer -- the TS part of a remote TS/PC number.
32ビットの符号なし整数-リモートTS / PC番号のTS部分。
o LastPC
o LastPC
A 16-bit unsigned integer -- the PC part of a remote TS/PC number.
16ビットの符号なし整数-リモートTS / PC番号のPC部分。
Each ANM table entry has an associated aging timer, which is reset by the receiving procedure (Section 5.4 item 9). If the timer expires, the entry is deleted from the ANM table.
各ANMテーブルエントリには、関連するエージングタイマーがあり、受信手順によってリセットされます（5.4項の項目9）。タイマーが期限切れになると、そのエントリはANMテーブルから削除されます。
An implementation SHOULD use persistent memory (NVRAM) to retain the contents of the ANM table across restarts of the Babel speaker, but only as long as both the Interface field reference and expiry of the aging timer remain correct. An implementation MUST be clear regarding if and how persistent memory is used for the ANM table. An implementation SHOULD allow the operator to retrieve the current contents of the ANM table at runtime. An implementation SHOULD allow the operator to remove some or all ANM table entries at runtime or by means of a Babel speaker restart.
実装では、Babelスピーカーの再起動後も永続メモリ（NVRAM）を使用してANMテーブルの内容を保持する必要があります（ただし、Interfaceフィールドの参照とエージングタイマーの有効期限の両方が正しい場合に限ります）。実装は、ANMテーブルに永続メモリが使用されるかどうか、およびどのように使用されるかについて明確でなければなりません。実装では、実行時にオペレーターがANMテーブルの現在の内容を取得できるようにする必要があります（SHOULD）。実装は、オペレーターが実行時またはBabelスピーカーの再起動によって一部またはすべてのANMテーブルエントリを削除できるようにする必要があります（SHOULD）。
ANM timeout is an unsigned integer parameter. An implementation SHOULD make ANM timeout a per-interface parameter but MAY make it specific to the whole protocol instance. ANM timeout is conceptually purposed for limiting the maximum age (in seconds) of entries in the ANM table that stand for inactive Babel speakers. The maximum age is immediately related to replay attack protection strength. The strongest protection is achieved with the maximum possible value of ANM timeout set, but it may not provide the best overall result for specific network segments and implementations of this mechanism.
ANMタイムアウトは、符号なし整数パラメーターです。実装は、ANMタイムアウトをインターフェイスごとのパラメーターにする必要がありますが、プロトコルインスタンス全体に固有にする必要があります（MAY）。 ANMタイムアウトは、概念的には、非アクティブなBabelスピーカーを表すANMテーブルのエントリの最大経過時間（秒単位）を制限することを目的としています。最大経過時間は、リプレイアタック保護の強さに直接関係します。最も強力な保護は、ANMタイムアウトセットの可能な最大値で達成されますが、特定のネットワークセグメントおよびこのメカニズムの実装に対して全体的に最良の結果を提供しない可能性があります。
Specifically, implementations unable to maintain the local TS/PC number strictly increasing across Babel speaker restarts will reuse the advertised TS/PC numbers after each restart (see Section 5.1). The neighbouring speakers will treat the new packets as replayed and discard them until the aging timer of the respective ANM table entry expires or the new TS/PC number exceeds the one stored in the entry.
具体的には、Babelスピーカーの再起動全体で厳密に増加するローカルTS / PC番号を維持できない実装は、再起動ごとにアドバタイズされたTS / PC番号を再利用します（セクション5.1を参照）。隣接するスピーカーは、新しいパケットを再生されたものとして扱い、それぞれのANMテーブルエントリのエージングタイマーが期限切れになるか、新しいTS / PC番号がエントリに格納されている数を超えるまで、それらを破棄します。
Another possible, but less probable, case could be an environment that uses IPv6 for the exchange of Babel datagrams and that involves physical moves of network-interface hardware between Babel speakers. Even when performed without restarting the speakers, these physical moves would cause random drops of the TS/PC number advertised for a given (Interface, Source) index, as viewed by neighbouring speakers, since IPv6 link-local addresses are typically derived from interface hardware addresses.
可能性は低いですが、もう1つのケースとして、Babelデータグラムの交換にIPv6を使用し、Babelスピーカー間でネットワークインターフェイスハードウェアを物理的に移動する環境が考えられます。スピーカーを再起動せずにこれらの物理的な移動を行った場合でも、IPv6リンクローカルアドレスは通常インターフェイスハードウェアから取得されるため、これらの物理的な移動により、特定の（インターフェイス、ソース）インデックスにアドバタイズされるTS / PC番号がランダムにドロップされます。アドレス。
Assuming that in such cases the operators would prefer to use a lower ANM timeout value to let the entries expire on their own rather than having to manually remove them from the ANM table each time, an implementation SHOULD set the default value of ANM timeout to a value between 30 and 300 seconds.
このような場合、オペレーターは、ANMタイムアウト値のデフォルト値を設定する必要があり、オペレーターは、ANMタイムアウト値のデフォルト値を設定する必要があります。 30〜300秒の値。
At the same time, network segments may exist with every Babel speaker having its advertised TS/PC number strictly increasing over the deployed lifetime. Assuming that in such cases the operators would prefer using a much higher ANM timeout value, an implementation SHOULD allow the operator to change the value of ANM timeout at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of ANM timeout at runtime or from the system documentation.
同時に、ネットワークセグメントが存在し、すべてのBabelスピーカーが、アドバタイズされたTS / PC番号が展開されたライフタイム全体で厳密に増加する場合があります。そのような場合にオペレーターがはるかに高いANMタイムアウト値を使用することを好むと仮定すると、実装はオペレーターが実行時またはBabelスピーカーの再起動によってANMタイムアウトの値を変更できるようにする必要があります。実装では、オペレーターが実行時またはシステムのドキュメントからANMタイムアウトの有効な値を検出できるようにする必要があります。
A Configured Security Association (CSA) is a data structure conceptually purposed for associating authentication keys and hash algorithms with Babel interfaces. All CSAs are managed in finite sequences, one sequence per interface (hereafter referred to as "interface's sequence of CSAs"). Each interface's sequence of CSAs, as an integral part of the Babel speaker configuration, MAY be intended for persistent storage as long as this conforms with the implementation's key-management policy. The default state of an interface's sequence of CSAs is empty, which has a special meaning of no authentication configured for the interface. The sending (Section 5.3 item 1) and the receiving (Section 5.4 item 1) procedures address this convention accordingly.
構成されたセキュリティアソシエーション（CSA）は、認証キーとハッシュアルゴリズムをBabelインターフェースに関連付けることを概念的に目的としたデータ構造です。すべてのCSAは、インターフェースごとに1つのシーケンス（以下、「インターフェースのCSAシーケンス」と呼びます）の有限シーケンスで管理されます。各インターフェースのCSAのシーケンスは、Babelスピーカー構成の不可欠な部分として、これが実装のキー管理ポリシーに準拠している限り、永続的なストレージを対象とする場合があります。インターフェイスのCSAシーケンスのデフォルト状態は空です。これは、インターフェイスに認証が設定されていないという特別な意味があります。送信（セクション5.3アイテム1）と受信（セクション5.4アイテム1）の手順は、この規則に応じて対応しています。
A single CSA structure consists of the following fields:
単一のCSA構造は、以下のフィールドで構成されています。
o HashAlgo
o HashAlgo
An implementation-specific reference to one of the hash algorithms supported by this implementation (see Section 2.1).
この実装でサポートされているハッシュアルゴリズムの1つへの実装固有の参照（セクション2.1を参照）。
o KeyChain
o キーチェーン
A finite sequence of elements (hereafter referred to as "KeyChain sequence") representing authentication keys, each element being a structure consisting of the following fields:
認証キーを表す要素の有限シーケンス（以下、「KeyChainシーケンス」と呼びます）。各要素は、次のフィールドで構成される構造です。
* LocalKeyID
* LocalKeyID
An unsigned integer of an implementation-specific bit length.
実装固有のビット長の符号なし整数。
* AuthKeyOctets
* AuthKeyOctets
A sequence of octets of an arbitrary, known length to be used as the authentication key.
認証キーとして使用される、既知の任意の長さのオクテットのシーケンス。
* KeyStartAccept
* KeyStartAccept
The time that this Babel speaker will begin considering this authentication key for accepting packets with authentication data.
このBabelスピーカーが、認証データを含むパケットを受け入れるためにこの認証キーを検討し始める時間。
* KeyStartGenerate
* KeyStartGenerate
The time that this Babel speaker will begin considering this authentication key for generating packet authentication data.
このBabelスピーカーがパケット認証データを生成するためにこの認証キーの検討を開始する時間。
* KeyStopGenerate
* KeyStopGenerate
The time that this Babel speaker will stop considering this authentication key for generating packet authentication data.
パケット認証データを生成するために、このBabelスピーカーがこの認証キーの考慮を停止する時間。
* KeyStopAccept
* KeyStopAccept
The time that this Babel speaker will stop considering this authentication key for accepting packets with authentication data.
このBabelスピーカーが、認証データを含むパケットを受け入れるためのこの認証キーの考慮を停止する時間。
Since there is no limit imposed on the number of CSAs per interface, but the number of HMAC computations per sent/received packet is limited (through MaxDigestsOut and MaxDigestsIn, respectively), it may appear that only a fraction of the associated keys and hash algorithms are used in the process. The ordering of elements within a sequence of CSAs and within a KeyChain sequence is important to make the association selection process deterministic and transparent. Once this ordering is deterministic at the Babel interface level, the intermediate data derived by the procedure defined in Section 5.2 will be deterministically ordered as well.
インターフェイスごとのCSAの数に制限はありませんが、送受信されたパケットごとのHMAC計算の数は（それぞれMaxDigestsOutとMaxDigestsInによって）制限されているため、関連するキーとハッシュアルゴリズムの一部しか表示されない場合があります。プロセスで使用されます。 CSAのシーケンス内およびKeyChainシーケンス内の要素の順序は、関連付けの選択プロセスを確定的かつ透過的にするために重要です。この順序付けがBabelインターフェースレベルで確定的になると、セクション5.2で定義された手順によって導出された中間データも確定的に順序付けされます。
An implementation SHOULD allow an operator to set any arbitrary order of elements within a given interface's sequence of CSAs and within the KeyChain sequence of a given CSA. Regardless of whether this requirement is or isn't met, the implementation MUST provide a means to discover the actual element order used. Whichever order is used by an implementation, it MUST be preserved across Babel speaker restarts.
実装では、オペレーターが、CSAの特定のインターフェースのシーケンス内および特定のCSAのKeyChainシーケンス内で要素の任意の順序を設定できるようにする必要があります（SHOULD）。この要件が満たされているかどうかに関係なく、実装では、使用されている実際の要素の順序を検出する手段を提供する必要があります。実装でどちらの順序が使用されていても、Babelスピーカーを再起動しても保持される必要があります。
Note that none of the CSA structure fields is constrained to contain unique values. Section 6.4 explains this in more detail. It is possible for the KeyChain sequence to be empty, although this is not the intended manner of using CSAs.
CSA構造フィールドは、一意の値を含むように制約されていないことに注意してください。セクション6.4でこれについて詳しく説明します。 KeyChainシーケンスが空になる可能性がありますが、これはCSAを使用する意図された方法ではありません。
The KeyChain sequence has a direct prototype, which is the "key chain" syntax item of some existing router configuration languages. If an implementation already implements this syntax item, it is suggested that the implementation reuse it, that is, implement a CSA syntax item that refers to a key chain item rather than reimplement the latter in full.
KeyChainシーケンスには直接プロトタイプがあり、これは一部の既存のルーター構成言語の「キーチェーン」構文項目です。実装がすでにこの構文項目を実装している場合、実装はそれを再利用すること、つまり、キーチェーン項目を完全に再実装するのではなく、キーチェーン項目を参照するCSA構文項目を実装することをお勧めします。
An Effective Security Association (ESA) is a data structure immediately used in sending (Section 5.3) and receiving (Section 5.4) procedures. Its conceptual purpose is to determine a runtime interface between those procedures and the deriving procedure defined in Section 5.2. All ESAs are temporary data units managed as elements of finite sequences that are not intended for persistent storage. Element ordering within each such finite sequence (hereafter referred to as "sequence of ESAs") MUST be preserved as long as the sequence exists.
効果的なセキュリティアソシエーション（ESA）は、送信（セクション5.3）および受信（セクション5.4）手順ですぐに使用されるデータ構造です。その概念的な目的は、これらのプロシージャと、セクション5.2で定義されている派生プロシージャとの間のランタイムインターフェイスを決定することです。すべてのESAは、永続的なストレージ用ではない有限シーケンスの要素として管理される一時データユニットです。シーケンスが存在する限り、そのような各有限シーケンス（以降、「ESAのシーケンス」と呼ばれます）内の要素の順序を保持する必要があります。
A single ESA structure consists of the following fields:
単一のESA構造は、次のフィールドで構成されています。
o HashAlgo
o HashAlgo
An implementation-specific reference to one of the hash algorithms supported by this implementation (see Section 2.1).
この実装でサポートされているハッシュアルゴリズムの1つへの実装固有の参照（セクション2.1を参照）。
o KeyID
o KeyID
A 16-bit unsigned integer.
16ビットの符号なし整数。
o AuthKeyOctets
o AuthKeyOctets
A sequence of octets of an arbitrary, known length to be used as the authentication key.
認証キーとして使用される、既知の任意の長さのオクテットのシーケンス。
Note that among the protocol data structures introduced by this mechanism, the ESA structure is the only one not directly interfaced with the system operator (see Figure 1 in Appendix A); it is not immediately present in the protocol encoding, either. However, the ESA structure is not just a possible implementation technique but an integral part of this specification: the deriving (Section 5.2), the sending (Section 5.3), and the receiving (Section 5.4) procedures are defined in terms of the ESA structure and its semantics provided herein. The ESA structure is as meaningful for a correct implementation as the other protocol data structures.
このメカニズムによって導入されたプロトコルデータ構造の中で、ESA構造は、システムオペレーターと直接インターフェースしない唯一のものであることに注意してください（付録Aの図1を参照）。また、プロトコルエンコーディングにもすぐには表示されません。ただし、ESA構造は単なる実装手法ではなく、この仕様の不可欠な部分です。派生（セクション5.2）、送信（セクション5.3）、および受信（セクション5.4）の手順は、ESA構造によって定義されます。ここで提供されるそのセマンティクス。 ESA構造は、他のプロトコルデータ構造と同様に、正しい実装にとって意味があります。
The choice of encoding is very important in the long term. The protocol encoding limits various authentication mechanism designs and encodings, which in turn limit future developments of the protocol.
エンコーディングの選択は、長期的には非常に重要です。プロトコルのエンコードにより、さまざまな認証メカニズムの設計とエンコードが制限され、プロトコルの将来の開発が制限されます。
Considering existing implementations of the Babel protocol instance itself and related modules of packet analysers, the current encoding of Babel allows for compact and robust decoders. At the same time, this encoding allows for future extensions of Babel by three (not excluding each other) principal means as defined in Sections 4.2 and 4.3 of [BABEL] and further discussed in [BABEL-EXTENSION]:
Babelプロトコルインスタンス自体とパケットアナライザーの関連モジュールの既存の実装を考慮すると、Babelの現在のエンコーディングでは、コンパクトで堅牢なデコーダーが可能です。同時に、このエンコーディングでは、[BABEL]のセクション4.2と4.3で定義され、[BABEL-EXTENSION]でさらに説明されているように、将来のBabelを3つ（相互に除外しない）の主要な手段で拡張できます。
a. A Babel packet consists of a four-octet header followed by a packet body, that is, a sequence of TLVs (see Figure 2 in Appendix A). Besides the header and the body, an actual Babel
a. Babelパケットは、4オクテットのヘッダーとその後に続くパケット本体、つまりTLVのシーケンスで構成されます（付録Aの図2を参照）。ヘッダーと本文の他に、実際のバベル
datagram may have an arbitrary amount of trailing data between the end of the packet body and the end of the datagram. An instance of the original protocol silently ignores such trailing data.
データグラムには、パケット本体の終わりとデータグラムの終わりの間に任意の量の後続データが含まれる場合があります。元のプロトコルのインスタンスは、そのような後続のデータを黙って無視します。
b. The packet body uses a binary format allowing for 256 TLV types and imposing no requirements on TLV ordering or number of TLVs of a given type in a packet. [BABEL] allocates TLV types 0 through 10 (see Table 1 in Appendix A), defines the TLV body structure for each, and establishes the requirement for a Babel protocol instance to ignore any unknown TLV types silently. This makes it possible to examine a packet body (to validate the framing and/or to pick particular TLVs for further processing), taking into account only the type (to distinguish between a Pad1 TLV and any other TLV) and the length of each TLV, regardless of whether any additional TLV types are eventually deployed (and if so, how many).
b. パケット本体はバイナリ形式を使用して、256のTLVタイプを可能にし、パケット内の特定のタイプのTLVの順序またはTLVの数に要件を課しません。 [BABEL]は、TLVタイプ0〜10（付録Aの表1を参照）を割り当て、それぞれにTLV本体構造を定義し、不明なTLVタイプをサイレントに無視するBabelプロトコルインスタンスの要件を確立します。これにより、タイプ（Pad1 TLVと他のTLVを区別するため）と各TLVの長さのみを考慮して、パケットボディを検査（フレーミングを検証したり、特定のTLVを選択してさらに処理したり）したりできます。 、追加のTLVタイプが最終的に展開されるかどうか（および展開される場合はその数）に関係なく。
c. Within each TLV of the packet body, there may be some extra data after the expected length of the TLV body. An instance of the original protocol silently ignores any such extra data. Note that any TLV types without the expected length defined (such as the PadN TLV) cannot be extended with the extra data.
c. パケット本体の各TLV内で、TLV本体の予想される長さの後にいくつかの追加データがある場合があります。元のプロトコルのインスタンスは、そのような余分なデータを黙って無視します。予期される長さが定義されていないTLVタイプ（PadN TLVなど）は、追加のデータで拡張できないことに注意してください。
Considering each of these three principal extension means for the specific purpose of adding authentication data items to each protocol packet, the following arguments can be made:
認証データ項目を各プロトコルパケットに追加するという特定の目的のために、これら3つの主要な拡張手段のそれぞれを考慮して、次の引数を作成できます。
o The use of the TLV extra data of some existing TLV type would not be a solution, since no particular TLV type is guaranteed to be present in a Babel packet.
o 特定のTLVタイプがBabelパケットに存在することが保証されていないため、一部の既存のTLVタイプのTLV追加データを使用しても解決策にはなりません。
o The use of the TLV extra data could also conflict with future developments of the protocol encoding.
o TLVの追加データの使用も、プロトコルエンコーディングの将来の開発と競合する可能性があります。
o Since the packet trailing data is currently unstructured, using it would involve defining an encoding structure and associated procedures; this would add to the complexity of both specification and implementation and would increase exposure to protocol attacks such as fuzzing.
o パケットのトレーリングデータは現在構造化されていないため、これを使用するには、エンコード構造と関連するプロシージャを定義する必要があります。これにより、仕様と実装の両方が複雑になり、ファジングなどのプロトコル攻撃の危険性が高まります。
o A naive use of the packet trailing data would make it unavailable to any future extension of Babel. Since this mechanism is possibly not the last extension and since some other extensions may allow no other embedding means except the packet trailing data, the defined encoding structure would have to enable the multiplexing of data items belonging to different extensions. Such a definition is out of the scope of this work.
o パケットの末尾データを単純に使用すると、将来のバベルの拡張では使用できなくなります。このメカニズムは最後の拡張ではない可能性があり、他の一部の拡張ではパケットの後続データ以外の埋め込み手段が許可されない可能性があるため、定義されたエンコード構造は、異なる拡張に属するデータ項目の多重化を有効にする必要があります。そのような定義はこの作業の範囲外です。
o Deprecating an extension (or only its protocol encoding) that uses purely purpose-allocated TLVs is as simple as deprecating the TLVs.
o 純粋に目的に割り当てられたTLVを使用する拡張機能（またはそのプロトコルエンコーディングのみ）を廃止するのは、TLVを廃止するのと同じくらい簡単です。
o The use of purpose-allocated TLVs is transparent for both the original protocol and any its future extensions, regardless of the embedding technique(s) used by the latter.
o 目的に割り当てられたTLVの使用は、後者が使用する埋め込み手法に関係なく、元のプロトコルとその将来の拡張の両方に対して透過的です。
Considering all of the above, this mechanism uses neither the packet trailing data nor the TLV extra data but uses two new TLV types: type 11 for a TS/PC number and type 12 for an HMAC result (see Table 1 in Appendix A).
上記のすべてを考慮すると、このメカニズムはパケットの後続データもTLVの追加データも使用せず、TS / PC番号のタイプ11とHMAC結果のタイプ12の2つの新しいTLVタイプを使用します（付録Aの表1を参照）。
The purpose of a TS/PC TLV is to store a single TS/PC number. There is exactly one TS/PC TLV in an authenticated Babel packet.
TS / PC TLVの目的は、単一のTS / PC番号を格納することです。認証されたBabelパケットには、TS / PC TLVが1つだけあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length | PacketCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type Set to 11 to indicate a TS/PC TLV.
「11に設定」と入力して、TS / PC TLVを示します。
Length The length, in octets, of the body, exclusive of the Type and Length fields.
長さタイプと長さフィールドを除く、ボディの長さ（オクテット単位）。
PacketCounter A 16-bit unsigned integer in network byte order -- the PC part of a TS/PC number stored in this TLV.
PacketCounterネットワークバイトオーダーの16ビット符号なし整数-このTLVに格納されているTS / PC番号のPC部分。
Timestamp A 32-bit unsigned integer in network byte order -- the TS part of a TS/PC number stored in this TLV.
タイムスタンプネットワークバイトオーダーの32ビット符号なし整数-このTLVに格納されているTS / PC番号のTS部分。
Note that the ordering of PacketCounter and Timestamp in the TLV structure is the opposite of the ordering of TS and PC in the TS/PC number and the 48-bit equivalent (see Section 2.3).
TLV構造でのPacketCounterとTimestampの順序は、TS / PC番号でのTSとPCの順序および48ビットの同等のものとは逆であることに注意してください（セクション2.3を参照）。
Considering the expected length and the extra data as mentioned in Section 4.3 of [BABEL], the expected length of a TS/PC TLV body is unambiguously defined as 6 octets. The receiving procedure would correctly process any TS/PC TLV with body length not less than the expected length, ignoring any extra data (Section 5.4 items 3 and 9).
[BABEL]のセクション4.3で説明されている予想される長さと追加のデータを考慮すると、TS / PC TLV本体の予想される長さは6オクテットとして明確に定義されています。受信手順では、余分なデータを無視して、本文の長さが予想される長さ以上のTS / PC TLVを正しく処理します（セクション5.4の項目3および9）。
The sending procedure produces a TS/PC TLV with body length equal to the expected length and the Length field, respectively, set as described in Section 5.3 item 3.
送信手順では、セクション長5.3の項目3で説明されているように設定された、予想される長さに等しいボディ長とLengthフィールドを持つTS / PC TLVを生成します。
Future Babel extensions (such as sub-TLVs) MAY modify the sending procedure to include the extra data after the fixed-size TS/PC TLV body defined herein, making adjustments to the Length TLV field, the "Body length" packet header field, and output buffer management (as explained in Section 6.2) necessary.
今後のBabel拡張機能（サブTLVなど）は、ここで定義された固定サイズのTS / PC TLV本体の後に追加データを含めるように送信手順を変更し、Length TLVフィールド、「Body length」パケットヘッダーフィールド、必要な出力バッファ管理（6.2で説明）。
The purpose of an HMAC TLV is to store a single HMAC result. To assist a receiver in reproducing the HMAC computation, LocalKeyID modulo 2^16 of the authentication key is also provided in the TLV. There is at least one HMAC TLV in an authenticated Babel packet.
HMAC TLVの目的は、単一のHMAC結果を格納することです。受信者がHMAC計算を再現するのを支援するために、認証キーの2 ^ 16を法とするLocalKeyIDもTLVで提供されます。認証されたBabelパケットに少なくとも1つのHMAC TLVがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | KeyID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest...
+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type Set to 12 to indicate an HMAC TLV.
Set to 12と入力して、HMAC TLVを示します。
Length The length, in octets, of the body, exclusive of the Type and Length fields.
長さタイプと長さフィールドを除く、ボディの長さ（オクテット単位）。
KeyID A 16-bit unsigned integer in network byte order.
KeyIDネットワークバイトオーダーの16ビット符号なし整数。
Digest A variable-length sequence of octets that is at least 16 octets long (see Section 2.2).
ダイジェスト少なくとも16オクテットの長さのオクテットの可変長シーケンス（セクション2.2を参照）。
Considering the expected length and the extra data as mentioned in Section 4.3 of [BABEL], the expected length of an HMAC TLV body is not defined. The receiving and padding procedures process every octet of the Digest field, deriving the field boundary from the Length field value (Section 5.4 item 7 and Section 2.2, respectively). The sending procedure produces HMAC TLVs with the Length field precisely sizing the Digest field to match the digest length of the hash algorithm used (Section 5.3 items 5 and 8).
予想される長さと[BABEL]のセクション4.3で説明されている追加データを考慮すると、HMAC TLV本体の予想される長さは定義されていません。受信およびパディング手順は、ダイジェストフィールドのすべてのオクテットを処理し、Lengthフィールド値からフィールド境界を導出します（それぞれセクション5.4アイテム7およびセクション2.2）。送信手順では、長さフィールドが使用されるハッシュアルゴリズムのダイジェスト長と一致するようにダイジェストフィールドのサイズを正確に設定したHMAC TLVを生成します（セクション5.3アイテム5および8）。
The HMAC TLV structure defined herein is final. Future Babel extensions MUST NOT extend it with any extra data.
ここで定義されているHMAC TLV構造は最終的なものです。将来のBabel拡張機能では、追加のデータを使用して拡張しないでください。
The LocalTS and LocalPC interface-specific variables constitute the TS/PC number of a Babel interface. This number is advertised in the TS/PC TLV of authenticated Babel packets sent from that interface. There is only one property that is mandatory for the advertised TS/PC number: its 48-bit equivalent (see Section 2.3) MUST be strictly increasing within the scope of a given interface of a Babel speaker as long as the protocol instance is continuously operating. This property, combined with ANM tables of neighbouring Babel speakers, provides them with the most basic replay attack protection.
LocalTSおよびLocalPCインターフェイス固有の変数は、BabelインターフェイスのTS / PC番号を構成します。この番号は、そのインターフェイスから送信された認証済みBabelパケットのTS / PC TLVでアドバタイズされます。アドバタイズされたTS / PC番号に必須のプロパティは1つだけです：48ビット相当（セクション2.3を参照）は、プロトコルインスタンスが継続的に動作している限り、Babelスピーカーの特定のインターフェースの範囲内で厳密に増加している必要があります。 。このプロパティは、隣接するBabelスピーカーのANMテーブルと組み合わせて、最も基本的なリプレイアタック保護を提供します。
Initialization and increment are two principal updates performed on an interface TS/PC number. The initialization is performed when a new interface becomes a part of a Babel protocol instance. The increment is performed by the sending procedure (Section 5.3 item 2) before advertising the TS/PC number in a TS/PC TLV.
初期化と増分は、インターフェイスTS / PC番号で実行される2つの主要な更新です。新しいインターフェイスがBabelプロトコルインスタンスの一部になると、初期化が実行されます。増分は、TS / PC TLVでTS / PC番号をアドバタイズする前に、送信手順（セクション5.3アイテム2）によって実行されます。
Depending on the particular implementation method of these two updates, the advertised TS/PC number may possess additional properties that improve the replay attack protection strength. This includes, but is not limited to, the methods below.
これら2つの更新の特定の実装方法によっては、アドバタイズされたTS / PC番号に、リプレイアタック保護の強度を向上させる追加のプロパティがある場合があります。これには、以下の方法が含まれますが、これに限定されません。
a. The most straightforward implementation would use LocalTS as a plain wrap counter, defining the updates as follows:
a. 最も単純な実装では、LocalTSをプレーンラップカウンターとして使用し、更新を次のように定義します。
initialization Set LocalPC to 0, and set LocalTS to 0.
初期化LocalPCを0に設定し、LocalTSを0に設定します。
increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF + 1 = 0x0000), increment LocalTS by 1.
LocalPCがラップする場合（0xFFFF + 1 = 0x0000）、LocalPCを1だけ増分します。LocalTSを1だけ増分します。
In this case, the advertised TS/PC numbers would be reused after each Babel protocol instance restart, making neighbouring speakers reject authenticated packets until the respective ANM table entries expire or the new TS/PC number exceeds the old (see Sections 3.6 and 3.7).
この場合、アドバタイズされたTS / PC番号は、各Babelプロトコルインスタンスの再起動後に再利用され、それぞれのANMテーブルエントリが期限切れになるか、新しいTS / PC番号が古い値を超えるまで、隣接するスピーカーが認証済みパケットを拒否します（セクション3.6および3.7を参照） 。
b. A more advanced implementation could make use of any 32-bit unsigned integer timestamp (number of time units since an arbitrary epoch), such as the UNIX timestamp, if the timestamp itself spans a reasonable time range and is guaranteed against a decrease (such as one resulting from network time use). The updates would be defined as follows:
b. タイムスタンプ自体が妥当な時間範囲にまたがり、減少が保証されている場合、より高度な実装では、UNIXタイムスタンプなどの32ビットの符号なし整数タイムスタンプ（任意のエポックからの時間単位の数）を利用できます（ネットワーク時間の使用に起因するもの）。更新は次のように定義されます。
initialization Set LocalPC to 0, and set LocalTS to 0.
初期化LocalPCを0に設定し、LocalTSを0に設定します。
increment If the current timestamp is greater than LocalTS, set LocalTS to the current timestamp and LocalPC to 0, then consider the update complete. Otherwise, increment LocalPC by 1, and if LocalPC wraps, increment LocalTS by 1.
increment現在のタイムスタンプがLocalTSより大きい場合は、LocalTSを現在のタイムスタンプに設定し、LocalPCを0に設定してから、更新が完了したと見なします。それ以外の場合は、LocalPCを1増やし、LocalPCがラップする場合は、LocalTSを1増やします。
In this case, the advertised TS/PC number would remain unique across the speaker's deployed lifetime without the need for any persistent storage. However, a suitable timestamp source is not available in every implementation case.
この場合、アドバタイズされたTS / PC番号は、永続的なストレージを必要とせずに、スピーカーの展開ライフタイム全体で一意のままです。ただし、適切なタイムスタンプソースがすべての実装ケースで利用できるわけではありません。
c. Another advanced implementation could use LocalTS in a way similar to the "wrap/boot count" suggested in Section 4.1 of [OSPF3-AUTH-BIS], defining the updates as follows:
c. 別の高度な実装では、[OSPF3-AUTH-BIS]のセクション4.1で提案されている「wrap / boot count」と同様の方法でLocalTSを使用し、更新を次のように定義します。
initialization Set LocalPC to 0. If there is a TS value stored in NVRAM for the current interface, set LocalTS to the stored TS value, then increment the stored TS value by 1. Otherwise, set LocalTS to 0, and set the stored TS value to 1.
初期化LocalPCを0に設定します。現在のインターフェースのTS値がNVRAMに保存されている場合は、LocalTSを保存されているTS値に設定し、保存されているTS値を1増やします。それ以外の場合は、LocalTSを0に設定し、保存されているTS値を設定します。 1に。
increment Increment LocalPC by 1. If LocalPC wraps, set LocalTS to the TS value stored in NVRAM for the current interface, then increment the stored TS value by 1.
increment LocalPCを1だけインクリメントします。LocalPCがラップする場合は、LocalTSを現在のインターフェイスのNVRAMに保存されているTS値に設定し、保存されているTS値を1だけインクリメントします。
In this case, the advertised TS/PC number would also remain unique across the speaker's deployed lifetime, relying on NVRAM for storing multiple TS numbers, one per interface.
この場合、アドバタイズされたTS / PC番号は、スピーカーの展開されたライフタイム全体で一意のままであり、NVRAMを使用して、インターフェイスごとに1つずつ、複数のTS番号を保存します。
As long as the TS/PC number retains its mandatory property stated above, it is up to the implementor to determine which methods of TS/ PC number updates are available and whether the operator can configure the method per interface and/or at runtime. However, an implementation MUST disclose the essence of each update method it includes, in a comprehensible form such as natural language description, pseudocode, or source code. An implementation MUST allow the operator to discover which update method is effective for any given interface, either at runtime or from the system documentation. These requirements are necessary to enable the optimal (see Section 3.7) management of ANM timeout in a network segment.
TS / PC番号が上記の必須プロパティを保持している限り、TS / PC番号の更新のどのメソッドを使用できるか、およびオペレーターがインターフェイスごとまたは実行時にメソッドを構成できるかどうかを決定するのは実装者の責任です。ただし、実装は、それが含む各更新メソッドの本質を、自然言語の説明、疑似コード、またはソースコードなどのわかりやすい形式で開示する必要があります。実装は、実行時またはシステムのドキュメントから、オペレーターが特定のインターフェイスに有効な更新方法を発見できるようにする必要があります。これらの要件は、ネットワークセグメントでANMタイムアウトを最適に（セクション3.7を参照）管理できるようにするために必要です。
Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is unlikely, but possible, causing the advertised TS/PC number to be reused. Resolving this situation requires replacing all authentication keys of the involved interface. In addition to that, if the wrap was caused by a timestamp reaching its end of epoch, using this mechanism will be impossible for the involved interface until some different timestamp or update implementation method is used.
LastTSのラッピング（0xFFFFFFFF + 1 = 0x00000000）は起こりそうにありませんが可能であり、アドバタイズされたTS / PC番号が再利用されることに注意してください。この状況を解決するには、関連するインターフェースのすべての認証キーを置き換える必要があります。それに加えて、タイムスタンプがエポックの終わりに達したためにラップが発生した場合、このメカニズムを使用することは、いくつかの異なるタイムスタンプまたは更新の実装方法が使用されるまで、関係するインターフェースでは不可能です。
Neither receiving nor sending procedures work with the contents of an interface's sequence of CSAs directly; both (Section 5.4 item 4 and Section 5.3 item 4, respectively) derive a sequence of ESAs from the sequence of CSAs and use the derived sequence (see Figure 1 in Appendix A). There are two main goals achieved through this indirection:
受信手順も送信手順も、インターフェースの一連のCSAの内容を直接処理することはできません。両方（それぞれセクション5.4のアイテム4とセクション5.3のアイテム4）は、CSAのシーケンスからESAのシーケンスを導出し、派生シーケンスを使用します（付録Aの図1を参照）。この間接化によって達成される主な目標は2つあります。
o Elimination of expired authentication keys and deduplication of security associations. This is done as early as possible to keep subsequent procedures focused on their respective tasks.
o 期限切れの認証キーの排除とセキュリティアソシエーションの重複排除。これは、後続の手順をそれぞれのタスクに集中させるために、できるだけ早く行われます。
o Maintenance of particular ordering within the derived sequence of ESAs. The ordering deterministically depends on the ordering within the interface's sequence of CSAs and the ordering within the KeyChain sequence of each CSA. The particular correlation maintained by this procedure implements a concept of fair (independent of the number of keys contained by each) competition between CSAs.
o ESAの派生シーケンス内の特定の順序の維持。順序付けは、インターフェースのCSAシーケンス内の順序と各CSAのKeyChainシーケンス内の順序に決定的に依存します。この手順によって維持される特定の相関関係は、CSA間の公平な（それぞれに含まれる鍵の数に関係なく）競争の概念を実装します。
The deriving procedure uses the following input arguments:
派生プロシージャは、次の入力引数を使用します。
o input sequence of CSAs
o CSAの入力シーケンス
o direction (sending or receiving)
o 方向（送信または受信）
o current time (CT) The processing of input arguments begins with an empty output sequence of ESAs and consists of the following steps:
o現在時刻（CT）入力引数の処理は、ESAの空の出力シーケンスで始まり、次のステップで構成されます。
1. Make a temporary copy of the input sequence of CSAs.
1. CSAの入力シーケンスの一時的なコピーを作成します。
2. Remove all expired authentication keys from each KeyChain sequence of the copy, that is, any keys such that:
2. コピーの各KeyChainシーケンスから期限切れの認証キーをすべて削除します。つまり、次のようなキーを削除します。
* for receiving: KeyStartAccept is greater than CT or KeyStopAccept is less than CT
* 受信用：KeyStartAcceptがCTより大きいか、KeyStopAcceptがCTより小さい
* for sending: KeyStartGenerate is greater than CT or KeyStopGenerate is less than CT
* 送信用：KeyStartGenerateがCTより大きいか、KeyStopGenerateがCTより小さい
Note well that there are no special exceptions. Remove all expired keys, even if there are no keys left after that (see Section 7.4).
特別な例外はないことに注意してください。その後にキーが残っていなくても、期限切れのキーをすべて削除します（セクション7.4を参照）。
3. Use the copy to populate the output sequence of ESAs as follows:
3. コピーを使用して、ESAの出力シーケンスに次のように入力します。
3.1. When the KeyChain sequence of the first CSA contains at least one key, use its first key to produce an ESA with fields set as follows:
3.1. 最初のCSAのKeyChainシーケンスに少なくとも1つのキーが含まれている場合、最初のキーを使用して、次のように設定されたフィールドを持つESAを作成します。
HashAlgo Set to HashAlgo of the current CSA.
HashAlgo現在のCSAのHashAlgoに設定します。
KeyID Set to LocalKeyID modulo 2^16 of the current key of the current CSA.
KeyID現在のCSAの現在のキーの2 ^ 16を法とするLocalKeyIDに設定します。
AuthKeyOctets Set to AuthKeyOctets of the current key of the current CSA.
AuthKeyOctets現在のCSAの現在のキーのAuthKeyOctetsに設定します。
Append this ESA to the end of the output sequence.
このESAを出力シーケンスの最後に追加します。
3.2. When the KeyChain sequence of the second CSA contains at least one key, use its first key the same way, and so forth until all first keys of the copy are processed.
3.2. 2番目のCSAのKeyChainシーケンスに少なくとも1つのキーが含まれている場合、コピーのすべての最初のキーが処理されるまで、最初のキーを同じように使用します。
3.3. When the KeyChain sequence of the first CSA contains at least two keys, use its second key the same way.
3.3. 最初のCSAのKeyChainシーケンスに少なくとも2つのキーが含まれている場合は、2番目のキーを同じ方法で使用します。
3.4. When the KeyChain sequence of the second CSA contains at least two keys, use its second key the same way, and so forth until all second keys of the copy are processed.
3.4. 2番目のCSAのKeyChainシーケンスに少なくとも2つのキーが含まれている場合は、2番目のキーを同じように使用し、コピーの2番目のキーがすべて処理されるまで続けます。
3.5. ...and so forth, until all keys of all CSAs of the copy are processed, exactly once each.
3.5. ...など、コピーのすべてのCSAのすべてのキーが処理されるまで、それぞれ1回だけです。
In the description above, the ordinals ("first", "second", and so on) with regard to keys stand for an element position after the removal of expired keys, not before. For example, if a KeyChain sequence was { Ka, Kb, Kc, Kd } before the removal and became { Ka, Kd } after, then Ka would be the "first" element and Kd would be the "second".
上記の説明では、キーに関する序数（「1番目」、「2番目」など）は、期限切れのキーを削除する前ではなく、削除した後の要素の位置を表しています。たとえば、KeyChainシーケンスが削除前は{Ka、Kb、Kc、Kd}で、その後{Ka、Kd}になった場合、Kaは「最初の」要素、Kdは「2番目の」要素になります。
4. Deduplicate the ESAs in the output sequence; that is, wherever two or more ESAs exist that share the same (HashAlgo, KeyID, AuthKeyOctets) triplet value, remove all of these ESAs except the one closest to the beginning of the sequence.
4. ESAを出力シーケンスで重複排除します。つまり、同じ（HashAlgo、KeyID、AuthKeyOctets）トリプレット値を共有するESAが2つ以上存在する場合は、シーケンスの先頭に最も近いESAを除いて、これらのESAをすべて削除します。
The resulting sequence will contain zero or more unique ESAs, ordered in a way deterministically correlated with the ordering of CSAs within the original input sequence of CSAs and the ordering of keys within each KeyChain sequence. This ordering maximizes the probability of having an equal amount of keys per original CSA in any N first elements of the resulting sequence. Possible optimizations of this deriving procedure are outlined in Section 6.3.
結果のシーケンスには、ゼロ以上の一意のESAが含まれ、CSAの元の入力シーケンス内のCSAの順序および各KeyChainシーケンス内のキーの順序と決定的に相関する方法で順序付けされます。この順序付けにより、元のCSAごとに、結果のシーケンスの最初のN個の要素に同じ量のキーが含まれる確率が最大になります。この導出手順の可能な最適化は、セクション6.3で概説されています。
Perform the following authentication-specific processing after the instance of the original protocol considers an outgoing Babel packet ready for sending, but before the packet is actually sent (see Figure 1 in Appendix A). After that, send the packet, regardless of whether the authentication-specific processing modified the outgoing packet or left it intact.
元のプロトコルのインスタンスが送信の準備ができている発信Babelパケットを検討した後、実際にパケットが送信される前に、次の認証固有の処理を実行します（付録Aの図1を参照）。その後、認証固有の処理によって発信パケットが変更されたか、そのままにされたかに関係なく、パケットを送信します。
1. If the current outgoing interface's sequence of CSAs is empty, finish authentication-specific processing and consider the packet ready for sending.
1. 現在の発信インターフェイスのCSAのシーケンスが空の場合は、認証固有の処理を終了し、パケットを送信する準備ができていると見なします。
2. Increment the TS/PC number of the current outgoing interface, as explained in Section 5.1.
2. セクション5.1で説明されているように、現在の発信インターフェイスのTS / PC番号を増やします。
3. Add to the packet body (see the note at the end of this section) a TS/PC TLV with fields set as follows:
3. パケット本文に（このセクションの最後の注を参照）、次のように設定されたフィールドを持つTS / PC TLVを追加します。
Type Set to 11.
タイプを11に設定します。
Length Set to 6.
長さを6に設定します。
PacketCounter Set to the current value of the LocalPC variable of the current outgoing interface.
PacketCounter現在の発信インターフェイスのLocalPC変数の現在の値に設定します。
Timestamp Set to the current value of the LocalTS variable of the current outgoing interface.
Timestamp現在の発信インターフェイスのLocalTS変数の現在の値に設定します。
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
4. Derive a sequence of ESAs, using the procedure defined in Section 5.2, with the current interface's sequence of CSAs as the input sequence of CSAs, the current time as CT, and "sending" as the direction. Proceed to the next step even if the derived sequence is empty.
4. セクション5.2で定義された手順を使用して、現在のインターフェースのCSAのシーケンスをCSAの入力シーケンスとして、現在の時刻をCTとして、「送信」を方向として、ESAのシーケンスを導出します。派生シーケンスが空の場合でも、次の手順に進みます。
5. Iterate over the derived sequence, using its ordering. For each ESA, add to the packet body (see the note at the end of this section) an HMAC TLV with fields set as follows:
5. 順序付けを使用して、派生シーケンスを反復します。各ESAについて、次のように設定されたフィールドを持つHMAC TLVをパケット本文に追加します（このセクションの最後の注を参照）。
Type Set to 12.
タイプを12に設定します。
Length Set to 2 plus the digest length of HashAlgo of the current ESA.
長さ2に設定し、現在のESAのHashAlgoのダイジェスト長を加えます。
KeyID Set to KeyID of the current ESA.
KeyID現在のESAのKeyIDに設定します。
Digest Size exactly equal to the digest length of HashAlgo of the current ESA. Pad (see Section 2.2), using the source address of the current packet (see Section 6.1).
ダイジェストサイズは、現在のESAのHashAlgoのダイジェスト長とまったく同じです。現在のパケットの送信元アドレスを使用してパッド（セクション2.2を参照）（セクション6.1を参照）。
As soon as there are MaxDigestsOut HMAC TLVs added to the current packet body, immediately proceed to the next step.
MaxDigestsOut HMAC TLVが現在のパケット本体に追加されたらすぐに、次のステップに進みます。
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
6. Increment the "Body length" field value of the current packet header by the total length of TS/PC and HMAC TLVs appended to the current packet body so far.
6. 現在のパケットボディに現在追加されているTS / PCおよびHMAC TLVの合計の長さだけ、現在のパケットヘッダーの「ボディ長」フィールドの値を増分します。
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
7. Make a temporary copy of the current packet.
7. 現在のパケットの一時的なコピーを作成します。
8. Iterate over the derived sequence again, using the same order and number of elements. For each ESA (and, respectively, for each HMAC TLV recently appended to the current packet body), compute an HMAC result (see Section 2.4), using the temporary copy (not the original packet) as Text, HashAlgo of the current ESA as H, and AuthKeyOctets of the current ESA as K. Write the HMAC result to the Digest field of the current HMAC TLV (see Table 4 in Appendix A) of the current packet (not the copy).
8. 同じ順序と数の要素を使用して、派生シーケンスを繰り返します。各ESA（および、それぞれ、現在のパケット本体に最近追加された各HMAC TLV）について、一時的なコピー（元のパケットではない）をテキストとして、現在のESAのHashAlgoを使用して、HMACの結果（セクション2.4を参照）を計算します。 H、および現在のESAのAuthKeyOctetsをKとして。現在のパケット（コピーではない）の現在のHMAC TLV（付録Aの表4を参照）のDigestフィールドにHMAC結果を書き込みます。
9. After this point, allow no more changes to the current packet header and body, and consider it ready for sending.
9. この後、現在のパケットヘッダーと本文に変更を加えないようにし、送信の準備ができていると見なします。
Note that even when the derived sequence of ESAs is empty, the packet is sent anyway, with only a TS/PC TLV appended to its body. Although such a packet would not be authenticated, the presence of the sole TS/PC TLV would indicate authentication key exhaustion to operators of neighbouring Babel speakers. See also Section 7.4.
ESAの派生シーケンスが空の場合でも、パケットはとにかく送信され、TS / PC TLVのみが本文に追加されます。そのようなパケットは認証されませんが、唯一のTS / PC TLVの存在は、隣接するBabelスピーカーのオペレーターに認証キーの枯渇を示します。セクション7.4も参照してください。
Also note that it is possible to place the authentication-specific TLVs in the packet's sequence of TLVs in a number of different valid ways so long as there is exactly one TS/PC TLV in the sequence and the ordering of HMAC TLVs relative to each other, as produced in step 5 above, is preserved.
また、シーケンスに1つのTS / PC TLVがあり、HMAC TLVが相互に順序付けされている限り、パケットのTLVシーケンスに認証固有のTLVをさまざまな有効な方法で配置できることに注意してください。上記のステップ5で作成されたように、保存されます。
For example, see Figure 2 in Appendix A. The diagrams represent a Babel packet without (D1) and with (D2, D3, D4) authentication-specific TLVs. The optional trailing data block that is present in D1 is preserved in D2, D3, and D4. Indexing (1, 2, ..., n) of the HMAC TLVs means the order in which the sending procedure produced them (and, respectively, the HMAC results). In D2, the added TLVs are appended: the previously existing TLVs are followed by the TS/PC TLV, which is followed by the HMAC TLVs. In D3, the added TLVs are prepended: the TS/PC TLV is the first and is followed by the HMAC TLVs, which are followed by the previously existing TLVs. In D4, the added TLVs are intermixed with the previously existing TLVs and the TS/PC TLV is placed after the HMAC TLVs. All three packets meet the requirements above.
たとえば、付録Aの図2を参照してください。これらの図は、認証固有のTLVがある（D1）とない（D2、D3、D4）のBabelパケットを表しています。 D1に存在するオプションの後続データブロックは、D2、D3、およびD4に保持されます。 HMAC TLVのインデックス付け（1、2、...、n）は、送信プロシージャがそれらを生成した順序（およびHMACの結果）を意味します。 D2では、追加されたTLVが追加されます。以前に存在したTLVの後にTS / PC TLVが続き、その後にHMAC TLVが続きます。 D3では、追加されたTLVが先頭に追加されます。TS/ PC TLVが最初で、その後にHMAC TLVが続き、その後に既存のTLVが続きます。 D4では、追加されたTLVが既存のTLVと混合され、TS / PC TLVがHMAC TLVの後に配置されます。 3つのパケットはすべて上記の要件を満たしています。
Implementors SHOULD use appending (D2) for adding the authentication-specific TLVs to the sequence; this is expected to result in more straightforward implementation and troubleshooting in most use cases.
実装者は、認証固有のTLVをシーケンスに追加するために追加（D2）を使用する必要があります（SHOULD）。これにより、ほとんどのユースケースでより簡単な実装とトラブルシューティングが実現することが期待されます。
Perform the following authentication-specific processing after an incoming Babel packet is received from the local network stack but before it is acted upon by the Babel protocol instance (see Figure 1 in Appendix A). The final action conceptually depends not only upon the result of the authentication-specific processing but also on the current value of the RxAuthRequired parameter. Immediately after any processing step below accepts or refuses the packet, either deliver the packet to the instance of the original protocol (when the packet is accepted or RxAuthRequired is FALSE) or discard it (when the packet is refused and RxAuthRequired is TRUE).
ローカルネットワークスタックから着信Babelパケットを受信した後、Babelプロトコルインスタンスによって処理される前に、次の認証固有の処理を実行します（付録Aの図1を参照）。最終的なアクションは、概念的には、認証固有の処理の結果だけでなく、RxAuthRequiredパラメータの現在の値にも依存します。以下の処理ステップがパケットを受け入れるか拒否した直後に、パケットを元のプロトコルのインスタンスに配信する（パケットが受け入れられるか、RxAuthRequiredがFALSEの場合）か、それを破棄します（パケットが拒否され、RxAuthRequiredがTRUEの場合）。
1. If the current incoming interface's sequence of CSAs is empty, accept the packet.
1. 現在の着信インターフェイスのCSAのシーケンスが空の場合は、パケットを受け入れます。
2. If the current packet does not contain exactly one TS/PC TLV, refuse it.
2. 現在のパケットにTS / PC TLVが1つだけ含まれていない場合は、拒否します。
3. Perform a lookup in the ANM table for an entry having Interface equal to the current incoming interface and Source equal to the source address of the current packet. If such an entry does not exist, immediately proceed to the next step. Otherwise, compare the entry's LastTS and LastPC field values with the Timestamp and PacketCounter values, respectively, of the TS/PC TLV of the packet. That is, refuse the packet if at least one of the following two conditions is true:
3. 現在の着信インターフェイスに等しいインターフェイスと現在のパケットの送信元アドレスに等しいソースを持つエントリについて、ANMテーブルで検索を実行します。そのようなエントリが存在しない場合は、すぐに次の手順に進みます。それ以外の場合は、エントリのLastTSおよびLastPCフィールド値を、パケットのTS / PC TLVのTimestampおよびPacketCounter値とそれぞれ比較します。つまり、次の2つの条件の少なくとも1つが当てはまる場合、パケットを拒否します。
* Timestamp is less than LastTS
* タイムスタンプがLastTSより小さい
* Timestamp is equal to LastTS and PacketCounter is not greater than LastPC
* タイムスタンプはLastTSに等しく、PacketCounterはLastPC以下です
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
4. Derive a sequence of ESAs, using the procedure defined in Section 5.2, with the current interface's sequence of CSAs as the input sequence of CSAs, current time as CT, and "receiving" as the direction. If the derived sequence is empty, refuse the packet.
4. セクション5.2で定義されている手順を使用して、現在のインターフェースのCSAのシーケンスをCSAの入力シーケンス、現在の時刻をCT、「受信」を方向として、ESAのシーケンスを導出します。派生シーケンスが空の場合、パケットを拒否します。
5. Make a temporary copy of the current packet.
5. 現在のパケットの一時的なコピーを作成します。
6. Pad (see Section 2.2) every HMAC TLV present in the temporary copy (not the original packet), using the source address of the original packet.
6. 元のパケットの送信元アドレスを使用して、（元のパケットではなく）一時コピーに存在するすべてのHMAC TLVをパディングします（セクション2.2を参照）。
7. Iterate over all the HMAC TLVs of the original input packet (not the copy), using their order of appearance in the packet. For each HMAC TLV, look up all ESAs in the derived sequence such that 2 plus the digest length of HashAlgo of the ESA is equal to Length of the TLV and KeyID of the ESA is equal to the value of KeyID of the TLV. Iterate over these ESAs in the relative order of their appearance on the full sequence of ESAs. Note that nesting the iterations the opposite way (over ESAs, then over HMAC TLVs) would be wrong.
7. パケット内の出現順序を使用して、元の入力パケット（コピーではない）のすべてのHMAC TLVを反復処理します。各HMAC TLVについて、ESAのHashAlgoのダイジェスト長に2を加えたものがTLVの長さに等しく、ESAのKeyIDがTLVのKeyIDの値と等しくなるように、派生シーケンスですべてのESAを検索します。 ESAの完全なシーケンスでの出現の相対的な順序でこれらのESAを反復します。反復を逆の方法で（ESAを介して、次にHMAC TLVを介して）入れ子にすることは間違っていることに注意してください。
For each of these ESAs, compute an HMAC result (see Section 2.4), using the temporary copy (not the original packet) as Text, HashAlgo of the current ESA as H, and AuthKeyOctets of the current ESA as K. If the current HMAC result exactly matches the contents of the Digest field of the current HMAC TLV, immediately proceed to the next step. Otherwise, if the number of HMAC computations done for the current packet so far is equal to MaxDigestsIn, immediately proceed to the next step. Otherwise, follow the normal order of iterations.
これらのESAのそれぞれについて、一時的なコピー（元のパケットではない）をテキストとして、現在のESAのHashAlgoをHとして、現在のESAのAuthKeyOctetsをKとして、HMAC結果（セクション2.4を参照）を計算します。現在のHMAC結果が現在のHMAC TLVのDigestフィールドの内容と完全に一致する場合は、すぐに次のステップに進みます。それ以外の場合で、現在のパケットに対してこれまでに行われたHMAC計算の数がMaxDigestsInと等しい場合は、すぐに次の手順に進みます。それ以外の場合は、通常の反復順序に従います。
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
8. Refuse the input packet unless there was a matching HMAC result in the previous step.
8. 前のステップで一致するHMAC結果がなかった場合を除き、入力パケットを拒否します。
9. Modify the ANM table, using the same index as for the entry lookup above, to contain an entry with LastTS set to the value of Timestamp and LastPC set to the value of PacketCounter fields of the TS/PC TLV of the current packet. That is, either add a new ANM table entry or update the existing one, depending on the result of the entry lookup above. Reset the entry's aging timer to the current value of ANM timeout.
9. 上記のエントリルックアップと同じインデックスを使用してANMテーブルを変更し、LastTSがTimestampの値に設定され、LastPCが現在のパケットのTS / PC TLVのPacketCounterフィールドの値に設定されたエントリを含めます。つまり、上記のエントリ検索の結果に応じて、新しいANMテーブルエントリを追加するか、既存のエントリを更新します。エントリのエージングタイマーをANMタイムアウトの現在の値にリセットします。
Note that the current step may involve byte order conversion.
現在のステップにはバイト順変換が含まれる場合があることに注意してください。
10. Accept the input packet.
10. 入力パケットを受け入れます。
Before performing the authentication-specific processing above, an implementation SHOULD perform those basic procedures of the original protocol that don't take any protocol actions on the contents of the packet but that will discard the packet if it is not sufficiently well formed for further processing. Although the exact composition of such procedures belongs to the scope of the original protocol, it seems reasonable to state that a packet SHOULD be discarded early, regardless of whether any authentication-specific processing is due, unless its source address conforms to Section 3.1 of [BABEL] and is not the receiving speaker's own address (see item (e) of Section 8).
上記の認証固有の処理を実行する前に、実装は、元のプロトコルの基本的な手順を実行する必要があります。これらの手順は、パケットの内容に対してプロトコルアクションを実行しませんが、その後の処理に十分な形式でない場合はパケットを破棄します。 。そのような手順の正確な構成は元のプロトコルの範囲に属しますが、送信元アドレスが[のセクション3.1に準拠している場合を除き、認証固有の処理が原因であるかどうかに関係なく、パケットを早期に破棄する必要があると述べておくのが妥当と思われます。 BABEL]であり、受信者自身のアドレスではありません（セクション8の（e）を参照）。
Note that RxAuthRequired affects only the final action but not the defined flow of authentication-specific processing. The purpose of this is to preserve authentication-specific processing feedback (such as log messages and event-counter updates), even with RxAuthRequired set to FALSE. This allows an operator to predict the effect of changing RxAuthRequired from FALSE to TRUE during a migration scenario (Section 7.3) implementation.
RxAuthRequiredは最終アクションにのみ影響し、認証固有の処理の定義されたフローには影響しないことに注意してください。これの目的は、RxAuthRequiredがFALSEに設定されていても、認証固有の処理フィードバック（ログメッセージやイベントカウンターの更新など）を保持することです。これにより、オペレーターは、移行シナリオ（第7.3項）の実装中にRxAuthRequiredをFALSEからTRUEに変更した場合の影響を予測できます。
A Babel speaker implementing this mechanism SHOULD maintain a set of counters for the following events, per protocol instance and per interface:
このメカニズムを実装するBabelスピーカーは、プロトコルインスタンスごとおよびインターフェイスごとに、次のイベントの一連のカウンターを維持する必要があります。
a. Sending an unauthenticated Babel packet through an interface having an empty sequence of CSAs (Section 5.3 item 1).
a. CSAの空のシーケンスを持つインターフェースを介して、認証されていないBabelパケットを送信する（セクション5.3アイテム1）。
b. Sending an unauthenticated Babel packet with a TS/PC TLV but without any HMAC TLVs, due to an empty derived sequence of ESAs (Section 5.3 item 4).
b. ESAの空のシーケンス（セクション5.3アイテム4）が原因で、TS / PC TLVはあるがHMAC TLVがない認証されていないBabelパケットを送信する。
c. Sending an authenticated Babel packet containing both TS/PC and HMAC TLVs (Section 5.3 item 9).
c. TS / PCとHMAC TLVの両方を含む認証済みBabelパケットを送信する（セクション5.3アイテム9）。
d. Accepting a Babel packet received through an interface having an empty sequence of CSAs (Section 5.4 item 1).
d. 空のCSAシーケンスを持つインターフェースを介して受信したBabelパケットを受け入れる（5.4の項目1）。
e. Refusing a received Babel packet due to an empty derived sequence of ESAs (Section 5.4 item 4).
e. ESAの派生シーケンスが空のため、受信したBabelパケットを拒否します（セクション5.4アイテム4）。
f. Refusing a received Babel packet that does not contain exactly one TS/PC TLV (Section 5.4 item 2).
f. TS / PC TLVが1つだけ含まれていない受信したBabelパケットを拒否する（5.4項の項目2）。
g. Refusing a received Babel packet due to the TS/PC TLV failing the ANM table check (Section 5.4 item 3). With possible future extensions in mind, in implementations of this mechanism, this event SHOULD leave out some small amount, per current (Interface, Source, LastTS, LastPC) tuple, of the packets refused due to the Timestamp value being equal to LastTS and the PacketCounter value being equal to LastPC.
g. TS / PC TLVがANMテーブルチェックに失敗したため、受信したBabelパケットを拒否します（セクション5.4アイテム3）。将来の拡張の可能性を考慮して、このメカニズムの実装では、このイベントは、Timestamp値がLastTSと等しいために拒否されたパケットの現在の（インターフェース、ソース、LastTS、LastPC）タプルごとに、少量を除外する必要があります（SHOULD）。 PacketCounterの値がLastPCと等しい。
h. Refusing a received Babel packet missing any HMAC TLVs (Section 5.4 item 8).
h. HMAC TLVが欠落している受信したBabelパケットを拒否する（セクション5.4項目8）。
i. Refusing a received Babel packet due to none of the processed HMAC TLVs passing the ESA check (Section 5.4 item 8).
i. ESAチェックに合格した処理済みのHMAC TLVがないため、受信したBabelパケットを拒否します（セクション5.4項目8）。
j. Accepting a received Babel packet having both TS/PC and HMAC TLVs (Section 5.4 item 10).
j. TS / PCとHMAC TLVの両方を含む受信したBabelパケットを受け入れる（5.4項の項目10）。
k. Delivery of a refused packet to the instance of the original protocol due to the RxAuthRequired parameter being set to FALSE.
k. RxAuthRequiredパラメータがFALSEに設定されているため、拒否されたパケットが元のプロトコルのインスタンスに配信されます。
Note that the terms "accepting" and "refusing" are used in the sense of the receiving procedure; that is, "accepting" does not mean a packet delivered to the instance of the original protocol purely because the RxAuthRequired parameter is set to FALSE. Event-counter readings SHOULD be available to the operator at runtime.
「受け入れる」および「拒否する」という用語は、受信手順の意味で使用されていることに注意してください。つまり、「受け入れる」とは、RxAuthRequiredパラメータがFALSEに設定されているため、元のプロトコルのインスタンスに配信されるパケットを純粋に意味するものではありません。イベントカウンターの読み取り値は、実行時にオペレーターが利用できる必要があります（SHOULD）。
Section 3.1 of [BABEL] allows for the exchange of protocol datagrams, using IPv4, IPv6, or both. The source address of the datagram is a unicast (link-local in the case of IPv6) address. Within an address family used by a Babel speaker, there may be more than one address eligible for the exchange and assigned to the same network interface. The original specification considers this case out of scope and leaves it up to the speaker's network stack to select one particular address as the datagram source address, but the sending procedure requires (Section 5.3 item 5) exact knowledge of the packet source address for proper padding of HMAC TLVs.
[BABEL]のセクション3.1では、IPv4、IPv6、またはその両方を使用したプロトコルデータグラムの交換が可能です。データグラムの送信元アドレスはユニキャスト（IPv6の場合はリンクローカル）アドレスです。 Babelスピーカーが使用するアドレスファミリ内には、交換に適格で、同じネットワークインターフェイスに割り当てられているアドレスが複数存在する場合があります。元の仕様では、このケースは範囲外と見なされ、スピーカーのネットワークスタックに任せて、特定のアドレスをデータグラムの送信元アドレスとして選択しますが、送信手順では、適切なパディングのためにパケットの送信元アドレスを正確に把握する必要があります（セクション5.3項目5）。 HMAC TLVの。
As long as a network interface has more than one address eligible for the exchange within the same address family, the Babel speaker SHOULD internally choose one of those addresses for Babel packet sending purposes and then indicate this choice to both the sending procedure and the network stack (see Figure 1 in Appendix A). Wherever this requirement cannot be met, this limitation MUST be clearly stated in the system documentation to allow an operator to plan network address management accordingly.
ネットワークインターフェースに同じアドレスファミリー内の交換に適格なアドレスが複数ある限り、Babelスピーカーは、Babelパケット送信目的でこれらのアドレスの1つを内部で選択し、送信手順とネットワークスタックの両方にこの選択を示す必要があります（SHOULD）。 （付録Aの図1を参照）。この要件が満たされない場合は常に、オペレーターがネットワークアドレス管理を計画できるように、この制限をシステムのドキュメントに明確に記載する必要があります。
An instance of the original protocol will buffer produced TLVs until the buffer becomes full or a delay timer has expired. This is performed independently for each Babel interface, with each buffer sized according to the interface MTU (see Sections 3.1 and 4 of [BABEL]).
元のプロトコルのインスタンスは、バッファーがいっぱいになるか、遅延タイマーが期限切れになるまで、生成されたTLVをバッファーします。これは、各バベルインターフェースごとに独立して実行され、各バッファーはインターフェースMTUに応じてサイズ設定されます（[BABEL]のセクション3.1および4を参照）。
Since TS/PC TLVs, HMAC TLVs, and any other TLVs -- and most likely the TLVs of the original protocol -- share the same packet space (see Figure 2 in Appendix A) and, respectively, the same buffer space, a particular portion of each interface buffer needs to be reserved for one TS/PC TLV and up to MaxDigestsOut HMAC TLVs. The amount (R) of this reserved buffer space is calculated as follows:
TS / PC TLV、HMAC TLV、およびその他のすべてのTLV-おそらく、元のプロトコルのTLV-は、同じパケットスペース（付録Aの図2を参照）およびそれぞれ同じバッファスペースを共有するため、特定の各インターフェイスバッファーの一部は、1つのTS / PC TLVと最大MaxDigestsOut HMAC TLV用に予約する必要があります。この予約済みバッファスペースの量（R）は、次のように計算されます。
R = St + MaxDigestsOut * Sh
R = 8 + MaxDigestsOut * (4 + Lmax)
St The size of a TS/PC TLV.
St TS / PC TLVのサイズ。
Sh The size of an HMAC TLV.
Sh HMAC TLVのサイズ。
Lmax The maximum possible digest length in octets for a particular interface. It SHOULD be calculated based on the particular interface's sequence of CSAs but MAY be taken as the maximum digest length supported by a particular implementation.
Lmax特定のインターフェイスの可能な最大ダイジェスト長（オクテット単位）。特定のインターフェイスのCSAのシーケンスに基づいて計算する必要があります（SHOULD）が、特定の実装でサポートされる最大のダイジェスト長と見なしてもかまいません（MAY）。
An implementation allowing for a per-interface value of MaxDigestsOut or Lmax has to account for a different value of R across different interfaces, even interfaces having the same MTU. An implementation allowing for a runtime change to the value of R (due to MaxDigestsOut or Lmax) has to take care of the TLVs already buffered by the time of the change -- specifically, when the value of R increases.
MaxDigestsOutまたはLmaxのインターフェイスごとの値を許可する実装は、同じMTUを持つインターフェイスであっても、異なるインターフェイス間で異なるRの値を考慮する必要があります。 Rの値へのランタイム変更を可能にする実装（MaxDigestsOutまたはLmaxによる）は、変更の時点で（具体的には、Rの値が増加したときに）すでにバッファーされているTLVを処理する必要があります。
The maximum safe value of the MaxDigestsOut parameter depends on the interface MTU and maximum digest length used. In general, at least 200-300 octets of a Babel packet should always be available to data other than TS/PC and HMAC TLVs. An implementation following the requirements of Section 4 of [BABEL] would send packets of 512 octets or larger. If, for example, the maximum digest length is 64 octets and the MaxDigestsOut value is 4, the value of R would be 280, leaving less than half of a 512-octet packet for any other TLVs. As long as the interface MTU is larger or the digest length is smaller, higher values of MaxDigestsOut can be used safely.
MaxDigestsOutパラメータの最大安全値は、使用されるインターフェイスMTUと最大ダイジェスト長によって異なります。一般に、Babelパケットの少なくとも200〜300オクテットは、TS / PCおよびHMAC TLV以外のデータで常に使用できる必要があります。 [BABEL]のセクション4の要件に従う実装は、512オクテット以上のパケットを送信します。たとえば、最大ダイジェスト長が64オクテットで、MaxDigestsOut値が4の場合、Rの値は280になり、他のTLVの512オクテットパケットの半分未満が残ります。インターフェースMTUが大きいか、ダイジェスト長が短い限り、MaxDigestsOutの値を高くしても安全に使用できます。
The following optimizations of the deriving procedure for ESAs can reduce the amount of CPU time consumed by authentication-specific processing, preserving an implementation's effective behaviour.
ESAの導出手順の以下の最適化により、認証固有の処理によって消費されるCPU時間を削減し、実装の効果的な動作を維持できます。
a. The most straightforward implementation would treat the deriving procedure as a per-packet action, but since the procedure is deterministic (its output depends on its input only), it is possible to significantly reduce the number of times the procedure is performed.
a. 最も単純な実装では、派生プロシージャをパケットごとのアクションとして扱いますが、プロシージャは確定的であるため（その出力は入力のみに依存します）、プロシージャの実行回数を大幅に削減できます。
The procedure would obviously return the same result for the same input arguments (sequence of CSAs, direction, CT) values. However, it is possible to predict when the result will remain the same, even for a different input. That is, when the input sequence of CSAs and the direction both remain the same but CT changes, the result will remain the same as long as CT's order on the time axis (relative to all critical points of the sequence of CSAs) remains unchanged. Here, the critical points are KeyStartAccept and KeyStopAccept (for the receiving direction), and KeyStartGenerate and KeyStopGenerate (for the sending direction), of all keys of all CSAs of the input sequence. In other words, in this case the result will remain the same as long as (1) none of the active keys expire and (2) none of the inactive keys enter into operation.
このプロシージャは、同じ入力引数（CSAのシーケンス、方向、CT）の値に対して同じ結果を返すことは明らかです。ただし、入力が異なっても、結果が同じになる時期を予測することは可能です。つまり、CSAの入力シーケンスと方向はどちらも同じままでCTが変化しても、時間軸上のCTの順序（CSAのシーケンスのすべての重要なポイントに対して）が変わらない限り、結果は変わりません。ここで、重要なポイントは、入力シーケンスのすべてのCSAのすべてのキーのKeyStartAcceptおよびKeyStopAccept（受信方向の場合）、およびKeyStartGenerateおよびKeyStopGenerate（送信方向の場合）です。言い換えると、この場合、（1）アクティブなキーの有効期限が切れておらず、（2）非アクティブなキーのいずれも動作しない限り、結果は同じままです。
An implementation optimized in this way would perform the full deriving procedure for a given (interface, direction) pair only after an operator's change to the interface's sequence of CSAs or after reaching one of the critical points mentioned above.
この方法で最適化された実装は、オペレーターがCSAのインターフェースのシーケンスを変更した後、または上記の重要なポイントの1つに達した後にのみ、特定の（インターフェース、方向）ペアの完全な導出手順を実行します。
b. Considering that the sending procedure iterates over at most MaxDigestsOut elements of the derived sequence of ESAs (Section 5.3 item 5), there would be little sense, in the case of the sending direction, in returning more than MaxDigestsOut ESAs in the derived sequence. Note that a similar optimization would be relatively difficult in the case of the receiving direction, since the number of ESAs actually used in examining a particular received packet (not to be confused with the number of HMAC computations) depends on additional factors besides just MaxDigestsIn.
b. 送信手順がESAの派生シーケンスの最大MaxDigestsOut要素（セクション5.3アイテム5）を反復処理することを考えると、送信方向の場合、派生シーケンスでMaxDigestsOut ESAより多くを返す意味はほとんどありません。特定の受信パケットの検査に実際に使用されるESAの数（HMAC計算の数と混同しないでください）がMaxDigestsIn以外の追加の要因に依存するため、受信方向の場合、同様の最適化は比較的困難です。
This specification defines three data structures as finite sequences: a KeyChain sequence, an interface's sequence of CSAs, and a sequence of ESAs. There are associated semantics to take into account during implementation, in that the same element can appear multiple times at different positions of the sequence. In particular, none of the CSA structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets), alone or in a combination, have to be unique within a given CSA, or within a given sequence of CSAs, or within all sequences of CSAs of a Babel speaker.
この仕様では、3つのデータ構造を有限シーケンスとして定義しています。KeyChainシーケンス、インターフェースのCSAシーケンス、ESAシーケンスです。シーケンスの異なる位置で同じ要素が複数回出現する可能性があるという点で、実装中に考慮に入れるべき関連するセマンティクスがあります。特に、CSA構造フィールド（HashAlgo、LocalKeyID、AuthKeyOctetsを含む）は、単独または組み合わせで、特定のCSA内、または特定のCSAシーケンス内、またはCSAのすべてのシーケンス内で一意である必要はありません。バベルスピーカー。
In the CSA space defined in this way, for any two authentication keys, their one field (in)equality would not imply another field (in)equality. In other words, it is acceptable to have more than one authentication key with the same LocalKeyID or the same AuthKeyOctets, or both at a time. It is a conscious design decision that CSA semantics allow for duplication of security associations. Consequently, ESA semantics allow for duplication of intermediate ESAs in the sequence until the explicit deduplication (Section 5.2 item 4).
この方法で定義されたCSA空間では、2つの認証キーの場合、それらの1つのフィールドが（不等）であっても、別のフィールドが（不）であることを意味するわけではありません。つまり、同じLocalKeyIDまたは同じAuthKeyOctets、あるいはその両方を持つ複数の認証キーを同時に持つことができます。 CSAセマンティクスがセキュリティアソシエーションの複製を許可することは、意識的な設計上の決定です。その結果、ESAセマンティクスは、明示的な重複排除（セクション5.2アイテム4）まで、シーケンス内の中間ESAの複製を許可します。
One of the intentions of this is to define the security association management in a way that allows the addressing of some specifics of Babel as a mesh routing protocol. For example, a system operator configuring a Babel speaker to participate in more than one administrative domain could find each domain using its own authentication key (AuthKeyOctets) under the same LocalKeyID value, e.g., a "well-known" or "default" value like 0 or 1. Since reconfiguring the domains to use distinct LocalKeyID values isn't always feasible, the multi-domain Babel speaker, using several distinct authentication keys under the same LocalKeyID, would make a valid use case for such duplication.
これの意図の1つは、メッシュルーティングプロトコルとしてBabelのいくつかの詳細をアドレス指定できるようにセキュリティアソシエーション管理を定義することです。たとえば、複数の管理ドメインに参加するようにBabelスピーカーを構成するシステムオペレーターは、同じLocalKeyID値の下に独自の認証キー（AuthKeyOctets）を使用して各ドメインを見つけることができます。 0または1。異なるLocalKeyID値を使用するようにドメインを再構成することが常に可能であるとは限らないため、同じLocalKeyIDで複数の異なる認証キーを使用するマルチドメインBabelスピーカーは、そのような複製の有効な使用例になります。
Furthermore, if the operator decided in this situation to migrate one of the domains to a different LocalKeyID value in a seamless way, the respective Babel speakers would use the same authentication key (AuthKeyOctets) under two different LocalKeyID values for the time of the transition (see also item (f) of Section 8). This would make a similar use case.
さらに、この状況でオペレーターがドメインの1つを別のLocalKeyID値にシームレスに移行することを決定した場合、それぞれのBabelスピーカーは、移行時に2つの異なるLocalKeyID値の下で同じ認証キー（AuthKeyOctets）を使用します（セクション8の（f）も参照してください。これは同様のユースケースになります。
Another intention of this design decision is to decouple security association management from authentication key management as much as possible, so that the latter, be it manual keying or a key-management protocol, could be designed and implemented independently (as the respective reasoning made in Section 3.1 of [RIP2-AUTH] still applies). This way, the additional key-management constraints, if any, would remain out of the scope of this authentication mechanism. A similar thinking justifies the LocalKeyID field having a bit length in an ESA structure definition, but not in that of the CSA.
この設計決定のもう1つの目的は、認証キー管理からセキュリティアソシエーション管理を可能な限り切り離して、手動キーイングまたはキー管理プロトコルのいずれかを独立して設計および実装できるようにすることです（それぞれの理由で[RIP2-AUTH]のセクション3.1が引き続き適用されます）。この方法では、追加のキー管理制約があるとしても、この認証メカニズムの範囲外のままになります。同様の考え方は、ESA構造の定義ではLocalKeyIDフィールドのビット長を正当化しますが、CSAのビット長では正当化しません。
Support of this mechanism is optional. It does not change the default behaviour of a Babel speaker and causes no compatibility issues with speakers properly implementing the original Babel specification. Given two Babel speakers -- one implementing this mechanism and configured for authenticated exchange (A) and another not implementing it (B) -- these speakers would not distribute routing information unidirectionally, form a routing loop, or experience other protocol logic issues specific purely to the use of this mechanism.
このメカニズムのサポートはオプションです。それはBabelスピーカーのデフォルトの動作を変更せず、元のBabel仕様を適切に実装するスピーカーとの互換性の問題を引き起こしません。 2つのBabelスピーカーが与えられた場合-1つはこのメカニズムを実装し、認証済み交換用に構成され（A）、もう1つは実装しない（B）-これらのスピーカーは、ルーティング情報を一方向に配信したり、ルーティングループを形成したり、純粋に他のプロトコルロジックの問題を経験したりしませんこのメカニズムの使用に。
The Babel design requires a bidirectional neighbour reachability condition between two given speakers for a successful exchange of routing information. Apparently, neighbour reachability would be unidirectional in the case above. The presence of TS/PC and HMAC TLVs in Babel packets sent by A would be transparent to B, but a lack of authentication data in Babel packets sent by B would make them effectively invisible to the instance of the original protocol of A. Unidirectional links are not specific to the use of this mechanism; they naturally exist on their own and are properly detected and coped with by the original protocol (see Section 3.4.2 of [BABEL]).
Babel設計では、ルーティング情報を正常に交換するために、2つの特定のスピーカー間の双方向ネイバー到達可能性条件が必要です。明らかに、上記の場合、ネイバーの到達可能性は単方向になります。 Aが送信したBabelパケットにTS / PCとHMAC TLVが存在することはBに対して透過的ですが、Bが送信したBabelパケットに認証データがないと、Aの元のプロトコルのインスタンスから事実上見えなくなります。単方向リンクこのメカニズムの使用に固有ではありません。それらは自然に存在し、元のプロトコルによって適切に検出および処理されます（[BABEL]のセクション3.4.2を参照）。
The receiving procedure treats a packet as authentic as soon as one of its HMAC TLVs passes the check against the derived sequence of ESAs. This allows for packet exchange authenticated with multiple (hash algorithm, authentication key) pairs simultaneously, in combinations as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut.
受信手順では、HMAC TLVの1つがESAの派生シーケンスに対するチェックに合格するとすぐに、パケットを信頼できるものとして扱います。これにより、MaxDigestsInおよびMaxDigestsOutで許可されている任意の組み合わせで、複数の（ハッシュアルゴリズム、認証キー）ペアで同時に認証されたパケット交換が可能になります。
For example, consider three Babel speakers with one interface each, configured with the following CSAs:
たとえば、次のCSAで構成された、それぞれ1つのインターフェイスを持つ3つのBabelスピーカーについて考えてみます。
o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key SK2)
o スピーカーA：（ハッシュアルゴリズムH1;キーSK1）、（ハッシュアルゴリズムH1;キーSK2）
o speaker B: (hash algorithm H1; key SK1)
o スピーカーB：（ハッシュアルゴリズムH1、キーSK1）
o speaker C: (hash algorithm H1; key SK2)
o スピーカーC：（ハッシュアルゴリズムH1、キーSK2）
Packets sent by A would contain two HMAC TLVs each. Packets sent by B and C would contain one HMAC TLV each. A and B would authenticate the exchange between themselves, using H1 and SK1; A and C would use H1 and SK2; B and C would discard each other's packets.
Aが送信するパケットには、それぞれ2つのHMAC TLVが含まれます。 BおよびCによって送信されたパケットには、それぞれ1つのHMAC TLVが含まれます。 AとBは、H1とSK1を使用して、それらの間の交換を認証します。 AとCはH1とSK2を使用します。 BとCは互いのパケットを破棄します。
Consider a similar set of speakers configured with different CSAs:
異なるCSAで構成された同様のスピーカーのセットを検討してください。
o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key SK4)
o スピーカーD：（ハッシュアルゴリズムH2;キーSK3）、（ハッシュアルゴリズムH3;キーSK4）
o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4; keys SK5 and SK6)
o スピーカーE：（ハッシュアルゴリズムH2;キーSK3）、（ハッシュアルゴリズムH4;キーSK5およびSK6）
o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm H5; key SK8)
o スピーカーF：（ハッシュアルゴリズムH3;キーSK4およびSK7）、（ハッシュアルゴリズムH5;キーSK8）
Packets sent by D would contain two HMAC TLVs each. Packets sent by E and F would contain three HMAC TLVs each. D and E would authenticate the exchange between themselves, using H2 and SK3; D and F would use H3 and SK4; E and F would discard each other's packets. The simultaneous use of H4, SK5, and SK6 by E, as well as the use of SK7, H5, and SK8 by F (for their own purposes), would remain insignificant to D.
Dから送信されるパケットには、それぞれ2つのHMAC TLVが含まれます。 EおよびFによって送信されたパケットには、それぞれ3つのHMAC TLVが含まれます。 DとEは、H2とSK3を使用して、それらの間の交換を認証します。 DとFはH3とSK4を使用します。 EとFは、互いのパケットを破棄します。 EによるH4、SK5、およびSK6の同時使用と、F（独自の目的）によるSK7、H5、およびSK8の使用は、Dにとって重要ではありません。
An operator implementing multi-domain authentication should keep in mind that values of MaxDigestsIn and MaxDigestsOut may be different both within the same Babel speaker and across different speakers. Since the minimum value of both parameters is 2 (see Sections 3.4 and 3.5), when more than two authentication domains are configured simultaneously it is advisable to confirm that every involved speaker can handle a sufficient number of HMAC results for both sending and receiving.
マルチドメイン認証を実装するオペレーターは、MaxDigestsInとMaxDigestsOutの値が同じBabelスピーカー内でも、異なるスピーカー間でも異なる可能性があることに注意してください。両方のパラメーターの最小値は2（セクション3.4および3.5を参照）であるため、3つ以上の認証ドメインを同時に構成する場合は、関係するすべてのスピーカーが送信と受信の両方で十分な数のHMAC結果を処理できることを確認することをお勧めします。
The recommended method of Babel speaker configuration for multi-domain authentication is to not only use a different authentication key for each domain but also a separate CSA for each domain, even when hash algorithms are the same. This allows for fair competition between CSAs and sometimes limits the consequences of a possible misconfiguration to the scope of one CSA. See also item (f) of Section 8.
マルチドメイン認証のBabelスピーカー構成の推奨される方法は、ハッシュアルゴリズムが同じであっても、ドメインごとに異なる認証キーを使用するだけでなく、ドメインごとに個別のCSAを使用することです。これにより、CSA間の公正な競争が可能になり、構成ミスの可能性がある結果を1つのCSAの範囲に制限する場合があります。セクション8の（f）も参照してください。
It is common in practice to consider a migration to the authenticated exchange of routing information only after the network has already been deployed and put into active use. Performing the migration in a way without regular traffic interruption is typically demanded, and this specification allows a smooth migration using the RxAuthRequired interface parameter defined in Section 3.1. This measure is similar to the "transition mode" suggested in Section 5 of [OSPF3-AUTH-BIS].
実際には、ネットワークがすでに展開されてアクティブに使用されている場合にのみ、認証されたルーティング情報の交換への移行を検討するのが一般的です。通常のトラフィックの中断なしに移行を実行することが通常要求されます。この仕様により、セクション3.1で定義されたRxAuthRequiredインターフェースパラメーターを使用してスムーズな移行が可能になります。この尺度は、[OSPF3-AUTH-BIS]のセクション5で提案されている「遷移モード」に似ています。
An operator performing the migration needs to arrange configuration changes as follows:
移行を実行するオペレーターは、構成の変更を次のように調整する必要があります。
1. Decide on particular hash algorithm(s) and key(s) to be used.
1. 使用する特定のハッシュアルゴリズムとキーを決定します。
2. Identify all speakers and their involved interfaces that need to be migrated to authenticated exchange.
2. 認証されたエクスチェンジに移行する必要があるすべてのスピーカーとその関連インターフェースを特定します。
3. For each of the speakers and the interfaces to be reconfigured, first set the RxAuthRequired parameter to FALSE, then configure necessary CSA(s).
3. 再構成するスピーカーとインターフェイスのそれぞれについて、最初にRxAuthRequiredパラメーターをFALSEに設定してから、必要なCSAを構成します。
4. Examine the speakers to confirm that Babel packets are successfully authenticated according to the configuration (for instance, by examining ANM table entries and authentication-specific statistics; see Figure 1 in Appendix A), and address any discrepancies before proceeding further.
4. スピーカーを調べて、Babelパケットが構成に従って正常に認証されていることを確認し（たとえば、ANMテーブルエントリと認証固有の統計を調べます。付録Aの図1を参照してください）、先に進む前に矛盾を解決します。
5. For each of the speakers and the reconfigured interfaces, set the RxAuthRequired parameter to TRUE.
5. スピーカーと再構成されたインターフェイスのそれぞれについて、RxAuthRequiredパラメーターをTRUEに設定します。
Likewise, temporarily setting RxAuthRequired to FALSE can be used to migrate smoothly from an authenticated packet exchange back to an unauthenticated one.
同様に、RxAuthRequiredを一時的にFALSEに設定すると、認証されたパケット交換から認証されていないパケット交換にスムーズに移行できます。
This specification employs a common concept of multiple authentication keys coexisting for a given interface, with two independent lifetime ranges associated with each key (one for sending and another for receiving). It is typically recommended that the keys be configured using finite lifetimes, adding new keys before the old keys expire. However, it is obviously possible for all keys to expire for a given interface (for sending, receiving, or both). Possible ways of addressing this situation raise their own concerns:
この仕様は、各キーに関連付けられた2つの独立したライフタイム範囲（1つは送信用、もう1つは受信用）を使用して、特定のインターフェースに共存する複数の認証キーという共通の概念を採用しています。通常は、キーを有限の有効期間を使用して構成し、古いキーが期限切れになる前に新しいキーを追加することをお勧めします。ただし、特定のインターフェース（送信、受信、またはその両方）のすべての鍵が期限切れになる可能性があることは明らかです。この状況に対処するための可能な方法は、彼ら自身の懸念を引き起こします：
o Automatic switching to unauthenticated protocol exchange. This behaviour invalidates the initial purposes of authentication and is commonly viewed as unacceptable ([RIP2-AUTH] Section 5.1, [OSPF2-AUTH] Section 3.2, and [OSPF3-AUTH-BIS] Section 3).
o 認証されていないプロトコル交換への自動切り替え。この動作は認証の最初の目的を無効にし、一般に受け入れられないと見なされます（[RIP2-AUTH]セクション5.1、[OSPF2-AUTH]セクション3.2、および[OSPF3-AUTH-BIS]セクション3）。
o Stopping routing information exchange over the interface. This behaviour is likely to impact regular traffic routing and is commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this regard.
o インターフェイスを介したルーティング情報の交換を停止します。この動作は通常のトラフィックルーティングに影響を与える可能性が高く、一般に「推奨されない」（[RIP2-AUTH]、[OSPF2-AUTH]、および[OSPF3-AUTH]）と見なされますが、[OSPF3-AUTH-BIS]はこの点について。
o The use of the "most recently expired" key over its intended lifetime range. This behaviour is recommended for implementation in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] but not in [OSPF3-AUTH-BIS]. Such use of this key may become a problem, due to an offline cryptographic attack (see item (f) of Section 8) or a compromise of the key. In addition, distinguishing a recently expired key from a key that has never been used may be impossible after a router restart.
o 意図された有効期間の範囲での「最近期限切れ」のキーの使用。この動作は、[RIP2-AUTH]、[OSPF2-AUTH]、および[OSPF3-AUTH]での実装に推奨されますが、[OSPF3-AUTH-BIS]では推奨されません。このキーのこのような使用は、オフラインの暗号攻撃（セクション8の（f）を参照）またはキーの侵害により、問題になる可能性があります。さらに、最近有効期限が切れたキーを、使用されたことのないキーと区別することは、ルーターの再起動後に不可能になる場合があります。
The design of this mechanism prevents automatic switching to unauthenticated exchange and is consistent with similar authentication mechanisms in this regard, but since the best choice between two other options depends on local site policy, this decision is left up to the operator rather than the implementor (in a way resembling the "fail secure" configuration knob described in Section 5.1 of [RIP2-AUTH]).
このメカニズムの設計は、認証されていない交換への自動切り替えを防止し、この点で同様の認証メカニズムと一致していますが、他の2つのオプション間の最良の選択はローカルサイトのポリシーに依存するため、この決定は実装者ではなくオペレーターに任されます（ [RIP2-AUTH]のセクション5.1で説明されている「フェイルセキュア」設定ノブに似た方法で）。
Although the deriving procedure does not allow for any exceptions in the filtering of expired keys (Section 5.2 item 2), the operator can trivially enforce one of the two remaining behaviour options through local key-management procedures. In particular, when using the key over its intended lifetime is preferable to regular traffic disruption, the operator would explicitly leave the old key expiry time open until the new key is added to the router configuration. In the opposite case, the operator would always configure the old key with a finite lifetime and bear associated risks.
導出手順では、期限切れのキーのフィルタリングで例外を許可していませんが（セクション5.2項目2）、オペレーターはローカルのキー管理手順を使用して、残りの2つの動作オプションのいずれかを簡単に適用できます。特に、意図したライフタイムにわたってキーを使用することが通常のトラフィックの中断よりも望ましい場合、オペレーターは、新しいキーがルーター構成に追加されるまで、古いキーの有効期限を明示的に開いたままにします。反対の場合、オペレーターは常に古いキーを有限の有効期間で構成し、関連するリスクを負うことになります。
The use of this mechanism implies requirements common to the use of shared authentication keys, including, but not limited to:
このメカニズムの使用は、共有認証キーの使用に共通する要件を意味します。
o holding the keys secret,
o キーを秘密にして
o including sufficient amounts of random bits into each key,
o 各キーに十分な量のランダムビットを含める、
o rekeying on a regular basis, and
o 定期的に鍵を更新する
o never reusing a used key for a different purpose.
o 使用済みのキーを別の目的で再利用しないでください。
That said, proper design and implementation of a key-management policy are out of the scope of this work. Many publications on this subject exist and should be used for this purpose (BCP 107 [RFC4107], BCP 132 [RFC4962], and [RFC6039] are suggested as starting points).
とはいえ、鍵管理ポリシーの適切な設計と実装は、この作業の範囲外です。この主題に関する多くの出版物が存在し、この目的で使用する必要があります（BCP 107 [RFC4107]、BCP 132 [RFC4962]、および[RFC6039]が出発点として提案されています）。
It is possible for a network that exercises rollover of authentication keys to experience accidental expiration of all the keys for a network interface, as discussed at greater length in Section 7.4. With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in such an event the Babel speaker MUST send a "last key expired" notification to the operator (e.g., via syslog, SNMP, and/or other implementation-specific means), most likely in relation to item (b) of Section 5.5. Also, any actual occurrence of an authentication key expiration MUST cause a security event to be logged by the implementation. The log item MUST include at least a note that the authentication key has expired, the Babel routing protocol instance(s) affected, the network interface(s) affected, the LocalKeyID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice.
セクション7.4で詳しく説明するように、認証キーのロールオーバーを実行するネットワークでは、ネットワークインターフェイスのすべてのキーが誤って期限切れになる可能性があります。それと[RIP2-AUTH]のセクション5.1のガイダンスを念頭に置いて、そのようなイベントでは、Babelスピーカーは "最後のキーの期限切れ"通知をオペレーターに送信する必要があります（たとえば、syslog、SNMP、および/または他の実装経由）。特定の手段）、おそらくセクション5.5の項目（b）に関連して。また、認証キーの有効期限が実際に発生すると、実装によってセキュリティイベントがログに記録される必要があります。ログ項目には、少なくとも認証キーの有効期限が切れていること、影響を受けるBabelルーティングプロトコルインスタンス、影響を受けるネットワークインターフェイス、影響を受けるLocalKeyID、および現在の日付/時刻が含まれている必要があります。オペレーターは、運用上のセキュリティ慣行として、このようなログを確認することをお勧めします。
Considering particular attacks being in scope or out of scope on one hand and measures taken to protect against particular in-scope attacks on the other, the original Babel protocol and this authentication mechanism are in line with similar datagram-based routing protocols and their respective mechanisms. In particular, the primary concerns addressed are:
特定の攻撃が一方ではスコープ内またはスコープ外であり、他方では特定のスコープ内攻撃から保護するために講じられた対策を考慮すると、元のBabelプロトコルとこの認証メカニズムは、同様のデータグラムベースのルーティングプロトコルとそれぞれのメカニズムと一致しています。特に、対処される主な懸念事項は次のとおりです。
a. Peer Entity Authentication
a. ピアエンティティ認証
The Babel speaker authentication mechanism defined herein is believed to be as strong as the class itself to which it belongs. This specification is built on fundamental concepts implemented for authentication of similar routing protocols: per-packet authentication, the use of the HMAC construction, and the use of shared keys. Although this design approach does not address all possible concerns, it is so far known to be sufficient for most practical cases.
ここで定義されているBabel話者認証メカニズムは、それが属するクラス自体と同じくらい強力であると考えられています。この仕様は、同様のルーティングプロトコルの認証のために実装された基本概念に基づいています。パケットごとの認証、HMAC構造の使用、共有キーの使用などです。この設計アプローチはすべての考えられる問題に対処するものではありませんが、ほとんどの実際的なケースではこれで十分であることがこれまでに知られています。
b. Data Integrity
b. データの整合性
Meaningful parts of a Babel datagram are the contents of the Babel packet (in the definition of Section 4.2 of [BABEL]) and the source address of the datagram (Section 3.5.3 of [BABEL]). This mechanism authenticates both parts, using the HMAC construction, so that making any meaningful change to an authenticated packet after it has been emitted by the sender should be as hard as attacking the HMAC construction itself or successfully recovering the authentication key.
Babelデータグラムの意味のある部分は、Babelパケットの内容（[BABEL]のセクション4.2の定義）とデータグラムの送信元アドレス（[BABEL]のセクション3.5.3）です。このメカニズムは、HMAC構造を使用して両方の部分を認証するため、送信者によって送信された後に認証済みパケットに意味のある変更を加えることは、HMAC構造自体を攻撃するか、認証キーを正常に回復するのと同じくらい難しいはずです。
Note well that any trailing data of the Babel datagram is not meaningful in the scope of the original specification and does not belong to the Babel packet. Integrity of the trailing data is thus not protected by this mechanism. At the same time, although any TLV extra data is also not meaningful in the same scope, its integrity is protected, since this extra data is a part of the Babel packet (see Figure 2 in Appendix A).
Babelデータグラムの後続データは、元の仕様の範囲では意味がなく、Babelパケットに属していないことに注意してください。したがって、後続データの整合性はこのメカニズムによって保護されません。同時に、TLVの追加データも同じスコープでは意味がありませんが、この追加データはBabelパケットの一部であるため、その整合性は保護されます（付録Aの図2を参照）。
c. Denial of Service
c. サービス拒否
Proper deployment of this mechanism in a Babel network significantly increases the efforts required for an attacker to feed arbitrary Babel packets into a protocol exchange (with the intent of attacking a particular Babel speaker or disrupting the exchange of regular traffic in a routing domain). It also protects the neighbour table from being flooded with forged speaker entries.
このメカニズムをBabelネットワークに適切に配置すると、攻撃者が任意のBabelパケットをプロトコル交換にフィードするために必要な労力が大幅に増加します（特定のBabelスピーカーを攻撃したり、ルーティングドメインでの通常のトラフィックの交換を妨害したりするため）。また、偽造されたスピーカーエントリでフラッディングされることからネイバーテーブルを保護します。
At the same time, this protection comes with a price of CPU time being spent on HMAC computations. This may be a concern for low-performance CPUs combined with high-speed interfaces, as sometimes seen in embedded systems and hardware routers. The MaxDigestsIn parameter, which is used to limit the maximum amount of CPU time spent on a single received Babel packet, addresses this concern to some extent.
同時に、この保護には、HMAC計算に費やされるCPU時間の代償が伴います。これは、組み込みシステムやハードウェアルーターで時々見られるように、高速インターフェイスと組み合わされた低パフォーマンスのCPUにとって問題になる可能性があります。 MaxDigestsInパラメーターは、受信した単一のBabelパケットに費やされるCPU時間の最大量を制限するために使用され、この問題にある程度対処します。
d. Reflection Attacks
d. リフレクション攻撃
Given the approach discussed in item (b), the only potential reflection attack on this mechanism could be replaying exact copies of Babel packets back to the sender from the same source address. The mitigation in this case is straightforward and is discussed in Section 5.4.
項目（b）で説明したアプローチを考えると、このメカニズムに対する潜在的なリフレクション攻撃は、同じ送信元アドレスから送信者に返されるBabelパケットの正確なコピーを再生することだけです。この場合の緩和策は簡単であり、セクション5.4で説明します。
The following in-scope concern is only partially addressed:
次の範囲内の問題は、部分的にしか対処されていません。
e. Replay Attacks
e. リプレイ攻撃
This specification establishes a basic replay protection measure (see Section 3.6), defines a timeout parameter affecting its strength (see Section 3.7), and outlines implementation methods also affecting protection strength in several ways (see Section 5.1). The implementor's choice of the timeout value and particular implementation methods may be suboptimal due to, for example, insufficient hardware resources of the Babel speaker.
この仕様は、基本的な再生保護対策（セクション3.6を参照）を確立し、その強度に影響を与えるタイムアウトパラメータ（セクション3.7を参照）を定義し、いくつかの点で保護強度に影響を与える実装方法の概要を示します（セクション5.1を参照）。実装者によるタイムアウト値の選択と特定の実装方法は、たとえば、Babelスピーカーのハードウェアリソースが不十分なために最適ではない可能性があります。
Furthermore, it may be possible that an operator configures the timeout and the methods to address particular local specifics, and this further weakens the protection. An operator concerned about replay attack protection strength should understand these factors and their meaning in a given network segment.
さらに、オペレーターが特定のローカル仕様に対処するためにタイムアウトとメソッドを構成する可能性があり、これにより保護がさらに弱められます。リプレイアタック保護強度を懸念するオペレーターは、特定のネットワークセグメントにおけるこれらの要因とその意味を理解する必要があります。
That said, a particular form of replay attack on this mechanism remains possible anyway. Whether there are two or more network segments using the same CSA and there is an adversary that captures Babel packets on one segment and replays on another (and vice versa, due to the bidirectional reachability requirement for neighbourship), some of the speakers on one such segment will detect the "virtual" neighbours from another and may prefer them for some destinations. This applies even more so as Babel doesn't require a common pre-configured network prefix between neighbours.
とは言っても、このメカニズムに対する特定の形式のリプレイ攻撃は依然として可能です。同じCSAを使用する2つ以上のネットワークセグメントがあり、1つのセグメントでBabelパケットをキャプチャして別のセグメントで再生する敵が存在するかどうか（近隣の双方向の到達可能性要件により、その逆も同様）、そのうちの1つのスピーカーセグメントは別の「仮想」ネイバーを検出し、いくつかの宛先にそれらを優先する場合があります。これは、Babelが近隣間で事前に構成された共通のネットワークプレフィックスを必要としないため、さらに当てはまります。
A reliable solution to this particular problem, which Section 4.5 of [RFC7186] discusses as well, is not currently known. It is recommended that the operators use distinct CSAs for distinct network segments.
[RFC7186]のセクション4.5でも説明されているこの特定の問題に対する信頼できる解決策は、現時点では不明です。事業者は、異なるネットワークセグメントに対して異なるCSAを使用することをお勧めします。
The following in-scope concerns are not addressed:
次の範囲内の懸念事項には対応していません。
f. Offline Cryptographic Attacks
f. オフライン暗号攻撃
This mechanism is obviously subject to offline cryptographic attacks. As soon as an attacker has obtained a copy of an authenticated Babel packet of interest (which gets easier to do in wireless networks), he has all of the parameters of the authentication-specific processing performed by the sender, except for authentication key(s) and the choice of particular hash algorithm(s). Since digest lengths of common hash algorithms are well known and can be matched with those seen in the packet, the complexity of this attack is essentially that of the authentication key attack.
このメカニズムは明らかにオフラインの暗号攻撃の影響を受けます。攻撃者は、認証された対象のBabelパケットのコピーを取得すると（ワイヤレスネットワークで実行する方が簡単になります）、認証キーを除いて、送信者が実行した認証固有の処理のすべてのパラメーターを取得します。 ）および特定のハッシュアルゴリズムの選択。一般的なハッシュアルゴリズムのダイジェスト長はよく知られており、パケットで見られるものと一致させることができるため、この攻撃の複雑さは、本質的に認証キー攻撃の複雑さです。
Viewing the cryptographic strength of particular hash algorithms as a concern of its own, the main practical means of resisting offline cryptographic attacks on this mechanism are periodic rekeying and the use of strong keys with a sufficient number of random bits.
特定のハッシュアルゴリズムの暗号強度をそれ自体の懸念事項として見ると、このメカニズムに対するオフラインの暗号攻撃に対抗する主な実用的な手段は、定期的な鍵の再生成と、十分な数のランダムビットを持つ強力な鍵の使用です。
It is important to understand that in the case of multiple keys being used within a single interface (for multi-domain authentication or during a key rollover) the strength of the combined configuration would be that of the weakest key, since only one successful HMAC test is required for an authentic packet. Operators concerned about offline cryptographic attacks should enforce the same strength policy for all keys used for a given interface.
単一のインターフェース内で複数の鍵が使用されている場合（マルチドメイン認証または鍵のロールオーバー中に）、HMACテストが1つだけ成功するため、組み合わせた構成の強度は最も弱い鍵の強度になることを理解することが重要です。本物のパケットには必須です。オフラインの暗号攻撃を懸念する事業者は、特定のインターフェイスで使用されるすべてのキーに同じ強度ポリシーを適用する必要があります。
Note that a special pathological case is possible with this mechanism. Whenever two or more authentication keys are configured for a given interface such that all keys share the same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 2^16 is different for each key, these keys will not be treated as duplicate (Section 5.2 item 4), but an HMAC result computed for a given packet will be the same for each of these keys. In the case of the sending procedure, this can produce multiple HMAC TLVs with exactly the same value of the Digest field but different values of the KeyID field. In this case, the attacker will see that the keys are the same, even without knowledge of the key itself. The reuse of authentication keys is not the intended use case of this mechanism and should be strongly avoided.
このメカニズムでは、特別な病理学的ケースが発生する可能性があることに注意してください。すべてのキーが同じAuthKeyOctetsと同じHashAlgoを共有するように特定のインターフェイスに2つ以上の認証キーが構成されているが、LocalKeyIDモジュロ2 ^ 16がキーごとに異なる場合、これらのキーは重複として扱われません（セクション5.2アイテム4 ）、ただし、特定のパケットに対して計算されたHMAC結果は、これらの各キーで同じになります。送信手順の場合、これにより、ダイジェストフィールドの値はまったく同じで、KeyIDフィールドの値が異なる複数のHMAC TLVが生成される可能性があります。この場合、攻撃者は、キー自体を知らなくても、キーが同じであることがわかります。認証キーの再利用は、このメカニズムの意図された使用例ではなく、強く回避する必要があります。
g. Non-repudiation
g. 否認防止
This specification relies on the use of shared keys. There is no timestamp infrastructure and no key-revocation mechanism defined to address the compromise of a shared key. Establishing the time that a particular authentic Babel packet was generated is thus not possible. Proving that a particular Babel speaker had actually sent a given authentic packet is also impossible as soon as the shared key is claimed compromised. Even if the shared key is not compromised, reliably identifying the speaker that had actually sent a given authentic Babel packet is not possible. Since any of the speakers sharing a key can impersonate any other speaker sharing the same key, it is only possible to prove that the speaker belongs to the group sharing the key.
この仕様は、共有キーの使用に依存しています。共有キーの侵害に対処するために定義されたタイムスタンプインフラストラクチャとキー失効メカニズムはありません。したがって、特定の本物のBabelパケットが生成された時間を確立することは不可能です。特定のBabelスピーカーが実際に特定の本物のパケットを送信したことを証明することも、共有キーが侵害されたと主張するや否や不可能です。共有キーが危険にさらされていない場合でも、特定の本物のBabelパケットを実際に送信したスピーカーを確実に識別することはできません。キーを共有しているスピーカーは、同じキーを共有している他のスピーカーになりすますことができるため、そのスピーカーがキーを共有しているグループに属していることを証明することしかできません。
h. Confidentiality Violations
h. 守秘義務違反
The original Babel protocol does not encrypt any of the information contained in its packets. The contents of a Babel packet are trivial to decode and thus can reveal network topology details. This mechanism does not improve this situation in any way. Since routing protocol messages are not the only kind of information subject to confidentiality concerns, a complete solution to this problem is likely to include measures based on the channel security model, such as IPsec and Wi-Fi Protected Access 2 (WPA2) at the time of this writing.
オリジナルのBabelプロトコルは、パケットに含まれる情報を暗号化しません。 Babelパケットの内容は簡単にデコードできるため、ネットワークトポロジの詳細を明らかにできます。このメカニズムは、この状況を決して改善しません。ルーティングプロトコルメッセージは機密性の問題の影響を受ける唯一の種類の情報ではないため、この問題に対する完全なソリューションには、当時のIPsecやWi-Fi Protected Access 2（WPA2）などのチャネルセキュリティモデルに基づく対策が含まれる可能性があります。この執筆の。
i. Key Management
i. キー管理
Any authentication key exchange/distribution concerns are out of scope. However, the internal representation of authentication keys (see Section 3.8) allows implementations to use such diverse key-management techniques as manual configuration, a provisioning system, a key-management protocol, or any other means that comply with this specification.
認証キーの交換/配布に関する懸念は範囲外です。ただし、認証キーの内部表現（セクション3.8を参照）により、実装では、手動構成、プロビジョニングシステム、キー管理プロトコル、またはこの仕様に準拠するその他の手段など、さまざまなキー管理手法を使用できます。
j. Message Deletion
j. メッセージの削除
Any message deletion attacks are out of scope. Since a datagram deleted by an attacker cannot be distinguished from a datagram naturally lost in transmission, and since datagram-based routing protocols are designed to withstand a certain loss of packets, the currently established practice is treating authentication purely as a per-packet function, without any added detection of lost packets.
メッセージ削除攻撃は範囲外です。攻撃者によって削除されたデータグラムは、送信で自然に失われるデータグラムと区別できず、データグラムベースのルーティングプロトコルはパケットの特定の損失に耐えるように設計されているため、現在確立されている慣行は、認証を純粋にパケットごとの機能として扱っています。失われたパケットの追加の検出なし。
At the time of publication of this document, the Babel TLV Types namespace did not have an IANA registry. TLV types 11 and 12 were assigned (see Table 1 in Appendix A) to the TS/PC and HMAC TLV types by Juliusz Chroboczek, designer of the original Babel protocol. Therefore, this document has no IANA actions.
このドキュメントの公開時点では、Babel TLV Types名前空間にはIANAレジストリがありませんでした。 TLVタイプ11および12（付録Aの表1を参照）は、元のBabelプロトコルの設計者であるJuliusz ChroboczekによってTS / PCおよびHMAC TLVタイプに割り当てられました。したがって、このドキュメントにはIANAアクションはありません。
Thanks to Randall Atkinson and Matthew Fanto for their comprehensive work on [RIP2-AUTH] that initiated a series of publications on routing protocol authentication, including this one. This specification adopts many concepts belonging to the whole series.
Randall AtkinsonとMatthew Fantoが[RIP2-AUTH]に関する包括的な作業を行ってくれたことに感謝します。この仕様は、シリーズ全体に属する多くのコンセプトを採用しています。
Thanks to Juliusz Chroboczek, Gabriel Kerneis, and Matthieu Boutier. This document incorporates many technical and editorial corrections based on their feedback. Thanks to all contributors to Babel, because this work would not be possible without the prior works. Thanks to Dominic Mulligan for editorial proofreading of this document. Thanks to Riku Hietamaki for suggesting the test vectors section.
Juliusz Chroboczek、Gabriel Kerneis、およびMatthieu Boutierに感謝します。このドキュメントには、フィードバックに基づいた多くの技術的および編集上の修正が組み込まれています。この作業は前の作業なしでは不可能だったので、Babelへのすべての貢献者に感謝します。この文書の編集校正をしてくれたDominic Mulliganに感謝します。テストベクターセクションを提案してくれたひたまきりくに感謝します。
Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen Farrell for providing (in chronological order) valuable feedback on earlier versions of this document.
このドキュメントの以前のバージョンに関する貴重なフィードバックを（年代順に）提供してくれたJoel Halpern、Jim Schaad、Randall Atkinson、およびStephen Farrellに感謝します。
Thanks to Jim Gettys and Dave Taht for developing the CeroWrt wireless router project and collaborating on many integration issues. A practical need for Babel authentication emerged during research based on CeroWrt that eventually became the very first use case of this mechanism.
CeroWrtワイヤレスルータープロジェクトを開発し、多くの統合問題に協力してくれたJim GettysとDave Tahtに感謝します。最終的にこのメカニズムの最初の使用例となったCeroWrtに基づく研究中に、Babel認証の実用的な必要性が生じました。
Thanks to Kunihiro Ishiguro and Paul Jakma for establishing the GNU Zebra and Quagga routing software projects, respectively. Thanks to Werner Koch, the author of Libgcrypt. The very first implementation of this mechanism was made on a base of Quagga and Libgcrypt.
GNU ZebraおよびQuaggaルーティングソフトウェアプロジェクトをそれぞれ立ち上げてくれた石黒邦弘とPaul Jakmaに感謝します。 Libgcryptの作者であるWerner Kochに感謝します。このメカニズムの最初の実装は、QuaggaとLibgcryptに基づいて行われました。
[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月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[FIPS-198] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008.
[FIPS-198]米国国立標準技術研究所、「キー付きハッシュメッセージ認証コード（HMAC）」、FIPS PUB 198-1、2008年7月。
[BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, April 2011.
[BABEL] Chroboczek、J。、「The Babel Routing Protocol」、RFC 6126、2011年4月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、2005年3月。
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[RFC4030] Stapp、M。およびT. Lemon、「動的ホスト構成プロトコル（DHCP）リレーエージェントオプションの認証サブオプション」、RFC 4030、2005年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] Hoffman、P.およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RIP2-AUTH] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RIP2-AUTH] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。
[ISIS-AUTH-A] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[ISIS-AUTH-A] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[ISIS-AUTH-B] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[ISIS-AUTH-B] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2月2009。
[OSPF2-AUTH] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[OSPF2-AUTH] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、2009年10月。
[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月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティに関する考慮事項」、RFC 6194、2011年3月。
[OSPF3-AUTH] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[OSPF3-AUTH] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 6506、2012年2月。
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.
[RFC6709] Carpenter、B.、Aboba、B。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、2012年9月。
[BABEL-EXTENSION] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", Work in Progress, June 2014.
[BABEL-EXTENSION] Chroboczek、J。、「Babel Routing Protocolの拡張メカニズム」、進行中の作業、2014年6月。
[OSPF3-AUTH-BIS] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014.
[OSPF3-AUTH-BIS] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 7166、2014年3月。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014.
[RFC7183] Herberg、U.、Dearlove、C。、およびT. Clausen、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 2（OLSRv2）」、RFC 7183、2014年4月。
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, April 2014.
[RFC7186] Yi、J.、Herberg、U。、およびT. Clausen、「Neighborhood Discovery Protocol（NHDP）のセキュリティ脅威」、RFC 7186、2014年4月。
+-------------------------------------------------------------+
| authentication-specific statistics |
+-------------------------------------------------------------+
^ | ^
| v |
| +-----------------------------------------------+ |
| | system operator | |
| +-----------------------------------------------+ |
| ^ | ^ | ^ | ^ | ^ | |
| | v | | | | | | | v |
+---+ +---------+ | | | | | | +---------+ +---+
| |->| ANM | | | | | | | | LocalTS |->| |
| R |<-| table | | | | | | | | LocalPC |<-| T |
| x | +---------+ | v | v | v +---------+ | x |
| | +----------------+ +---------+ +----------------+ | |
| p | | MaxDigestsIn | | | | MaxDigestsOut | | p |
| r |<-| ANM timeout | | CSAs | | |->| r |
| o | | RxAuthRequired | | | | | | o |
| c | +----------------+ +---------+ +----------------+ | c |
| e | +-------------+ | | +-------------+ | e |
| s | | Rx ESAs | | | | Tx ESAs | | s |
| s |<-| (temporary) |<----+ +---->| (temporary) |->| s |
| i | +-------------+ +-------------+ | i |
| n | +------------------------------+----------------+ | n |
| g | | instance of | output buffers |=>| g |
| |=>| the original +----------------+ | |
| | | protocol | source address |->| |
+---+ +------------------------------+----------------+ +---+
/\ | ||
|| v \/
+-------------------------------------------------------------+
| network stack |
+-------------------------------------------------------------+
/\ || /\ || /\ || /\ ||
|| \/ || \/ || \/ || \/
+---------+ +---------+ +---------+ +---------+
| speaker | | speaker | ... | speaker | | speaker |
+---------+ +---------+ +---------+ +---------+
Flow of control data : --->
Flow of Babel datagrams/packets: ===>
Figure 1: Interaction Diagram
図1：相互作用図
P
|<---------------------------->| (D1)
| B |
| |<------------------------->|
| | |
+--+-----+-----+...+-----+-----+--+ P: Babel packet
|H |some |some | |some |some |T | H: Babel packet header
| |TLV |TLV | |TLV |TLV | | B: Babel packet body
| | | | | | | | T: optional trailing data block
+--+-----+-----+...+-----+-----+--+
P
|<----------------------------------------------------->| (D2)
| B |
| |<-------------------------------------------------->|
| | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
|H |some |some | |some |some |TS/PC |HMAC | |HMAC |T |
| |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | |
| | | | | | | | | | | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
P
|<----------------------------------------------------->| (D3)
| B |
| |<-------------------------------------------------->|
| | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
|H |TS/PC |HMAC | |HMAC |some |some | |some |some |T |
| |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | |
| | | | | | | | | | | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
P
|<------------------------------------------------------------>| (D4)
| B |
| |<--------------------------------------------------------->|
| | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
|H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T |
| |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | |
| | | | | | | | | | | | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
Figure 2: Babel Datagram Structure
図2：Babelデータグラムの構造
+-------+-------------------------+---------------+
| Value | Name | Reference |
+-------+-------------------------+---------------+
| 0 | Pad1 | [BABEL] |
| 1 | PadN | [BABEL] |
| 2 | Acknowledgement Request | [BABEL] |
| 3 | Acknowledgement | [BABEL] |
| 4 | Hello | [BABEL] |
| 5 | IHU | [BABEL] |
| 6 | Router-Id | [BABEL] |
| 7 | Next Hop | [BABEL] |
| 8 | Update | [BABEL] |
| 9 | Route Request | [BABEL] |
| 10 | Seqno Request | [BABEL] |
| 11 | TS/PC | this document |
| 12 | HMAC | this document |
+-------+-------------------------+---------------+
Table 1: Babel TLV Types 0 through 12
表1：バベルTLVタイプ0〜12
+--------------+-----------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+--------------+-----------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:14 | 20 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
+--------------+-----------------------------+-------------------+
Table 2: A Babel Packet without Authentication TLVs
表2：認証TLVのないBabelパケット
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
+---------------+-------------------------------+-------------------+
Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address
fe80::0a11:96ff:fe1c:10c8
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result |
| | 60:3a:ed:fd:06:55:83:f7:ee:79 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result |
| | c7:73:e0:b5:22:82:ce:fe:e2:3c | |
+---------------+-------------------------------+-------------------+
Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result
表4：HMAC結果を含む各HMAC TLVを含むバベルパケット
The test vectors below may be used to verify the correctness of some procedures performed by an implementation of this mechanism, namely:
以下のテストベクトルは、このメカニズムの実装によって実行されるいくつかの手順の正確さを確認するために使用できます。
o appending TS/PC and HMAC TLVs to the Babel packet body,
o TS / PCおよびHMAC TLVをBabelパケット本体に追加し、
o padding the HMAC TLV(s),
o HMAC TLVのパディング、
o computation of the HMAC result(s), and
o HMAC結果の計算、および
o placement of the result(s) in the TLV(s).
o TLVでの結果の配置。
This verification isn't exhaustive. There are other important implementation aspects that would require testing methods of their own.
この検証は完全ではありません。独自のテスト方法を必要とする重要な実装の側面が他にもあります。
The test vectors were produced as follows.
試験ベクターは以下のように作製した。
1. A Babel speaker with a network interface with IPv6 link-local address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs for the interface:
1. IPv6リンクローカルアドレスfe80 :: 0a11：96ff：fe1c：10c8のネットワークインターフェースを備えたBabelスピーカーは、インターフェースに2つのCSAを使用するように構成されました。
* CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, AuthKeyOctets=Key26}}}
* CSA1 = {HashAlgo = RIPEMD-160、KeyChain = {{LocalKeyID = 200、AuthKeyOctets = Key26}}}
* CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, AuthKeyOctets=Key70}}}
* CSA2 = {HashAlgo = SHA-1、KeyChain = {{LocalKeyId = 100、AuthKeyOctets = Key70}}}
The authentication keys above are:
上記の認証キーは次のとおりです。
* Key26 in ASCII:
* ASCIIのKey26：
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
* Key26 in hexadecimal:
* 16進数のKey26：
41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50
51:52:53:54:55:56:57:58:59:5a
* Key70 in ASCII:
* ASCIIのKey70：
This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
* Key70 in hexadecimal:
* 16進数のKey70：
54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63
74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f
6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c
4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31
32:33:34:35:36:37
The length of each key was picked to relate (using the terms listed in Section 2.4) to the properties of its respective hash algorithm as follows:
各キーの長さは、次のようにそれぞれのハッシュアルゴリズムのプロパティに関連付けるために（セクション2.4にリストされている用語を使用して）選択されました。
* the digest length (L) of both RIPEMD-160 and SHA-1 is 20 octets,
* RIPEMD-160とSHA-1の両方のダイジェスト長（L）は20オクテットです。
* the internal block size (B) of both RIPEMD-160 and SHA-1 is 64 octets,
* RIPEMD-160とSHA-1の両方の内部ブロックサイズ（B）は64オクテットです。
* the length of Key26 (26) is greater than L but less than B, and
* Key26（26）の長さがLより長くBより小さい
* the length of Key70 (70) is greater than B (and thus greater than L).
* Key70の長さ（70）がBより大きい（したがって、Lより大きい）。
KeyStartAccept, KeyStopAccept, KeyStartGenerate, and KeyStopGenerate were set to make both authentication keys valid.
KeyStartAccept、KeyStopAccept、KeyStartGenerate、およびKeyStopGenerateは、両方の認証キーを有効にするように設定されました。
2. The instance of the original protocol of the speaker produced a Babel packet (PktO) to be sent from the interface. Table 2 provides a decoding of PktO, the contents of which are below:
2. スピーカーの元のプロトコルのインスタンスは、インターフェイスから送信されるBabelパケット（PktO）を生成しました。表2に、PktOのデコードを示します。その内容は次のとおりです。
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff
3. The authentication mechanism appended one TS/PC TLV and two HMAC TLVs to the packet body, updated the "Body length" packet header field, and padded the Digest field of the HMAC TLVs, using the link-local IPv6 address of the interface and the necessary amount of zeroes. Table 3 provides a decoding of the resulting temporary packet (PktT), the contents of which are below:
3. 認証メカニズムは、1つのTS / PC TLVと2つのHMAC TLVをパケット本体に追加し、「Body length」パケットヘッダーフィールドを更新し、インターフェイスとリンクのリンクローカルIPv6アドレスを使用して、HMAC TLVのダイジェストフィールドにパディングしましたゼロの必要な量。表3に、結果の一時パケット（PktT）のデコードを示します。その内容は次のとおりです。
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff
fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00
00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00
4. The authentication mechanism produced two HMAC results, performing the computations as follows:
4. 認証メカニズムは2つのHMAC結果を生成し、次のように計算を実行しました。
* For H=RIPEMD-160, K=Key26, and Text=PktT, the HMAC result is:
* H = RIPEMD-160、K = Key26、およびText = PktTの場合、HMACの結果は次のとおりです。
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
83:f7:ee:79
* For H=SHA-1, K=Key70, and Text=PktT, the HMAC result is:
* H = SHA-1、K = Key70、およびText = PktTの場合、HMACの結果は次のとおりです。
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
ce:fe:e2:3c
5. The authentication mechanism placed each HMAC result into its respective HMAC TLV, producing the final authenticated Babel packet (PktA), which was eventually sent from the interface.
5. 認証メカニズムは、各HMAC結果をそれぞれのHMAC TLVに配置し、最終的に認証されたBabelパケット（PktA）を生成します。これは最終的にインターフェースから送信されました。
Table 4 provides a decoding of PktA, the contents of which are below:
表4にPktAのデコードを示します。その内容は次のとおりです。
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a
ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e
d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c
Interpretation of this process is to be done differently for the sending and receiving directions (see Figure 1).
このプロセスの解釈は、送信方向と受信方向で異なります（図1を参照）。
For the sending direction, given a Babel speaker configured using the IPv6 address and the sequence of CSAs as described above, the implementation SHOULD (see notes in Section 5.3) produce exactly the temporary packet PktT if the original protocol instance produces exactly the packet PktO to be sent from the interface. If the temporary packet exactly matches PktT, the HMAC results computed afterwards MUST exactly match the respective results above, and the final authenticated packet MUST exactly match PktA above.
送信方向については、上記のようにIPv6アドレスとCSAのシーケンスを使用して構成されたBabelスピーカーが与えられた場合、元のプロトコルインスタンスがパケットPktOを正確に生成する場合、実装SHOULD（5.3節の注記を参照）が一時パケットPktTを正確に生成する必要があります。インターフェイスから送信されます。一時パケットがPktTと完全に一致する場合、後で計算されるHMAC結果は上記のそれぞれの結果と完全に一致する必要があり、最終認証パケットは上記のPktAと完全に一致する必要があります。
For the receiving direction, given a Babel speaker configured using the sequence of CSAs as described above (but a different IPv6 address), the implementation MUST (assuming that the TS/PC check didn't fail) produce exactly the temporary packet PktT above if its network stack receives through the interface exactly the packet PktA above from the source IPv6 address above. The first HMAC result computed afterwards MUST match the first result above. The receiving procedure doesn't compute the second HMAC result in this case, but if the implementor decides to compute it anyway for verification purposes, it MUST exactly match the second result above.
受信方向については、上記のようにCSAのシーケンスを使用して構成されたバベルスピーカー（ただし、異なるIPv6アドレス）が与えられた場合、実装は（TS / PCチェックが失敗しなかったと仮定して）上記の一時パケットPktTを正確に生成する必要がありますそのネットワークスタックは、上記の送信元IPv6アドレスから上記のパケットPktAを正確にインターフェイス経由で受信します。後で計算される最初のHMAC結果は、上記の最初の結果と一致する必要があります。この場合、受信手順は2番目のHMAC結果を計算しませんが、実装者が検証目的でそれを計算することを決定した場合、上記の2番目の結果と正確に一致する必要があります。
Author's Address
著者のアドレス
Denis Ovsienko Yandex 16, Leo Tolstoy St. Moscow 119021 Russia
Denis Ovsienko Yandex 16、Leo Tolstoy St. Moscow 119021ロシア
EMail: infrastation@yandex.ru