[要約] RFC 4822は、RIPv2における暗号認証の仕組みを提案している。目的は、RIPv2のセキュリティを向上させ、認証されていないルーティング情報の受け入れを防ぐことである。
Network Working Group R. Atkinson
Request for Comments: 4822 Extreme Networks
Obsoletes: 2082 M. Fanto
Updates: 2453 NIST
Category: Standards Track February 2007
RIPv2 Cryptographic Authentication
RIPv2暗号化認証
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
IESG Note
IESG Note
In the interests of encouraging rapid migration away from Keyed-MD5 and its known weakness, the IESG has approved this document even though it does not meet the guidelines in BCP 107 (RFC 4107). However, the IESG stresses that automated key management should be used to establish session keys and urges that the future work on key management described in Section 5.6 of this document should be performed as soon as possible.
Keyed-MD5からの迅速な移行とその既知の弱点を奨励するために、IESGはBCP 107（RFC 4107）のガイドラインに適合していなくても、このドキュメントを承認しました。ただし、IESGは、自動化されたキー管理を使用してセッションキーを確立する必要があることを強調し、このドキュメントのセクション5.6で説明されているキー管理に関する将来の作業をできるだけ早く実行するように求めています。
Abstract
概要
This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section.
このノートでは、RFC 2082で最初に指定されたRIPv2暗号化認証メカニズムの改訂について説明します。このドキュメントは、RFC 2082を廃止し、RFC 2453を更新します。ドキュメントは、Keyed-MD5の使用のみを指定しています。また、このドキュメントでは、このメカニズムに対するアクティブな攻撃の潜在的な問題を明確にし、「セキュリティに関する考慮事項」セクションに重要なテキストを追加しています。
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIPv2 provides for unauthenticated service (as in classical RIP), or password authentication. Both are vulnerable to passive attacks currently widespread in the Internet. Well-understood security issues exist in routing protocols [Bell89]. Cleartext passwords, originally specified for use with RIPv2, are widely understood to be vulnerable to easily deployed passive attacks [HA94].
インターネットの成長により、ルーティング情報の認証を改善する必要性が認識されました。 RIPv2は、認証されていないサービス（従来のRIPと同様）、またはパスワード認証を提供します。どちらも、現在インターネットで広まっているパッシブ攻撃に対して脆弱です。よく理解されているセキュリティ問題がルーティングプロトコルに存在します[Bell89]。元々RIPv2で使用するために指定されたクリアテキストパスワードは、簡単に展開されるパッシブ攻撃[HA94]に対して脆弱であると広く理解されています。
The original RIPv2 cryptographic authentication specification, RFC 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. Further, some end users, particularly several different governments, require the use of the SHA hash function family rather than any other such function for policy reasons. Finally, the original specification uses a hashing construction widely believed to be weaker than the HMAC construction used with the algorithms added in this revision of the specification.
オリジナルのRIPv2暗号化認証仕様であるRFC 2082 [AB97]は、Keyed-MD5暗号化メカニズムを使用していました。そのメカニズムに対する公に公開された攻撃はありませんが、一部のレポート[Dobb96a、Dobb96b]は、MD5暗号化ハッシュ関数の最終的な強度について懸念を抱いています。さらに、一部のエンドユーザー、特にいくつかの異なる政府は、ポリシー上の理由から、他のそのような関数ではなくSHAハッシュ関数ファミリの使用を要求しています。最後に、元の仕様は、この仕様の改訂で追加されたアルゴリズムで使用されるHMAC構成よりも弱いと広く信じられているハッシュ構成を使用しています。
This document obsoletes the original specification, RFC 2082 [AB97]. This specification differs from RFC 2082 by adding support for the SHA family of hash algorithms and the HMAC technique, while retaining the original Keyed-MD5 algorithm and mode. As the original RIPv2 Cryptographic Authentication mechanism was algorithm-independent, backwards compatibility is retained. This requirement for backwards compatibility precludes making significant protocol changes. So, this document limits changes to the addition of support for an additional family of cryptographic algorithms. The original specification has been very widely implemented, is known to be widely interoperable, and is also widely deployed.
このドキュメントは、元の仕様であるRFC 2082 [AB97]を廃止します。この仕様は、RFC 2082とは異なり、ハッシュアルゴリズムのSHAファミリとHMAC技術のサポートを追加する一方で、元のKeyed-MD5アルゴリズムとモードを保持しています。元のRIPv2暗号化認証メカニズムはアルゴリズムに依存しないため、下位互換性が維持されます。下位互換性に関するこの要件により、プロトコルを大幅に変更することはできません。したがって、このドキュメントでは、追加の暗号化アルゴリズムファミリのサポートの追加に対する変更を制限しています。元の仕様は非常に広く実装されており、広く相互運用可能であることが知られており、広く展開されています。
The authors do NOT believe that this specification is the final answer to RIPv2 authentication and encourage the reader to consult the Security Considerations section of this document for more details.
著者は、この仕様がRIPv2認証に対する最終的な回答であるとは考えていません。詳細については、このドキュメントの「セキュリティに関する考慮事項」セクションを参照することをお勧めします。
If RIPv2 authentication is disabled, then only simple misconfigurations are detected. The original RIPv2 authentication mechanism relied upon reused cleartext passwords. Use of cleartext password authentication can protect against accidental misconfigurations if that were the only concern, but is not helpful from a security perspective. By simply capturing information on the wire -- straightforward even in a remote environment -- a hostile entity can read the cleartext RIPv2 password and use that knowledge to inject false information into the routing system via the RIPv2 routing protocol.
RIPv2認証が無効になっている場合は、単純な設定ミスのみが検出されます。元のRIPv2認証メカニズムは、再利用されたクリアテキストパスワードに依存していました。クリアテキストのパスワード認証の使用は、それが唯一の懸念事項である場合、偶発的な誤設定から保護できますが、セキュリティの観点からは役立ちません。悪意のあるエンティティは、リモート環境でも単純にネットワーク上の情報をキャプチャするだけで、クリアテキストのRIPv2パスワードを読み取り、その知識を使用して、RIPv2ルーティングプロトコルを介してルーティングシステムに誤った情報を注入できます。
This mechanism is intended to reduce the risk of a successful passive attack upon RIPv2 deployments. That is, deployment of this mechanism greatly reduces the vulnerability of the RIPv2-based routing system from a passive attack. When cryptographic authentication is enabled, we transmit the output of a keyed cryptographic one-way function in the authentication field of the RIPv2 packet, instead of sending a cleartext reusable password in the RIPv2 packet. The RIPv2 Authentication Key is known only to the authorized parties of the RIPv2 session. The RIPv2 Authentication Key is never sent over the network in the clear.
このメカニズムは、RIPv2展開に対するパッシブ攻撃が成功するリスクを軽減することを目的としています。つまり、このメカニズムの展開により、RIPv2ベースのルーティングシステムの脆弱性がパッシブ攻撃から大幅に軽減されます。暗号化認証が有効な場合、RIPv2パケットでクリアテキストの再利用可能なパスワードを送信する代わりに、RIPv2パケットの認証フィールドでキー付き暗号化一方向関数の出力を送信します。 RIPv2認証キーは、RIPv2セッションの許可された当事者だけが知っています。 RIPv2認証キーがネットワーク上に平文で送信されることはありません。
In this way, protection is afforded against forgery or message modification. While it is possible to replay a message until the sequence number changes, a sequence number can be used to reduce replay risks. The mechanism does not provide confidentiality, since messages stay in the clear. Since the objective of a routing protocol is to advertise the routing topology, confidentiality is not normally required for routing protocols.
このようにして、偽造やメッセージの変更に対する保護が提供されます。シーケンス番号が変わるまでメッセージを再生することは可能ですが、シーケンス番号を使用して、再生のリスクを減らすことができます。メッセージは平文のままなので、メカニズムは機密性を提供しません。ルーティングプロトコルの目的はルーティングトポロジをアドバタイズすることなので、通常、ルーティングプロトコルには機密性は必要ありません。
Other relevant rationales for the approach are that MD5 and SHA-1 are both being used for other purposes and are therefore generally already present in IP routers, as is some form of password management.
このアプローチに関連する他の理論的根拠は、MD5とSHA-1の両方が他の目的で使用されているため、何らかの形式のパスワード管理と同様に、一般にIPルーターにすでに存在していることです。
In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [BCP14] and indicate requirement levels for compliant or conformant implementations.
このドキュメントでは、「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「オプション」は、[BCP14]で説明されているように解釈され、準拠または適合実装の要件レベルを示します。
Implementation requires use of a special packet format, special authentication procedures, and also management controls. Implementers need to remember that the Security Considerations section is an integral part of this specification and contains important parts of this specification.
実装には、特別なパケット形式、特別な認証手順、および管理制御の使用が必要です。実装者は、セキュリティに関する考慮事項のセクションがこの仕様の不可欠な部分であり、この仕様の重要な部分を含んでいることを覚えておく必要があります。
The basic RIPv2 message format provides for an 8-octet header with an array of 20-octet records as its data content. When RIPv2 Cryptographic Authentication is enabled, the same header and content are used as with the original RIPv2 specification, but the 16-octet "Authentication" password field of the original RIPv2 specification is reused to contain a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number.
基本的なRIPv2メッセージフォーマットは、データコンテンツとして20オクテットのレコードの配列を持つ8オクテットヘッダーを提供します。 RIPv2暗号認証が有効になっている場合、元のRIPv2仕様と同じヘッダーとコンテンツが使用されますが、元のRIPv2仕様の16オクテットの「認証」パスワードフィールドは、認証データへのパケットオフセットを含むために再利用されます。識別子、認証データ長、および減少しないシーケンス番号。
AUTHENTICATION TYPE The "Authentication Type" is Cryptographic Hash Function, which is indicated by the value 3.
認証タイプ「認証タイプ」は、値3で示される暗号化ハッシュ関数です。
RIPv2 PACKET LENGTH An unsigned 16-bit offset from the start of the RIPv2 header to the end of the regular RIPv2 packet (not including the authentication trailer).
RIPv2パケットの長さRIPv2ヘッダーの先頭から通常のRIPv2パケットの末尾（認証トレーラーは含まない）までの符号なし16ビットオフセット。
KEY IDENTIFIER An unsigned 8-bit field that contains the Key Identifier or Key-ID. This, in combination with the network interface, identifies the RIPv2 Security Association in use for this packet. The RIPv2 Security Association, which is defined in Section 2.2 below, includes the Authentication Key that was used to create the Authentication Data for this RIPv2 message and other parameters. In implementations supporting more than one authentication algorithm, the RIPv2 Security Association also includes information about which authentication algorithm is in use for this message. A RIPv2 Security Association is always associated with an interface, rather than with a router. The actual cryptographic key is part of the RIPv2 Security Association.
KEY IDENTIFIERキー識別子またはキーIDを含む符号なし8ビットフィールド。これは、ネットワークインターフェイスと組み合わせて、このパケットに使用されているRIPv2セキュリティアソシエーションを識別します。以下のセクション2.2で定義されているRIPv2セキュリティアソシエーションには、このRIPv2メッセージおよびその他のパラメーターの認証データを作成するために使用された認証キーが含まれています。複数の認証アルゴリズムをサポートする実装では、RIPv2セキュリティアソシエーションには、このメッセージに使用されている認証アルゴリズムに関する情報も含まれています。 RIPv2セキュリティアソシエーションは、ルーターではなく、常にインターフェイスに関連付けられています。実際の暗号化キーは、RIPv2 Security Associationの一部です。
AUTHENTICATION DATA LENGTH An unsigned 8-bit field that contains the length in octets of the trailing Authentication Data field. The presence of this field helps provide cryptographic algorithm independence.
AUTHENTICATION DATA LENGTH後続の認証データフィールドの長さをオクテット単位で含む符号なし8ビットフィールド。このフィールドの存在は、暗号アルゴリズムの独立性を提供するのに役立ちます。
AUTHENTICATION DATA This field contains the cryptographic Authentication Data used to validate this packet. The length of this field is stored in the AUTHENTICATION DATA LENGTH field above.
AUTHENTICATION DATAこのフィールドには、このパケットの検証に使用される暗号化認証データが含まれています。このフィールドの長さは、上のAUTHENTICATION DATA LENGTHフィールドに格納されています。
SEQUENCE NUMBER An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing for all messages sent from a given source router with a given Key ID value.
シーケンス番号符号なし32ビットシーケンス番号。シーケンス番号は、特定のキーID値を持つ特定のソースルーターから送信されるすべてのメッセージで減少しないようにする必要があります。
The authentication trailer contains the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
認証トレーラーには、キー付き暗号化ハッシュ関数の出力である認証データが含まれています。このフィールドの計算の詳細については、このセクションの後のサブセクションを参照してください。
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
+---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+
Understanding the RIPv2 Security Association concept is central to understanding this specification. A RIPv2 Security Association contains the set of shared authentication configuration parameters needed by the legitimate sender or any legitimate receiver.
この仕様を理解するには、RIPv2セキュリティアソシエーションの概念を理解することが中心です。 RIPv2セキュリティアソシエーションには、正当な送信者または正当な受信者が必要とする共有認証構成パラメータのセットが含まれています。
An implementation MUST be able to support at least 2 concurrent RIPv2 Security Associations on each RIP interface. This is a functional requirement for supporting key rollover. Support for key rollover is mandatory.
実装は、各RIPインターフェイスで少なくとも2つの同時RIPv2セキュリティアソシエーションをサポートできる必要があります。これは、キーのロールオーバーをサポートするための機能要件です。キーのロールオーバーのサポートは必須です。
The RIPv2 Security Association, defined below, is selected by the sender based on the outgoing router interface. Each RIPv2 Security Association has a lifetime and other configuration parameters associated with it. In normal operation, a RIPv2 Security Association is never used outside its lifetime. Certain abnormal cases are discussed later in this document.
以下で定義するRIPv2セキュリティアソシエーションは、発信ルーターインターフェイスに基づいて送信者が選択します。各RIPv2セキュリティアソシエーションには、ライフタイムとその他の設定パラメータが関連付けられています。通常の運用では、RIPv2セキュリティアソシエーションはその有効期間外には使用されません。特定の異常なケースについては、このドキュメントで後述します。
The minimum data items in a RIPv2 Security Association are as follows:
RIPv2セキュリティアソシエーションの最小データ項目は次のとおりです。
KEY-IDENTIFIER (KEY-ID) The unsigned 8-bit KEY-ID value is used to identify the RIPv2 Security Association in use for this packet.
KEY-IDENTIFIER（KEY-ID）符号なし8ビットKEY-ID値は、このパケットに使用されているRIPv2セキュリティアソシエーションを識別するために使用されます。
The receiver uses the combination of the interface the packet was received upon and the KEY-ID value to uniquely identify the appropriate Security Association.
レシーバーは、パケットが受信されたインターフェイスとKEY-ID値の組み合わせを使用して、適切なセキュリティアソシエーションを一意に識別します。
The sender selects which RIPv2 Security Association to use based on the outbound interface for this RIPv2 packet and then places the correct KEY-ID value into that packet. If multiple valid and active RIPv2 Security Associations exist for a given outbound interface at the time a RIPv2 packet is sent, the sender may use any of those security associations to protect the packet.
送信者は、このRIPv2パケットの送信インターフェイスに基づいて、使用するRIPv2セキュリティアソシエーションを選択し、正しいKEY-ID値をそのパケットに配置します。 RIPv2パケットが送信されるときに、複数の有効かつアクティブなRIPv2セキュリティアソシエーションが特定の送信インターフェイスに存在する場合、送信者はそれらのセキュリティアソシエーションのいずれかを使用してパケットを保護できます。
AUTHENTICATION ALGORITHM This specifies the cryptographic algorithm and algorithm mode used with the RIPv2 Security Association. This information is never sent in cleartext over the wire. Because this information is not sent on the wire, the implementer chooses an implementation specific representation for this information. At present, the following values are possible: KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
AUTHENTICATION ALGORITHMこれは、RIPv2 Security Associationで使用される暗号化アルゴリズムとアルゴリズムモードを指定します。この情報がネットワーク上で平文で送信されることはありません。この情報はネットワーク上で送信されないため、実装者はこの情報に対して実装固有の表現を選択します。現在、可能な値はKEYED-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512です。
AUTHENTICATION KEY This is the value of the cryptographic authentication key used with the associated Authentication Algorithm. It MUST NOT ever be sent over the network in cleartext via any protocol. The length of this key will depend on the Authentication Algorithm in use. Operators should take care to select unpredictable and strong keys, avoiding any keys known to be weak for the algorithm in use. [ESC05] contains helpful information on both key generation techniques and cryptographic randomness.
AUTHENTICATION KEYこれは、関連する認証アルゴリズムで使用される暗号化認証キーの値です。ネットワークを介して、プロトコルを介してクリアテキストで送信することはできません。このキーの長さは、使用している認証アルゴリズムによって異なります。オペレーターは、予測できない強力なキーを選択するように注意し、使用中のアルゴリズムに対して脆弱であることがわかっているキーを回避する必要があります。 [ESC05]には、鍵生成技術と暗号のランダム性の両方に関する役立つ情報が含まれています。
SEQUENCE NUMBER This is an unsigned 32-bit number. For a given KEY-ID value and sender, this number MUST NOT decrease. In normal operation, the operator should rekey the RIPv2 session prior to reaching the maximum value. The initial value used in the sequence number is arbitrary. Receivers SHOULD keep track of the most recent sequence number received from a given sender.
シーケンス番号これは、符号なし32ビット番号です。与えられたKEY-ID値と送信者について、この数は減少してはならない（MUST NOT）。通常の操作では、オペレーターは最大値に達する前にRIPv2セッションのキーを再設定する必要があります。シーケンス番号に使用される初期値は任意です。受信者は、特定の送信者から受信した最新のシーケンス番号を追跡する必要があります（SHOULD）。
START TIME This is a local representation of the day and time that this Security Association first becomes valid.
開始時間これは、このセキュリティアソシエーションが最初に有効になる日時のローカル表現です。
STOP TIME This is a local representation of the day and time that this Security Association becomes invalid (i.e., when it expires). It is permitted, but not recommended, for an operator to configure this to "never expire". The "never expire" value is not recommended operational practice because it reduces security as compared with periodic rekeying. Normally, a RIPv2 Security Association is deleted at its STOP TIME. However, there are certain pathological cases, which are discussed in Section 5.1.
STOP TIMEこれは、このSecurity Associationが無効になる（つまり、有効期限が切れる）日時のローカルな表現です。オペレーターがこれを「無期限」に構成することは許可されていますが、お勧めできません。 「有効期限なし」の値は、定期的な鍵の再生成と比較してセキュリティが低下するため、運用上の推奨事項ではありません。通常、RIPv2セキュリティアソシエーションはその停止時間に削除されます。ただし、セクション5.1で説明されている特定の病理学的ケースがあります。
The authentication trailer consists of the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
認証トレーラーは、キー付き暗号化ハッシュ関数の出力である認証データで構成されています。このフィールドの計算の詳細については、このセクションの後のサブセクションを参照してください。
When the authentication type is "Cryptographic Hash Function", message processing is changed in message creation and reception as compared with the original RIPv2 specification in [Mal94].
認証タイプが「暗号化ハッシュ関数」の場合、[Mal94]の元のRIPv2仕様と比較して、メッセージの作成と受信におけるメッセージ処理が変更されます。
This section describes the message processing generically. Additional algorithm-dependent processing that is required is described in separate, subsequent sections of this document. As of this writing, there are 2 kinds of algorithm-dependent processing. One covers the "Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of algorithms.
このセクションでは、メッセージ処理について一般的に説明します。必要な追加のアルゴリズム依存処理については、このドキュメントの後続のセクションで説明します。これを書いている時点では、2種類のアルゴリズム依存処理があります。 1つは「Keyed-MD5」アルゴリズムをカバーしています。もう1つは、アルゴリズムの「HMAC-SHA1」ファミリーをカバーしています。
The RIPv2 Packet is created as usual, with these exceptions:
RIPv2パケットは通常どおり作成されますが、次の例外があります。
(1) The UDP checksum SHOULD be calculated, but MAY be set to zero because any of the cryptographic authentication mechanisms in this specification will provide stronger integrity protection than the standard UDP checksum.
（1）UDPチェックサムを計算する必要があります（SHOULD）が、この仕様の暗号化認証メカニズムは標準のUDPチェックサムよりも強力な整合性保護を提供するため、ゼロに設定する必要があります。
(2) The Authentication Type field indicates Cryptographic Authentication (3).
（2）「認証タイプ」フィールドは、暗号化認証（3）を示します。
(3) The Authentication "password" field is reused to store a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number.
（3）認証「パスワード」フィールドは、認証データ、キー識別子、認証データ長、および減少しないシーケンス番号へのパケットオフセットを格納するために再利用されます。
See also Section 2.2 above on RIPv2 Security Association for other important background information.
その他の重要な背景情報については、RIPv2 Security Associationに関する上記のセクション2.2も参照してください。
When creating the RIPv2 Packet, the following process is followed:
RIPv2パケットを作成する場合、次のプロセスに従います。
(1) The Packet Length field of the RIPv2 header indicates the size of the main body of the RIPv2 packet.
（1）RIPv2ヘッダーのパケット長フィールドは、RIPv2パケットの本体のサイズを示します。
(2) An appropriate RIPv2 Security Association is selected for use with this packet, based on the outbound interface for the packet. Any valid RIPv2 Security Association for that outbound interface may be used. The Authentication Data Offset, Key Identifier, and Authentication Data Length fields are filled in appropriately.
（2）パケットの発信インターフェースに基づいて、このパケットで使用するために適切なRIPv2セキュリティアソシエーションが選択されます。そのアウトバウンド・インターフェースの有効なRIPv2 Security Associationを使用できます。 「認証データのオフセット」、「鍵ID」、および「認証データの長さ」フィールドに適切に入力されます。
(3) Algorithm-dependent processing occurs now, either for the "Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family. See the respective sub-sections (below) for details of this algorithm-dependent processing.
（3）「Keyed-MD5」アルゴリズムまたは「HMAC-SHA1」アルゴリズムファミリのいずれかに、アルゴリズム依存の処理が行われるようになりました。このアルゴリズムに依存する処理の詳細については、それぞれのサブセクション（下記）を参照してください。
(4) The resulting Authentication Data value is written into the Authentication Data field. The trailing pad (if any) is not actually transmitted, as it is entirely predictable from the message length and Authentication Algorithm in use.
（4）結果の認証データ値は、認証データフィールドに書き込まれます。末尾のパッド（ある場合）は、メッセージの長さと使用中の認証アルゴリズムから完全に予測できるため、実際には送信されません。
When the message is received, the process is reversed:
メッセージを受信すると、プロセスが逆になります。
(1) The received Authentication Data is set aside and stored for later use,
（1）受信した認証データは、後で使用できるように保存されます。
(2) The appropriate RIPv2 Security Association is determined from the value of the Key Identifier field and the interface the packet was received on. If there is no valid RIPv2 Security Association for the received Key Identifier on the interface that the packet was received on, then:
（2）適切なRIPv2セキュリティアソシエーションは、Key Identifierフィールドの値とパケットが受信されたインターフェイスから決定されます。パケットが受信されたインターフェース上に、受信された鍵IDの有効なRIPv2セキュリティー・アソシエーションがない場合は、次のようになります。
(a) all processing of the incoming packet ceases, and
（a）着信パケットのすべての処理が停止します。
(b) a security event SHOULD be logged by the RIPv2 subsystem of the receiving system. That security event should indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that no valid RIPv2 Security Association was found for that interface and Key-ID combination.
（b）セキュリティイベントは、受信システムのRIPv2サブシステムによってログに記録される必要があります（SHOULD）。このセキュリティイベントは、少なくとも不良パケットを受信した日時、受信したRIPv2パケットの送信元IPアドレス、Key-IDフィールド値、不良パケットが到着したインターフェイス、および有効なRIPv2がないことを示す必要がありますそのインターフェイスとキーIDの組み合わせに対するセキュリティアソシエーションが見つかりました。
(3) Algorithm-dependent processing is performed, using the algorithm specified by the appropriate RIPv2 Security Association for this packet. This results in calculation of the Authentication Data based on the information in the received RIPv2 packet and information from the appropriate RIPv2 Security Association for that packet.
（3）このパケットに対して適切なRIPv2セキュリティアソシエーションによって指定されたアルゴリズムを使用して、アルゴリズムに依存する処理が実行されます。これにより、受信したRIPv2パケットの情報と、そのパケットの適切なRIPv2セキュリティアソシエーションからの情報に基づいて、認証データが計算されます。
(4) The calculated Authentication Data result is compared with the received Authentication Data.
（4）計算された認証データの結果は、受信した認証データと比較されます。
(5) If the calculated authentication data result does not match the received Authentication Data field, then:
（5）計算された認証データの結果が受信した認証データフィールドと一致しない場合：
(a) the message MUST be discarded without being processed, and
（a）メッセージは処理されずに破棄されなければならない、そして
(b) a security event SHOULD be logged by the RIPv2 subsystem of the receiving system. That security event SHOULD indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that RIPv2 Authentication failed upon receipt of the packet.
（b）セキュリティイベントは、受信システムのRIPv2サブシステムによってログに記録される必要があります（SHOULD）。そのセキュリティイベントは、少なくとも不良パケットが受信された日時、受信されたRIPv2パケットの送信元IPアドレス、Key-IDフィールド値、不良パケットが到着したインターフェイス、およびRIPv2認証が失敗したことを示す必要があります（SHOULD）。パケットを受信すると。
(6) If the neighbor has been heard from recently enough to have viable routes in the local routing table, and the received sequence number is less than the last sequence number received, then the message MUST be discarded unprocessed. If the received sequence number is less than the last sequence number received, that fact SHOULD be logged as a security event. This logged security event SHOULD indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, and the fact that an out-of-order RIPv2 sequence number was received.
（6）ローカルルーティングテーブルに実行可能なルートが存在するほど最近からネイバーからの応答があり、受信したシーケンス番号が最後に受信したシーケンス番号よりも小さい場合、メッセージは未処理で破棄されなければなりません（MUST）。受信したシーケンス番号が最後に受信したシーケンス番号より小さい場合、その事実はセキュリティイベントとしてログに記録される必要があります（SHOULD）。このログに記録されたセキュリティイベントは、少なくとも不良パケットが受信された日時、受信されたRIPv2パケットの送信元IPアドレス、Key-IDフィールド値、および異常なRIPv2シーケンス番号があったことを示す必要があります（SHOULD）。受け取った。
When connectivity to the neighbor has been lost, the receiver SHOULD be ready to accept either:
ネイバーへの接続が失われた場合、レシーバーは次のいずれかを受け入れる準備ができている必要があります。
- a message with a sequence number of zero.
- シーケンス番号がゼロのメッセージ。
- a message with a higher sequence number than the last received sequence number.
- 最後に受信したシーケンス番号よりも大きいシーケンス番号を持つメッセージ。
(7) Acceptable messages are now truncated to the RIPv2 message itself, minus the authentication trailer, and are processed normally (i.e., in accordance with the RIPv2 base specification in RFC 2453 [Mal98]). The last received sequence number for this RIPv2 Security Association and sender is also updated.
（7）受け入れ可能なメッセージは、認証トレーラを除いたRIPv2メッセージ自体に切り捨てられ、通常どおり処理されます（つまり、RFC 2453 [Mal98]のRIPv2基本仕様に従って）。このRIPv2セキュリティアソシエーションと送信者の最後に受信したシーケンス番号も更新されます。
NOTA BENE: A router that has forgotten its current sequence number but remembers its Security Association MUST send its first packet with a sequence number of zero. This leaves a small opening for a replay attack. To reduce the risk of such attacks by precluding the situation where a router has forgotten its current sequence number, implementers SHOULD provide non-volatile storage for all components of a RIPv2 Security Association, and receiving systems SHOULD provide non-volatile storage for the last received sequence number from each sender. See also the Security Considerations section of this document.
注：現在のシーケンス番号を忘れたが、セキュリティアソシエーションを記憶しているルーターは、シーケンス番号がゼロの最初のパケットを送信する必要があります。これにより、リプレイ攻撃の余地が少なくなります。ルーターが現在のシーケンス番号を忘れた状況を排除することにより、このような攻撃のリスクを減らすために、実装者はRIPv2セキュリティアソシエーションのすべてのコンポーネントに不揮発性ストレージを提供する必要があり（SHOULD）、受信システムは最後に受信した不揮発性ストレージを提供する必要があります（SHOULD）各送信者からのシーケンス番号。このドキュメントの「セキュリティに関する考慮事項」セクションも参照してください。
This section describes the algorithm-dependent processing steps applicable when the "Keyed-MD5" authentication algorithm is in use. The RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is in use.
このセクションでは、「Keyed-MD5」認証アルゴリズムが使用されている場合に適用可能な、アルゴリズムに依存する処理手順について説明します。 「Keyed-MD5」が使用されている場合、RIPv2認証キーは常に16オクテットです。
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet in memory.
（1）RIPv2認証キーがメモリ内のRIPv2パケットに追加されます。
(2) The Trailing Pad for MD5 and message length fields are added in memory. The diagram below shows how these additions appear when appended in memory:
（2）MD5のトレーリングパッドとメッセージ長フィールドがメモリに追加されます。以下の図は、メモリに追加されたときにこれらの追加がどのように表示されるかを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) The Authentication Data is then calculated according to the MD5 algorithm defined by RFC 1321 [Rivest92].
（3）次に、RFC 1321 [Rivest92]で定義されたMD5アルゴリズムに従って認証データが計算されます。
This section describes the processing steps for HMAC Authentication. While HMAC was originally documented in [KMC97], for this specification, the terminology used in [FIPS-198] is used. While the current specification only provides full details for HMAC Authentication using the National Institute of Standards and Technology (NIST) SHA-1 algorithm (and its direct derivatives), this same basic process could be used with other cryptographic hash functions in the future. Because the RIPv2 packet is only hashed once, the overhead of the double hashing in this process is negligible.
このセクションでは、HMAC認証の処理手順について説明します。 HMACはもともと[KMC97]で文書化されていましたが、この仕様では[FIPS-198]で使用されている用語が使用されています。現在の仕様では、米国連邦情報・技術局（NIST）のSHA-1アルゴリズム（およびその直接派生物）を使用したHMAC認証の完全な詳細のみが提供されていますが、この同じ基本プロセスは、将来、他の暗号化ハッシュ関数で使用される可能性があります。 RIPv2パケットは1回だけハッシュされるため、このプロセスでのダブルハッシュのオーバーヘッドは無視できます。
The US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2], includes specifications for SHA-1, SHA-256, SHA-384, and SHA-512. This specification defines processing for each of these.
[FIPS-180-2]で定義されたUS NISTセキュアハッシュ標準（SHS）には、SHA-1、SHA-256、SHA-384、およびSHA-512の仕様が含まれています。この仕様では、これらのそれぞれの処理を定義しています。
The output of the cryptographic computations (e.g., HMAC-SHA1) is NOT truncated for RIPv2 Cryptographic Authentication.
暗号化計算の出力（HMAC-SHA1など）は、RIPv2暗号化認証では切り捨てられません。
The Authentication Data Length is equal to the Message Digest Size for the hash algorithm in use.
認証データ長は、使用中のハッシュアルゴリズムのメッセージダイジェストサイズと同じです。
Any key value known to be weak with an algorithm defined by the NIST Secure Hash Standard MUST NOT be used with such an algorithm in an implementation of this specification. US NIST is the authoritative source for public information on weak keys for those algorithms.
NIST Secure Hash Standardで定義されたアルゴリズムで脆弱であることがわかっているキー値は、この仕様の実装でそのようなアルゴリズムと共に使用してはなりません（MUST NOT）。 US NISTは、これらのアルゴリズムの脆弱な鍵に関する公開情報の信頼できる情報源です。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:
以下のアルゴリズムの説明では、[FIPS-198]と一致する次の用語が使用されています。
H is the specific hashing algorithm, for example, SHA-1 or SHA-256. Ko is the cryptographic key used with the hash algorithm. B is the block-size of H, measured in octets, not bits. Note that B is the internal block size, not the hash size. For SHA-1 and SHA-256: B == 64. For SHA-384 and SHA-512: B == 128 L is the length of the hash, measured in octets, not bits. For example, with SHA-1, L == 20. XOR is the exclusive-or operation. Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
Hは、SHA-1やSHA-256などの特定のハッシュアルゴリズムです。 Koは、ハッシュアルゴリズムで使用される暗号化キーです。 BはHのブロックサイズであり、ビットではなくオクテットで測定されます。 Bは内部ブロックサイズであり、ハッシュサイズではないことに注意してください。 SHA-1およびSHA-256の場合：B ==64。SHA-384およびSHA-512の場合：B == 128 Lはハッシュの長さで、ビットではなくオクテットで測定されます。たとえば、SHA-1の場合、L == 20です。XORは排他的論理和演算です。 Opadは、16進値0x5cをB回繰り返したものです。 Ipadは、16進値0x36をB回繰り返したものです。 Apadは、16進値0x878FE1F3を（L / 4）回繰り返したものです。
(1) PREPARATION OF KEY In this application, Ko is always L octets long.
（1）キーの準備このアプリケーションでは、Koは常にLオクテットの長さです。
If the Authentication Key is L octets long, then Ko is set equal to the Authentication Key. If the Authentication Key is more than L octets long, then Ko is set to H(Authentication Key). If the Authentication Key is less than L octets long, then Ko is set to the Authentication Key with zeros appended to the end of the Authentication Key such that Ko is L octets long.
認証キーがLオクテット長である場合、Koは認証キーと等しく設定されます。認証キーがLオクテットより長い場合、KoはH（認証キー）に設定されます。認証キーがLオクテットより短い場合、Koは認証キーに設定され、認証キーの最後にゼロが追加されてKoがLオクテットになるようになります。
(2) FIRST HASH First, the RIPv2 packet's Authentication Data field is filled with the value Apad.
（2）FIRST HASHまず、RIPv2パケットの認証データフィールドに値Apadが入力されます。
Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (RIPv2 Packet))
次に、内部ハッシュとも呼ばれる最初のハッシュが次のように計算されます。First-Hash = H（Ko XOR Ipad ||（RIPv2 Packet））
(3) SECOND HASH Then a second hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash)
（3）2番目のハッシュ次に、2番目のハッシュ（外部ハッシュとも呼ばれます）は次のように計算されます：2番目のハッシュ= H（Ko XOR Opad ||最初のハッシュ）
(4) RESULT The result Second-Hash becomes the authentication data that is sent in the Authentication Data field of the RIPv2 packet. The length of the Authentication Data field is always identical to the message digest size of the hash function H that is being used.
（4）結果結果のSecond-Hashは、RIPv2パケットのAuthentication Dataフィールドで送信される認証データになります。 「認証データ」フィールドの長さは、使用されているハッシュ関数Hのメッセージダイジェストサイズと常に同じです。
This also implies that use of hash functions with larger output sizes will also increase the size of the packet as transmitted on the wire.
これは、出力サイズが大きいハッシュ関数を使用すると、回線上で送信されるパケットのサイズも大きくなることも意味します。
Key management is an important component of this mechanism and proper implementation is central to providing the intended level of risk reduction.
キー管理はこのメカニズムの重要なコンポーネントであり、適切な実装は、意図したレベルのリスク削減を提供するための中心です。
It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be configured or stored using protocols (e.g., RADIUS) or cryptographic algorithms that have known flaws.
1つのインターネットプロトコルの仮想セキュリティ違反が他のインターネットプロトコルを自動的に侵害しないことが強く望まれます。この仕様の認証キーは、既知の欠陥があるプロトコル（RADIUSなど）または暗号化アルゴリズムを使用して構成または保存しないでください。
Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface. Implementations MUST associate a specific Security Association lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key. Implementations also MUST support manual key distribution. An example of manual key distribution is having the privileged user typing in the key, key lifetime, and key identifier on the router console. An operator may configure the Security Association lifetime to infinite, which means that the session is never rekeyed. However, instead, it is strongly recommended that operators rekey regularly, using a moderately short Security Association lifetime (e.g., 24 hours).
実装は、同時に複数のキーの格納をサポートしなければなりません（MUST）が、通常、インターフェース上でアクティブになるのは1つのキーだけであることは認識されています。実装は、特定のセキュリティアソシエーションの有効期間（つまり、最初に有効な日付/時刻ともはや有効でない日付/時刻）とキー識別子を各キーに関連付ける必要があります。実装は手動の鍵配布もサポートする必要があります。手動でのキー配布の例としては、特権ユーザーがルータコンソールでキー、キーの有効期間、およびキー識別子を入力することが挙げられます。オペレータは、セキュリティアソシエーションのライフタイムを無限に設定する場合があります。つまり、セッションは再生成されません。ただし、代わりに、やや短いセキュリティアソシエーションのライフタイム（24時間など）を使用して、オペレーターが定期的に鍵を更新することを強くお勧めします。
This specification requires support for at least two authentication algorithms, so the implementation MUST require that the authentication algorithm be specified for each key when the other key information is entered. Manual deletion of active Security Associations MUST be supported.
この仕様では、少なくとも2つの認証アルゴリズムのサポートが必要であるため、他のキー情報を入力するときは、実装ごとにキーごとに認証アルゴリズムを指定する必要があります。アクティブなセキュリティアソシエーションの手動削除をサポートする必要があります。
It is likely that the IETF will define a standard key management protocol for use with routing protocols. It is strongly desirable to use an IETF standards-track key management protocol to distribute RIPv2 Authentication Keys among communicating RIPv2 implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key-ID field can be used as a hook between RIPv2 and such a future protocol.
IETFは、ルーティングプロトコルで使用する標準のキー管理プロトコルを定義する可能性があります。通信しているRIPv2実装間でRIPv2認証キーを配布するには、IETF標準トラックキー管理プロトコルを使用することが強く望まれます。このようなプロトコルはスケーラビリティを提供し、人間の管理負担を大幅に軽減します。 Key-IDフィールドは、RIPv2とそのような将来のプロトコルとの間のフックとして使用できます。
Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RIPv2 implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
鍵管理プロトコルには微妙な欠陥の長い歴史があり、プロトコルが最初に公開されてからかなり後に発見されることがよくあります。このような欠陥が発見された場合にすべてのRIPv2実装を変更する必要がないように、統合されたキー管理プロトコル技術はこの仕様から意図的に省略されました。
As with all security methods using keys, it is necessary to change the RIPv2 Authentication Key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one RIPv2 Authentication Key on a given interface at the same time.
キーを使用するすべてのセキュリティメソッドと同様に、RIPv2認証キーを定期的に変更する必要があります。そのような変更の間、ルーティングの安定性を維持するために、実装は、与えられたインターフェースで同時に複数のRIPv2認証キーを保存して使用できなければなりません（MUST）。
Each key will have its own Key Identifier (KEY-ID), which is stored locally. The combination of the Key Identifier and the interface associated with the message uniquely identifies the Authentication Algorithm and RIPv2 Authentication Key in use.
各キーには、ローカルに保存される独自のキー識別子（KEY-ID）があります。キー識別子とメッセージに関連付けられたインターフェイスの組み合わせにより、使用中の認証アルゴリズムとRIPv2認証キーが一意に識別されます。
As noted above in Section 2.3.1, the party creating the RIPv2 message will select a valid RIPv2 Security Association from the set of valid RIPv2 Security Associations for that interface. The receiver MUST use the Key Identifier and receiving interface to determine which RIPv2 Security Association to use for authentication of the received message. More than one RIPv2 Security Association MAY be associated with an interface at the same time. The receiver MUST NOT simply try all RIPv2 Security Associations (i.e., keys) that might be configured for RIPv2 on the receiving interface, as that creates an easily exploited denial-of-service attack on the RIP subsystem of the receiver. (At least one widely used implementation of the previous version of this specification violates these requirements as of the publication date of this document and has consequent security vulnerabilities.)
上記のセクション2.3.1で述べたように、RIPv2メッセージを作成するパーティは、そのインターフェースの有効なRIPv2セキュリティアソシエーションのセットから有効なRIPv2セキュリティアソシエーションを選択します。受信者はキー識別子と受信インターフェイスを使用して、受信したメッセージの認証に使用するRIPv2セキュリティアソシエーションを決定する必要があります。複数のRIPv2セキュリティアソシエーションを同時にインターフェイスに関連付けることができます。受信側のRIPサブシステムで簡単に悪用されるサービス拒否攻撃を作成するため、受信側は、受信側インターフェースでRIPv2用に構成されている可能性があるすべてのRIPv2セキュリティアソシエーション（つまり、キー）を単純に試行してはなりません（MUST NOT）。 （この仕様の以前のバージョンの少なくとも1つの広く使用されている実装は、このドキュメントの公開日におけるこれらの要件に違反しており、その結果としてセキュリティの脆弱性があります。）
Hence, it is possible to have fairly smooth RIPv2 Security Association (i.e., key) rollovers, without losing legitimate RIPv2 messages due to an invalid shared key and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating RIPv2 system must be updated with the new RIPv2 Security Association (including the new key) several minutes before the current RIPv2 Security Association will expire and several minutes before the new RIPv2 Security Association lifetime begins. Also, the new RIPv2 Security Association should have a lifetime that starts several minutes before the old RIPv2 Security Association expires. This gives time for each system to learn of the new security association before that security association will be used. It also ensures that the new security association will begin use and the current security association will go out of use before the current security association's lifetime expires. For the duration of the overlap in security association lifetimes, a system may receive messages corresponding to either security association and successfully authenticate the message. The Key-ID in the received message is used to select the appropriate security association (i.e., key) to be used for authentication.
したがって、無効な共有キーが原因で正当なRIPv2メッセージを失うことなく、またすべてのキーを一度に変更する必要なく、かなりスムーズなRIPv2セキュリティアソシエーション（つまり、キー）のロールオーバーを実現できます。スムーズなロールオーバーを保証するには、現在のRIPv2セキュリティアソシエーションが期限切れになる数分前、および新しいRIPv2セキュリティアソシエーションのライフタイムが始まる数分前に、通信中の各RIPv2システムを新しいRIPv2セキュリティアソシエーション（新しいキーを含む）で更新する必要があります。また、新しいRIPv2セキュリティアソシエーションの有効期間は、古いRIPv2セキュリティアソシエーションが期限切れになる数分前に開始する必要があります。これにより、セキュリティアソシエーションが使用される前に、各システムが新しいセキュリティアソシエーションを学習する時間を確保できます。また、現在のセキュリティアソシエーションの有効期限が切れる前に、新しいセキュリティアソシエーションが使用を開始し、現在のセキュリティアソシエーションが使用されなくなることも保証します。セキュリティアソシエーションのライフタイムが重複している間、システムはいずれかのセキュリティアソシエーションに対応するメッセージを受信し、メッセージを正常に認証できます。受信したメッセージのキーIDを使用して、認証に使用する適切なセキュリティアソシエーション（つまり、キー）を選択します。
For this specification, the term "conformance" has identical meaning to the phrase "full compliance".
この仕様では、「適合」という用語は「完全な適合」という語句と同じ意味を持っています。
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm MUST be implemented by all conforming implementations. In addition, the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384, and SHA-512 have been defined by the US NIST in [FIPS-180-2].
鍵付きMD5認証アルゴリズムとHMAC-SHA1アルゴリズムは、すべての準拠する実装によって実装する必要があります。さらに、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512アルゴリズムを実装する必要があります（SHOULD）。 MD5は[Rivest92]で定義されています。 SHA-1、SHA-256、SHA-384、およびSHA-512は、[FIPS-180-2]でUS NISTによって定義されています。
A conforming implementation MAY also support additional authentication algorithms, provided those additional algorithms are publicly and openly specified.
適合実装は、追加の認証アルゴリズムが公開され、公に指定されている場合に限り、追加の認証アルゴリズムもサポートする場合があります。
Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key rollover described under "Key Management Procedures". This also means that implementations MUST support at least 2 concurrent RIPv2 Security Associations.
上記の手動による鍵配布は、すべての準拠する実装でサポートされている必要があります。すべての実装は、「キー管理手順」で説明されているスムーズなキーのロールオーバーをサポートする必要があります。これは、実装が少なくとも2つの同時RIPv2セキュリティアソシエーションをサポートする必要があることも意味します。
The user documentation provided with the implementation ought to contain clear instructions on how to configure the implementation such that smooth key rollover occurs successfully.
実装とともに提供されるユーザードキュメントには、スムーズなキーのロールオーバーが正常に行われるように実装を構成する方法に関する明確な指示が含まれている必要があります。
Implementations SHOULD support a standard key management protocol for secure distribution of RIPv2 Authentication Keys once such a key management protocol is standardized by the IETF.
実装では、IETFによって標準化されたRIPv2認証キーを安全に配布するために、標準のキー管理プロトコルをサポートする必要があります（SHOULD）。
The Security Considerations section of this document is an integral part of the specification, not just a discussion of the protocol.
このドキュメントのセキュリティに関する考慮事項のセクションは、プロトコルの説明だけでなく、仕様の不可欠な部分です。
This entire memo describes and specifies an authentication mechanism for the RIPv2 routing protocol that is believed to be secure against passive attacks. The term "passive attack" is defined in RFC 1704 [HA94]. The analysis contained in RFC 1704 motivated this work. Passive attacks are clearly widespread in the Internet at present [HA94].
このメモ全体では、パッシブ攻撃に対して安全であると考えられているRIPv2ルーティングプロトコルの認証メカニズムについて説明および指定しています。 「パッシブ攻撃」という用語は、RFC 1704 [HA94]で定義されています。 RFC 1704に含まれる分析がこの作業の動機となりました。パッシブ攻撃は、現在インターネットで明らかに広まっています[HA94]。
Protection against active attacks is incomplete in this current specification. The main issue relative to active attacks lies in the need to support the case where another router has recently rebooted and that router lacks the non-volatile storage needed to remember the RIPv2 Security Association(s) and last received RIPv2 sequence number(s) across that reboot.
この現在の仕様では、アクティブな攻撃に対する保護は不完全です。アクティブな攻撃に関する主な問題は、別のルーターが最近再起動し、そのルーターにRIPv2セキュリティアソシエーションと最後に受信したRIPv2シーケンス番号を記憶するために必要な不揮発性ストレージが不足している場合をサポートする必要性にありますそのリブート。
Two known pathological cases exist that MUST be handled by implementations. Both of these are failures of the network manager. Each of these should be exceedingly rare in normal operation.
実装によって処理しなければならない2つの既知の病理学的ケースが存在します。これらは両方ともネットワークマネージャの障害です。これらのそれぞれは、通常の操作では非常にまれです。
(1) During key rollover, devices might exist that have not yet been successfully configured with the new key. Therefore, routers SHOULD implement an algorithm that detects the set of RIPv2 Security Associations being used by its neighbors, and transmit its messages using both the new and old RIPv2 Security Associations (i.e., keys) until all of the neighbors are using the new security association or the lifetime of the old security association expires. Under normal circumstances, this elevated transmission rate will exist for a single RIP update interval.
（1）キーのロールオーバー中に、まだ新しいキーで正常に構成されていないデバイスが存在する可能性があります。したがって、ルーターは、ネイバーが使用しているRIPv2セキュリティアソシエーションのセットを検出するアルゴリズムを実装し、すべてのネイバーが新しいセキュリティアソシエーションを使用するまで、新旧両方のRIPv2セキュリティアソシエーション（つまり、キー）を使用してメッセージを送信する必要があります（SHOULD）。または、古いセキュリティアソシエーションのライフタイムが期限切れになります。通常の状況では、この高い伝送速度は単一のRIP更新間隔で存在します。
(2) In the event that the last RIPv2 Security Association of an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router MUST send a "last RIPv2 Security Association expiration" notification to the network manager (e.g., via SYSLOG, SNMP, and/or other means) and SHOULD treat that last Security Association as having an infinite lifetime until the lifetime is extended, the Security Association is deleted by network management, or a new security association is configured.
（2）インターフェイスの最後のRIPv2セキュリティアソシエーションが期限切れになった場合、認証されていない状態に戻すことは受け入れられず、ルーティングを中断することはお勧めできません。したがって、ルータは「最後のRIPv2セキュリティアソシエーションの期限切れ」通知をネットワークマネージャに送信する必要があり（たとえば、SYSLOG、SNMP、および/またはその他の手段を介して）、ライフタイムが延長されるまで、その最後のセキュリティアソシエーションが無限のライフタイムを持つものとして扱う必要があります（SHOULD）。 、セキュリティアソシエーションがネットワーク管理によって削除されるか、新しいセキュリティアソシエーションが構成されます。
In some circumstances, the practice described in (2) can leave an opening to an active attack on the RIPv2 routing subsystem. Therefore, any actual occurrence of a RIPv2 Security Association expiration MUST cause a security event to be logged by the implementation. This log item MUST include at least a note that the RIPv2 Authentication Key expired, the RIP routing protocol instance(s) affected, the routing interfaces affected, the Key-ID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice to help detect active attacks on the RIPv2 routing subsystem. Further, implementations SHOULD provide a configuration knob ("fail secure") to let a network operator prefer to have the RIPv2 routing fail when the last key expires, rather than continue using RIPv2 in an insecure manner.
状況によっては、（2）で説明されている方法で、RIPv2ルーティングサブシステムにアクティブな攻撃を与える可能性があります。したがって、RIPv2セキュリティアソシエーションの有効期限が実際に発生すると、実装によってセキュリティイベントがログに記録される必要があります。このログアイテムには、RIPv2認証キーの有効期限が切れたこと、影響を受けたRIPルーティングプロトコルインスタンス、影響を受けたルーティングインターフェイス、影響を受けたキーID、および現在の日付/時刻が少なくとも含まれている必要があります。オペレーターは、RIPv2ルーティングサブシステムに対するアクティブな攻撃を検出するための運用上のセキュリティ対策として、このようなログを確認することをお勧めします。さらに、実装は、安全でない方法でRIPv2を使い続けるのではなく、ネットワークオペレーターが最後のキーの期限が切れたときにRIPv2ルーティングを失敗させることを好むように、構成ノブ（「フェイルセキュア」）を提供する必要があります。
Also, the use of SNMP, even SNMPv3 with cryptographic authentication and cryptographic confidentiality enabled, to modify or configure the RIPv2 Security Associations, or any component of the security association (for example, the cryptographic key), is NOT RECOMMENDED. This practice would create a potential for a cascading vulnerability, whereby a compromise in the SNMP security implementation would necessarily lead to a compromise not only of the local routing table (which could be accessed via SNMP) but also of all other routers that receive RIPv2 packets (directly or indirectly) from the compromised router.
また、RIPv2セキュリティアソシエーションまたはセキュリティアソシエーションの任意のコンポーネント（たとえば、暗号化キー）を変更または構成するためのSNMPの使用（暗号化認証と暗号化機密性が有効になっているSNMPv3であっても）は推奨されません。この慣行は連鎖的な脆弱性の可能性を生み出し、それによってSNMPセキュリティ実装の妥協は必然的にローカルルーティングテーブル（SNMPを介してアクセスできる）だけでなく、RIPv2パケットを受信する他のすべてのルーターの侵害につながります。 （直接的または間接的に）侵害されたルーターから。
Similarly, the use of protocols not designed and evaluated for use in key management (e.g., RADIUS, Diameter) to configure the security association is also NOT RECOMMENDED. Reading the Security Associations via SNMP is allowed, but the information is to be treated as security-sensitive and protected by using the priv mode.
同様に、セキュリティアソシエーションを構成するための鍵管理（RADIUS、Diameterなど）で使用するために設計および評価されていないプロトコルの使用も推奨されません。 SNMP経由でセキュリティアソシエーションを読み取ることは許可されていますが、情報はセキュリティ上重要なものとして扱われ、privモードを使用して保護されます。
Also, the use of SNMP to configure which form of RIPv2 authentication is in use is also NOT RECOMMENDED because of a similar cascading failure issue. Any future revision of the RIPv2 Management Information Base (MIB) [MB94] should consider making the rip2IfConfAuthType object read-only. Further, this object would need a new enum value to accommodate the RIPv2 cryptographic authentication type. In addition, the compliance statement for this MIB does not have a MIN-ACCESS for this object. At a minimum, if the MIB is updated, a new compliance statement SHOULD be written for this object that allows this object to be implemented as read-only. For the rip2ifConfAuthKey object, since this object always returns ''H when read, the object's MIN-ACCESS in any revised compliance statement SHOULD be not-accessible if the MIB is updated.
また、同様のカスケード障害の問題があるため、SNMPを使用してRIPv2認証のどの形式を使用するかを構成することもお勧めしません。 RIPv2管理情報ベース（MIB）[MB94]の将来の改訂では、rip2IfConfAuthTypeオブジェクトを読み取り専用にすることを検討する必要があります。さらに、このオブジェクトには、RIPv2暗号認証タイプに対応するための新しい列挙値が必要です。さらに、このMIBのコンプライアンスステートメントには、このオブジェクトのMIN-ACCESSがありません。少なくとも、MIBが更新された場合、このオブジェクトを読み取り専用として実装できるようにするために、このオブジェクトに対して新しい準拠ステートメントを作成する必要があります（SHOULD）。 rip2ifConfAuthKeyオブジェクトの場合、このオブジェクトは読み取られると常に '' Hを返すため、MIBが更新された場合、改訂された準拠ステートメント内のオブジェクトのMIN-ACCESSにアクセスできません（SHOULD）。
Further, for similar reasons, any future revisions to the RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any objects that would permit the writing of any RIPv2 Security Association or RIPv2 Security Association component (e.g., the cryptographic key).
さらに、同様の理由で、RIPv2管理情報ベース（MIB）の今後の改訂では、RIPv2セキュリティアソシエーションまたはRIPv2セキュリティアソシエーションコンポーネント（暗号化キーなど）の書き込みを許可するオブジェクトを非推奨にするか省略する必要があります（SHOULD）。
Also, it is RECOMMENDED that any future revisions to the RIPv2 Management Information Base (MIB) consider adding MIB objects to hold information about any RIPv2 security events that might have occurred, and MIB objects that could be used to read the set of security events that have been logged by the RIPv2 subsystem. For each security event mentioned in this document, it is also RECOMMENDED that appropriate notifications be included, with a MAX-ACCESS of Accessible-for-notify, in any future versions of the RIPv2 MIB module.
また、RIPv2管理情報ベース（MIB）の今後の改訂では、MIBオブジェクトを追加して、発生した可能性のあるすべてのRIPv2セキュリティイベントに関する情報を保持することを検討することをお勧めします。MIBオブジェクトを使用して一連のセキュリティイベントを読み取ることができます。 RIPv2サブシステムによってログに記録されています。このドキュメントで言及されているセキュリティイベントごとに、RIPv2 MIBモジュールの将来のバージョンでは、適切な通知を、Accessible-for-notifyのMAX-ACCESSとともに含めることをお勧めします。
For the past several years, manual configuration (e.g., via a console) has been commonly used to create and modify RIPv2 Security Associations. There are a number of large-scale RIP deployments today that successfully use manual configuration of RIPv2 Security Associations. There are also sites that use scripts (e.g., combining Tcl/Expect, PERL, and SSHv2) with a site-specific configuration database and secure console connections to dynamically manage all aspects of their router configurations, including their RIPv2 Security Associations. This last approach is similar to the current IETF approach to Network Configuration (NetConf) standards.
過去数年間、RIPv2セキュリティアソシエーションを作成および変更するために、手動による構成（コンソールなどによる）が一般的に使用されてきました。今日、RIPv2セキュリティアソシエーションの手動構成を正常に使用する大規模なRIP展開が数多くあります。スクリプト（Tcl / Expect、PERL、SSHv2の組み合わせなど）とサイト固有の構成データベースおよび安全なコンソール接続を使用して、RIPv2セキュリティアソシエーションを含むルーター構成のすべての側面を動的に管理するサイトもあります。この最後のアプローチは、ネットワーク構成（NetConf）標準に対する現在のIETFアプローチに似ています。
Recent IETF Multicast Security (MSEC) working group efforts into multicast key management appear promising. Several large RIPv2 deployments happen to also have deployed the Kerberos authentication system. Recent IETF work into the use of Kerberos for Internet Key Negotiation (KINK) also seems relevant; one might use Kerberos to support RIPv2 key management functions for use at sites that have already deployed Kerberos. It is hoped that in the future the IETF will standardize a key management protocol suitable for managing RIPv2 Security Associations.
マルチキャストキー管理への最近のIETFマルチキャストセキュリティ（MSEC）ワーキンググループの取り組みは有望であるようです。いくつかの大規模なRIPv2展開では、Kerberos認証システムも展開されています。インターネットキーネゴシエーション（KINK）でのKerberosの使用に関する最近のIETF作業も関連しているようです。 Kerberosを使用して、すでにKerberosを展開しているサイトで使用するためのRIPv2キー管理機能をサポートする場合があります。将来、IETFがRIPv2セキュリティアソシエーションの管理に適したキー管理プロトコルを標準化することが望まれます。
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RIPv2 implementations. This mechanism also depends on the RIPv2 Authentication Key being kept confidential by all parties. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
ユーザーは、このメカニズムによって提供されるセキュリティの品質が、実装されている認証アルゴリズムの強度、使用されているキーの強度、および通信しているすべてのRIPv2実装におけるセキュリティメカニズムの正しい実装に完全に依存することを理解する必要があります。このメカニズムは、RIPv2認証キーがすべての関係者によって機密に保たれていることにも依存します。これらのいずれかが正しくない、または安全性が不十分である場合、このメカニズムのユーザーには実際のセキュリティは提供されません。
Use of high-assurance development methods is RECOMMENDED for implementations of this specification, in order to reduce the risk of subtle implementation flaws that might adversely impact the operational risk reduction that this specification seeks to provide.
この仕様の提供するオペレーショナルリスクの低減に悪影響を与える可能性のある微妙な実装の欠陥のリスクを低減するために、この仕様の実装には高保証の開発方法の使用が推奨されます。
Confidentiality is not provided by this mechanism. It is generally considered that an IP routing protocol does not require confidentiality, as the purpose of any routing protocols is to disseminate information about the topology of the network.
このメカニズムでは機密性は提供されません。ルーティングプロトコルの目的はネットワークのトポロジに関する情報を広めることであるため、IPルーティングプロトコルは機密性を必要としないと一般的に考えられています。
Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption SHOULD be used when protection against traffic analysis is required [CKHD89].
トラフィック分析に対する保護も提供されていません。バルクリンク暗号化などのメカニズムは、トラフィック分析に対する保護が必要な場合に使用する必要があります[CKHD89]。
Separately, the receipt of a RIPv2 packet using cryptographic authentication but containing an invalid or unknown Key-ID value might indicate an active attack on the RIP routing subsystem and is a significant security event. Therefore, any actual receipt of a RIPv2 packet using cryptographic authentication and containing an unknown, expired, or otherwise invalid KEY-ID value SHOULD cause a security event to be logged by the implementation. This log item SHOULD include at least the fact that the invalid KEY-ID was received, the source IP address of the packet containing the invalid KEY-ID, the interface(s) the packet was received on, the KEY-ID received, and the current date/time.
これとは別に、暗号化認証を使用してRIPv2パケットを受信したが、無効または不明なKey-ID値が含まれている場合は、RIPルーティングサブシステムへのアクティブな攻撃を示している可能性があり、重大なセキュリティイベントです。したがって、暗号認証を使用し、不明、期限切れ、または無効なKEY-ID値を含むRIPv2パケットを実際に受信すると、実装によってセキュリティイベントがログに記録される必要があります（SHOULD）。このログ項目には、少なくとも無効なKEY-IDが受信されたという事実、無効なKEY-IDを含むパケットの送信元IPアドレス、パケットが受信されたインターフェイス、受信されたKEY-ID、および現在の日付/時刻。
A subtle user-interface consideration also should be noted. If a user interface only permits the entry of human-readable text (e.g., a password in US-ASCII format) for use as a cryptographic key, significant numbers of bits of the cryptographic key in use become predictable, thereby reducing the strength of the key in this context. For this reason, implementations of this specification SHOULD support the entry of RIPv2 cryptographic authentication keys in hexadecimal format.
また、ユーザーインターフェイスの微妙な考慮事項にも注意してください。ユーザーインターフェイスが人間が読み取れるテキスト（たとえば、US-ASCII形式のパスワード）の入力のみを暗号化キーとして使用できる場合、使用中の暗号化キーのかなりの数のビットが予測可能になり、それにより、このコンテキストのキー。このため、この仕様の実装は、RIPv2暗号認証キーの16進形式のエントリをサポートする必要があります（SHOULD）。
Specification and deployment of a standards-track key management protocol that supports this RIPv2 cryptographic authentication mechanism would be a significant next step in operational risk reduction and might actually increase the ease of deployment and operation of this mechanism. Such specification is beyond the scope of this document. Recent IETF work in MSEC and KINK working groups appears promising in this regard. Recent IETF work in the NETCONF working group towards standardizing methods for secure configuration management of routers is also relevant.
このRIPv2暗号化認証メカニズムをサポートする標準化された鍵管理プロトコルの仕様と展開は、運用上のリスクを軽減するための重要な次のステップであり、このメカニズムの展開と運用の容易さを実際に高める可能性があります。そのような仕様は、このドキュメントの範囲を超えています。 MSECおよびKINKワーキンググループでの最近のIETFの作業は、この点で有望であるようです。ルーターの安全な構成管理のための標準化方法に向けたNETCONFワーキンググループでの最近のIETF作業も関連しています。
Finally, we observe that this mechanism is not the final word on RIPv2 authentication. Rather, it is believed that this particular mechanism represents a significant risk reduction over previous methods (e.g., plaintext passwords), while remaining straightforward to implement correctly and also straightforward to deploy.
最後に、このメカニズムはRIPv2認証の最後の言葉ではないことがわかります。むしろ、この特定のメカニズムは、以前の方法（たとえば、プレーンテキストのパスワード）に比べてリスクを大幅に削減し、正しく実装するのは簡単で、展開も簡単であると考えられています。
User communities that believe this mechanism is not adequate to their needs are encouraged to consider using digital signatures with RIPv2. [MBW97] specifies the use of OSPF with Digital signatures; that document might be a starting point for creating such a specification for the RIPv2 protocol. Digital signatures are significantly more expensive computationally and are also significantly more difficult to deploy operationally, as compared with the mechanism specified here. However, it appears likely that much of the mechanism in this document could be reused with digital signatures.
このメカニズムが彼らのニーズに十分ではないと考えるユーザーコミュニティは、RIPv2でのデジタル署名の使用を検討することをお勧めします。 [MBW97]は、デジタル署名によるOSPFの使用を指定します。そのドキュメントは、RIPv2プロトコルのそのような仕様を作成するための出発点になる可能性があります。デジタル署名は、ここで指定したメカニズムと比較して、計算上非常に高価であり、運用上で展開するのも非常に困難です。ただし、このドキュメントのメカニズムの多くはデジタル署名で再利用できるようです。
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication document [AB97]. This document is a direct derivative of that earlier document, though it has been significantly reworked. The current authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of versions of this document.
Fred Bakerは、以前のRIPv2 MD5認証ドキュメント[AB97]の共著者でした。このドキュメントは以前のドキュメントの直接の派生物ですが、大幅に書き直されています。現在の著者は、この文書のバージョンのレビューについて、（米国）NISTのBill Burr、Tim Polk、John Kelsey、およびMorris Dworkinに感謝します。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[Mal98] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf>.
[FIPS-180-2]米国国立標準技術研究所、「Secure Hash Standard」、FIPS PUB 180-2、2002年8月、<http://csrc.nist.gov/publications/fips/fips180-2/ fips180- 2.pdf>。
[FIPS-198] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002, <http://csrc.nist.gov/publications/ fips/fips198/fips-198a.pdf>.
[FIPS-198]米国国立標準技術研究所、「キー付きハッシュメッセージ認証コード（HMAC）」、FIPS PUB 198、2002年3月、<http://csrc.nist.gov/publications/fips/fips198/fips -198a.pdf>。
[AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[AB97]ベイカー、F。およびR.アトキンソン、「RIP-2 MD5認証」、RFC 2082、1997年1月。
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[Bell89] S. Bellovin、「TCP / IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Volume 19、Number 2、32-48ページ、1989年4月。
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and John R. Davis, "Multilevel Secure Mixed-Media Communication Networks", Proceedings of the IEEE Military Communications Conference (MILCOM '89), IEEE, 1989.
[CKHD89] Cole Jr、Raymond、Donald Kallgren、Richard Hale、およびJohn R. Davis、「Multilevel Secure Mixed-Media Communication Networks」、Proceedings of the IEEE Military Communications Conference（MILCOM '89）、IEEE、1989。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at Rump Session of EuroCrypt 1996.)
[Dobb96a] Dobbertin、H。、「MD5 Compressの暗号解読」、テクニカルレポート、1996年5月2日。（EuroCrypt 1996のランプセッションで発表）
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[Dobb96b] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、CryptoBytes、Vol。 2、2、1996年夏。
[ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ESC05] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94] Haller、N。およびR. Atkinson、「On Internet Authentication」、RFC 1704、1994年10月。
[KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[KMC97] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[Mal94] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[Mal94] Malkin、G。、「RIP Version 2-Carrying Additional Information」、RFC 1723、1994年11月。
[MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, November 1994.
[MB94] Malkin、G。およびF. Baker、「RIPバージョン2 MIB拡張」、RFC 1724、1994年11月。
[MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[MBW97]マーフィー、S。、バジャー、M。、およびB.ウェリントン、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[Rivest92] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
Authors' Addresses
著者のアドレス
R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara、CA 95051 USA
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
M. Fanto (US) National Institute of Standards and Technology Gaithersburg, MD 20878 USA
M.ファント（米国）国立標準技術研究所ゲイザースバーグ、MD 20878米国
Phone: +1 (301) 975-2000
EMail: mattjf@umd.edu
Web: http://csrc.nist.gov
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。