[要約] RFC 6039は、ルーティングプロトコルの既存の暗号化保護手法に関連する問題点を検討し、その目的は、これらの問題を特定し、将来のセキュリティ強化のための基盤を提供することです。この文書は、ルーティングプロトコルのセキュリティを強化するためのガイドラインや推奨事項を提供することを目的としており、ネットワーク管理者やプロトコル開発者にとって有用です。関連するRFCには、ルーティングプロトコルのセキュリティに関連するRFC 4271（BGP-4）、RFC 2328（OSPFv2）などがあります。RFC 6039は、これらのプロトコルのセキュリティ機能を評価し、改善のための洞察を提供します。
Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 6039 IP Infusion
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
J. Jaeggli
Nokia Inc.
R. White
Cisco Systems
October 2010
Issues with Existing Cryptographic Protection Methods for Routing Protocols
ルーティングプロトコルの既存の暗号化保護方法に関する問題
Abstract
概要
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
ルーティングプロトコルは、暗号化メカニズムを使用するように時間をかけて拡張され、隣接ルーターから受信したデータが転送中に変更されず、実際に承認された隣接ルーターから発信されたものであることが保証されます。
The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.
これまでに定義され、このドキュメントで説明されている暗号化メカニズムは、ルーティングプロトコルパケットにカプセル化されたペイロードにハッシュアルゴリズムを適用して生成されたダイジェストに依存しています。
This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations.
このドキュメントでは、現在のメカニズムのいくつかの制限、これらの暗号アルゴリズムの手動キーイングの問題、およびこれらの制限を悪用する可能性のあるベクトルについて概説します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6039.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6039で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Problem Statement ...............................................3
1.1. Pre-Image vs. Collision Attacks ............................4
1.2. Concerns about MD5 and the SHA-1 Algorithm .................4
2. Open Shortest Path First Version 2 (OSPFv2) .....................5
2.1. Management Issues with OSPFv2 ..............................5
2.2. Technical Issues with OSPFv2 ...............................6
3. Open Shortest Path First Version 3 (OSPFv3) .....................7
3.1. Management Issues with OSPFv3 ..............................7
3.2. Technical Issues with OSPFv3 ...............................8
4. Intermediate System to Intermediate System Routing
Protocol (IS-IS) ................................................9
4.1. Management Issues with IS-IS ...............................9
4.2. Technical Issues with IS-IS ...............................10
5. Border Gateway Protocol (BGP-4) ................................11
5.1. Management Issues with BGP-4 ..............................12
5.2. Technical Issues with BGP-4 ...............................13
6. The Routing Information Protocol (RIP) .........................13
6.1. Technical Issues with RIP .................................14
7. Bidirectional Forwarding Detection (BFD) .......................15
7.1. Technical Issues with BFD .................................15
8. Security Considerations ........................................17
9. Acknowledgements ...............................................17
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................18
11. Contributor's Address .........................................21
Protocols, such as OSPF version 2 [RFC2328], version 3 [RFC5340], IS-IS [RFC1195], BGP-4 [RFC4271], and BFD [RFC5880], employ various mechanisms to create a cryptographic digest of each transmitted protocol packet. Traditionally, these digests are the results of a one-way hash algorithm, such as Message Digest 5 (MD5) [RFC1321], across the contents of the packet being transmitted. A secret key is used as the hash base (or seed). The digest is then recomputed by the receiving router, using the same key as the original router used to create the hash, then compared with the transmitted digest to verify:
OSPFバージョン2 [RFC2328]、バージョン3 [RFC5340]、IS-IS [RFC1195]、BGP-4 [RFC4271]、BFD [RFC5880]などのプロトコルは、さまざまなメカニズムを使用して、送信された各プロトコルパケットの暗号化ダイジェストを作成します。従来、これらのダイジェストは、送信されているパケットのコンテンツ全体で、Message Digest 5（MD5）[RFC1321]などの一方向ハッシュアルゴリズムの結果です。秘密鍵がハッシュベース（またはシード）として使用されます。次に、ハッシュを作成するために使用された元のルーターと同じキーを使用して、ダイジェストを受信ルーターが再計算し、送信されたダイジェストと比較して確認します。
o That the router originating this packet is authorized via the shared key mechanism to peer with the local router and exchange routing data. The implicit trust of the routing protocol exchange protected by a shared secret is intended to protect against the injection of falsely generated routing data into the routing system by unauthorized systems.
o このパケットを発信するルーターは、共有キーメカニズムを介してローカルルーターとピアリングしてルーティングデータを交換することを承認されます。共有シークレットで保護されたルーティングプロトコル交換の暗黙的な信頼は、不正に生成されたルーティングデータが不正なシステムによってルーティングシステムに挿入されるのを防ぐことを目的としています。
o That the data has not been altered in transit between the two neighboring routers.
o 2つの隣接ルーター間で転送中にデータが変更されていないこと。
Digest verification schemes are not intended to protect the confidentiality of information being exchanged between routers. The information (entries in the routing table) is potentially available through other mechanisms. Moreover, access to the physical media between two routers exchanging routing data will confer the ability to capture or otherwise discover the contents of the routing tables in those routers.
ダイジェスト検証スキームは、ルーター間で交換される情報の機密性を保護するためのものではありません。情報（ルーティングテーブルのエントリ）は、他のメカニズムを通じて潜在的に利用可能です。さらに、ルーティングデータを交換する2つのルーター間で物理メディアにアクセスすると、これらのルーターのルーティングテーブルの内容をキャプチャしたり、発見したりすることができます。
Authentication mechanisms defined today have notable limitations:
今日定義されている認証メカニズムには、注目すべき制限があります。
o Manual configuration of shared secret keys, especially in large networks and between networks, poses a major management problem. In many cases, it is challenging to replace keys without significant coordination or disruption.
o 特に大規模なネットワークやネットワーク間の共有秘密鍵を手動で構成すると、管理上の大きな問題が発生します。多くの場合、大幅な調整や中断なしにキーを置き換えることは困難です。
o In some cases, when manual keys are configured, some forms of replay protection are no longer possible, allowing the routing protocol to be attacked through the replay of captured routing messages.
o 場合によっては、手動キーが構成されていると、一部の形式の再生保護が不可能になり、キャプチャされたルーティングメッセージの再生を通じてルーティングプロトコルが攻撃される可能性があります。
This document outlines some of the problems with manual keying of these cryptographic algorithms.
このドキュメントでは、これらの暗号化アルゴリズムの手動キーイングに関する問題のいくつかについて概説します。
A pre-image attack (an attempt to find new data with the same hash value) would enable someone to find an input message that causes a hash function to produce a particular output. In contrast, a collision attack finds two messages with the same hash, but the attacker can't pick what the message will be. Feasible collision attacks against MD4, MD5, HAVAL-128, and RIPEMD have been documented in [Crypto2004].
プリイメージ攻撃（同じハッシュ値を持つ新しいデータを見つける試み）は、ハッシュ関数に特定の出力を生成させる入力メッセージを誰かが見つけられるようにします。対照的に、衝突攻撃は同じハッシュを持つ2つのメッセージを見つけますが、攻撃者はメッセージの内容を選択することはできません。 MD4、MD5、HAVAL-128、およびRIPEMDに対する実現可能な衝突攻撃は、[Crypto2004]で文書化されています。
The ability to produce a collision does not currently introduce any obvious or known attacks on routing protocols. Pre-image attacks have the potential to cause problems in the future; however, due to the message length, there are serious limitations to the feasibility of mounting such an attack.
衝突を生成する機能は、現時点ではルーティングプロトコルに明らかな攻撃や既知の攻撃をもたらしません。プリイメージ攻撃は、将来的に問題を引き起こす可能性があります。ただし、メッセージの長さのため、このような攻撃を仕掛ける可能性には重大な制限があります。
Protocols themselves have some built-in protection against collision attacks. This is because a lot of values for fields in a protocol packet are invalid or will produce an unusable packet. For example, in OSPF the Link State Advertisement (LSA) type can be from 1 to 11. Any other value in the field will result in the packet being discarded.
プロトコル自体には、衝突攻撃に対する組み込みの保護機能があります。これは、プロトコルパケットのフィールドの値の多くが無効であるか、使用できないパケットが生成されるためです。たとえば、OSPFでは、リンクステートアドバタイズメント（LSA）のタイプは1〜11です。フィールドに他の値を指定すると、パケットは破棄されます。
Assume two packets M and M' are generated and have the same hash. The above condition will further reduce the ability to produce a message that is also a correct message from the protocol perspective, as a lot of potential values are themselves not valid.
2つのパケットMとM 'が生成され、同じハッシュを持つと仮定します。上記の条件では、多くの潜在的な値自体が無効であるため、プロトコルの観点からも正しいメッセージであるメッセージを生成する能力がさらに低下します。
There are published concerns about the overall strength of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those published concerns apply to the use of MD5 in other modes (e.g., use of MD5 X.509v3/PKIX digital certificates), they are not an attack upon Keyed MD5 and Hash-based Message Authentication Code MD5 (HMAC-MD5), which is what the current routing protocols have specified. There are also published concerns about the Secure Hash Algorithm (SHA) algorithm ([Wang05], [Philip01], [Prav01], [Prav02], [Arjen05]) and also concerns about the MD5 and SHA algorithms in the HMAC [RFC2104] mode ([RR07], [RR08]). The National Institute of Standards and Technology (NIST) will be supporting HMAC-SHA-1 even after 2010 [NISTHmacSHA], whereas it will drop support for SHA-1 in digital signatures. NIST also recommends application and protocol designers move to the SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) for all new applications and protocols.
MD5アルゴリズムの全体的な強さに関する懸念が公開されています（[Dobb96a]、[Dobb96b]、[Wang04]）。これらの公開された懸念は他のモードでのMD5の使用（たとえば、MD5 X.509v3 / PKIXデジタル証明書の使用）に適用されますが、キー付きMD5およびハッシュベースのメッセージ認証コードMD5（HMAC-MD5）に対する攻撃ではありません。これは、現在のルーティングプロトコルで指定されているものです。セキュアハッシュアルゴリズム（SHA）アルゴリズム（[Wang05]、[Philip01]、[Prav01]、[Prav02]、[Arjen05]）に関する懸念も公開されており、HMAC [RFC2104]のMD5およびSHAアルゴリズムに関する懸念もあります。モード（[RR07]、[RR08]）。国立標準技術研究所（NIST）は、2010年以降もHMAC-SHA-1をサポートする予定ですが[NISTHmacSHA]、デジタル署名でのSHA-1のサポートは終了します。 NISTはまた、すべての新しいアプリケーションとプロトコルについて、アプリケーションとプロトコルの設計者がハッシュ関数のSHA-2ファミリー（つまり、SHA-224、SHA-256、SHA-384、SHA-512）に移行することを推奨しています。
However, as explained above, such attacks are currently not applicable to the routing protocols. Separately, some organizations (e.g., the US government) prefer NIST algorithms, such as the SHA family, over other algorithms (like MD5) for local policy reasons.
ただし、上記で説明したように、現在、このような攻撃はルーティングプロトコルには適用されません。これとは別に、一部の組織（米国政府など）は、ローカルポリシーの理由から、他のアルゴリズム（MD5など）よりもSHAファミリなどのNISTアルゴリズムを優先しています。
OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. MD5 keys are manually configured. The OSPF packet header includes an authentication type field as well as 64 bits of data for use by the appropriate authentication scheme. OSPF also provides for a non-decreasing sequence number to be included in each OSPF protocol packet to protect against replay attacks.
OSPF [RFC2328]では、OSPFパケットでのMD5ダイジェストの使用について説明しています。 MD5キーは手動で設定されます。 OSPFパケットヘッダーには、認証タイプフィールドと、適切な認証方式で使用する64ビットのデータが含まれています。 OSPFは、リプレイ攻撃から保護するために、各OSPFプロトコルパケットに含まれる非減少シーケンス番号も提供します。
"OSPF with Digital Signatures" [RFC2154] is an Experimental RFC that describes extensions to OSPF to digitally sign its Link State Advertisements (LSAs). It is believed that if stronger authentication and security is required, then OSPF (and the other routing protocols) must migrate to using full digital signatures. Doing this would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, and thereby provide much stronger integrity protection for the OSPF routing domain. However, since there have been no deployments, there is precious little operational experience with this specification, and hence it is not covered in this document.
「OSPF with Digital Signatures」[RFC2154]は、リンク状態アドバタイズメント（LSA）にデジタル署名するためのOSPFへの拡張を説明する実験的RFCです。より強力な認証とセキュリティが必要な場合、OSPF（およびその他のルーティングプロトコル）は完全なデジタル署名を使用するように移行する必要があると考えられています。これを行うと、各OSPFリンクステートアドバタイズメントを発信するOSPFルーターの正確な認証が可能になり、OSPFルーティングドメインの完全性が大幅に保護されます。ただし、デプロイされていないため、この仕様での運用経験はほとんどないため、このドキュメントでは扱いません。
According to the OSPF specification [RFC2328], digests are applied to packets transmitted between adjacent neighbors, rather than being applied to the routing information originated by a router (digests are not applied at the LSA level, but rather at the packet level). [RFC2328] states that any set of OSPF routers adjacent across a single link may use a different key to build MD5 digests than the key used to build MD5 digests on any other link. Thus, MD5 keys may be configured, and changed, on a per-link basis in an OSPF network.
OSPF仕様[RFC2328]によれば、ダイジェストは、ルーターが発信したルーティング情報に適用されるのではなく、隣接するネイバー間で送信されるパケットに適用されます（ダイジェストはLSAレベルではなくパケットレベルで適用されます）。 [RFC2328]は、単一のリンクを介して隣接するOSPFルーターのセットは、他のリンクでMD5ダイジェストを構築するために使用されるキーとは異なるキーを使用してMD5ダイジェストを構築できると述べています。したがって、OSPFネットワークでは、リンクごとにMD5キーを設定および変更できます。
OSPF does not specify a mechanism to negotiate keys, nor does it specify any mechanism to negotiate the hash algorithms to be used.
OSPFは、キーをネゴシエートするメカニズムを指定せず、使用するハッシュアルゴリズムをネゴシエートするメカニズムも指定しません。
With the proliferation of the number of hash algorithms, as well as the need to continuously upgrade the algorithms, manually configuring the information becomes very tedious. It should also be noted that rekeying OSPF requires coordination among the adjacent routers.
ハッシュアルゴリズムの数が急増し、アルゴリズムを継続的にアップグレードする必要があるため、情報を手動で構成するのは非常に面倒になります。 OSPFのキーを再生成するには、隣接するルーター間の調整が必要であることにも注意してください。
While OSPF provides relatively strong protection through the inclusion of MD5 digests, with additional data and sequence numbers in transmitted packets, there are still attacks against OSPF:
OSPFはMD5ダイジェストを含めることで比較的強力な保護を提供しますが、送信されるパケットに追加のデータとシーケンス番号が含まれますが、OSPFに対する攻撃は依然として存在します。
o The sequence number is initialized to zero when forming an adjacency with a newly discovered neighbor. When an adjacency is brought down, the sequence number is also set to zero. If the cryptographically protected packets of a router that is brought down (for administrative or other reasons) are replayed by a malicious router, traffic could be forced through the malicious router. A malicious router might then induce routing loops, or intercept or blackhole the traffic.
o シーケンス番号は、新しく検出されたネイバーと隣接関係を形成するときにゼロに初期化されます。隣接関係が停止すると、シーケンス番号もゼロに設定されます。 （管理上またはその他の理由で）ダウンしたルーターの暗号で保護されたパケットが悪意のあるルーターによって再生されると、トラフィックは悪意のあるルーターを通過する可能性があります。悪意のあるルーターがルーティングループを引き起こしたり、トラフィックを傍受したりブラックホール化したりする可能性があります。
o OSPF allows multiple packets with the same sequence number. This means that it's possible to replay the same packet many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received. The Hello interval, which is unknown, determines the attack window.
o OSPFは、同じシーケンス番号を持つ複数のパケットを許可します。つまり、次の正当なパケットが送信される前に、同じパケットを何度も再生することが可能です。攻撃者は、次のHelloパケットが送受信されるまで、同じパケットを繰り返し再送信する可能性があります。不明なHello間隔により、攻撃ウィンドウが決まります。
o OSPF does not require the use of any particular hash algorithm; however, only the use of MD5 digests for authentication and replay protection is specified in RFC 2328. Most OSPF implementations only support MD5 in addition to Null and Simple Password authentication.
o OSPFでは、特定のハッシュアルゴリズムを使用する必要はありません。ただし、RFC 2328で指定されているのは、認証とリプレイ保護のためのMD5ダイジェストの使用のみです。ほとんどのOSPF実装では、NullおよびSimple Password認証に加えてMD5のみがサポートされています。
Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of MD5 in routing protocols, it is prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5709] adds support for using SHA-1 and SHA-2 with the HMAC construct for OSPF.
最近、MD5およびSHA-1ハッシュ関数の耐衝突性の制限が発見されました。 [RFC4270]は発見を要約しています。 MD5をハッシュとして使用する攻撃がありました。これらの攻撃はルーティングプロトコルでのMD5の使用には直接適用されませんが、他のオプションを利用できるようにすることは賢明です。このため、これらのアルゴリズムの一般的な使用はお勧めできません。[RFC5709]は、OSPFのHMAC構成でSHA-1およびSHA-2を使用するためのサポートを追加します。
o OSPF on a broadcast network shares the same key between all neighbors on that broadcast network. Some OSPF packets are sent to a multicast address.
o ブロードキャストネットワーク上のOSPFは、そのブロードキャストネットワーク上のすべてのネイバー間で同じキーを共有します。一部のOSPFパケットはマルチキャストアドレスに送信されます。
Spoofing by any malicious neighbor possessing credentials or replayable packets is therefore very easy. Possession of the key itself is used as an identity validation, and no other identity check is used. A malicious neighbor could send a packet, forging the identity of the sender as being from another neighbor. There would be no way in which the victim could distinguish the identity of the packet sender.
したがって、資格情報または再生可能なパケットを所有する悪意のあるネイバーによるなりすましは非常に簡単です。キー自体の所有はID検証として使用され、他のIDチェックは使用されません。悪意のあるネイバーがパケットを送信し、送信者のIDを別のネイバーからのものとして偽造する可能性があります。被害者がパケット送信者の身元を識別できる方法はありません。
o In some OSPF implementations, neighbors on broadcast, non-broadcast multi-access (NBMA), and point-to-multipoint networks are identified by the IP address in the IP header. The IP header is not covered by the MAC in the cryptographic authentication scheme as described in RFC 2328, and an attack can be made to exploit this omission.
o 一部のOSPF実装では、ブロードキャスト、非ブロードキャストマルチアクセス（NBMA）、およびポイントツーマルチポイントネットワークのネイバーは、IPヘッダーのIPアドレスによって識別されます。 RFC 2328で説明されているように、IPヘッダーは暗号化認証スキームのMACによってカバーされていないため、この省略を悪用する攻撃が可能です。
Assume the following scenario.
次のシナリオを想定しています。
R1 sends an authenticated HELLO to R2. This HELLO is captured and replayed back to R1. The source IP in the IP header of the replayed packet is changed to that of R2.
R1は認証されたHELLOをR2に送信します。このハローはキャプチャされ、R1に再生されます。再生されたパケットのIPヘッダーのソースIPがR2のソースIPに変更されます。
R1, not finding itself in the HELLO, would deduce that the connection is not bidirectional and would bring down the adjacency.
R1がHELLOで自分自身を見つけられない場合、接続は双方向ではないと推定し、隣接関係をダウンさせます。
OSPFv3 [RFC5340] relies on the IP Authentication Header (AH) [RFC4302] and the IP Encapsulating Security Payload (ESP) [RFC4303] to cryptographically sign routing information passed between routers.
OSPFv3 [RFC5340]は、IP認証ヘッダー（AH）[RFC4302]およびIPカプセル化セキュリティペイロード（ESP）[RFC4303]を使用して、ルーター間で渡されるルーティング情報に暗号で署名します。
When using ESP, the null encryption algorithm [RFC2410] is used, so the data carried in the OSPFv3 packets is signed, but not encrypted. This provides data origin authentication for adjacent routers, and data integrity (which gives the assurance that the data transmitted by a router has not changed in transit). However, it does not provide confidentiality of the information transmitted; this is acceptable because the privacy of the information being carried in the routing protocols need not be kept secret.
ESPを使用する場合、ヌル暗号化アルゴリズム[RFC2410]が使用されるため、OSPFv3パケットで伝送されるデータは署名されますが、暗号化されません。これにより、隣接ルーターのデータ発信元認証とデータ整合性が提供されます（これにより、ルーターによって送信されたデータが転送中に変更されていないことが保証されます）。ただし、送信される情報の機密性は提供されません。ルーティングプロトコルで運ばれる情報のプライバシーを秘密にする必要がないため、これは許容されます。
"Authentication/Confidentiality for OSPFv3" [RFC4552] mandates the use of ESP with null encryption for authentication and also does encourage the use of confidentiality to protect the privacy of the routing information transmitted, using ESP encryption. However, it only specifies the use of manual keying of routing information as discussed in the following section.
「OSPFv3の認証/機密性」[RFC4552]では、認証にnull暗号化を使用したESPの使用が義務付けられており、ESP暗号化を使用して送信されるルーティング情報のプライバシーを保護するために機密性を使用することも推奨されています。ただし、次のセクションで説明するように、ルーティング情報の手動キーイングの使用を指定するだけです。
The OSPFv3 security document ("Authentication/Confidentiality for OSPFv3" [RFC4552]) discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as IKEv2 [RFC4306]. The primary problem is the lack of a suitable key management mechanism, as OSPF adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the system administrator to use manually configured security associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services.
OSPFv3セキュリティドキュメント（ "OSPFv3の認証/機密性" [RFC4552]）は、IKEv2 [RFC4306]などの一部の自動キー管理プロトコルではなく、手動で構成されたキーを使用する背後にある理由について詳細に説明しています。 OSPF隣接関係は1対多で形成され、ほとんどのキー管理メカニズムは1対1の通信モデル向けに設計されているため、主な問題は適切なキー管理メカニズムの欠如です。これにより、システム管理者は手動で構成されたセキュリティアソシエーション（SA）と暗号化キーを使用して、認証と、必要に応じて機密サービスを提供する必要があります。
Regarding replay protection, [RFC4552] states that:
再生保護に関して、[RFC4552]は次のように述べています：
Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.
現在の標準を使用して手動キーイングを使用しながら完全な再生保護を提供することは不可能であるため、提案されたソリューションは再生攻撃に対する保護を提供しません。
In the OSPFv3 case, the primary administrative issue with manually configured SAs and keys is the management issue -- maintaining shared sets of keys on all routers within a network. As with OSPFv2, rekeying is an infrequent event requiring coordination. [RFC4552] does not require that all OSPFv3 routers have the same key configured for every neighbor, so each set of neighbors connected to a given link could have a different key configured. While this makes it easier to change the keys (by forcing the system administrator to only change the keys on the routers on a single link), the process of manual configuration for all the routers in a network to change the keys used for OSPFv3 digests and confidentiality on a periodic basis can be difficult.
OSPFv3の場合、手動で設定されたSAとキーの主な管理上の問題は管理上の問題であり、ネットワーク内のすべてのルーターでキーの共有セットを維持します。 OSPFv2と同様に、再キーイングは、調整を必要とするまれなイベントです。 [RFC4552]では、すべてのOSPFv3ルーターがすべてのネイバーに同じキーを設定する必要がないため、特定のリンクに接続されたネイバーの各セットに異なるキーを設定できます。これにより、キーの変更が容易になりますが（システム管理者に単一リンク上のルーターのキーのみを変更させる）、ネットワーク内のすべてのルーターを手動で構成して、OSPFv3ダイジェストと定期的な機密保持は困難な場合があります。
The primary technical concern with the current specifications for OSPFv3 is that when manual SA and key management is used as specified in "Sequence Number Generation", Section 3.3.2 of [RFC4302]: "The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management". Replaying OSPFv3 packets can induce several failures in a network, including:
OSPFv3の現在の仕様に関する主な技術的懸念は、[シーケンス番号の生成]の[RFC4302]のセクション3.3.2で指定されているように手動のSAおよびキー管理が使用される場合、「送信者はアンチリプレイがデフォルトで有効になっていると想定していることです。 、受信者から通知されない限り（セクション3.4.3を参照）、SAが手動の鍵管理を使用して構成されている場合を除きます。 OSPFv3パケットを再生すると、ネットワークに次のようないくつかの障害が発生する可能性があります。
o Replaying Hello packets with an empty neighbor list can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
o 空のネイバーリストを使用してHelloパケットを再生すると、送信ルータとのすべてのネイバー隣接関係がリセットされ、ネットワーク通信が中断する可能性があります。
o Replaying Hello packets from early in the designated router election process on broadcast links can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
o ブロードキャストリンクで指定ルーター選定プロセスの早い段階からHelloパケットを再生すると、送信ルーターとのすべての隣接関係がリセットされ、ネットワーク通信が中断される可能性があります。
o Replaying database description (DB-Description) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
o データベース記述（DB-Description）パケットを再生すると、送信側ルーターとの完全な隣接関係がすべてリセットされ、ネットワーク通信が中断される可能性があります。
o Replaying link state request (LS-Request) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
o リンク状態要求（LS-Request）パケットを再生すると、送信側ルーターとの完全な隣接関係がすべてリセットされ、ネットワーク通信が中断される可能性があります。
o Capturing a full adjacency process (from two-way all the way to FULL state), and then replaying this process when the router is no longer attached can cause a false adjacency to be formed, allowing an attacker to attract traffic.
o 完全な隣接プロセス（双方向から完全状態まで）をキャプチャし、ルーターが接続されていないときにこのプロセスを再生すると、偽の隣接関係が形成され、攻撃者がトラフィックを引き寄せることができます。
o OSPFv3 on a broadcast network shares the same key between all neighbors on that network. Some OSPF packets are sent to a multicast address.
o ブロードキャストネットワーク上のOSPFv3は、そのネットワーク上のすべてのネイバー間で同じキーを共有します。一部のOSPFパケットはマルチキャストアドレスに送信されます。
Spoofing by a malicious neighbor is very easy. Possession of the key itself is used as an identity check. There is no other identity check used. A neighbor could send a packet specifying the packet came from some other neighbor and there would be no way in which the attacked router could figure out the identity of the packet sender.
悪意のある隣人によるなりすましは非常に簡単です。キー自体の所有は、アイデンティティチェックとして使用されます。他に使用されるIDチェックはありません。ネイバーは、他のネイバーから送信されたパケットを指定してパケットを送信でき、攻撃されたルーターがパケット送信者のIDを把握する方法はありません。
Integrated IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as described in [RFC5304], and has recently been extended to provide support for using the HMAC construct along with the SHA family of cryptographic hash functions [RFC5310]. There is no provision within IS-IS to encrypt the body of a routing protocol message.
統合IS-IS [RFC1195]は、[RFC5304]で説明されているように、手動キーイングでHMAC-MD5認証を使用し、最近、暗号化ハッシュ関数のSHAファミリ[RFC5310]とともにHMACコンストラクトを使用するためのサポートを提供するように拡張されました。 IS-IS内には、ルーティングプロトコルメッセージの本文を暗号化する機能はありません。
[RFC5304] states that each Link State Protocol Data Unit (LSP) generated by an intermediate system is signed with the HMAC-MD5 algorithm using a key manually defined by the network administrator. Since authentication is performed on the LSPs transmitted by an intermediate system, rather than on the packets transmitted to a specific neighbor, it is implied that all the intermediate systems within a single flooding domain must be configured with the same key in order for authentication to work correctly.
[RFC5304]は、中間システムによって生成された各リンク状態プロトコルデータユニット（LSP）が、ネットワーク管理者が手動で定義したキーを使用してHMAC-MD5アルゴリズムで署名されていると述べています。認証は特定のネイバーに送信されるパケットではなく、中間システムによって送信されるLSPで実行されるため、認証が機能するためには、単一のフラッディングドメイン内のすべての中間システムに同じキーを設定する必要があることを意味します正しく。
The initial configuration of manual keys for authentication within an IS-IS network is simplified by a state where LSPs containing HMAC-MD5/HMAC-SHA authentication TLVs are accepted by intermediate systems without the keys, but the digest is not validated. Once keys are configured on all routers, changing those keys becomes much more difficult.
IS-ISネットワーク内での認証用の手動キーの初期構成は、HMAC-MD5 / HMAC-SHA認証TLVを含むLSPがキーのない中間システムによって受け入れられるが、ダイジェストは検証されない状態によって簡略化されます。すべてのルーターでキーを構成すると、それらのキーを変更するのがはるかに困難になります。
IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor does it specify any mechanism to negotiate the hash algorithms to be used.
IS-IS [RFC1195]は、キーをネゴシエートするメカニズムを指定しておらず、使用するハッシュアルゴリズムをネゴシエートするメカニズムも指定していません。
With the proliferation of available hash algorithms, as well as the need to upgrade the algorithms, manual configuration requires coordination among intermediate systems, which can become tedious.
利用可能なハッシュアルゴリズムが急増し、アルゴリズムをアップグレードする必要があるため、手動構成では中間システム間の調整が必要になり、面倒な作業になる可能性があります。
[RFC5304] states: "This mechanism does not prevent replay attacks; however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information".
[RFC5304]は次のように述べています。「このメカニズムはリプレイ攻撃を防ぎません。しかし、ほとんどの場合、そのような攻撃はIS-ISプロトコルの既存のメカニズムをトリガーし、古い情報を効果的に拒否します。
The few cases where existing mechanisms in the IS-IS protocol would not effectively reject old information are: - the Hello packets or the IS-IS Hellos (IIHs) that are used to discover neighbors, and - the Sequence Number Packets (SNPs).
IS-ISプロトコルの既存のメカニズムが古い情報を効果的に拒否しないいくつかのケースは、次のとおりです。-Helloパケットまたはネイバーの検出に使用されるIS-IS Hello（IIH）、および-シーケンス番号パケット（SNP）。
As described in IS-IS [RFC1195], a list of known neighbors is included in each Hello transmitted by an intermediate system to ensure two-way communications with any specific neighbor before exchanging link state databases.
IS-IS [RFC1195]で説明されているように、リンク状態データベースを交換する前に特定のネイバーとの双方向通信を確保するために、中間システムによって送信される各Helloに既知のネイバーのリストが含まれています。
IS-IS does not provide a sequence number. IS-IS packets are vulnerable to replay attacks; any packet can be replayed at any point of time. So long as the keys used are the same, protocol elements that would not be rejected will affect existing sessions.
IS-ISはシーケンス番号を提供しません。 IS-ISパケットは、リプレイ攻撃に対して脆弱です。どのパケットもいつでも再生できます。使用されるキーが同じである限り、拒否されないプロトコル要素は既存のセッションに影響します。
A Hello packet containing a digest within a TLV and an empty neighbor list could be replayed, resulting in all adjacencies with the original transmitting intermediate system to be restarted.
TLV内のダイジェストと空のネイバーリストを含むHelloパケットが再生され、元の送信中間システムとのすべての隣接関係が再開される可能性があります。
A replay of an old Complete Sequence Number Packet (CSNP) could cause LSPs to be flooded, resulting in an LSP storm.
古い完全シーケンス番号パケット（CSNP）を再生すると、LSPがフラッディングされ、LSPストームが発生する可能性があります。
IS-IS specifies the use of the HMAC-MD5 and HMAC-SHA-1 to protect IS-IS packets.
IS-ISは、IS-ISパケットを保護するためのHMAC-MD5およびHMAC-SHA-1の使用を指定します。
IS-IS does not have a notion of Key ID. During key rollover, each message received has to be checked for integrity against all keys that are valid. A denial-of-service (DoS) attack may be induced by sending IS-IS packets with random hashes. This will cause the IS-IS packet to be checked for authentication with all possible keys, increasing the amount of processing required. This issue, however, has been fixed in the recent [RFC5310], which introduces the concept of Key IDs in IS-IS.
IS-ISにはキーIDの概念はありません。キーのロールオーバー中に、受信した各メッセージは、有効なすべてのキーに対する整合性をチェックする必要があります。ランダムハッシュを含むIS-ISパケットを送信することにより、サービス拒否（DoS）攻撃が引き起こされる可能性があります。これにより、IS-ISパケットの認証がすべての可能なキーでチェックされ、必要な処理量が増加します。ただし、この問題は最近の[RFC5310]で修正され、IS-ISのキーIDの概念が導入されています。
Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of HMAC-MD5 in IS-IS, it is prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5310] adds support for using HMAC-SHA with IS-IS.
最近、MD5およびSHA-1ハッシュ関数の耐衝突性の制限が発見されました。 [RFC4270]は発見を要約しています。 MD5をハッシュとして使用する攻撃がありました。これらの攻撃はIS-ISでのHMAC-MD5の使用には直接適用されませんが、他のオプションを利用できるようにすることは賢明です。このため、これらのアルゴリズムの一般的な使用はお勧めできません。[RFC5310]では、IS-ISでHMAC-SHAを使用するためのサポートが追加されています。
IS-IS on a broadcast network shares the same key between all neighbors on that network.
ブロードキャストネットワーク上のIS-ISは、そのネットワーク上のすべてのネイバー間で同じキーを共有します。
This makes spoofing by a malicious neighbor easy since IS-IS packets are sent to a link-layer multicast address. Possession of the key itself is used as an authorization check. A neighbor could send a packet spoofing the identity of a neighbor, and there would be no way in which the attacked router could discern the identity of the malicious packet sender.
IS-ISパケットがリンク層マルチキャストアドレスに送信されるため、悪意のあるネイバーによるなりすましが容易になります。キー自体の所有は、承認チェックとして使用されます。ネイバーはネイバーのIDを偽装してパケットを送信する可能性があり、攻撃されたルータが悪意のあるパケット送信者のIDを識別できる方法はありません。
The Remaining Lifetime field in the LSP is not covered by the authentication. An IS-IS router can receive its own self-generated LSP segment with zero lifetime remaining. In that case, if it has a copy with non-zero lifetime, it purges that LSP, i.e., it increments the current sequence number and floods all the segments again. This is much worse in IS-IS than in OSPF because there is only one LSP other than the pseudonode LSPs for the LANs on which the IS-IS router is the Designated Intermediate System (DIS).
LSPのRemaining Lifetimeフィールドは認証の対象外です。 IS-ISルーターは、独自の自己生成LSPセグメントを受信でき、残りのライフタイムはゼロです。その場合、ゼロ以外の有効期間のコピーがある場合、そのLSPは消去されます。つまり、現在のシーケンス番号が増分され、すべてのセグメントが再びフラッディングされます。 IS-ISルーターが指定中間システム（DIS）であるLANの疑似ノードLSP以外にLSPが1つしかないため、これはOSPFよりIS-ISの方がはるかに悪いです。
In this way, an attacker can force the router to flood all segments -- potentially a large number if the number of routes is large. It also causes the sequence number of all the LSPs to increase fast. If the sequence number increases to the maximum (0xFFFFFFFF), the IS-IS process must shut down for around 20 minutes (the product of MaxAge + ZeroAgeLifetime) to allow the old LSPs to age out of all the router databases.
このようにして、攻撃者はルーターにすべてのセグメントを強制的にフラッディングさせることができます。ルートの数が多い場合、潜在的に大きな数になります。また、すべてのLSPのシーケンス番号が急速に増加します。シーケンス番号が最大値（0xFFFFFFFF）に増加した場合、古いLSPがすべてのルーターデータベースからエージングアウトできるように、IS-ISプロセスは約20分間（MaxAge + ZeroAgeLifetimeの積）シャットダウンする必要があります。
BGP-4 [RFC4271] uses TCP [RFC0793] for transporting routing information between BGP speakers that have formed an adjacency.
BGP-4 [RFC4271]はTCP [RFC0793]を使用して、隣接関係を形成したBGPスピーカー間でルーティング情報を転送します。
[RFC2385] describes the use of the TCP MD5 digest option for providing packet origin authentication and data integrity protection of BGP packets. [RFC3562] provides suggestions for choosing the key length of the ad hoc Keyed MD5 mechanism specified in [RFC2385]. There is no provision for confidentiality for any of these BGP messages.
[RFC2385]は、パケットの起点認証とBGPパケットのデータ整合性保護を提供するためのTCP MD5ダイジェストオプションの使用について説明しています。 [RFC3562]は、[RFC2385]で指定されているアドホックキー付きMD5メカニズムのキー長を選択するための提案を提供します。これらのBGPメッセージの機密性については規定されていません。
TCP MD5 [RFC2385] has recently been obsoleted by a new TCP Authentication Option (TCP-AO) [RFC5925]. [RFC5925] specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details than TCP-MD5 on the association of security with TCP connections. It allows rekeying during a TCP connection, assuming that an out-of-band protocol or manual mechanism provides the new keys. Note that TCP MD5 does not preclude rekeying during a connection, but does not require its support either. Further, TCP-AO supports key changes with zero segment loss, whereas key changes in TCP MD5 can lose segments in transit during the changeover or require trying multiple keys on each received segment during key use overlap because TCP MD5 lacks an explicit Key ID. Although TCP recovers lost segments through retransmission, loss can have a substantial impact on performance.
TCP MD5 [RFC2385]は最近、新しいTCP認証オプション（TCP-AO）[RFC5925]によって廃止されました。 [RFC5925]は、より強力なメッセージ認証コード（MAC）の使用を指定し、存続期間の長いTCP接続でもリプレイから保護し、TCP接続とのセキュリティの関連付けでTCP-MD5よりも詳細を提供します。帯域外プロトコルまたは手動メカニズムが新しいキーを提供すると想定すると、TCP接続中にキーの再生成が可能になります。 TCP MD5は接続中の再キーイングを排除しないが、そのサポートを必要としないことに注意してください。さらに、TCP-AOはセグメント損失ゼロのキー変更をサポートしていますが、TCP MD5でのキー変更は、切り替え中に転送中にセグメントを失うか、TCP MD5には明示的なキーIDがないため、キー使用の重複中に受信した各セグメントで複数のキーを試す必要があります。 TCPは再送信によって失われたセグメントを回復しますが、損失はパフォーマンスに大きな影響を与える可能性があります。
However, this document covers only TCP MD5, as all current deployments are still using BGP with TCP MD5 and have not upgraded to [RFC5925]. There isn't enough operational experience present to evaluate the technical and management issues with this proposal yet.
ただし、このドキュメントではTCP MD5のみを扱います。現在のすべての展開では、まだTCP MD5でBGPを使用しており、[RFC5925]にアップグレードされていないためです。この提案の技術的および管理上の問題を評価するのに十分な運用経験がまだありません。
Compared to previously described IGP protocols, BGP has additional exposure due to the nature of the environment where it is typically used -- namely, between autonomous networks (under different administrative control). While routers running interior gateway protocols may all be configured with the same administrative authority, two BGP peers may be in different administrative domains, having different policies for key strength, rollover frequency, etc. An autonomous system must often support a large number of keys at different BGP boundaries, as each connecting AS represents a different administrative entity. In practice, once set, shared secrets between BGP peers are rarely, if ever, changed.
前述のIGPプロトコルと比較して、BGPは、通常使用される環境の性質、つまり自律ネットワーク間（異なる管理制御下）により、さらされています。内部ゲートウェイプロトコルを実行しているルーターはすべて同じ管理権限で構成されている場合がありますが、2つのBGPピアが異なる管理ドメインにあり、キー強度、ロールオーバー頻度などのポリシーが異なる場合があります。自律システムは、多くの場合、多数のキーをサポートする必要があります。接続する各ASが異なる管理エンティティを表すため、異なるBGP境界。実際には、一度設定すると、BGPピア間の共有シークレットが変更されることはほとんどありません。
Each pair of BGP speakers forming a peering may have a different MD5 shared key that facilitates the independent configuration and changing of keys across a large-scale network. Manual configuration and maintenance of cryptographic keys across all BGP sessions is a challenge in any large-scale environment.
ピアリングを形成するBGPスピーカーの各ペアは、大規模ネットワーク全体での独立した構成とキーの変更を容易にする、異なるMD5共有キーを持っている場合があります。すべてのBGPセッションで暗号鍵を手動で構成および保守することは、大規模環境では困難です。
Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup, in order to allow for MD5 keys to be changed with minimal impact on operation of the network. This technique does, however, allow some short period of time during which an attacker may inject BGP packets with false MD5 digests into the network and can expect those packets to be accepted, even though the MD5 digests are not valid.
ほとんどのBGP実装は、ピアリングの起動時にBGPピア間でネゴシエートされたホールドインターバルまで不良ダイジェストのBGPパケットを受け入れます。これにより、ネットワークの動作への影響を最小限に抑えてMD5キーを変更できるようになります。ただし、この手法では、MD5ダイジェストが有効ではない場合でも、攻撃者が誤ったMD5ダイジェストを含むBGPパケットをネットワークに挿入し、それらのパケットが受け入れられることを期待できる短い期間を許可します。
BGP relies on TCP [RFC0793] for transporting data between BGP speakers. BGP can rely on TCP's protection against data corruption and replay to preclude replay attacks against BGP sessions. A great deal of research has gone into the feasibility of an attacker overcoming these protections, including [TcpWindow] and [Conv01]. Most router and operating system (OS) vendors have modified their TCP implementations to resolve the security vulnerabilities described in these references, where possible.
BGPはBGPスピーカー間でデータを転送するためにTCP [RFC0793]に依存しています。 BGPは、データの破損とリプレイに対するTCPの保護に依存して、BGPセッションに対するリプレイ攻撃を防止できます。 [TcpWindow]や[Conv01]など、これらの保護を克服する攻撃者の実現可能性については、多くの調査が行われています。ほとんどのルーターおよびオペレーティングシステム（OS）ベンダーは、可能な場合、これらのリファレンスで説明されているセキュリティの脆弱性を解決するために、TCP実装を変更しました。
As mentioned earlier, MD5 is vulnerable to collision attacks and can be attacked through several means, such as those explored in [Wang04].
先に述べたように、MD5は衝突攻撃に対して脆弱であり、[Wang04]で探索されたようないくつかの手段を通じて攻撃される可能性があります。
Though it can be argued that the collision attacks do not have a practical application in this scenario, the use of MD5 should be discouraged.
このシナリオでは衝突攻撃は実用的ではないと主張できますが、MD5の使用はお勧めできません。
Routers performing cryptographic processing of packets in software may be exposed to additional opportunities for DoS attacks. An attacker may be able to transmit enough spoofed traffic with false digests that the router's processor and memory resources are consumed, causing the router to be unable to perform normal processing. This exposure is particularly problematic between routers not under unified administrative control.
ソフトウェアでパケットの暗号処理を実行するルーターは、DoS攻撃の追加の機会にさらされる可能性があります。攻撃者は、偽のダイジェストを使用して十分なスプーフィングされたトラフィックを送信できるため、ルーターのプロセッサとメモリリソースが消費され、ルーターが通常の処理を実行できない可能性があります。この露出は、統一された管理制御下にないルーター間で特に問題になります。
The initial version of RIP was specified in STD 34 [RFC1058]. This version did not provide for any authentication or authorization of routing data, and thus was vulnerable to any of a number of attacks against routing protocols. This limitation was one reason why this protocol was moved to Historic status [RFC1923].
RIPの初期バージョンはSTD 34 [RFC1058]で指定されました。このバージョンは、ルーティングデータの認証や承認を提供していなかったため、ルーティングプロトコルに対する数多くの攻撃に対して脆弱でした。この制限が、このプロトコルが歴史的ステータス[RFC1923]に移行した理由の1つでした。
RIPv2, originally specified in [RFC1388], then [RFC1723], was finalized in STD 56 [RFC2453]. This version of the protocol provides for authenticating packets with a digest. The details thereof have initially been provided in "RIP-2 MD5 Authentication" [RFC2082]; "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] and adds details of how the SHA family of hash algorithms can be used to protect RIPv2. [RFC2082] only specified the use of Keyed MD5.
元々[RFC1388]、次に[RFC1723]で指定されたRIPv2は、STD 56 [RFC2453]で確定されました。このバージョンのプロトコルでは、ダイジェストを使用してパケットを認証します。その詳細は、当初「RIP-2 MD5認証」[RFC2082]で提供されていました。 「RIPv2 Cryptographic Authentication」[RFC4822]は廃止され[RFC2082]、ハッシュアルゴリズムのSHAファミリを使用してRIPv2を保護する方法の詳細が追加されています。 [RFC2082]は、キー付きMD5の使用のみを指定しました。
o The sequence number used by a router is initialized to zero at startup, and is also set to zero whenever the neighbor is brought down. If the cryptographically protected packets of a router that is brought down (for administrative or other reasons) are stored by a malicious router, the new router could replay the packets from the previous session, thus forcing traffic through the malicious router. Dropping of such packets by the router could result in blackholes. Also, forwarding wrong packets could result in routing loops.
o ルーターが使用するシーケンス番号は、起動時にゼロに初期化され、ネイバーがダウンしたときにもゼロに設定されます。 （管理上またはその他の理由で）ダウンしたルーターの暗号で保護されたパケットが悪意のあるルーターによって保存された場合、新しいルーターは以前のセッションからのパケットを再生し、悪意のあるルーターを介してトラフィックを強制する可能性があります。ルーターがこのようなパケットをドロップすると、ブラックホールが発生する可能性があります。また、間違ったパケットを転送すると、ルーティングループが発生する可能性があります。
o RIPv2 allows multiple packets with the same sequence number. This could mean the same packet may be replayed many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received, which means the Hello interval therefore determines the attack window.
o RIPv2は、同じシーケンス番号を持つ複数のパケットを許可します。これは、次の正当なパケットが送信される前に、同じパケットが何度も再生される可能性があることを意味します。攻撃者は、次のHelloパケットが送受信されるまで同じパケットを繰り返し再送信する可能性があります。つまり、Hello間隔が攻撃ウィンドウを決定します。
o RIPv2 [RFC2453] did not specify the use of any particular hash algorithm. RFC 4822 introduced HMAC-SHA1 as mandatory to implement, along with Keyed MD5 as specified in [RFC2082]. Support for Keyed MD5 was mandated to ensure compatability with legacy implementations.
o RIPv2 [RFC2453]は、特定のハッシュアルゴリズムの使用を指定していません。 RFC 4822は、[RFC2082]で指定されているキー付きMD5とともに、実装が必須のHMAC-SHA1を導入しました。 Keyed MD5のサポートは、レガシー実装との互換性を確保するために必須でした。
o "RIPv2 Cryptographic Authentication" [RFC4822] does not cover the UDP and the IP headers. It is therefore possible for an attacker to modify some fields in the above headers without routers becoming aware of it.
o 「RIPv2暗号化認証」[RFC4822]は、UDPおよびIPヘッダーをカバーしていません。したがって、攻撃者がルーターに気付かれずに上記のヘッダーの一部のフィールドを変更する可能性があります。
There is limited exposure to modification of the UDP header, as the RIP protocol uses only it to compute the length of the RIP packet. Changes introduced in the UDP header would cause RIP authentication to fail the RIP authentication, thereby limiting exposure.
RIPプロトコルはRIPパケットの長さを計算するためにそれだけを使用するため、UDPヘッダーの変更への露出は限られています。 UDPヘッダーに変更が加えられると、RIP認証がRIP認証に失敗し、それによって公開が制限されます。
RIP uses the source IP address from the IP header to determine which RIP neighbor it has learnt the RIP Update from. Changing the source IP address can be used by an attacker to disrupt the RIP routing sessions between two routers R1 and R2, as shown in the following examples.
RIPはIPヘッダーのソースIPアドレスを使用して、RIP更新を学習したRIPネイバーを判別します。次の例に示すように、攻撃者は送信元IPアドレスの変更を使用して、2つのルーターR1とR2間のRIPルーティングセッションを中断することができます。
Scenario 1:
シナリオ1：
R1 sends an authenticated RIP message to R2 with a cryptographic sequence number X.
R1は、認証されたRIPメッセージを暗号シーケンス番号XとともにR2に送信します。
The attacker then needs a packet with a higher sequence number originated by R2 either, from this session or from some earlier session.
次に、攻撃者は、このセッションまたは以前のセッションからR2によって発信された、より高いシーケンス番号のパケットを必要とします。
The attacker can then replay this packet to R2 by changing the source IP to that of R1.
攻撃者は、送信元IPをR1のIPに変更することにより、このパケットをR2に再生できます。
R2 would then no longer accept any more RIP Updates from R1, as those would have a lower cryptographic sequence number. After 180 seconds (or less), R2 would consider R1 timed out and bring down the RIP session.
その後、R2はR1からのRIP更新を受け入れなくなります。RIP更新は暗号シーケンス番号が低いためです。 180秒（またはそれ以下）が経過すると、R2はR1がタイムアウトしたと見なし、RIPセッションを停止します。
Scenario 2:
シナリオ2：
R1 announces a route with cost C1 to R2. This packet can be captured by an attacker. Later, if this cost changes and R1 announces this with a different cost C2, the attacker can replay the captured packet, modifying the source IP to a new arbitrary IP address, thereby masquerading as a different router.
R1は、コストがC1のルートをR2にアナウンスします。このパケットは、攻撃者によってキャプチャされる可能性があります。その後、このコストが変化し、R1が異なるコストC2でこれをアナウンスした場合、攻撃者はキャプチャされたパケットを再生し、送信元IPを新しい任意のIPアドレスに変更して、別のルーターになりすますことができます。
R2 will accept this route and the router as a new gateway, and R2 would then use the non-existent router as a next hop for that network. This would only be effective if the cost C1 is less than C2.
R2はこのルートとルーターを新しいゲートウェイとして受け入れ、存在しないルーターをそのネットワークのネクストホップとして使用します。これは、コストC1がC2より小さい場合にのみ有効です。
BFD is specified in [RFC5880]. Extensions to BFD for multihop [RFC5883] and single hop [RFC5881] are defined for IPv4 and IPv6. It is designed to detect failure with the forwarding plane next hop.
BFDは[RFC5880]で指定されています。マルチホップ[RFC5883]およびシングルホップ[RFC5881]のBFDへの拡張は、IPv4およびIPv6で定義されています。フォワーディングプレーンのネクストホップで障害を検出するように設計されています。
The BFD base specification specifies an optional authentication mechanism that can be used by the receiver of a packet to be able to authenticate the source of the packet. It relies on the facts that the keys are shared between the peers and no mechanism is defined for the actual key generation.
BFD基本仕様は、パケットの送信元を認証できるようにするために、パケットの受信者が使用できるオプションの認証メカニズムを指定します。これは、キーがピア間で共有され、実際のキー生成用のメカニズムが定義されていないという事実に依存しています。
o The level of security provided is based on the Authentication Type used. However, the authentication algorithms defined are MD5 or SHA-1 based. As mentioned earlier, MD5 and SHA-1 are both known to be vulnerable to collision attacks.
o 提供されるセキュリティのレベルは、使用される認証タイプに基づいています。ただし、定義されている認証アルゴリズムはMD5またはSHA-1ベースです。前述のように、MD5とSHA-1はどちらも衝突攻撃に対して脆弱であることがわかっています。
o The BFD specification mentions mechanisms to allow for the change of authentication state based on the state of a received packet. This can cause a denial-of-service attack where a malicious authenticated packet (stored from a past session) can be relayed over a session that does not use authentication. This causes one end to assume that authentication is enabled at the other end, and hence the BFD adjacency is dropped. This would be a harder attack to put forth when meticulously keyed authentication is in use.
o BFD仕様には、受信したパケットの状態に基づいて認証状態を変更できるメカニズムが記載されています。これにより、サービス拒否攻撃が発生し、悪意のある認証済みパケット（過去のセッションから保存されたもの）が、認証を使用しないセッションを介して中継される可能性があります。これにより、一方の端でもう一方の端で認証が有効になっていると想定され、BFD隣接がドロップされます。これは、細心の注意を払って認証を使用している場合、より困難な攻撃になります。
o BFD works on microsecond timers. When malicious packets are sent at short intervals, with the authentication bit set, it can cause a DoS attack.
o BFDはマイクロ秒タイマーで動作します。悪意のあるパケットが短い間隔で送信され、認証ビットが設定されている場合、DoS攻撃を引き起こす可能性があります。
o BFD allows a mode called the echo mode. Echo packets are not defined in the BFD specification, though they can keep the BFD session up. There are no guidelines on the properties of the echo packets beyond the choice of the source and destination addresses. While the BFD specification recommends applying security mechanisms to prevent spoofing of these packets, there are no guidelines on what type of mechanisms are appropriate.
o BFDでは、エコーモードと呼ばれるモードを使用できます。エコーパケットはBFD仕様で定義されていませんが、BFDセッションを維持できます。送信元アドレスと宛先アドレスの選択以外のエコーパケットのプロパティに関するガイドラインはありません。 BFD仕様では、これらのパケットのスプーフィングを防止するためにセキュリティメカニズムを適用することを推奨していますが、適切なメカニズムのタイプに関するガイドラインはありません。
Any security issues in the echo mode will directly affect the BFD protocol and session states, and hence the network stability. The potential effects and remedies as understood today are somewhat limited, however. For instance, any replay attacks would be indistinguishable from normal forwarding of the tested router. An attack would still cause a faulty link to be believed to be up, but there is little that can be done about it. However, if the echo packets are guessable, it may be possible to spoof from an external source and cause BFD to believe that a one-way link is really bidirectional. As a result, it is important that the echo packets contain random material that is also checked upon reception.
エコーモードでのセキュリティの問題は、BFDプロトコルとセッションステートに直接影響するため、ネットワークの安定性に影響します。しかし、今日理解されている潜在的な影響と救済策は、やや限定されています。たとえば、リプレイ攻撃は、テストされたルーターの通常の転送と区別がつきません。攻撃によって依然として障害のあるリンクがアップしていると思われる可能性がありますが、それに対して実行できることはほとんどありません。ただし、エコーパケットが推測可能な場合は、外部ソースからスプーフィングして、BFDに一方向リンクが本当に双方向であると信じ込ませることができる場合があります。その結果、エコーパケットにはランダムな素材が含まれ、受信時にもチェックされることが重要です。
o BFD packets can be sent at millisecond intervals (the protocol uses timers at microsecond intervals). When using authentication, this can cause frequent sequence number wrap-around as a 32-bit sequence number is used, thus considerably reducing the security of the authentication algorithms.
o BFDパケットはミリ秒間隔で送信できます（プロトコルはマイクロ秒間隔でタイマーを使用します）。認証を使用する場合、32ビットのシーケンス番号が使用されるため、シーケンス番号の折り返しが頻繁に発生し、認証アルゴリズムのセキュリティが大幅に低下する可能性があります。
o Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of HMAC-MD5 and keyed SHA-1 in BFD, it is prudent to have other options available. Such attacks do not mean that BFD using SHA-1 for authentication is at risk. However, it does mean that SHA-1 should be replaced as soon as possible and should not be used for new applications.
o 最近、MD5およびSHA-1ハッシュ関数の耐衝突性の制限が発見されました。 [RFC4270]は発見を要約しています。 MD5をハッシュとして使用する攻撃がありました。これらの攻撃は、BFDでのHMAC-MD5およびキー付きSHA-1の使用には直接適用されませんが、他のオプションを利用できるようにすることは賢明です。このような攻撃は、認証にSHA-1を使用するBFDが危険にさらされていることを意味しません。ただし、SHA-1はできるだけ早く交換する必要があり、新しいアプリケーションには使用しないでください。
It should be noted that if SHA-1 is used in the Hashed Message Authentication Code (HMAC) [RFC2104] construction, then collision attacks currently known against SHA-1 do not apply. The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1.
ハッシュメッセージ認証コード（HMAC）[RFC2104]の構築でSHA-1が使用されている場合、SHA-1に対して現在知られている衝突攻撃は適用されないことに注意してください。 SHA-1に対する新しい攻撃は、HMAC-SHA-1のセキュリティに影響を与えません。
There are already proposals [GenBFDAuth] that add support for HMAC with the SHA-1 and SHA-2 family of hash functions for BFD.
BFDのハッシュ関数のSHA-1およびSHA-2ファミリーでHMACのサポートを追加する提案[GenBFDAuth]がすでにあります。
This document outlines security issues arising from the current methodology for manual keying of various routing protocols. No specific changes to routing protocols are proposed in this document; likewise, no new security requirements result.
このドキュメントでは、さまざまなルーティングプロトコルの手動キーイングの現在の方法論から生じるセキュリティの問題について概説します。このドキュメントでは、ルーティングプロトコルに対する特定の変更は提案されていません。同様に、新しいセキュリティ要件は発生しません。
We would like to acknowledge Sam Hartman, Ran Atkinson, Stephen Kent and Brian Weis for their initial comments on this document. Thanks to Merike Kaeo and Alfred Hoenes for reviewing many sections of the document and providing lot of useful comments.
このドキュメントに対する最初のコメントについて、サムハートマン、ランアトキンソン、スティーブンケント、ブライアンウェイスに感謝します。ドキュメントの多くのセクションをレビューし、多くの有用なコメントを提供してくれたMerike KaeoとAlfred Hoenesに感謝します。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y。、編、Li、T。、編、およびS. Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Kent, S., "IP Authentication Header",
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。ケント、S。、「IP認証ヘッダー」、
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[Arjen05] Arjen K. Lenstra, "Further progress in Hashing cryptanalysis", Lucent Bell Laboratories, February 26, 2005.
[Arjen05] Arjen K. Lenstra、「ハッシュ暗号解読のさらなる進歩」、ルーセントベルラボラトリーズ、2005年2月26日。
[Conv01] Convery, et al., "BGP Vulnerability Testing: Separating Fact from FUD v1.00", NANOG 28, pp. 1-61, June 2003.
[Conv01] Convery、et al。、 "BGP Vulnerability Testing：Separating Fact from FUD v1.00"、NANOG 28、pp。1-61、2003年6月。
[Crypto2004] Xiaoyun Wang, Xuejia Lai, Dengguo Feng, and Hongbo Yu, "Collisions for hash functions MD4, MD5, HAVAL-128, and RIPEMD", Crypto 2004 Rump Session.
[Crypto2004] Xiaoyun Wang、Xuejia Lai、Dengguo Feng、Hongbo Yu、「ハッシュ関数MD4、MD5、HAVAL-128、およびRIPEMDの衝突」、Crypto 2004ランプセッション。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the 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年夏。
[GenBFDAuth] Bhatia, M. and V. Manral, "BFD Generic Cryptographic Authentication", Work in Progress, June 2010.
[GenBFDAuth] Bhatia、M.およびV. Manral、「BFD Generic Cryptographic Authentication」、Work in Progress、2010年6月。
[NISTHmacSHA] "NIST's Policy on Hash Functions", 2006, http://csrc.nist.gov/groups/ST/hash/policy.html.
[NISTHmacSHA]「ハッシュ関数に関するNISTのポリシー」、2006年、http：//csrc.nist.gov/groups/ST/hash/policy.html。
[Philip01] Philip Hawkes, Michael Paddon, and Gregory G. Rose, "On Corrective Patterns for the SHA-2 Family", IACR ePrint Archive, 2004, http://eprint.iacr.org/2004/207.
[Philip01] Philip Hawkes、Michael Paddon、Gregory G. Rose、「SHA-2ファミリの修正パターンについて」、IACR ePrint Archive、2004、http：//eprint.iacr.org/2004/207。
[Prav01] Praveen Gauravaram, et al., "Collision Attacks on MD5 and SHA-1: Is this the 'Sword of Domocles' for Electronic Commerce?", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
[Prav01] Praveen Gauravaram、他「MD5とSHA-1への衝突攻撃：これは電子商取引の「剣の剣」ですか？」、情報セキュリティ研究所（ISI）、クイーンズランド工科大学（QUT）、オーストラリア。
[Prav02] Praveen Gauravaram, et al., "Some thoughts on Collision Attacks in the Hash Functions Md5, SHA-0 and SHA-1", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
[Prav02] Praveen Gauravaram、他「ハッシュ関数Md5、SHA-0およびSHA-1での衝突攻撃に関するいくつかの考察」、情報セキュリティ研究所（ISI）、クイーンズランド工科大学（QUT）、オーストラリア。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058] Hedrick、C。、「Routing Information Protocol」、RFC 1058、1988年6月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993.
[RFC1388] Malkin、G。、「RIP Version 2 Carrying Additional Information」、RFC 1388、1993年1月。
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[RFC1723] Malkin、G。、「RIPバージョン2-追加情報の運搬」、RFC 1723、1994年11月。
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
[RFC1923] Halpern、J。およびS. Bradner、「歴史的地位に関するRIPv1の適用に関する声明」、RFC 1923、1996年3月。
[RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[RFC2082]ベイカー、F。およびR.アトキンソン、「RIP-2 MD5認証」、RFC 2082、1997年1月。
[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月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154] Murphy、S.、Badger、M。、およびB. Wellington、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、1998年11月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、M。、「TCP MD5署名オプションのキー管理に関する考慮事項」、RFC 3562、2003年7月。
[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月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、編、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）for IPv4 and IPv6（Single Hop）」、RFC 5881、2010年6月。
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC5883] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）for Multihop Paths」、RFC 5883、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RR07] Rechberger, C. and V. Rijmen, "On Authentication with HMAC and Non-random Properties", Financial Cryptography and Data Security, Lecture Notes in Computer Science, Volume 4886/2008, Springer-Verlag, Berlin, December 2007.
[RR07] Rechberger、C。およびV. Rijmen、「HMACおよび非ランダムプロパティによる認証について」、金融暗号化およびデータセキュリティ、コンピュータサイエンスの講義ノート、ボリューム4886/2008、Springer-Verlag、ベルリン、2007年12月。
[RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC when Instantiated with Popular Hash Functions", Journal of Universal Computer Science, Volume 14, Number 3, pp. 347-376, 1 February 2008.
[RR08] Rechberger、C。およびV. Rijmen、「人気のハッシュ関数でインスタンス化されたときのNMAC / HMACの新しい結果」、Universal Computer Scienceジャーナル、14巻、3号、347〜376ページ、2008年2月1日。
[TcpWindow] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://cansecwest.com/csw04archive.html.
[TcpWindow] Watson、P。、「Slipping in the Window：TCP Reset attack」、2004 CanSecWestでのプレゼンテーション、http：//cansecwest.com/csw04archive.html。
[Wang04] Wang, X., et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, IACR ePrint Archive, http://eprint.iacr.org/2004/199.
[Wang04] Wang、X。、他、「ハッシュ関数MD4、MD5、HAVAL-128およびRIPEMDの衝突」、2004年8月、IACR ePrint Archive、http：//eprint.iacr.org/2004/199。
[Wang05] Wang, X., et al., "Finding Collisions in the Full SHA-1", Proceedings of Crypto 2005, Lecture Notes in Computer Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, August 31, 2005.
[Wang05] Wang、X.、et al。、 "Finding Collisions in the Full SHA-1"、Proceedings of Crypto 2005、Lecture Notes in Computer Science、Volume 3621、pp。17-36、Springer-Verlag、Berlin、August 2005年31月。
Sue Hares NextHop USA EMail: shares@nexthop.com
Sue Hares NextHop USAメール：shares@nexthop.com
Authors' Addresses
著者のアドレス
Vishwas Manral IP Infusion, Inc. 1188 E. Arques Ave. Sunnyvale, CA 94085 EMail: vishwas@ipinfusion.com
Vishwas Maral Pip Infosys、です。西暦1188年アークスAV。 Sunnyvale、Ka 94085メール：trust@pinfusions.com
Manav Bhatia Alcatel-Lucent Bangalore India EMail: manav.bhatia@alcatel-lucent.com
Manav Bhatiaアルカテルルーセントバンガロールインドメール：manav.bhatia@alcatel-lucent.com
Joel P. Jaeggli Nokia Inc. EMail: joel.jaeggli@nokia.com
Joel P. Jaeggli Nokia Inc.メール：joel.jaeggli@nokia.com
Russ White Cisco Systems RTP North Carolina USA EMail: riw@cisco.com
Russ White Cisco Systems RTP North Carolina USA Eメール：riw@cisco.com