[要約] RFC 6518は、ルーティングプロトコルの鍵管理と認証に関する設計ガイドラインです。その目的は、セキュリティを向上させ、ルーティングプロトコルの信頼性と安全性を確保することです。
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6518 M. Bhatia
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 February 2012
Keying and Authentication for Routing Protocols (KARP) Design Guidelines
ルーティングプロトコル（KARP）設計ガイドラインのキーと認証
Abstract
概要
This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.
このドキュメントは、ルーティングプロトコルでのメッセージ認証のための最新の暗号化メカニズムとアルゴリズムの使用のためのプロトコル仕様作業のロードマップの定義に関係するシリーズの1つです。特に、メッセージ認証と整合性のセッションキーを作成および管理するために使用できるキー管理プロトコルのフレームワークを定義します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc6518.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6518で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Categorizing Routing Protocols ..................................5
2.1. Category: Message Transaction Type .........................5
2.2. Category: Peer versus Group Keying .........................6
3. Consider the Future Existence of a Key Management Protocol ......6
3.1. Consider Asymmetric Keys ...................................7
3.2. Cryptographic Keys Life Cycle ..............................8
4. Roadmap .........................................................9
4.1. Work Phases on Any Particular Protocol .....................9
4.2. Work Items per Routing Protocol ...........................11
5. Routing Protocols in Categories ................................13
6. Supporting Incremental Deployment ..............................16
7. Denial-of-Service Attacks ......................................17
8. Gap Analysis ...................................................18
9. Security Considerations ........................................20
9.1. Use Strong Keys ...........................................21
9.2. Internal versus External Operation ........................22
9.3. Unique versus Shared Keys .................................22
9.4. Key Exchange Mechanism ....................................24
10. Acknowledgments ...............................................26
11. References ....................................................26
11.1. Normative References ....................................26
11.2. Informative References ..................................26
In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that document states that "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure". Section 8.2 calls for "[t]ightening the security of the core routing infrastructure". Four main steps were identified for that tightening:
2006年3月、インターネットアーキテクチャ委員会（IAB）は、「不要なインターネットトラフィック」のトピックに関するワークショップを開催しました。そのワークショップのレポートは、RFC 4948 [RFC4948]に文書化されています。そのドキュメントのセクション8.1は、「単純なリスク分析は、最小コストの理想的な攻撃目標であるが最大の混乱がコアルーティングインフラストラクチャであることを示唆するだろう」と述べています。セクション8.2では、「コアルーティングインフラストラクチャのセキュリティを観察する」ことを求めています。その引き締めのために4つの主要なステップが特定されました。
o Increase the security mechanisms and practices for operating routers.
o ルーターを操作するためのセキュリティメカニズムと実践を増やします。
o Clean up the Internet Routing Registry [IRR] repository, and securing both the database and the access, so that it can be used for routing verifications.
o インターネットルーティングレジストリ[IRR]リポジトリをクリーンアップし、データベースとアクセスの両方を保護するため、ルーティングの検証に使用できます。
o Create specifications for cryptographic validation of routing message content.
o ルーティングメッセージコンテンツの暗号化検証の仕様を作成します。
o Secure the routing protocols' packets on the wire.
o ワイヤー上のルーティングプロトコルのパケットを保護します。
The first bullet is being addressed in the OPSEC working group. The second bullet should be addressed through liaisons with those running the IRR's globally. The third bullet is being addressed in the SIDR working group.
最初の弾丸は、OPSECワーキンググループで対処されています。2番目の弾丸は、IRRをグローバルに実行している人と一緒にリエゾンを通して対処する必要があります。3番目の弾丸は、SIDRワーキンググループで対処されています。
This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. Thus, it is concerned with guidelines for describing issues and techniques for protecting the messages between directly communicating peers. This may overlap with, but is strongly distinct from, protection designed to ensure that routing information is properly authorized relative to sources of this information. Such authorizations are provided by other mechanisms and are outside the scope of this document and the work that relies on it.
このドキュメントは、ルーティングプロトコル交換のワイヤー上のパケットを固定する最後の弾丸に対応しています。したがって、直接通信する仲間の間でメッセージを保護するための問題とテクニックを説明するためのガイドラインに関係しています。これは、この情報のソースと比較してルーティング情報が適切に承認されるように設計された保護と重複する場合がありますが、強く異なります。このような承認は、他のメカニズムによって提供され、このドキュメントの範囲とそれに依存する作業の外側にあります。
This document uses the terminology "on the wire" to talk about the information used by routing systems. This term is widely used in RFCs, but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances and to underlying protocols that may also need to be protected in specific circumstances. Other documents that will analyze individual protocols will need to indicate how they use the term "on the wire".
このドキュメントでは、「ワイヤー上」という用語を使用して、ルーティングシステムで使用される情報について説明します。この用語はRFCSで広く使用されていますが、いくつかの異なる方法で使用されています。このドキュメントでは、ルーティングプロトコルインスタンス間で交換された情報と、特定の状況でも保護する必要がある基礎となるプロトコルの両方を参照するために使用されます。個々のプロトコルを分析する他のドキュメントでは、「ワイヤー上」という用語をどのように使用するかを示す必要があります。
The term "routing transport" is used to refer to the layer that exchanges the routing protocols. This can be TCP, UDP, or even direct link-level messaging in the case of some routing protocols. The term is used here to allow a referent for discussing both common and disparate issues that affect or interact with this dimension of the routing systems. The term is used here to refer generally to the set of mechanisms and exchanges underneath the routing protocol, whatever that is in specific cases.
「ルーティングトランスポート」という用語は、ルーティングプロトコルを交換するレイヤーを参照するために使用されます。これは、一部のルーティングプロトコルの場合のTCP、UDP、または直接リンクレベルのメッセージングでさえ可能です。この用語は、ルーティングシステムのこの次元に影響または相互作用する一般的および異なる問題の両方を議論するための指示対象者を許可するために使用されます。この用語は、特定の場合に関係するものが何であれ、ルーティングプロトコルの下にある一連のメカニズムと交換を一般的に参照するために使用されます。
Keying and Authentication for Routing Protocols (KARP) will focus on an abstraction for keying information that describes the interface between routing protocols, operators, and automated key management. Conceptually, when routing protocols send or receive messages, they will look up the key to use in this abstract key table. Conceptually, there will be an interface for a routing protocol to make requests of automated key management when it is being used; when keys become available, they will be made available in the key table. There is no requirement that this abstraction be used for implementation; the abstraction serves the needs of standardization and management. Specifically, as part of the KARP work plan:
ルーティングプロトコル（KARP）のキーイングと認証は、ルーティングプロトコル、オペレーター、および自動化されたキー管理の間のインターフェイスを説明するキーイング情報の抽象化に焦点を当てます。概念的には、プロトコルをルーティングするとメッセージが送信または受信されると、この抽象キーテーブルで使用するキーを検索します。概念的には、使用されているときに自動化されたキー管理の要求を行うためのルーティングプロトコルのインターフェイスがあります。キーが利用可能になると、キーテーブルで利用可能になります。この抽象化を実装に使用する必要はありません。抽象化は、標準化と管理のニーズに応えます。具体的には、KARP作業計画の一部として：
1) KARP will design the key table abstraction, the interface between key management protocols and routing protocols, and possibly security protocols at other layers.
1) KARPは、キーテーブルの抽象化、キー管理プロトコルとルーティングプロトコルの間のインターフェイス、および他のレイヤーでのセキュリティプロトコルを設計します。
2) For each routing protocol, KARP will define the mapping between how the protocol represents key material and the protocol-independent key table abstraction. When routing protocols share a common mechanism for authentication, such as the TCP Authentication Option, the same mapping is likely to be reused between protocols. An implementation may be able to move much of the keying logic into code related to this shared authentication primitive rather than code specific to routing protocols.
2) 各ルーティングプロトコルについて、KARPは、プロトコルがキー資料とプロトコルに依存しないキーテーブルの抽象化を表す方法のマッピングを定義します。ルーティングプロトコルが、TCP認証オプションなどの認証の共通メカニズムを共有する場合、同じマッピングがプロトコル間で再利用される可能性があります。実装により、キーイングロジックの多くを、ルーティングプロトコルに固有のコードではなく、この共有認証プリミティブに関連するコードに移動できる場合があります。
3) When designing automated key management for both symmetric keys and group keys, we will only use the abstractions designed in point 1 above to communicate between automated key management and routing protocols.
3) 対称キーとグループキーの両方に自動化されたキー管理を設計する場合、上記のポイント1で設計された抽象化のみを使用して、自動化されたキー管理プロトコルとルーティングプロトコル間で通信します。
Readers must refer to [THTS-REQS] for a clear definition of the scope, goals, non-goals, and the audience for the design work being undertaken in the KARP WG.
読者は、KARP WGで行われているデザイン作業の範囲、目標、非ゴール、および聴衆の明確な定義については、[THTS-REQS]を参照する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document places the routing protocols into two categories according to their requirements for authentication. We hope these categories will allow design teams to focus on security mechanisms for a given category. Further, we hope that each protocol in the group will be able to reuse the authentication mechanism. It is also hoped that, down the road, we can create one Key Management Protocol (KMP) per category (if not for several categories), so that the work can be easily leveraged for use in the various routing protocol groupings. KMPs are useful for allowing simple, automated updates of the traffic keys used in a base protocol. KMPs replace the need for humans, or operational support systems (OSS) routines, to periodically replace keys on running systems. It also removes the need for a chain of manual keys to be chosen or configured on such systems. When configured properly, a KMP will enforce the key freshness policy among peers by keeping track of the key's lifetime and negotiating a new key at the defined interval.
このドキュメントは、ルーティングプロトコルを認証の要件に従って2つのカテゴリに配置します。これらのカテゴリにより、設計チームが特定のカテゴリのセキュリティメカニズムに集中できるようになることを願っています。さらに、グループ内の各プロトコルが認証メカニズムを再利用できることを願っています。また、さまざまなルーティングプロトコルグループで使用するために作業を簡単に活用できるように、カテゴリごとに1つの主要な管理プロトコル（KMP）を作成できることが期待されています（いくつかのカテゴリではない場合）。 KMPは、ベースプロトコルで使用されるトラフィックキーのシンプルで自動化された更新を許可するのに役立ちます。 KMPは、ランニングシステムのキーを定期的に置き換えるために、人間または運用サポートシステム（OSS）ルーチンの必要性を置き換えます。また、そのようなシステムで選択または構成される手動キーのチェーンの必要性を削除します。適切に構成すると、KMPは、キーの生涯を追跡し、定義されたインターバルで新しいキーを交渉することにより、ピア間のキーフレッシュネスポリシーを実施します。
The first category defines three types of messaging transactions used on the wire by the base routing protocol. They are as follows:
最初のカテゴリは、ベースルーティングプロトコルによってワイヤーで使用される3種類のメッセージングトランザクションを定義します。彼らは次のとおりです：
One-to-One
1対1
One peer router directly and intentionally delivers a route update specifically to one other peer router. Examples are BGP [RFC4271]; LDP [RFC5036]; BFD [RFC5880]; and RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151]. Point-to-point modes of both IS-IS [RFC1195] and OSPF [RFC2328], when sent over both traditional point-to-point links and when using multi-access layers, may both also fall into this category.
1つのピアルーターが直接的かつ意図的にルートアップデートを他のピアルーターに特別に提供します。例はBGP [RFC4271]です。LDP [RFC5036];BFD [RFC5880];およびRSVP-TE [RFC3209]、[RFC3473]、[RFC4726]、および[RFC5151]。IS-IS [RFC1195]とOSPF [RFC2328]の両方のポイントツーポイントモードは、従来のポイントツーポイントリンクの両方で送信された場合、およびマルチアクセスレイヤーを使用する場合、どちらもこのカテゴリに分類される場合があります。
One-to-Many
1対多い
A router peers with multiple other routers on a single network segment -- i.e., on link local -- such that it creates and sends one route update message that is intended for multiple peers. Examples would be OSPF and IS-IS in their broadcast, non-point-to-point mode and Routing Information Protocol (RIP) [RFC2453].
単一のネットワークセグメント（つまり、Link Local）に他の複数のルーターを備えたルーターピアが、複数のピアを対象とした1つのルート更新メッセージを作成および送信します。例は、OSPFとIS-ISの放送、非点からポイントモード、およびルーティング情報プロトコル（RIP）[RFC2453]です。
Multicast
マルチキャスト
Multicast protocols have unique security properties because they are inherently group-based protocols; thus, they have group keying requirements at the routing level where link-local
マルチキャストプロトコルには、本質的にグループベースのプロトコルであるため、独自のセキュリティプロパティがあります。したがって、リンクローカルのルーティングレベルでグループキーイング要件を持っています
routing messages are multicasted. Also, at least in the case of Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], some messages are sent unicast to a given peer(s), as is the case with router-close-to-sender and the "Rendezvous Point". Some work for application-layer message security has been done in the Multicast Security (MSEC) working group and may be helpful to review, but it is not directly applicable.
ルーティングメッセージはマルチキャストです。また、少なくともプロトコル独立したマルチキャスト - スパースモード（PIM-SM）[RFC4601]の場合、一部のメッセージは特定のピアにユニキャストが送信されます。「ランデブーポイント」。アプリケーション層メッセージセキュリティの一部の作業は、マルチキャストセキュリティ（MSEC）ワーキンググループで行われており、レビューに役立つ場合がありますが、直接適用できません。
These categories affect both the routing protocol view of the communication and the actual message transfer. As a result, some message transaction types for a few routing protocols may be mixtures, for example, using broadcast where multicast might be expected or using unicast to deliver what looks to the routing protocol like broadcast or multicast.
これらのカテゴリは、通信のルーティングプロトコルビューと実際のメッセージ転送の両方に影響します。その結果、いくつかのルーティングプロトコルのメッセージトランザクションタイプの一部は、たとえばマルチキャストが予想されるブロードキャストを使用したり、ユニキャストを使用してブロードキャストやマルチキャストなどのルーティングプロトコルに見えるものを配信するための混合物である場合があります。
Protocol security analysis documents produced in the KARP working group need to pay attention both to the semantics of the communication and the techniques that are used for the message exchanges.
KARPワーキンググループで作成されたプロトコルセキュリティ分析ドキュメントは、コミュニケーションのセマンティクスとメッセージ交換に使用される技術の両方に注意を払う必要があります。
The second category is the keying mechanism that will be used to distribute the session keys to the routing transports. They are as follows:
2番目のカテゴリは、セッションキーをルーティングトランスポートに配布するために使用されるキーイングメカニズムです。彼らは次のとおりです：
Peer Keying
ピアキーイング
One router sends the keying messages only to one other router, such that a one-to-one, uniquely keyed security association (SA) is established between the two routers (e.g., BGP, BFD and LDP).
1つのルーターは、キーイングメッセージを他の1つのルーターにのみ送信します。これにより、2つのルーター（BGP、BFD、LDPなど）の間に1対1のユニークなキー付きセキュリティ協会（SA）が確立されます。
Group Keying
グループキーイング
One router creates and distributes a single keying message to multiple peers. In this case, a group SA will be established and used among multiple peers simultaneously. Group keying exists for protocols like OSPF [RFC2328] and for multicast protocols like PIM-SM [RFC4601].
1つのルーターは、複数のピアに単一のキーイングメッセージを作成および配布します。この場合、グループSAが確立され、複数のピア間で同時に使用されます。Group Keyingは、OSPF [RFC2328]などのプロトコルおよびPIM-SM [RFC4601]などのマルチキャストプロトコルに存在します。
When it comes time for the KARP WG to design a reusable model for a Key Management Protocol (KMP), [RFC4107] should be consulted.
KARP WGが主要な管理プロトコル（KMP）の再利用可能なモデルを設計する時が来たら、[RFC4107]に相談する必要があります。
When conducting the design work on a manually keyed version of a routing protocol's authentication mechanism, consideration must be made for the eventual use of a KMP. In particular, design teams must consider what parameters would need to be handed to the routing protocols by a KMP.
ルーティングプロトコルの認証メカニズムの手動でキー付きバージョンで設計作業を実施する場合、KMPの最終的な使用について考慮する必要があります。特に、設計チームは、KMPによってルーティングプロトコルに渡す必要があるパラメーターを考慮する必要があります。
Examples of parameters that might need to be passed are as follows: a security association identifier (e.g., IPsec Security Parameter Index (SPI) or the TCP Authentication Option's (TCP-AO's) KeyID), a key lifetime (which may be represented in either bytes or seconds), the cryptographic algorithms being used, the keys themselves, and the directionality of the keys (i.e., receiving versus the sending keys).
渡す必要がある可能性のあるパラメーターの例は次のとおりです。セキュリティ協会識別子（IPSECセキュリティパラメーターインデックス（SPI）またはTCP認証オプション（TCP-AO）KeyID）、重要な寿命（どちらでも表される可能性があります。バイトまたは秒）、使用されている暗号化アルゴリズム、キー自体、キーの方向性（つまり、送信キーに対して受信）。
The use of asymmetric keys can be a very powerful way to authenticate machine peers as used in routing protocol peer exchanges. If generated on the machine, and never moved off the machine, these keys will not need to be changed if an administrator leaves the organization. Since the keys are random, they are far less susceptible to off-line dictionary and guessing attacks.
非対称キーの使用は、ルーティングプロトコルピア交換で使用されるように、マシンピアを認証するための非常に強力な方法です。マシンで生成され、マシンから離れない場合、管理者が組織を離れる場合、これらのキーを変更する必要はありません。キーはランダムであるため、オフラインの辞書や推測攻撃の影響がはるかに低くなります。
An easy and simple way to use asymmetric keys is to start by having the router generate a public/private key pair. At the time of this writing, the recommended key size for algorithms based on integer factorization cryptography like RSA is 1024 bits and 2048 bits for extremely valuable keys like the root key pair used by a certification authority. It is believed that a 1024-bit RSA key is equivalent in strength to 80-bit symmetric keys and 2048-bit RSA keys to 112-bit symmetric keys [RFC3766]. Elliptic Curve Cryptography (ECC) [RFC4492] appears to be secure with shorter keys than those needed by other asymmetric key algorithms. National Institute of Standards and Technology (NIST) guidelines [NIST-800-57] state that ECC keys should be twice the length of equivalent strength symmetric key algorithms. Thus, a 224-bit ECC key would roughly have the same strength as a 112-bit symmetric key.
非対称キーを使用する簡単で簡単な方法は、ルーターにパブリック/プライベートキーペアを生成することから始めることです。この執筆時点では、RSAのような整数因子化暗号化に基づくアルゴリズムの推奨キーサイズは、認定機関が使用するルートキーペアのような非常に貴重なキーのために1024ビットと2048ビットです。1024ビットRSAキーは、80ビット対称キーと112ビット対称キー[RFC3766]に2048ビットRSAキーに強度が同等であると考えられています。楕円曲線暗号化（ECC）[RFC4492]は、他の非対称キーアルゴリズムで必要なキーよりも短いキーで安全であるように見えます。国立標準技術研究所（NIST）ガイドライン[NIST-800-57]は、ECCキーが同等の強度対称キーアルゴリズムの2倍の長さである必要があると述べています。したがって、224ビットのECCキーは、112ビット対称キーとほぼ同じ強度を持ちます。
Many routers have the ability to be remotely managed using Secure Shell (SSH) Protocol [RFC4252] and [RFC4253]. As such, routers will also have the ability to generate and store an asymmetric key pair, because this is the common authentication method employed by SSH when an administrator connects to a router for management sessions.
多くのルーターには、Secure Shell（SSH）プロトコル[RFC4252]および[RFC4253]を使用してリモート管理する機能があります。そのため、ルーターは非対称キーペアを生成および保存する機能も備えています。これは、管理者が管理セッションのルーターに接続したときにSSHが採用する一般的な認証方法であるためです。
Once an asymmetric key pair is generated, the KMP generating security association parameters and keys for routing protocol may use the machine's asymmetric keys for the authentication mechanism. The form of the identity proof could be raw keys, the more easily administrable self-signed certificate format, or a PKI-issued [RFC5280] certificate credential.
非対称キーペアが生成されると、KMPは、ルーティングプロトコル用のセキュリティアソシエーションパラメーターとキーを生成し、認証メカニズムにマシンの非対称キーを使用できます。身分証明書の形式は、生キー、より簡単に管理できる自己署名証明書形式、またはPKI発行[RFC5280]証明書の資格情報です。
Regardless of which credential is standardized, the authentication mechanism can be as simple as a strong hash over a string of human-readable and transferable form of ASCII characters. More complex, but also more secure, the identity proof could be verified through the use of a PKI system's revocation checking mechanism, (e.g., Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) responder). If the SHA-1 fingerprint is used, the solution could be as simple as loading a set of neighbor routers' peer ID strings into a table and listing the associated fingerprint string for each ID string. In most organizations or peering points, this list will not be longer than a thousand or so routers, and often the list will be much shorter. In other words, the entire list for a given organization's router ID and hash could be held in a router's configuration file, uploaded, downloaded, and moved about at will. Additionally, it doesn't matter who sees or gains access to these fingerprints, because they can be distributed publicly as it needn't be kept secret.
どの資格情報が標準化されているかにかかわらず、認証メカニズムは、ASCII文字の一連の人間が読みやすく転送可能な形式よりも強力なハッシュと同じくらい単純です。より複雑ですが、より安全であるため、IDの証明は、PKIシステムの取り消しチェックメカニズム（例：証明書取消リスト（CRL）またはオンライン証明書ステータスプロトコル（OCSP）レスポンダー）を使用することで検証できます。 SHA-1フィンガープリントを使用すると、近隣ルーターのピアID文字列のセットをテーブルにロードし、各ID文字列の関連する指紋文字列をリストするのと同じくらい簡単です。ほとんどの組織またはピアリングポイントでは、このリストは1000ルーターほどではなく、多くの場合、リストははるかに短くなります。言い換えれば、特定の組織のルーターIDとハッシュのリスト全体をルーターの構成ファイルに保持し、アップロード、ダウンロード、および自由に移動することができます。さらに、これらの指紋にアクセスできる人を誰が見たり、獲得したりすることは関係ありません。なぜなら、それらは秘密にする必要がないため公開される可能性があるからです。
Cryptographic keys should have a limited lifetime and may need to be changed when an operator who had access to them leaves. Using a key chain, a set of keys derived from the same keying material and used one after the other, also does not help as one still has to change all the keys in the key chain when an operator having access to all those keys leaves the company. Additionally, key chains will not help if the routing transport subsystem does not support rolling over to the new keys without bouncing the routing sessions and adjacencies. So the first step is to fix the routing stack so that routing protocols can change keys without breaking or bouncing the adjacencies.
暗号化キーの寿命は限られている必要があり、それらにアクセスできるオペレーターが去るときに変更する必要がある場合があります。キーチェーンを使用して、同じキーイング素材から派生し、次々に使用されるキーのセットも、オペレーターがそれらのすべてのキーにアクセスできるようになったときにキーチェーンのすべてのキーを変更する必要があるため、役に立ちません。会社。さらに、ルーティングトランスポートサブシステムがルーティングセッションや隣接をバウンスせずに新しいキーへの転がりをサポートしていない場合、キーチェーンは役に立ちません。したがって、最初のステップは、ルーティングスタックを修正して、ルーティングプロトコルが隣接を壊したりバウンスしたりせずにキーを変更できるようにすることです。
An often cited reason for limiting the lifetime of a key is to minimize the damage from a compromised key. It could be argued that it is likely a user will not discover an attacker has compromised the key if the attacker remains "passive"; thus, relatively frequent key changes will limit any potential damage from compromised keys.
キーの寿命を制限することがよく引用される理由は、侵害されたキーからの損傷を最小限に抑えることです。攻撃者が「パッシブ」のままである場合、攻撃者がキーを損なうことを発見しない可能性が高いと主張することができます。したがって、比較的頻繁なキー変更により、侵害されたキーからの潜在的な損傷が制限されます。
Another threat against the long-lived key is that one of the systems storing the key, or one of the users entrusted with the key, will be subverted. So, while there may not be cryptographic motivations of changing the keys, there could be system security motivations for rolling the key.
長寿命のキーに対するもう1つの脅威は、キーを保存するシステムの1つ、またはキーを委託するユーザーの1つが破壊されることです。したがって、キーを変更するという暗号化の動機はないかもしれませんが、キーを転がすためのシステムセキュリティの動機がある可能性があります。
Although manual key distribution methods are subject to human error and frailty, more frequent manual key changes might actually increase the risk of exposure, as it is during the time that the keys are being changed that they are likely to be disclosed. In these cases, especially when very strong cryptography is employed, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequent, poorly controlled manual key distributions. In general, where strong cryptography is employed, physical, procedural, and logical access protection considerations often have more impact on the key life than do algorithm and key size factors.
手動のキーディストリビューション方法はヒューマンエラーと虚弱の対象となりますが、より頻繁な手動のキー変更は、実際に曝露のリスクを高める可能性があります。これらの場合、特に非常に強力な暗号化が採用されている場合、より頻繁で制御不十分な手動の主要な分布ではなく、より少ない、十分に制御された手動の主要な分布を持つことはより賢明かもしれません。一般に、強い暗号が採用されている場合、物理的、手続き的、および論理的なアクセス保護の考慮事項は、アルゴリズムと主要なサイズの要因よりも重要な生活により大きな影響を与えることがよくあります。
For incremental deployments, we could start by associating life times with the send and the receive keys in the key chain for the long-lived keys. This is an incremental approach that we could use until the cryptographic keying material for individual sessions is derived from the keying material stored in a database of long-lived cryptographic keys as described in [CRPT-TAB]. A key derivation function (KDF) and its inputs are also specified in the database of long-lived cryptographic keys; session-specific values based on the routing protocol are input to the KDF. Protocol-specific key identifiers may be assigned to the cryptographic keying material for individual sessions if needed.
インクリメンタルデプロイメントのために、長命のキーのキーチェーンの送信と受信キーに寿命を関連付けることから始めることができます。これは、[CRPT-TAB]で説明されているように、長寿命の暗号キーのデータベースに保存されているキーイング素材から派生するまで、個々のセッションの暗号化キーイング素材が導出されるまで使用できるインクリメンタルアプローチです。キー派生関数（KDF）とその入力は、長寿命の暗号キーのデータベースでも指定されています。ルーティングプロトコルに基づくセッション固有の値は、KDFに入力されます。プロトコル固有のキー識別子は、必要に応じて個々のセッションのために暗号化キーイング資料に割り当てることができます。
The long-lived cryptographic keys used by the routing protocols can either be inserted manually in a database or make use of an automated key management protocol to do this.
ルーティングプロトコルで使用される長寿命の暗号化キーは、データベースに手動で挿入するか、自動化されたキー管理プロトコルを使用してこれを行うことができます。
It is believed that improving security for any routing protocol will be a two-phase process. The first phase would be to modify routing protocols to support modern cryptography algorithms and key agility. The second phase would be to design and move to an automated key management mechanism. This is like a crawl, walk, and run process. In order for operators to accept these phases, we believe that the key management protocol should be clearly separated from the routing transport. This would mean that the routing transport subsystem is oblivious to how the keys are derived, exchanged, and downloaded as long as there is something that it can use. It is like having a
ルーティングプロトコルのセキュリティを改善することは、2フェーズプロセスになると考えられています。最初の段階は、ルーティングプロトコルを変更して、最新の暗号アルゴリズムとキーアジリティをサポートすることです。2番目のフェーズは、自動化された主要な管理メカニズムに設計および移動することです。これは、クロール、ウォーク、ランプロセスのようなものです。オペレーターがこれらのフェーズを受け入れるためには、主要な管理プロトコルをルーティング輸送から明確に分離する必要があると考えています。これは、ルーティングトランスポートサブシステムが、使用できるものがある限り、キーの導出、交換、ダウンロードの方法を忘れていることを意味します。それは持っているようなものです
routing-protocol-configuration switch that requests the security module for the "KARP security parameters" so that it can refer to some module written, maintained, and operated by security experts and insert those parameters in the routing exchange.
「KARPセキュリティパラメーター」のセキュリティモジュールを要求するルーティングプロトコル制度スイッチにより、セキュリティの専門家によって書かれ、維持、運用されているモジュールを参照し、ルーティング交換にそれらのパラメーターを挿入できます。
The desired end state for the KARP work contains several items. First, the people desiring to deploy securely authenticated and integrity validated packets between routing peers have the tools specified, implemented, and shipped in order to deploy. These tools should be fairly simple to implement and not more complex than the security mechanisms to which the operators are already accustomed. (Examples of security mechanisms to which router operators are accustomed include: the use of asymmetric keys for authentication in SSH for router configuration, the use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, the use of self-signed certificates for HTTP Secure (HTTPS) access to device Web-based user interfaces, the use of strongly constructed passwords and/or identity tokens for user identification when logging into routers and management systems.) While the tools that we intend to specify may not be able to stop a deployment from using "foobar" as an input key for every device across their entire routing domain, we intend to make a solid, modern security system that is not too much more difficult than that. In other words, simplicity and deployability are keys to success. The routing protocols will specify modern cryptographic algorithms and security mechanisms. Routing peers will be able to employ unique, pair-wise keys per peering instance, with reasonable key lifetimes, and updating those keys on a regular basis will be operationally easy, causing no service interruption.
KARP作業の目的のエンド状態には、いくつかのアイテムが含まれています。まず、ルーティングピア間で安全に認証され、整合性の検証済みパケットを展開したい人には、展開するために指定、実装、および出荷されたツールがあります。これらのツールは、実装がかなり簡単で、オペレーターがすでに慣れているセキュリティメカニズムよりも複雑ではありません。 （ルーターオペレーターが慣れているセキュリティメカニズムの例には、ルーター構成のSSHでの認証のための非対称キーの使用、BGP保護のためのTCP MD5での事前共有キー（PSK）の使用、自己署名証明書の使用が含まれます。 HTTPセキュア（HTTPS）デバイスWebベースのユーザーインターフェイスへのアクセスの場合、ルーターや管理システムにログインするときにユーザー識別のために強力に構築されたパスワードおよび/またはIDトークンの使用。）展開がルーティングドメイン全体にわたるすべてのデバイスの入力キーとして「Foobar」を使用するのを止めるために、それ以上に難しくない堅実な最新のセキュリティシステムを作成するつもりです。言い換えれば、シンプルさと展開性は成功の鍵です。ルーティングプロトコルは、最新の暗号化アルゴリズムとセキュリティメカニズムを指定します。ルーティングピアは、ピアリングインスタンスごとにユニークなペアごとのキーを採用でき、合理的なキーライフタイムを備えており、定期的にそれらのキーを更新することは操作的に簡単で、サービスの中断はありません。
Achieving the above described end state using manual keys may be pragmatic only in very small deployments. However, manual keying in larger deployments will be too burdensome for operators. Thus, the second goal is to support key life cycle management with a KMP. We expect that both manual and automated key management will coexist in the real world.
手動キーを使用して上記の上記のエンド状態を達成することは、非常に小さな展開でのみ実用的である可能性があります。ただし、大規模な展開での手動キーイングは、オペレーターにとっては負担が大きすぎます。したがって、2番目の目標は、KMPで主要なライフサイクル管理をサポートすることです。手動と自動化された主要な管理の両方が、現実の世界で共存することを期待しています。
In accordance with the desired end state just described, we define two main work phases for each routing protocol:
記述された希望の終了状態に従って、各ルーティングプロトコルの2つの主要な作業フェーズを定義します。
1. Enhance the routing protocol's current authentication mechanism(s). This work involves enhancing a routing protocol's current security mechanisms in order to achieve a consistent, modern level of security functionality within its existing key management framework. It is understood and accepted that the existing key management frameworks are largely based on manual keys. Since many operators have already built operational support systems (OSS) around these manual key implementations, there is some automation available for an operator to leverage in
1. ルーティングプロトコルの現在の認証メカニズムを強化します。この作業には、既存の主要な管理フレームワーク内で一貫した最新レベルのセキュリティ機能を達成するために、ルーティングプロトコルの現在のセキュリティメカニズムを強化することが含まれます。既存のキー管理フレームワークは主に手動キーに基づいていることが理解され、受け入れられています。多くのオペレーターは、これらの手動の主要な実装を中心に運用サポートシステム（OSS）をすでに構築しているため、オペレーターが活用できる自動化があります
that way, if the underlying mechanisms are themselves secure. In this phase, we explicitly exclude embedding or creating a KMP. Refer to [THTS-REQS] for the list of the requirements for Phase 1 work.
そうすれば、基礎となるメカニズム自体が安全である場合。このフェーズでは、埋め込みまたはKMPの作成を明示的に除外します。フェーズ1作業の要件のリストについては、[THTS-REQS]を参照してください。
2. Develop an automated key management framework. The second phase will focus on the development of an automated keying framework to facilitate unique pair-wise (group-wise, where applicable) keys per peering instance. This involves the use of a KMP. The use of automatic key management mechanisms offers a number of benefits over manual keying. Most important, it provides fresh traffic keying material for each session, thus helping to prevent inter-connection replay attacks. In an inter-connection replay attack, protocol packets from the earlier protocol session are replayed affecting the current execution of the protocol. A KMP is also helpful because it negotiates unique, pair-wise, random keys, without administrator involvement. It negotiates several SA parameters like algorithms, modes, and parameters required for the secure connection, thus providing interoperability between endpoints with disparate capabilities and configurations. In addition it could also include negotiating the key lifetimes. The KMP can thus keep track of those lifetimes using counters and can negotiate new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the traffic key, and those new traffic keys will be installed and used in the current connection. In summary, a KMP provides a protected channel between the peers through which they can negotiate and pass important data required to exchange proof of identities, derive traffic keys, determine rekeying, synchronize their keying state, signal various keying events, notify with error messages, etc.
2. 自動化された主要な管理フレームワークを開発します。第2フェーズでは、ピアリングインスタンスごとに一意のペアワイズ（グループごとに）キーを促進するために、自動キーイングフレームワークの開発に焦点を当てます。これには、KMPの使用が含まれます。自動キー管理メカニズムの使用は、手動キーイングよりも多くの利点を提供します。最も重要なことは、セッションごとに新鮮な交通キーイング素材を提供し、接続間リプレイ攻撃を防ぐのに役立つことです。相互接続リプレイ攻撃では、以前のプロトコルセッションのプロトコルパケットが再生され、プロトコルの現在の実行に影響があります。 KMPは、管理者が関与することなく、ユニークでペアのようにランダムなキーを交渉するため、役立ちます。安全な接続に必要なアルゴリズム、モード、パラメーターなどのいくつかのSAパラメーターを交渉し、異なる機能と構成を備えたエンドポイント間の相互運用性を提供します。さらに、重要な寿命の交渉も含めることができます。したがって、KMPは、カウンターを使用してこれらの生涯を追跡でき、管理者の相互作用なしに期限切れになる前に新しいキーとパラメーターを交渉できます。さらに、違反が発生した場合、KMPキーを変更すると、トラフィックキーに対してRekeyがすぐに発生し、これらの新しいトラフィックキーがインストールされ、現在の接続で使用されます。要約すると、KMPはピア間の保護されたチャネルを提供します。ピアは、アイデンティティの証明を交換し、トラフィックキーを導き出し、再キーイングを決定し、キーイング状態を同期させ、さまざまなキーイングイベントを合成し、エラーメッセージで通知し、エラーメッセージで通知するために必要な重要なデータを交渉して渡すことができるピア間で保護されたチャネルを提供します。等
Each routing protocol will have a team (the Routing_Protocol-KARP team, e.g., the OSPF-KARP team) working on incrementally improving the security of a routing protocol. These teams will have the following main work items:
各ルーティングプロトコルには、ルーティングプロトコルのセキュリティの改善に取り組んでいるチーム（OSPF-KARPチームなど）が機能します。これらのチームには、次の主な作業項目があります。
PHASE 1:
フェーズ1：
Characterize the Routing Protocol
ルーティングプロトコルを特徴付けます
Assess the routing protocol to see what authentication and integrity mechanisms it has today. Does it need significant improvement to its existing mechanisms or not? This will
ルーティングプロトコルを評価して、今日の認証と整合性のメカニズムを確認します。既存のメカニズムに大幅な改善が必要ですか？この意志
include determining if modern, strong security algorithms and parameters are present and if the protocol supports key agility without bouncing adjacencies.
最新の強力なセキュリティアルゴリズムとパラメーターが存在するかどうか、およびプロトコルが隣接をバウンスすることなく重要な俊敏性をサポートするかどうかを判断することを含めます。
Define Optimal State
最適な状態を定義します
List the requirements for the routing protocol's session key usage and format to contain modern, strong security algorithms and mechanisms, per the Requirements document [THTS-REQS]. The goal here is to determine what is needed for the routing protocol to be used securely with at least manual key management.
要件ドキュメント[THTS-REQS]に従って、ルーティングプロトコルのセッションのキーの使用法とフォーマットを最新の強力なセキュリティアルゴリズムとメカニズムを含む要件をリストします。ここでの目標は、少なくとも手動のキー管理でルーティングプロトコルを安全に使用するために必要なものを決定することです。
Gap Analysis
ギャップ分析
Enumerate the requirements for this protocol to move from its current security state, the first bullet, to its optimal state, as listed just above.
このプロトコルが現在のセキュリティ状態である最初の弾丸から最適な状態に移動するための要件を列挙します。
Transition and Deployment Considerations
移行と展開の考慮事項
Document the operational transition plan for moving from the old to the new security mechanism. Will adjacencies need to bounce? What new elements/servers/services in the infrastructure will be required? What is an example work flow that an operator will take? The best possible case is if the adjacency does not break, but this may not always be possible.
古いセキュリティメカニズムに移行するための運用移行計画を文書化します。隣接は跳ね返る必要がありますか？インフラストラクチャ内の新しい要素/サーバー/サービスが必要になりますか？オペレーターが取るワークフローの例は何ですか？可能な限り最良のケースは、隣接が壊れない場合ですが、これが常に可能であるとは限りません。
Define, Assign, Design
定義、割り当て、設計
Create a deliverables list of the design and specification work, with milestones. Define owners. Release one or more documents.
マイルストーンを使用して、デザインと仕様作業の成果物リストを作成します。所有者を定義します。1つ以上のドキュメントをリリースします。
PHASE 2:
フェーズ2：
KMP Analysis
KMP分析
Review requirements for KMPs. Identify any nuances for this particular routing protocol's needs and its use cases for a KMP. List the requirements that this routing protocol has for being able to be used in conjunction with a KMP. Define the optimal state and check how easily it can be decoupled from the KMP.
KMPの要件を確認します。この特定のルーティングプロトコルのニーズとKMPのユースケースのニュアンスを特定します。このルーティングプロトコルがKMPと組み合わせて使用できるための要件をリストします。最適な状態を定義し、KMPから簡単に分離できるかを確認します。
Gap Analysis
ギャップ分析
Enumerate the requirements for this protocol to move from its current security state to its optimal state, with respect to the key management.
主要な管理に関して、このプロトコルが現在のセキュリティ状態から最適な状態に移行するための要件を列挙します。
Define, Assign, Design
定義、割り当て、設計
Create a deliverables list of the design and specification work, with milestones. Define owners. Generate the design and document work for a KMP to be able to generate the routing protocol's session keys for the packets on the wire. These will be the arguments passed in the API to the KMP in order to bootstrap the session keys for the routing protocol.
マイルストーンを使用して、デザインと仕様作業の成果物リストを作成します。所有者を定義します。KMPの設計とドキュメントの作業を生成して、ワイヤー上のパケットのルーティングプロトコルのセッションキーを生成できるようにします。これらは、ルーティングプロトコルのセッションキーをブートストラップするために、APIでKMPに渡された引数となります。
There will also be a team formed to work on the base framework mechanisms for each of the main categories.
また、各メインカテゴリのベースフレームワークメカニズムに取り組むために形成されたチームもあります。
This section groups the routing protocols into categories according to attributes set forth in the Categories' Section (Section 2). Each group will have a design team tasked with improving the security of the routing protocol mechanisms and defining the KMP requirements for their group, then rolling both into a roadmap document upon which they will execute.
このセクションでは、ルーティングプロトコルをカテゴリのセクション（セクション2）に示す属性に従ってカテゴリに分類します。各グループには、ルーティングプロトコルメカニズムのセキュリティの改善とグループのKMP要件の定義を課すデザインチームがあり、その後、実行するロードマップドキュメントに両方を展開します。
BGP, LDP, PCEP, and MSDP
BGP、LDP、PCEP、およびMSDP
These routing protocols fall into the category of the one-to-one peering messages and will use peer keying protocols. Border Gateway Protocol (BGP) [RFC4271], Path Computation Element Communication Protocol (PCEP) [RFC5440], and Multicast Source Discovery Protocol (MSDP) [RFC3618] messages are transmitted over TCP, while Label Distribution Protocol (LDP) [RFC5036] uses both UDP and TCP. A team will work on one mechanism to cover these TCP unicast protocols. Much of the work on the routing protocol update for its existing authentication mechanism has already occurred in the TCPM working group, on the TCP-AO [RFC5925] document, as well as its cryptography-helper document, TCP-AO-CRYPTO [RFC5926]. However, TCP-AO cannot be used for discovery exchanges carried in LDP as those are carried over UDP. A separate team might want to look at LDP. Another exception is the mode where LDP is used directly on the LAN. The work for this may go into the group keying category (along with OSPF) as mentioned below.
これらのルーティングプロトコルは、1対1のピアリングメッセージのカテゴリに分類され、ピアキーイングプロトコルを使用します。 Border Gateway Protocol（BGP）[RFC4271]、パス計算要素通信プロトコル（PCEP）[RFC5440]、およびマルチキャストソース発見プロトコル（MSDP）[RFC3618]メッセージはTCPを介して送信されますが、ラベル分布プロトコル（LDP）[RFC5036] USES USES UDPとTCPの両方。チームは、これらのTCPユニキャストプロトコルをカバーするために1つのメカニズムに取り組みます。既存の認証メカニズムのルーティングプロトコルアップデートの作業の多くは、TCPMワーキンググループ、TCP-AO [RFC5925]ドキュメント、およびその暗号化分類文書、TCP-AO-CRYPTO [RFC5926]ですでに発生しています。 。ただし、TCP-AOは、UDPの上に運ばれるため、LDPで運ばれるディスカバリー交換に使用することはできません。別のチームがLDPを見たいかもしれません。別の例外は、LDPがLANで直接使用されるモードです。これの作業は、以下に言及したように（OSPFとともに）グループキーイングカテゴリに入ることができます。
OSPF, IS-IS, and RIP
OSPF、IS-IS、およびRIP
The routing protocols that fall into the category group keying (with one-to-many peering) includes OSPF [RFC2328], IS-IS [RFC1195] and RIP [RFC2453]. Not surprisingly, all these routing protocols have two other things in common. First, they are run on a combination of the OSI datalink Layer 2, and the OSI network Layer 3. By this we mean that they have a component of how the routing protocol works, which is specified in Layer 2 as well as in Layer 3. Second, they are all internal gateway protocols (IGPs). The keying mechanisms will be much more complicated to define for these than for a one-to-one messaging protocol.
カテゴリグループキーイングに分類されるルーティングプロトコル（1対Many Peering）には、OSPF [RFC2328]、IS-IS [RFC1195]、RIP [RFC2453]が含まれます。当然のことながら、これらのルーティングプロトコルにはすべて、他に2つの共通点があります。まず、OSI Datalinkレイヤー2とOSIネットワークレイヤー3の組み合わせで実行されます。これにより、レイヤー2およびレイヤー3で指定されているルーティングプロトコルの仕組みのコンポーネントがあることを意味します。第二に、それらはすべて内部ゲートウェイプロトコル（IGPS）です。キーイングメカニズムは、1対1のメッセージングプロトコルよりも、これらのために定義するのがはるかに複雑になります。
BFD
BFD
Because it is less of a routing protocol, per se, and more of a peer liveness detection mechanism, Bidirectional Forwarding Detection (BFD) [RFC5880] will have its own team. BFD is also different from the other protocols covered here as it works on millisecond timers and would need separate considerations to mitigate the potential for Denial-of-Service (DoS) attacks. It also raises interesting issues [RFC6039] with respect to the sequence number scheme that is generally deployed to protect against replay attacks as this space can roll over quite frequently because of the rate at which BFD packets are generated.
それはルーティングプロトコルではなく、それ自体がより多くのピアライデンス検出メカニズムであるため、双方向転送検出（BFD）[RFC5880]は独自のチームを持っています。BFDは、ミリ秒タイマーで機能するため、ここでカバーされている他のプロトコルとは異なり、サービス拒否（DOS）攻撃の可能性を軽減するために個別の考慮事項が必要です。また、BFDパケットが生成されるレートのためにこのスペースが非常に頻繁に転がる可能性があるため、一般的にリプレイ攻撃から保護するために展開されるシーケンス番号スキームに関して、興味深い問題[RFC6039]を提起します。
RSVP and RSVP-TE
RSVPおよびRSVP-TE
The Resource reSerVation Protocol (RSVP) [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747]. In this mode, an integrity object is attached to each RSVP message to transmit a keyed message digest. This message digest allows the recipient to verify the identity of the RSVP node that sent the message and to validate the integrity of the message. Through the inclusion of a sequence number in the scope of the digest, the digest also offers replay protection.
[RFC2747]で指定されているように、リソース予約プロトコル（RSVP）[RFC2205]により、RSVPネイバーのホップバイホップ認証が可能になります。このモードでは、各RSVPメッセージに整合性オブジェクトが接続され、キー付きメッセージダイジェストが送信されます。このメッセージダイジェストにより、受信者はメッセージを送信したRSVPノードのIDを確認し、メッセージの整合性を検証できます。ダイジェストの範囲にシーケンス番号を含めることにより、ダイジェストはリプレイ保護も提供します。
[RFC2747] does not dictate how the key for the integrity operation is derived. Currently, most implementations of RSVP use a statically configured key, on a per-interface or per-neighbor basis.
[RFC2747]は、整合性操作の鍵がどのように導出されるかを決定しません。現在、RSVPのほとんどの実装は、インターフェイスごとまたはニーバーごとに静的に構成されたキーを使用しています。
RSVP relies on a per-peer authentication mechanism where each hop authenticates its neighbor using a shared key or a certificate.
RSVPは、各ホップが共有キーまたは証明書を使用して近隣を認証するピアごとの認証メカニズムに依存しています。
Trust in this model is transitive. Each RSVP node trusts, explicitly, only its RSVP next-hop peers through the message digest contained in the INTEGRITY object [RFC2747]. The next-hop
このモデルへの信頼は推移的です。各RSVPノードは、明示的に、整合性オブジェクト[RFC2747]に含まれるメッセージを介してRSVPのネクストホップピアのみを信頼しています。次のホップ
RSVP speaker, in turn, trusts its own peers, and so on. See also the document "RSVP Security Properties" [RFC4230] for more background.
RSVPスピーカーは、順番に、独自の仲間などを信頼しています。詳細については、ドキュメント「RSVPセキュリティプロパティ」[RFC4230]も参照してください。
The keys used for protecting the RSVP messages can be group keys (for example, distributed via the Group Domain of Interpretation (GDOI) [RFC6407], as discussed in [GDOI-MAC]).
RSVPメッセージの保護に使用されるキーは、[GDOI-MAC]で説明されているように、グループキー（たとえば、解釈のグループドメイン（GDOI）[RFC6407]を介して分布する）にすることができます。
The trust an RSVP node has with another RSVP node has an explicit and implicit component. Explicitly, the node trusts the other node to maintain the integrity (and, optionally, the confidentiality) of RSVP messages depending on whether authentication or encryption (or both) are used. This means that the message has not been altered or its contents seen by another, non-trusted node. Implicitly, each node trusts the other node to maintain the level of protection specified within that security domain. Note that in any group key management scheme, like GDOI, each node trusts all the other members of the group with regard to data origin authentication.
RSVPノードが別のRSVPノードを持つトラストには、明示的かつ暗黙的なコンポーネントがあります。明示的に、ノードは他のノードを信頼して、認証または暗号化（またはその両方）が使用されるかどうかに応じて、RSVPメッセージの整合性（およびオプションでは機密性）を維持します。これは、メッセージが変更されていないこと、または他の非信頼性ノードで見られる内容が変更されていないことを意味します。暗黙的に、各ノードは他のノードを信頼して、そのセキュリティドメイン内で指定された保護レベルを維持します。GDOIのようなグループキー管理スキームでは、各ノードは、データオリジン認証に関してグループの他のすべてのメンバーを信頼していることに注意してください。
RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151] is an extension of the RSVP protocol for traffic engineering. It supports the reservation of resources across an IP network and is used for establishing MPLS label switch paths (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops. RSVP-TE signaling is used to establish both intra- and inter-domain TE LSPs.
RSVP-TE [RFC3209]、[RFC3473]、[RFC4726]、および[RFC5151]は、トラフィックエンジニアリング用のRSVPプロトコルの拡張です。IPネットワーク全体のリソースの予約をサポートし、利用可能な帯域幅や明示的ホップなどのネットワーク制約パラメーターを考慮して、MPLSラベルスイッチパス（LSP）の確立に使用されます。RSVP-TEシグナル伝達は、ドメイン内および領域間TE LSPの両方を確立するために使用されます。
When signaling an inter-domain RSVP-TE LSP, operators may make use of the security features already defined for RSVP-TE [RFC3209]. This may require some coordination between domains to share keys ([RFC2747][RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with Fast Reroute, since the merge point (MP) and point of local repair (PLR) should also share the key.
ドメイン間のRSVP-TE LSPをシグナル伝えると、演算子はRSVP-TE [RFC3209]ですでに定義されているセキュリティ機能を利用できます。これには、キーを共有するためにドメイン間の調整が必要になる場合があり（[RFC2747] [RFC3097]）、キーが十分に頻繁に変更されるように注意する必要があります。マージポイント（MP）とローカル修理のポイント（PLR）もキーを共有するため、ドメインの境界ノードを高速再ルートで保護する場合、これには追加の同期が含まれる場合があります。
For inter-domain signaling for MPLS-TE, the administrators of neighboring domains must satisfy themselves as to the existence of a suitable trust relationship between the domains. In the absence of such a relationship, the administrators should decide not to deploy inter-domain signaling and should disable RSVP-TE on any inter-domain interfaces.
MPLS-TEのドメイン間シグナル伝達の場合、隣接するドメインの管理者は、ドメイン間の適切な信頼関係の存在に関して自分自身を満たさなければなりません。このような関係がない場合、管理者はドメイン間シグナル伝達を展開しないことを決定する必要があり、ドメイン間インターフェイスでRSVP-TEを無効にする必要があります。
KARP will currently be working only on RSVP-TE, as the native RSVP lies outside the scope of the WG charter.
Karpは現在、ネイティブRSVPがWGチャーターの範囲外にあるため、RSVP-TEでのみ作業しています。
PIM-SM and PIM-DM
PIM-SMおよびPIM-DM
Finally, the multicast protocols Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] and Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] will be grouped together. PIM-SM multicasts routing information (Hello, Join/Prune, Assert) on a link-local basis, using a defined multicast address. In addition, it specifies unicast communication for exchange of information (Register, Register-Stop) between the router closest to a group sender and the "Rendezvous Point". The Rendezvous Point is typically not "on-link" for a particular router. While much work has been done on multicast security for application-layer groups, little has been done to address the problem of managing hundreds or thousands of small one-to-many groups with link-local scope. Such an authentication mechanism should be considered along with the router-to-Rendezvous Point authentication mechanism. The most important issue is ensuring that only the "authorized neighbors" get the keys for source/group (S,G), so that rogue routers cannot participate in the exchanges. Another issue is that some of the communication may occur intra-domain, e.g., the link-local messages in an enterprise, while others for the same (*,G) may occur inter-domain, e.g., the router-to-Rendezvous Point messages may be from one enterprise's router to another.
最後に、マルチキャストプロトコルプロトコル独立マルチキャスト - スパースモード（PIM -SM）[RFC4601]およびプロトコル独立マルチキャスト - 密度モード（PIM -DM）[RFC3973]がグループ化されます。 PIM-SMマルチキャストは、定義されたマルチキャストアドレスを使用して、Link-Localベースで情報（Hello、Join/Prune、Assert）をルーティングします。さらに、グループ送信者に最も近いルーターと「ランデブーポイント」との間の情報交換（レジスタ、レジスタストップ）のユニキャスト通信を指定します。ランデブーポイントは、通常、特定のルーターの「オンリンク」ではありません。アプリケーション層グループのマルチキャストセキュリティに関する多くの作業が行われていますが、リンクローカルスコープを持つ数百または数千の1対多数のグループを管理する問題に対処するためにはほとんど行われていません。このような認証メカニズムは、ルーターからレンダブスポイント認証メカニズムとともに考慮する必要があります。最も重要な問題は、「承認された隣人」のみがソース/グループ（s、g）の鍵を取得して、ローグルーターが交換に参加できないようにすることです。別の問題は、コミュニケーションの一部がドメイン内で発生する可能性があることです。たとえば、エンタープライズのリンクローカルメッセージが発生するのに対し、他の問題（*、g）はドメイン間で発生する可能性があります。メッセージは、あるエンタープライズのルーターから別のエンタープライズまでのものです。
One possible solution proposes a region-wide "master" key server (possibly replicated), and one "local" key server per speaking router. There is no issue with propagating the messages outside the link, because link-local messages, by definition, are not forwarded. This solution is offered only as an example of how work may progress; further discussion should occur in this work team. Specification of a link-local protection mechanism for PIM-SM is defined in [RFC4601], and this mechanism has been updated in PIM-SM-LINKLOCAL [RFC5796]. However, the KMP part is completely unspecified and will require work outside the expertise of the PIM working group to accomplish, another example of why this roadmap is being created.
可能なソリューションの1つは、スピーキングルーターごとに、地域全体の「マスター」キーサーバー（おそらく複製された可能性が高い）と、1つの「ローカル」キーサーバーを提案します。リンクの外側のメッセージの伝播に問題はありません。これは、定義上、リンクローカルメッセージが転送されないためです。このソリューションは、仕事がどのように進行するかの例としてのみ提供されます。この作業チームでは、さらなる議論が行われるはずです。PIM-SMのリンクローカル保護メカニズムの仕様は[RFC4601]で定義されており、このメカニズムはPIM-SM-Linklocal [RFC5796]で更新されています。ただし、KMPパートは完全に特定されておらず、PIMワーキンググループの専門知識以外の作業を達成する必要があります。これは、このロードマップが作成されている理由の別の例です。
It is imperative that the new authentication and security mechanisms defined support incremental deployment, as it is not feasible to deploy a new routing protocol authentication mechanism throughout the network instantaneously. One of the goals of the KARP WG is to add incremental security to existing mechanisms rather than replacing them. Delivering better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. It may also not be possible to deploy such a mechanism to all routers in a large Autonomous System (AS) at one
新しい認証とセキュリティメカニズムが、ネットワーク全体に瞬時に新しいルーティングプロトコル認証メカニズムを展開することが不可能であるため、サポート増分展開を定義することが不可欠です。KARP WGの目標の1つは、既存のメカニズムを置き換えるのではなく、既存のメカニズムにインクリメンタルセキュリティを追加することです。ベンダーとオペレーターが移行できるより良い展開可能なソリューションを提供することは、完璧なセキュリティソリューションを取得するよりも重要です。また、大きな自律システム（AS）でそのようなメカニズムをすべてのルーターに展開することもできない場合があります
time. This means that the designers must work on this aspect of the authentication mechanism for the routing protocol on which they are working. The mechanisms must provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment.
時間。これは、設計者が、機能しているルーティングプロトコルの認証メカニズムのこの側面に取り組む必要があることを意味します。メカニズムは、混合セキュリティ環境を介して伝達されるルーティング情報のメッセージのフォーマット、送信、および処理における後方互換性を提供する必要があります。
DoS attacks must be kept in mind when designing KARP solutions. [THTS-REQS] describes DoS attacks that are in scope for the KARP work. Protocol designers should ensure that the new cryptographic validation mechanisms must not provide an attacker with an opportunity for DoS attacks. Cryptographic validation, while typically cheaper than signing, is still an incremental cost. If an attacker can force a system to validate many packets multiple times, then this could be a potential DoS attack vector. On the other hand, if the authentication procedure is itself quite CPU intensive, then overwhelming the CPU with multiple bogus packets can bring down the system. In this case, the authentication procedure itself aids the DoS attack.
KARPソリューションを設計する際には、DOS攻撃を念頭に置いておく必要があります。[THTS-REQS]は、KARPの仕事の範囲にあるDOS攻撃について説明しています。プロトコル設計者は、新しい暗号化検証メカニズムが攻撃者にDOS攻撃の機会を提供してはならないことを確認する必要があります。暗号化の検証は、通常署名よりも安価ですが、依然として増分コストです。攻撃者がシステムに多くのパケットを複数回検証するように強制できる場合、これは潜在的なDOS攻撃ベクトルになる可能性があります。一方、認証手順自体が非常にCPU集中的である場合、複数の偽のパケットを使用してCPUを圧倒すると、システムを倒すことができます。この場合、認証手順自体がDOS攻撃を支援します。
There are some known techniques to reduce the cryptographic computation load. Packets can include non-cryptographic consistency checks. For example, [RFC5082] provides a mechanism that uses the IP header to limit the attackers that can inject packets that will be subject to cryptographic validation. In the design, Phase 2, once an automated key management protocol is developed, it may be possible to determine the peer IP addresses that are valid participants. Only the packets from the verified sources could be subject to cryptographic validation.
暗号化計算負荷を減らすためのいくつかの既知の手法があります。パケットには、非暗号化の一貫性チェックを含めることができます。たとえば、[RFC5082]は、IPヘッダーを使用して、暗号化検証の対象となるパケットを挿入できる攻撃者を制限するメカニズムを提供します。デザインのフェーズ2では、自動化されたキー管理プロトコルが開発されると、有効な参加者であるピアIPアドレスを決定することが可能になる場合があります。検証済みのソースからのパケットのみが暗号化の検証の対象となります。
Protocol designers must ensure that a device never needs to check incoming protocol packets using multiple keys, as this can overwhelm the CPU, leading to a DoS attack. KARP solutions should indicate the checks that are appropriate prior to performing cryptographic validation. KARP solutions should indicate where information about valid neighbors can be used to limit the scope of the attacks.
プロトコル設計者は、複数のキーを使用してデバイスが着信プロトコルパケットをチェックする必要がないことを確認する必要があります。これにより、CPUが圧倒され、DOS攻撃につながる可能性があります。KARPソリューションは、暗号化の検証を実行する前に適切なチェックを示す必要があります。KARPソリューションは、有効な隣人に関する情報を使用して攻撃の範囲を制限できる場所を示す必要があります。
Particular care needs to be paid to the design of automated key management schemes. It is often desirable to force a party attempting to authenticate to do work and to maintain state until that work is done. That is, the initiator of the authentication should maintain the cost of any state required by the authentication for as long as possible. This also helps when an attacker sends an overwhelming load of keying protocol initiations from bogus sources.
自動化された主要な管理スキームの設計には、特定の注意が必要です。しばしば、仕事を行うことを認証しようとする当事者を強制し、その作業が完了するまで状態を維持することが望ましいです。つまり、認証のイニシエーターは、可能な限り認証に必要な状態のコストを維持する必要があります。これは、攻撃者が偽のソースから圧倒的なキーイングプロトコルの開始を送信する場合にも役立ちます。
Another important class of attack is denial of service against the routing protocol where an attacker can manipulate either the routing protocol or the cryptographic authentication mechanism to disrupt routing adjacencies.
攻撃のもう1つの重要なクラスは、攻撃者がルーティングプロトコルまたは暗号化認証メカニズムを操作してルーティングの隣接を妨害するルーティングプロトコルに対するサービスの拒否です。
Without KARP solutions, many routing protocols are subject to disruption simply by injecting an invalid packet or a packet for the wrong state. Even with cryptographic validation, replay attacks are often a vector where a previously valid packet can be injected to create a denial of service. KARP solutions should prevent all cases where packet replays or other packet injections by an outsider can disrupt routing sessions.
KARPソリューションがなければ、多くのルーティングプロトコルは、単に無効なパケットまたは間違った状態のパケットを注入することにより、混乱の影響を受けます。暗号化の検証を使用しても、リプレイ攻撃は、以前に有効なパケットを注入してサービスの拒否を作成できるベクトルであることがよくあります。KARPソリューションは、部外者によるパケットリプレイまたはその他のパケットインジェクションがルーティングセッションを混乱させる可能性があるすべてのケースを防ぐ必要があります。
Some residual denial-of-service risk is always likely. If an attacker can generate a large enough number of packets, the routing protocol can get disrupted. Even if the routing protocol is not disrupted, the loss rate on a link may rise to a point where claiming that traffic can successfully be routed across the link will be inaccurate.
一部の残存サービス拒否リスクは常に可能性があります。攻撃者が十分な数のパケットを生成できる場合、ルーティングプロトコルが破壊される可能性があります。ルーティングプロトコルが破壊されなくても、リンクの損失率は、リンク全体でトラフィックを正常にルーティングできると主張するポイントに上昇する可能性があります。
The [THTS-REQS] document lists the generic requirements for the security mechanisms that must exist for the various routing protocols that come under the purview of KARP. There will be different design teams working for each of the categories of routing protocols defined.
[THTS-REQS]ドキュメントには、KARPの範囲内にあるさまざまなルーティングプロトコルに存在する必要があるセキュリティメカニズムの一般的な要件がリストされています。定義されたルーティングプロトコルの各カテゴリで、さまざまな設計チームが作業します。
To start, design teams must review the "Threats and Requirements for Authentication of routing protocols" document [THTS-REQS]. This document contains detailed descriptions of the threat analysis for routing protocol authentication and integrity in general. Note that it does not contain all the authentication-related threats for any one routing protocol, or category of routing protocols. The design team must conduct a protocol-specific threat analysis to determine if threats beyond those in the [THTS-REQS] document arise in the context of the protocol (group) and to describe those threats.
開始するには、設計チームは、「ルーティングプロトコルの認証に関する脅威と要件」ドキュメント[THTS-REQS]を確認する必要があります。このドキュメントには、ルーティングプロトコル認証と一般的な整合性に関する脅威分析の詳細な説明が含まれています。1つのルーティングプロトコル、またはルーティングプロトコルのカテゴリのすべての認証関連の脅威は含まれていないことに注意してください。設計チームは、プロトコル固有の脅威分析を実施して、[THTS-REQS]ドキュメントの脅威がプロトコル（グループ）のコンテキストで生じるかどうかを判断し、それらの脅威を説明する必要があります。
The [THTS-REQS] document also contains many security requirements. Each routing protocol design team must walk through each section of the requirements and determine one by one how its protocol either does or does not relate to each requirement.
[THTS-REQS]ドキュメントには、多くのセキュリティ要件も含まれています。各ルーティングプロトコル設計チームは、要件の各セクションを通過し、そのプロトコルが各要件にどのように関連するか、または関連していないかを1つずつ決定する必要があります。
Examples include modern, strong, cryptographic algorithms, with at least one such algorithm listed as a MUST, algorithm agility, secure use of simple PSKs, intra-connection replay protection, inter-connection replay protection, etc.
例には、モダンで強力な暗号化アルゴリズムが含まれます。少なくとも1つのそのようなアルゴリズムは、必須としてリストされています。アルゴリズムの俊敏性、単純なPSKの安全な使用、接続内リプレイ保護、接続間リプレイ保護など。
When doing the gap analysis, we must first identify the elements of each routing protocol that we wish to protect. In case of protocols riding on top of IP, we might want to protect the IP header and the protocol headers, while for those that work on top of TCP, it will be the TCP header and the protocol payload. There is patently value in protecting the IP header and the TCP header if the routing protocols rely on these headers for some information (for example, identifying the neighbor that originated the packet).
ギャップ分析を行うとき、最初に保護したい各ルーティングプロトコルの要素を特定する必要があります。IPの上に乗っているプロトコルの場合、IPヘッダーとプロトコルヘッダーを保護することをお勧めしますが、TCPの上で動作する人にとっては、TCPヘッダーとプロトコルペイロードになります。ルーティングプロトコルがこれらのヘッダーにいくつかの情報を依存している場合、IPヘッダーとTCPヘッダーを保護することには、特許的に価値があります（たとえば、パケットを発信した隣人を識別します）。
Then, there will be a set of cryptography requirements that we might want to look at. For example, there must be at least one set of cryptographic algorithms (MD5, SHA, etc.) or constructions (Hashed MAC (HMAC), etc.) whose use is supported by all implementations and can be safely assumed to be supported by any implementation of the authentication option. The design teams should look for the protocol on which they are working. If such algorithms or constructions are not available, then some should be defined to support interoperability by having a single default.
次に、私たちが見たいと思うかもしれない一連の暗号化要件があります。たとえば、使用はすべての実装によってサポートされており、あらゆる人によってサポートされると安全に想定できる、少なくとも1つの暗号化アルゴリズム（MD5、SHAなど）または構造（ハッシュマック（HMAC）など）のセットが必要です。認証オプションの実装。設計チームは、作業中のプロトコルを探す必要があります。そのようなアルゴリズムまたは構造が利用できない場合、単一のデフォルトを持つことで相互運用性をサポートするために定義する必要があります。
Design teams must ensure that the default cryptographic algorithms and constructions supported by the routing protocols are accepted by the community. This means that the protocols must not rely on non-standard or ad hoc hash functions, keyed-hash constructions, signature schemes, or other functions, and they must use published and standard schemes.
設計チームは、ルーティングプロトコルによってサポートされているデフォルトの暗号化アルゴリズムと構造がコミュニティによって受け入れられることを確認する必要があります。これは、プロトコルが非標準またはアドホックハッシュ機能、キー付きハッシュ構造、署名スキーム、またはその他の機能に依存してはならず、公開されたスキームと標準スキームを使用する必要があることを意味します。
Care should also be taken to ensure that the routing protocol authentication scheme has algorithm agility (i.e., it is capable of supporting algorithms other than its defaults). Ideally, the authentication mechanism should not be affected by packet loss and reordering.
また、ルーティングプロトコル認証スキームにアルゴリズムの俊敏性があることを確認するように注意する必要があります（つまり、デフォルト以外のアルゴリズムをサポートできる）。理想的には、認証メカニズムは、パケットの損失と並べ替えの影響を受けるべきではありません。
Design teams should ensure that their protocol's authentication mechanism is able to accommodate rekeying. This is essential since it is well known that keys must periodically be changed. Also, what the designers must ensure is that this rekeying event should not affect the functioning of the routing protocol. For example, OSPF rekeying requires coordination among the adjacent routers, while IS-IS requires coordination among routers in the entire domain.
設計チームは、プロトコルの認証メカニズムが再キーリングに対応できるようにする必要があります。これは、キーを定期的に変更する必要があることがよく知られているため、不可欠です。また、設計者が確実にしなければならないことは、この再キーキングイベントがルーティングプロトコルの機能に影響しないことです。たとえば、OSPFの再キーイングには隣接するルーター間の調整が必要ですが、IS-ISにはドメイン全体のルーター間の調整が必要です。
If new authentication and security mechanisms are needed, then the design teams must design in such a manner that the routing protocol authentication mechanism remains oblivious to how the keying material is derived. This decouples the authentication mechanism from the key management system that is employed.
新しい認証とセキュリティメカニズムが必要な場合、設計チームは、ルーティングプロトコル認証メカニズムがキーイング材料の導出方法に忘れられないように設計する必要があります。これにより、採用されている主要な管理システムからの認証メカニズムが切り離されます。
Design teams should also note that many routing protocols require prioritized treatment of certain protocol packets and authentication mechanisms should honor this.
設計チームは、多くのルーティングプロトコルには特定のプロトコルパケットの優先順位付け処理が必要であり、認証メカニズムがこれを尊重する必要があることにも注意する必要があります。
Not all routing protocol authentication mechanisms provide support for replay attacks, and the design teams should identify such authentication mechanisms and work on them so that this can get fixed. The design teams must look at the protocols that they are working on and see if packets captured from the previous/stale sessions can be replayed.
すべてのルーティングプロトコル認証メカニズムがリプレイ攻撃のサポートを提供するわけではなく、設計チームはそのような認証メカニズムを特定して、これが修正できるように作業する必要があります。設計チームは、取り組んでいるプロトコルを調べて、以前の/古いセッションからキャプチャされたパケットを再生できるかどうかを確認する必要があります。
What might also influence the design is the rate at which the protocol packets are originated. In case of protocols like BFD, where packets are originated at millisecond intervals, there are some special considerations that must be kept in mind when defining the new authentication and security mechanisms.
また、設計に影響を与える可能性があるのは、プロトコルパケットが発信されるレートです。パケットがミリ秒間隔で発信されるBFDのようなプロトコルの場合、新しい認証とセキュリティのメカニズムを定義する際に留意する必要がある特別な考慮事項がいくつかあります。
The designers should also consider whether the current authentication mechanisms impose considerable processing overhead on a router that's doing authentication. Most currently deployed routers do not have hardware accelerators for cryptographic processing and these operations can impose a significant processing burden under some circumstances. The proposed solutions should be evaluated carefully with regard to the processing burden that they will impose, since deployment may be impeded if network operators perceive that a solution will impose a processing burden which either entails substantial capital expenses or threatens to destabilize the routers.
設計者はまた、現在の認証メカニズムが認証を行っているルーターにかなりの処理オーバーヘッドを課すかどうかを検討する必要があります。現在展開されているルーターのほとんどには、暗号化処理用のハードウェアアクセラレータがなく、これらの操作は、状況によっては重大な処理負荷を課す可能性があります。ネットワークオペレーターがソリューションが実質的な資本費用を伴うか、ルーターを不安定にすることを脅かす処理負担を課すことを認識している場合、展開が課される可能性があるため、提案されたソリューションは、課す処理の負担に関して慎重に評価されるべきです。
As mentioned in the Introduction, RFC 4948 [RFC4948] identifies additional steps needed to achieve the overall goal of improving the security of the core routing infrastructure. Those include validation of route origin announcements, path validation, cleaning up the IRR databases for accuracy, and operational security practices that prevent routers from becoming compromised devices. The KARP work is but one step needed to improve core routing infrastructure.
導入部で述べたように、RFC 4948 [RFC4948]は、コアルーティングインフラストラクチャのセキュリティを改善するという全体的な目標を達成するために必要な追加の手順を特定します。これらには、ルートオリジンの発表の検証、パス検証、精度のためにIRRデータベースのクリーンアップ、およびルーターが侵害されないデバイスにならないようにする運用セキュリティプラクティスが含まれます。KARPの作業は、コアルーティングインフラストラクチャを改善するために必要な1つのステップにすぎません。
The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
暗号化ベースのシステムのセキュリティは、選択された暗号化アルゴリズムの強度と、それらのアルゴリズムで使用されるキーの強度の両方に依存します。セキュリティは、システム全体のセキュリティをバイパスするための非暗号化方法がないことを保証するために、システムで使用されるプロトコルのエンジニアリングにも依存します。
Care should be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.
選択されたキーが予測不可能であることを確認するために注意する必要があります。これは、使用中のアルゴリズムに対して弱いことが知られているキーを避けてください。[RFC4086]には、主要な生成技術と暗号ランダム性の両方に関する有用な情報が含まれています。
Care should also be taken when choosing the length of the key. [RFC3766] provides some additional information on asymmetric and symmetric key sizes and how they relate to system requirements for attack resistance.
キーの長さを選択する際には、注意する必要があります。[RFC3766]は、非対称および対称的なキーサイズと、攻撃抵抗のシステム要件とどのように関連するかに関するいくつかの追加情報を提供します。
In addition to using a key of appropriate length and randomness, deployers of KARP should use different keys between different routing peers whenever operationally possible. This is especially true when the routing protocol takes a static traffic key as opposed to a traffic key derived on a per-connection basis using a KDF. The burden for doing so is understandably much higher than using the same static traffic key across all peering routers. Depending upon the specific KMP, it can be argued that generally using a KMP network-wide increases peer-wise security. Consider an attacker that learns or guesses the traffic key used by two peer routers: if the traffic key is only used between those two routers, then the attacker has only compromised that one connection not the entire network.
適切な長さとランダム性のキーを使用することに加えて、KARPの展開者は、運用的に可能な限り、異なるルーティングピア間で異なるキーを使用する必要があります。これは、KDFを使用して接続ごとに導出されたトラフィックキーとは対照的に、ルーティングプロトコルが静的トラフィックキーを使用する場合に特に当てはまります。そうするための負担は、すべてのピアリングルーターで同じ静的トラフィックキーを使用するよりもはるかに高いです。特定のKMPに応じて、一般にKMPネットワーク全体を使用すると、ピアワイズセキュリティが増加すると主張できます。2つのピアルーターで使用されるトラフィックキーを学習または推測する攻撃者を考えてみましょう。トラフィックキーがこれらの2つのルーターの間でのみ使用される場合、攻撃者はネットワーク全体ではなく1つの接続のみを侵害しました。
However whenever using manual keys, it is best to design a system where a given pre-shared key (PSK) will be used in a KDF mixed with connection-specific material, in order to generate session unique -- and therefore peer-wise -- traffic keys. Doing so has the following advantages: the traffic keys used in the per-message authentication mechanism are peer-wise unique, it provides inter-connection replay protection, and if the per-message authentication mechanism covers some connection counter, intra-connection replay protection.
ただし、手動キーを使用するときはいつでも、特定の事前共有キー（PSK）が接続固有の素材と混合されたKDFで使用されるシステムを設計するのが最適です。 - トラフィックキー。そうすることには、次の利点があります。メッセージごとの認証メカニズムで使用されるトラフィックキーは、ピアごとのユニークであり、接続間リプレイ保護を提供します。。
Note that certain key derivation functions (e.g., KDF_AES_128_CMAC) as used in TCP-AO [RFC5926], the pseudorandom function (PRF) used in the KDF may require a key of a certain fixed size as an input.
TCP-AO [RFC5926]で使用される特定のキー導出関数（例：KDF_AES_128_CMAC）、KDFで使用される擬似ランダム関数（PRF）には、入力として特定の固定サイズのキーが必要になる場合があります。
For example, AES_128_CMAC requires a 128-bit (16-byte) key as the seed. However, for the convenience of the administrators, a specification may not want to require the entry of a PSK be of exactly 16 bytes. Instead, a specification may call for a key prep routine that could handle a variable-length PSK, one that might be less or more than 16 bytes (see [RFC4615], Section 3, as an example). That key prep routine would derive a key of exactly the required length, thus, be suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-800-118]. We simply attempted
たとえば、AES_128_CMACには、シードとして128ビット（16バイト）キーが必要です。ただし、管理者の便利さのために、仕様はPSKの入力を正確に16バイトの侵入を要求したくない場合があります。代わりに、仕様には、16バイト未満または16バイトを超える可能性のある可変長PSKを処理できるキープレップルーチンが必要になる場合があります（例として[RFC4615]、セクション3を参照）。そのキープレップルーチンは、必要な長さの正確なキーを導き出すため、PRFの種として適しています。これは、管理者が弱いキーを安全に使用できることを意味するものではありません。管理者は[RFC4086] [NIST-800-118]に従うことをお勧めします。私たちは単に試みました
to "put a fence around stupidity", as much as possible as it's hard to imagine administrators putting in a password that is, say 16 bytes in length.
「愚かさの周りにフェンスを置く」ために、管理者が長さ16バイトなどのパスワードを入れることを想像するのは困難です。
A better option, from a security perspective, is to use some representation of a device-specific asymmetric key pair as the identity proof, as described in section "Unique versus Shared Keys" section.
セキュリティの観点から、より良いオプションは、セクション「一意と共有キー」セクションで説明されているように、デバイス固有の非対称キーペアの表現をIDの証明として使用することです。
Design teams must consider whether the protocol is an internal routing protocol or an external one, i.e., does it primarily run between peers within a single domain of control or between two different domains of control? Some protocols may be used in both cases, internally and externally, and as such, various modes of authentication operation may be required for the same protocol. While it is preferred that all routing exchanges run with the best security mechanisms enabled in all deployment contexts, this exhortation is greater for those protocols running on inter-domain point-to-point links. It is greatest for those on shared access link layers with several different domains interchanging together, because the volume of attackers are greater from the outside. Note however, that the consequences of internal attacks maybe no less severe -- in fact, they may be quite a bit more severe -- than an external attack. An example of this internal versus external consideration is BGP, which has both EBGP and IBGP modes. Another example is a multicast protocol where the neighbors are sometimes within a domain of control and sometimes at an inter-domain exchange point. In the case of PIM-SM running on an internal multi-access link, it would be acceptable to give up some security to get some convenience by using a group key among the peers on the link. On the other hand, in the case of PIM-SM running over a multi-access link at a public exchange point, operators may favor security over convenience by using unique pair-wise keys for every peer. Designers must consider both modes of operation and ensure the authentication mechanisms fit both.
設計チームは、プロトコルが内部ルーティングプロトコルであるか外部のプロトコルであるかを考慮する必要があります。つまり、主に単一の制御ドメイン内のピア間で、または2つの異なる制御ドメイン間で実行されますか？一部のプロトコルは、内部および外部の両方で使用される場合があり、そのため、同じプロトコルにはさまざまな認証操作が必要になる場合があります。すべてのルーティング交換は、すべての展開コンテキストで有効になっている最高のセキュリティメカニズムで実行されることが推奨されますが、この勧めは、ドメイン間のポイントツーポイントリンクで実行されるプロトコルの方が大きくなります。攻撃者の量が外側から大きいため、共有アクセスリンクレイヤーを使用している人にとっては最大です。ただし、内部攻撃の結果は、外部攻撃よりも、実際にはそれほど深刻ではないかもしれないことに注意してください。この内部と外部の考慮事項の例は、EBGPモードとIBGPモードの両方を備えたBGPです。別の例は、近隣が制御の領域内にあり、時にはドメイン間交換ポイントにあるマルチキャストプロトコルです。内部マルチアクセスリンクでPIM-SMが実行されている場合、リンク上のピアの間でグループキーを使用して、ある程度のセキュリティを放棄することは受け入れられます。一方、PIM-SMがパブリックエクスチェンジポイントでマルチアクセスリンクを越えて実行されている場合、オペレーターはすべてのピアに一意のペアワイズキーを使用することにより、便利なセキュリティを支持する場合があります。設計者は両方の操作モードを考慮し、認証メカニズムが両方に適合するようにする必要があります。
Operators are encouraged to run cryptographic authentication on all their adjacencies, but to work from the outside in, i.e., External BGP (EBGP) links are a higher priority than the Internal BGP (IBGP) links because they are externally facing, and, as a result, more likely to be targeted in an attack.
オペレーターは、すべての隣接で暗号化認証を実行することをお勧めしますが、外部から作業するために、つまり外部BGP（EBGP）リンクは、外部に面しているため、内部BGP（IBGP）リンクよりも優先度が高く、結果、攻撃で標的にされる可能性が高くなります。
This section discusses security considerations regarding when it is appropriate to use the same authentication key inputs for multiple peers and when it is not. This is largely a debate of convenience
このセクションでは、複数のピアに同じ認証キー入力を使用することが適切であることと、そうでない場合に関するセキュリティに関する考慮事項について説明します。これは主に利便性の議論です
versus security. It is often the case that the best secured mechanism is also the least convenient mechanism. For example, an air gap between a host and the network absolutely prevents remote attacks on the host, but having to copy and carry files using the "sneaker net" is quite inconvenient and does not scale.
対セキュリティ。多くの場合、最も安全なメカニズムが最も便利なメカニズムでもあることがあります。たとえば、ホストとネットワークの間のエアギャップは、ホストのリモート攻撃を絶対に防止しますが、「スニーカーネット」を使用してファイルをコピーして持ち運ぶ必要があることは非常に不便であり、拡張しません。
Operators have erred on the side of convenience when it comes to securing routing protocols with cryptographic authentication. Many do not use it at all. Some use it only on external links, but not on internal links. Those that do use it often use the same key for all peers in a network. It is common to see the same key in use for years, e.g., the key was entered when authentication mechanisms were originally configured or when the routing gear was deployed.
オペレーターは、暗号化認証を使用してルーティングプロトコルを保護することに関して、便利な側で誤りを犯しています。多くはそれをまったく使用していません。一部の人は、外部リンクでのみ使用しますが、内部リンクでは使用しません。それを使用するものは、ネットワーク内のすべてのピアに同じキーを使用することがよくあります。同じキーが長年使用されているのが一般的です。たとえば、認証メカニズムが最初に構成されたとき、またはルーティングギアが展開されたときにキーが入力されました。
One goal for designers is to create authentication and integrity mechanisms that are easy for operators to deploy and manage, and still use unique keys between peers (or small groups on multi-access links) and for different sessions among the same peers. Operators have the impression that they NEED one key shared across the network, when, in fact, they do not. What they need is the relative convenience they experience from deploying cryptographic authentication with one key (or a few keys) compared to the inconvenience they would experience if they deployed the same authentication mechanism using unique pair-wise keys. An example is BGP route reflectors. Here, operators often use the same authentication key between each client and the route reflector. The roadmaps defined from this guidance document should allow for unique keys to be used between each client and the peer, without sacrificing much convenience. Designers should strive to deliver peer-wise unique keying mechanisms with similar ease-of-deployment properties as today's one-key method.
デザイナーの目標の1つは、オペレーターが簡単に展開および管理できる認証と整合性のメカニズムを作成し、ピア（またはマルチアクセスリンク上の小グループ）と同じピア間の異なるセッションに対してユニークなキーを使用することです。オペレーターは、実際にはそうでない場合、ネットワーク全体で1つのキーを共有する必要があるという印象を持っています。彼らが必要とするのは、一意のペアワイズキーを使用して同じ認証メカニズムを展開した場合に経験する不便さと比較して、1つのキー（またはいくつかのキー）を使用して暗号化認証を展開することから経験する相対的な利便性です。例は、BGPルートリフレクターです。ここでは、オペレーターはしばしば各クライアントとルートリフレクターの間で同じ認証キーを使用します。このガイダンスドキュメントから定義されたロードマップは、あまり利便性を犠牲にすることなく、各クライアントとピアの間で一意のキーを使用できるようにする必要があります。デザイナーは、今日の1キーの方法と同様の展開の容易さを備えた、仲間のユニークなキーイングメカニズムを提供するよう努力する必要があります。
Operators must understand the consequences of using the same key across many peers. One argument against using the same key is that if the same key that is used in multiple devices, then a compromise of any one of the devices will expose the key. Also, since the same key is supported on many devices, this is known by many people, which affects its distribution to all of the devices.
オペレーターは、多くのピアで同じキーを使用することの結果を理解する必要があります。同じキーを使用することに対する1つの引数は、複数のデバイスで使用されている同じキーの場合、デバイスのいずれかの妥協がキーを公開することです。また、同じキーが多くのデバイスでサポートされているため、これは多くの人々に知られており、すべてのデバイスへの分布に影響します。
Consider also the attack consequence size, the amount of routing adjacencies that can be negatively affected once a breach has occurred, i.e., once the keys have been acquired by the attacker.
また、攻撃の結果サイズ、違反が発生した後に悪影響を受ける可能性のあるルーティングの隣接の量、つまり攻撃者によってキーが取得された後に考えてみてください。
Again, if a shared key is used across the internal domain, then the consequence size is the whole network. Ideally, unique key pairs would be used for each adjacency.
繰り返しますが、共有キーが内部ドメイン全体で使用されている場合、結果サイズはネットワーク全体です。理想的には、各隣接に一意のキーペアが使用されます。
In some cases, use of shared keys is needed because of the problem space. For example, a multicast packet is sent once but then consumed by several routing neighbors. If unique keys were used per neighbor, the benefit of multicast would be erased because the sender would have to create a different announcement packet for each receiver. Though this may be desired and acceptable in some small number of use cases, it is not the norm. Shared (i.e., group) keys are an acceptable solution here, and much work has been done already in this area (by the MSEC working group).
場合によっては、問題のあるスペースのために共有キーの使用が必要です。たとえば、マルチキャストパケットは一度送信されますが、いくつかのルーティングネイバーによって消費されます。近隣ごとに一意のキーが使用された場合、送信者が各レシーバーに対して異なるアナウンスパケットを作成する必要があるため、マルチキャストの利点が消去されます。これは、少数のユースケースで望まれ、受け入れられる場合がありますが、それは標準ではありません。ここでは、共有（つまり、グループ）キーは許容可能なソリューションであり、この分野ではすでに多くの作業が行われています（MSECワーキンググループによって）。
This section discusses the security and use case considerations for key exchange for routing protocols. Two options exist: an out-of-band mechanism or a KMP. An out-of-band mechanism involves operators configuring keys in the device through a configuration tool or management method (e.g., Simple Network Management Protocol (SNMP), Network Configuration Protocol (NETCONF)). A KMP is an automated protocol that exchanges keys without operator intervention. KMPs can occur either in-band to the routing protocol or out-of-band to the routing protocol (i.e., a different protocol).
このセクションでは、ルーティングプロトコルの主要な交換に関するセキュリティとユースケースの考慮事項について説明します。2つのオプションが存在します：帯域外のメカニズムまたはKMP。帯域外のメカニズムには、構成ツールまたは管理方法（単純なネットワーク管理プロトコル（SNMP）、ネットワーク構成プロトコル（NetConf））を介してデバイス内のキーを構成する演算子が含まれます。KMPは、オペレーターの介入なしでキーを交換する自動化されたプロトコルです。KMPは、ルーティングプロトコルにインバンドまたはルーティングプロトコル（つまり、別のプロトコル）に帯域外に発生する可能性があります。
An example of an out-of-band configuration mechanism could be an administrator who makes a remote management connection (e.g., using SSH) to a router and manually enters the keying information, e.g., the algorithm, the key(s), the key lifetimes, etc. Another example could be an OSS system that inputs the same information by using a script over an SSH connection or by pushing configuration through some other management connection, standard (NETCONF-based) or proprietary.
帯域外構成メカニズムの例は、リモート管理接続（SSHを使用するなど）をルーターに手動で作成し、キー情報、たとえばアルゴリズム、キー、キーを手動で入力する管理者である可能性があります。生涯など。別の例は、SSH接続を介したスクリプトを使用して、または他の管理接続、標準（NetConfベース）または専有を介して構成をプッシュすることにより、同じ情報を入力するOSSシステムです。
The drawbacks of an out-of-band configuration mechanism include lack of scalability, complexity, and speed of changing if a security breach is suspected. For example, if an employee who had access to keys was terminated, or if a machine holding those keys was believed to be compromised, then the system would be considered insecure and vulnerable until new keys were generated and distributed. Those keys then need to be placed into the OSS system, and the OSS system then needs to push the new keys -- often during a very limited change window -- into the relevant devices. If there are multiple organizations involved in these connections, because the protected connections are inter-domain, this process is very complicated.
帯域外構成メカニズムの欠点には、セキュリティ侵害が疑われる場合、スケーラビリティ、複雑さ、および変化の速度の欠如が含まれます。たとえば、キーにアクセスできる従業員が終了した場合、またはそれらのキーを保持しているマシンが侵害されていると考えられていた場合、システムは新しいキーが生成され、分布するまで安全で脆弱であると見なされます。その後、これらのキーはOSSシステムに配置する必要があり、OSSシステムは、多くの場合、非常に限られた変更ウィンドウ中に新しいキーを関連するデバイスにプッシュする必要があります。保護された接続がドメイン間であるため、これらの接続に複数の組織が関与している場合、このプロセスは非常に複雑です。
The principle benefit of out-of-band configuration mechanism is that once the new keys/parameters are set in OSS system, they can be pushed automatically to all devices within the OSS's domain.
帯域外構成メカニズムの主な利点は、新しいキー/パラメーターがOSSシステムに設定されると、OSSのドメイン内のすべてのデバイスに自動的にプッシュできることです。
Operators have mechanisms in place for this already for managing other router configuration data. In small environments with few routers, a manual system is not difficult to employ.
オペレーターには、他のルーター構成データを管理するための既にこれのメカニズムがあります。ルーターが少ない小さな環境では、手動システムを使用するのは難しくありません。
We further define a peer-to-peer KMP as using cryptographically protected identity verification, session key negotiation, and security association parameter negotiation between the two routing peers. The KMP among peers may also include the negotiation of parameters, like cryptographic algorithms, cryptographic inputs (e.g., initialization vectors), key lifetimes, etc.
さらに、ピアツーピアKMPを、2つのルーティングピア間の暗号化されたアイデンティティ検証、セッションキーネゴシエーション、セキュリティ協会のパラメーター交渉を使用していると定義します。ピア間のKMPには、暗号化アルゴリズム、暗号化入力（例：初期化ベクトル）、重要な寿命などのパラメーターの交渉も含まれる場合があります。
There are several benefits of a peer-to-peer KMP versus centrally managed and distributing keys. It results in key(s) that are privately generated, and it need not be recorded permanently anywhere. Since the traffic keys used in a particular connection are not a fixed part of a device configuration, no security sensitive data exists anywhere else in the operator's systems that can be stolen, e.g., in the case of a terminated or turned employee. If a server or other data store is stolen or compromised, the thieves gain limited or no access to current traffic keys. They may gain access to key derivation material, like a PSK, but may not be able to access the current traffic keys in use. In this example, these PSKs can be updated in the device configurations (either manually or through an OSS) without bouncing or impacting the existing session at all. In the case of using raw asymmetric keys or certificates, instead of PSKs, the data theft (from the data store) would likely not result in any compromise, as the key pairs would have been generated on the routers and never leave those routers. In such a case, no changes are needed on the routers; the connections will continue to be secure, uncompromised. Additionally, with a KMP, regular rekey operations occur without any operator involvement or oversight. This keeps keys fresh.
ピアツーピアKMPと中央管理および配布キーには、いくつかの利点があります。その結果、個人的に生成されるキーが生成され、どこでも永久に記録する必要はありません。特定の接続で使用されるトラフィックキーはデバイス構成の固定部分ではないため、たとえば、終了または回転した従業員の場合、オペレーターのシステムの他のどこにもセキュリティに敏感なデータは存在しません。サーバーまたはその他のデータストアが盗まれたり侵害されたりすると、泥棒は現在のトラフィックキーに限られているか、アクセスできません。 PSKのようなキー派生材料にアクセスできるかもしれませんが、使用中の現在のトラフィックキーにアクセスできない場合があります。この例では、これらのPSKは、既存のセッションにバウンスしたり影響を与えたりすることなく、デバイス構成（手動またはOSを介して）で更新できます。生の非対称キーまたは証明書を使用する場合、PSKの代わりに、キーペアがルーターで生成され、それらのルーターを離れることはないため、データの盗難は（データストアから）妥協することはないでしょう。そのような場合、ルーターに変更は必要ありません。接続は引き続き安全で、妥協しません。さらに、KMPでは、オペレーターの関与や監視なしに定期的なRekey操作が発生します。これにより、キーが新鮮になります。
There are a few drawbacks to using a KMP. First, a KMP requires more cryptographic processing for the router at the beginning of a connection. This will add some minor start-up time to connection establishment versus a purely manual key management approach. Once a connection with traffic keys has been established via a KMP, the performance is the same in the KMP and the out-of-band configuration case. KMPs also add another layer of protocol and configuration complexity, which can fail or be misconfigured. This was more of an issue when these KMPs were first deployed, but less so as these implementations and operational experience with them have matured.
KMPを使用することにはいくつかの欠点があります。まず、KMPでは、接続の先頭にルーターに対してより多くの暗号化処理が必要です。これにより、純粋に手動の主要な管理アプローチと比較して、接続の確立にマイナーな起動時間が追加されます。KMPを介してトラフィックキーとの接続が確立されると、パフォーマンスはKMPおよび帯域外構成のケースで同じです。KMPはまた、プロトコルと構成の複雑さの別の層を追加します。これは、これらのKMPが最初に展開されたときの問題でしたが、これらの実装と運用の経験が成熟しているため、これはそれほど問題でした。
One of the goals for KARP is to develop a KMP; an out-of-band configuration protocol for key exchange is out of scope.
KARPの目標の1つは、KMPを開発することです。キー交換用の帯域外構成プロトコルは範囲外です。
Within this constraint, there are two approaches for a KMP:
この制約の中で、KMPには2つのアプローチがあります。
The first is to use a KMP that runs independent of the routing and the signaling protocols. It would run on its own port and use its own transport (to avoid interfering with the routing protocol that it is serving). When a routing protocol needs a key, it would contact the local instance of this key management protocol and request a key. The KMP generates a key that is delivered to the routing protocol for it to use for authenticating and integrity verification of the routing protocol packets. This KMP could either be an existing key management protocol such as ISAKMP/IKE, GKMP, etc., extended for the routing protocols, or it could be a new KMP, designed for the routing protocol context.
1つ目は、ルーティングとシグナリングプロトコルから独立して実行されるKMPを使用することです。独自のポートで実行され、独自のトランスポートを使用します（提供しているルーティングプロトコルへの干渉を避けるため）。ルーティングプロトコルにキーが必要な場合、このキー管理プロトコルのローカルインスタンスに連絡し、キーを要求します。KMPは、ルーティングプロトコルに配信されるキーを生成し、ルーティングプロトコルパケットの認証と整合性の検証に使用します。このKMPは、ルーティングプロトコル用に拡張されたISAKMP/IKE、GKMPなどの既存の主要な管理プロトコルであるか、ルーティングプロトコルのコンテキスト向けに設計された新しいKMPである可能性があります。
The second approach is to define an in-band KMP extension for existing routing protocols putting the key management mechanisms inside the protocol itself. In this case, the key management messages would be carried within the routing protocol packets, resulting in very tight coupling between the routing protocols and the key management protocol.
2番目のアプローチは、既存のルーティングプロトコルの帯域内KMP拡張を定義することです。主要な管理メカニズムをプロトコル自体に配置します。この場合、主要な管理メッセージはルーティングプロトコルパケット内で実施され、ルーティングプロトコルと主要な管理プロトコル間の非常に緊密な結合が生じます。
Much of the text for this document came originally from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz.
このドキュメントのテキストの多くは、もともと「ワイヤー上のルーティングプロトコルパケットの暗号化認証のためのロードマップ」から来ました。
We would like to thank Sam Hartman, Eric Rescorla, Russ White, Sean Turner, Stephen Kent, Stephen Farrell, Adrian Farrel, Russ Housley, Michael Barnes, and Vishwas Manral for their comments on the document.
サム・ハートマン、エリック・レスコルラ、ラス・ホワイト、ショーン・ターナー、スティーブン・ケント、スティーブン・ファレル、エイドリアン・ファレル、ラス・ハウズリー、マイケル・バーンズ、ヴィシュワス・マンラルにドキュメントにコメントしてくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日、不要なトラフィックに関するIABワークショップの報告」、RFC 4948、2007年8月。
[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-I-ISの使用」、RFC 1195、1990年12月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B.、ed。、およびD. Meyer、ed。、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、BCP 86、RFC 3766、2004年4月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230] Tschofenig、H。およびR. Graveman、「RSVPセキュリティプロパティ」、RFC 4230、2005年12月。
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonen、T。およびC. Lonvick、ed。、「The Secure Shell（SSH）認証プロトコル」、RFC 4252、2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、ed。、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。
[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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、 "楕円曲線暗号化（ECC）輸送層セキュリティ（TLS）の暗号スイート"、RFC 4492、2006年5月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (- AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4615] Song、J.、Poovendran、R.、Lee、J。、およびT. Iwata、「高度な暗号化標準サイファーベースのメッセージ認証コード-Pseudo-Random function-128（-aes-cmac-prf-）128）インターネットキーエクスチェンジプロトコル（IKE）のアルゴリズム "、RFC 4615、2006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5796] Atwood、W.、Islam、S。、およびM. Siami、「プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージの認証と機密性」、RFC 5796、2010年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、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、「TCP認証オプション」、RFC 5925、2010年6月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926] Lebovitz、G。およびE. Rescorla、「TCP認証オプションの暗号化アルゴリズム（TCP-AO）」、RFC 5926、2010年6月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「ルーティングプロトコルの既存の暗号保護方法の問題」、RFC 6039、2010年10月。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6407] Weis、B.、Rowles、S。、およびT. Hardjono、「解釈のグループ領域」、RFC 6407、2011年10月。
[THTS-REQS] Lebovitz, G., "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", Work in Progress, June 2011.
[Thts-reqs] Lebovitz、G。、「ルーティングプロトコル「トランスポート」の暗号化認証の脅威分析と要件」、2011年6月、進行中の作業。
[CRPT-TAB] Housley, R. and Polk, T., "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2011
[Crpt-Tab] Housley、R。and Polk、T。、「長寿命の対称的な暗号化キーのデータベース」、2011年10月の作業
[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
[GDOI-MAC] Weis、B。およびS. Rowles、「GDOI Genericメッセージ認証コードポリシー」、2011年9月、Work in Progress。
[IRR] Merit Network Inc , "Internet Routing Registry Routing Assets Database", 2006, http://www.irr.net/.
[IRR] Merit Network Inc、「インターネットルーティングレジストリルーティングアセットデータベース」、2006、http：//www.irr.net/。
[NIST-800-57] US National Institute of Standards & Technology, "Recommendation for Key Management Part 1: General (Revised)", March 2007
[NIST-800-57]米国国立標準技術研究所、「主要な管理パート1：一般（改訂）」、2007年3月
[NIST-800-118] US National Institute of Standards & Technology, "Guide to Enterprise Password Management (Draft)", April 2009
[NIST-800-118]米国国立標準技術研究所、「エンタープライズパスワード管理ガイド（ドラフト）」、2009年4月
Authors' Addresses
著者のアドレス
Gregory M. Lebovitz Aptos, California USA 95003
Gregory M. Lebovitz Aptos、California USA 95003
EMail: gregory.ietf@gmail.com
Manav Bhatia Alcatel-Lucent Bangalore India
Manav Bhatia Alcatel-Lucent Bangalore India
EMail: manav.bhatia@alcatel-lucent.com