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
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.
この文書では、ルーティングプロトコルのメッセージ認証のための現代の暗号メカニズムとアルゴリズムの使用のためのプロトコル仕様作業のロードマップを定義することに関する一連の一つです。特に、それは、メッセージ認証及び完全性のためのセッションキーを作成および管理するために使用することができる鍵管理プロトコルのためのフレームワークを定義します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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項は、「簡単なリスク分析は、最小限のコストの理想的な攻撃対象が、最大の混乱は、コアルーティングインフラストラクチャであることを示唆している」と述べています。セクション「コアルーティングインフラストラクチャのセキュリティをightening [T]」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ワーキンググループで対処されています。第二弾がIRRのグローバルを実行しているものとリエゾンを通じて対処する必要があります。第三弾は、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".
この文書では、ルーティングシステムで使用される情報について話をし、「ワイヤ上」の用語を使用しています。この用語は、RFCで広く使用されているが、いくつかの異なる方法で使用されています。この文書では、ルーティング・プロトコル・インスタンス間で、また、特定の状況で保護する必要があるかもしれない基本的なプロトコルに交換される情報の両方を指すために使用されます。個々のプロトコルを分析する他の文書は、彼らが「ワイヤ上の」という用語を使用する方法を指示する必要があります。
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:
キーイングおよびルーティングプロトコル（カープ）の認証は、ルーティングプロトコル、オペレータ、および自動化された鍵管理との間のインターフェースを記述する情報をキーイングするための抽象化に焦点を当てます。概念的には、ルーティングプロトコルがメッセージを送信または受信するとき、彼らはこの抽象キーテーブルに使用するキーを検索します。概念的には、それが使用されている自動化された鍵管理の要求を行うために、ルーティングプロトコルのためのインタフェースがあるでしょう。キーが利用可能になったとき、彼らはキーテーブルで利用できるようになります。この抽象化を実装するために使用する必要はありません。抽象化は、標準化と管理のニーズに対応しています。具体的には、カープの作業計画の一環として：
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）カープは、他の層における鍵テーブル抽象化、鍵管理プロトコルとルーティングプロトコルの間のインタフェース、およびおそらくセキュリティプロトコルを設計します。
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）各ルーティングプロトコルの場合、カープは、プロトコルは、鍵材料およびプロトコルに依存しないキーテーブル抽象化を表す方法の間のマッピングを定義します。ルーティングプロトコルは、認証のための共通の機構を共有する場合、そのような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.
読者は明確な範囲の定義、目標、非目標、カープ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.
この文書では、認証のための彼らの要求に応じて二つのカテゴリーにルーティングプロトコルを配置します。私たちは、これらのカテゴリは、設計チームは、特定のカテゴリのセキュリティ・メカニズムに集中できるよう願っています。さらに、当社は、グループ内の各プロトコルは、認証機構を再利用できるようになることを願っています。また、作業が簡単にさまざまなルーティングプロトコルのグループで使用するために活用することができるように道を、私たちは、カテゴリごとに鍵管理プロトコル（KMP）（そうでない場合は、いくつかのカテゴリのための）を作成することができ、ことが期待されています。 KMPsは基本プロトコルで使用されるトラフィックキーの簡単な、自動更新を可能にするために有用です。 KMPsは、定期的に実行しているシステム上のキーを交換する人間、あるいは運用支援システム（OSS）ルーチンの必要性を、交換してください。それはまた、選択された、またはそのようなシステム上で設定されるマニュアルのキーチェーンの必要性を除去します。適切に設定すると、KMPは、キーの有効期間を追跡し、定義された間隔で新しいキーを交渉することによってピア間のキー鮮度ポリシーを適用します。
The first category defines three types of messaging transactions used on the wire by the base routing protocol. They are as follows:
最初のカテゴリは、基本ルーティングプロトコルによってワイヤ上で使用されるメッセージング・トランザクションの三種類を定義します。それらは次の通りです：
One-to-One
一対一の
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
一対多
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].
それが作成され、複数のピアのために意図されている1つのルート更新メッセージを送信するように - リンクローカルで、すなわち、 - 単一のネットワークセグメント上の他の複数のルータと、ルータピア。例としては、OSPFとその放送、非ポイントツーポイントモードおよびルーティング情報プロトコル（RIP）でIS-IS [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.
カープワーキンググループで生産プロトコルセキュリティ分析ドキュメントは、両方の通信のセマンティクスとメッセージ交換のために使用されている技術に注意を払う必要があります。
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、一意のキー付きセキュリティアソシエーション（SA）はつのルータ（例えば、BGP、BFDとLDP）との間に確立されるように、唯一つの他のルータにキーイングメッセージを送信します。
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].
一つのルータは、複数のピアに単一キーイングメッセージを作成し、配布しています。この場合、グループSAは、同時に複数のピア間で確立され、使用されるであろう。グループキーは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.
それはカープ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の）鍵ID）で表すことができる、キーの有効期間（いずれかバイトまたは秒）、暗号化アルゴリズムが使用されて、キー自体、およびキーの方向（すなわち、送信キーに対して受信）。
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鍵は112ビット対称鍵[RFC3766]に80ビットの対称鍵と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文字の-人間が読める、譲渡の形式の文字列を超える強力なハッシュのような単純なことができます。より複雑なだけでなく、より安全な、身元証明が（例えば、証明書失効リスト（CRL）またはオンライン証明書状態プロトコル（OCSP）レスポンダー）、PKIシステムの失効チェックメカニズムを使用して検証することができます。 SHA-1指紋が使用される場合、溶液は、テーブルに隣接ルータのピアIDの文字列のセットをロードし、各ID列に関連付けられた指紋列をリストのように単純であってもよいです。ほとんどの組織やピアリングポイントでは、このリストは千かそこらのルーターよりも長くないだろう、と多くの場合、リストはかなり短くなります。つまり、与えられた組織のルータ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.
暗号鍵は、限られた寿命を有するべきであり、それらへのアクセスを持っていたオペレータが離れたときに変更する必要があります。 、キーチェーン、同じ鍵素材由来とキーのセットを次々に使用使用して1は、まだすべてのこれらのキーへのアクセス権を持つオペレータが離れたときに、キーチェーンにすべてのキーを変更することがあるとしても助けにはなりません会社。さらに、キーチェーンは、ルーティング、トランスポートサブシステムは、ルーティングセッションと隣接関係をバウンスすることなく、新しいキーにロールオーバーサポートしていない場合は助けにはなりません。だから、最初のステップは、ルーティングプロトコルは、隣接関係を壊すか、バウンスせずにキーを変更することができるように、ルーティングスタックを修正することです。
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.
長寿命のキーに対するもう一つの脅威は、鍵を格納方式の一つ、またはキーを委託ユーザーのいずれかが、覆されることです。鍵を変更する暗号動機は存在しないかもしれないがそう、キーを転がすためのシステムのセキュリティの動機がある可能性があります。
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.
増分の展開のために、我々は、sendとの生活時間を関連付けることによって開始することができますし、長寿命のキーのキーチェーンにキーを受け取ります。これは、個々のセッションのための暗号化キーイングマテリアルは、[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 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.
任意のルーティングプロトコルのためのセキュリティを改善する二相プロセスであると考えられます。最初のフェーズでは、近代的な暗号化アルゴリズムとキー俊敏性をサポートするために、ルーティングプロトコルを変更することであろう。第二段階は、設計し、自動化された鍵管理機構に移動することです。これは、クロール、散歩、実行プロセスのようなものです。事業者はこれらのフェーズを受け入れるようにするために、我々は、鍵管理プロトコルが明確にルーティング輸送から分離されるべきであると信じています。これは、ルーティング、トランスポートサブシステムは、キーが、派生交換し、限り、それは使用することができます何かがあるようにダウンロードされているかを忘れていることを意味します。それは、書かれ維持され、セキュリティの専門家によって操作さいくつかのモジュールを参照して、ルーティング交換にこれらのパラメータを挿入することができるように、「カープセキュリティパラメータ」のセキュリティモジュールを要求するルーティング・プロトコル設定スイッチを有するようなものです。
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.
カープの仕事のための所望の最終状態は、いくつかの項目が含まれています。まず、展開することを望む人々が安全に認証され、ルーティングピア間の整合性検証済みのパケットはツールは、指定された実装、および展開するために出荷されています。これらのツールは、オペレータが既に慣れているにセキュリティメカニズムよりも複雑を実装していないためにかなり簡単でなければなりません。 （ルータオペレータが慣れているために、セキュリティ・メカニズムの例には、ルータの設定、BGP保護、自己署名証明書を使用するためのTCP MD5で事前共有キーを使用する（PSKs）のSSHでの認証のために非対称鍵の使用HTTPのためのセキュア（HTTPS）デバイスのWebベースのユーザインターフェースへのアクセス、ユーザー識別のための強力構築パスワードおよび/またはアイデンティティトークンの使用ルータと管理システムにログインする。）我々が指定する予定のツールができないかもしれないが彼らの全体のルーティングドメイン間ですべてのデバイス用の入力キーとして「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.
手動鍵を使用して上記端状態を達成することは非常に小規模な展開に実用的であってもよいです。しかし、大規模な展開で手動キーは、オペレータのためにあまりにも負担になります。このように、第二の目標は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 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.
1.ルーティングプロトコルの現在の認証メカニズム（複数可）を高めます。この作品は、その既存の鍵管理フレームワーク内のセキュリティ機能の一貫性のある、近代的なレベルを達成するために、ルーティングプロトコルの現在のセキュリティ・メカニズムの強化が含まれます。既存の鍵管理フレームワークは、主に手動キーに基づいていることを理解して受け入れられています。多くのオペレータは、すでにこれらの手動キーの実装の周りの運用支援システム（OSS）を構築しているので、基礎となるメカニズムは、安全な自分自身をしている場合、オペレータは、そのように活用するために利用可能ないくつかの自動化があります。この段階では、我々は、明示的に埋め込むまたは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.自動化された鍵管理フレームワークを開発します。第二相は、容易にするために、自動化されたキーフレームワークの開発に焦点を当てるユニークなペアワイズ（グループ単位、該当する場合）のインスタンスをピアリングあたりキー。これはKMPの使用を含みます。自動鍵管理機構の使用は、手動キー入力を超える多くの利点を提供しています。最も重要なこと、それは、このように相互接続リプレイ攻撃を防ぐために貢献し、各セッションのための材料をキーイング新鮮なトラフィックを提供します。相互接続リプレイ攻撃では、以前のプロトコルセッションからプロトコルパケットは、プロトコルの現在の実行に影響を与える再生されます。それは、管理者の関与なしに、ユニークな、対に、ランダムキーを交渉するためKMPも便利です。したがって、異種の機能と構成のエンドポイント間の相互運用性を提供し、安全な接続のために必要なアルゴリズム、モード、およびパラメータのようないくつかのSAパラメータをネゴシエートします。さらに、それはまた、キーの有効期間の交渉を含めることができます。 KMPは、このようにカウンタを使用して、それらの寿命を追跡することができ、彼らは再び、期限が切れる前に管理者の操作なしで、新しいキーとパラメータを交渉することができます。また、違反があった場合には、KMPキーを変更すると、すぐに再入力がトラフィックキーのために発生します、そして、それらの新しいトラフィックキーがインストールされ、現在の接続に使用されます。要約すると、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:
各ルーティングプロトコルは、チームを有することになる（Routing_Protocol - カープチーム、例えば、OSPF-カープチーム）増分作業ルーティングプロトコルのセキュリティを向上させることができます。これらのチームは、主に以下の作業項目を持つことになります。
PHASE 1:
PHASE 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.
KMPsのための要件を確認します。この特定のルーティングプロトコルのニーズと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は、ワイヤ上のパケットのルーティングプロトコルのセッション鍵を生成できるようにするための設計と文書作業を生成します。これらは、ルーティングプロトコルのためのセッションキーをブートストラップするために、KMPのAPIに渡される引数になります。
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のピアリングのメッセージのカテゴリに分類され、ピアキーイングプロトコルを使用します。ボーダーゲートウェイプロトコル（BGP）[RFC4271]、経路計算要素通信プロトコル（PCEP）[RFC5440]、および[RFC3618]メッセージは、TCPを介して送信されては、Multicast Source Discovery Protocol（MSDP）ラベル配布プロトコル（LDP）[RFC5036]使用しているがUDPとTCPの両方。チームはこれらのTCPのユニキャストプロトコルをカバーするために一つのメカニズムで動作します。その既存の認証メカニズムのためのルーティングプロトコルのアップデートの作業の多くは、すでに、TCP-AO [RFC5925]ドキュメントに、TCPMワーキンググループで発生しているだけでなく、その暗号ヘルパー文書、TCP-AO-CRYPTO [RFC5926] 。しかし、TCP-AOは、それらのUDP上で実行されているとして、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.
（一対多ピアリングで）カテゴリグループキーイングに分類ルーティングプロトコルがOSPF [RFC2328]、[RFC1195]はIS-ISと[RFC2453] RIP含みます。驚くことではないが、これらすべてのルーティングプロトコルは、一般的な2つの他のものを持っています。まず、彼らは、レイヤ3ならびにレイヤ2で指定されたルーティングプロトコルがどのように動作するかのコンポーネントを、持っていることを我々は意味これによりOSIデータリンクレイヤ2、およびOSIネットワークレイヤ3の組み合わせ上で実行されています。第二に、それらはすべて、内部ゲートウェイプロトコル（のIGP）です。キーイングのメカニズムは、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.
リソース予約プロトコル（RSVP）[RFC2205]、[RFC2747]で指定されるように、RSVP隣人のホップバイホップ認証を可能にします。このモードでは、保全オブジェクトは、キー付きメッセージダイジェストを送信するために各RSVPメッセージに添付されています。このメッセージダイジェストは、受信者がメッセージを送ったRSVPノードの身元を確認するために、メッセージの整合性を検証することができます。ダイジェストの範囲内のシーケンス番号を含めることによって、ダイジェストもリプレイ保護を提供しています。
[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ノード信託は、明示的メッセージを介してのみ、そのRSVP次ホップピアはINTEGRITYオブジェクト[RFC2747]に含まれるダイジェスト。ネクストホップ
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）[RFC6407]を介して配信[GDOI-MAC]）。
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プロトコルの拡張です。これは、利用可能な帯域幅と明示ホップとして考慮ネットワーク制約パラメータを考慮して、（LSPの）IPネットワーク上のリソースの予約をサポートし、MPLSラベルスイッチパスを確立するために使用されます。 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.
ネイティブ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マルチキャスト定義されたマルチキャストアドレスを使用して、リンクローカルベースで（こんにちは、/プルーン、アサートに参加）。また、グループの送信者に最も近いルータと「ランデブーポイント」との間の情報交換（登録、登録・ストップ）のためのユニキャスト通信を指定します。ランデブーポイントは、特定のルータのための「オンリンク」は、典型的ではありません。多くの仕事は、アプリケーション層のグループのためのマルチキャストセキュリティで行われてきたが、少しは、リンクローカルスコープで小さな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.
一つの可能な解決策は、地域全体の「マスター」キーサーバ（おそらく複製さ）、およびルータを話すごとに「ローカル」キーサーバーを提案しています。リンクローカルメッセージは、定義により、転送されませんので、リンク外のメッセージを伝播して何の問題もありません。このソリューションは、唯一の作業が進行することが方法の例として提供されています。さらなる議論は、この作業チーム内で起こらなければなりません。 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 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.
瞬時にネットワーク全体の新しいルーティングプロトコルの認証メカニズムを展開することは不可能であると定義された新しい認証およびセキュリティメカニズムは、増分展開をサポートすることが不可欠です。カープWGの目標の一つは、むしろそれらを交換するよりも、既存のメカニズムに増分セキュリティを追加することです。ベンダーや事業者が移行することができたに優れた展開可能なソリューションを提供することは、完璧なセキュリティソリューションを取得するよりも重要です。また、一度に大きな自律システム（AS）内のすべてのルータに、このような機構を展開することが可能ではないかもしれません。これは、設計者は、彼らが作業しているルーティングプロトコルの認証メカニズムのこの局面に働かなければならないことを意味します。機構は、後方メッセージフォーマットに互換性、送信、および混合セキュリティ環境を介して搬送される情報のルーティングの処理を提供しなければなりません。
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.
カープ・ソリューションを設計する際にDoS攻撃を念頭に置いておく必要があります。 [THTS-REQS]はカープ作業の範囲内にある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.
プロトコル設計者は、これはDoS攻撃につながる、CPUを圧倒できるような装置は、複数のキーを使用して、着信プロトコルパケットをチェックする必要がないことを確認する必要があります。カープソリューションは、従来の暗号化検証を行うに適切なチェックを示すべきです。有効なネイバーに関する情報は、攻撃の範囲を限定するために使用できる場所カープソリューションが示す必要があります。
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.
攻撃のもう一つの重要なクラスは、攻撃者がルーティングプロトコルやルーティングの隣接関係を破壊する暗号認証メカニズムのいずれかを操作することができ、ルーティングプロトコルに対するサービス拒否です。
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.
カープのソリューションがなければ、多くのルーティングプロトコルは、単純に、無効なパケットまたは間違った状態のためのパケットを注入することによって、混乱の対象となっています。でも、暗号化の検証で、リプレイ攻撃は、多くの場合、以前に有効なパケットがサービス拒否を作成するために注入することができるベクトルです。カープのソリューションは、部外者によるパケットリプレイや他のパケット注射はルーティングセッションを中断させることができ、すべてのケースを防ぐ必要があります。
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]文書は、カープの範囲の下に来るさまざまなルーティングプロトコルのために存在しなければならないセキュリティ・メカニズムのための一般的な要件を示します。定義されたルーティングプロトコルのカテゴリのそれぞれのために働い異なる設計チームがあります。
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]を確認する必要があります。この文書は、一般的には、プロトコルの認証と完全性をルーティングするための脅威分析の詳細な説明が含まれています。それは、ルーティングプロトコルのいずれかのルーティングプロトコル、またはカテゴリのすべての認証関連の脅威が含まれていないことに注意してください。設計チームは、[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]文書はまた、多くのセキュリティ要件が含まれています。各ルーティングプロトコルの設計チームは、要件の各セクションをウォークスルーし、そのプロトコルがないか、各要件に関係しないかどのように一つ一つを決定する必要があります。
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つのこのようなアルゴリズム、アルゴリズムの俊敏性、シンプルPSKsイントラ接続リプレイ保護、相互接続リプレイ保護などの安全な使用と
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の上に乗ったプロトコルの場合には、我々は、TCP上で動作するもののために、それはTCPヘッダとプロトコルペイロードになりながら、IPヘッダおよびプロトコルヘッダを保護することをお勧めします。ルーティングプロトコルは、いくつかの情報については、これらのヘッダに依存している場合（例えば、パケットを発信したネイバーを識別する）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.
その後、私たちは見たいかもしれない暗号化要件のセットがあるでしょう。例えば、使用するすべての実装によってサポートされており、安全にいずれかによってサポートされると仮定することができる暗号化アルゴリズム（MD5、SHA等）または構造（等ハッシュMAC（HMAC））の少なくとも1つの組が存在しなければなりません認証オプションの実装。設計チームは、彼らが作業しているプロトコルを探す必要があります。そのようなアルゴリズムや構造が利用できない場合は、いくつかは、単一のデフォルトを持っていることによって、相互運用性をサポートするために定義する必要があります。
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.
デザインチームは、プロトコルの認証メカニズムは、鍵の変更に対応することが可能であることを確認する必要があります。キーは定期的に変更しなければならないことはよく知られているので、これは必要不可欠です。また、どのような設計者が保証しなければならないことは、このキーの再発行イベントは、ルーティングプロトコルの機能に影響を与えるべきではないということです。 IS-ISは、ドメイン全体のルータ間の調整を必要とする、例えば、OSPFのリキーは、隣接ルータ間の調整を必要とします。
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データベースをクリーンアップし、妥協のデバイスになってからルータを防ぐ運用セキュリティ対策が含まれています。カープの仕事は、コアルーティングインフラストラクチャを改善するために必要な一歩に過ぎません。
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.
いつでも運用可能な適切な長さとランダム性の鍵を使用することに加えて、カープのデプロイヤは異なるルーティングピア間で異なる鍵を使用する必要があります。ルーティングプロトコルは、KDFを使用して接続ごとに由来トラフィックキーとは対照的に、静的なトラフィックキーをとる場合、これは特に真実です。そうするための負担は当然のことながら、すべてのピアリングルータで同じ静的なトラフィックキーを使用するよりもはるかに高いです。特定のKMPによっては、一般的にピア・ワイズセキュリティをKMPネットワーク全体の増加を使用していることを主張することができます。 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に使用される擬似ランダム関数（PRF）は、入力として、特定の固定サイズの鍵を必要とするかもしれない特定の鍵導出関数（例えば、KDF_AES_128_CMAC）ことに留意されたいです。
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バイト）の鍵を必要とします。ただし、管理者の便宜のため、仕様は正確に16バイトであることPSKの入力を要求したくないかもしれません。その代わりに、仕様は以下又は16以上のバイトであるかもしれない可変長PSK、いずれかを処理できる鍵準備ルーチンを要求してもよい（例として、第3、[RFC4615]参照）。その鍵準備ルーチンは、このように、正確に必要な長さの鍵を導出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.
より良いオプションは、セキュリティの観点からは、「ユニーク共有鍵対」のセクションで説明したように、身分証として、デバイス固有の非対称鍵ペアのいくつかの表現を使用することです。
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つの異なるドメイン間でピア間で実行しない、プロトコルは内部のルーティングプロトコルまたは外部の1であるかどうかを検討しなければなりませんか？いくつかのプロトコルは、内部と外部の両方の場合に使用することができる、そのようなものとして、認証動作の様々なモードは、同じプロトコルのために必要とされてもよいです。それはすべてのルーティング交換はすべてのデプロイメント・コンテキストで有効になって最高のセキュリティメカニズムを実行することが好ましいが、この勧告は、ドメイン間のポイントツーポイントリンク上で実行されているこれらのプロトコルのために大きいです。攻撃者のボリュームが外部から大きいので、一緒に交換いくつかの異なるドメインと共有アクセスリンク層上でそれらのために最大です。内部からの攻撃の影響が多分に劣らず深刻なことに、しかし注意してください - 実際に、彼らはかなりより厳しいかもしれ - 外部からの攻撃よりも。外部考慮対この内部の一例は、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つのキー（または少数のキー）で暗号認証を展開から体験相対便利です。例は、BGPルートリフレクタです。ここで、オペレータは、多くの場合、各クライアントおよびルートリフレクタとの間に同じ認証キーを使用します。このガイダンス文書から定義されたロードマップには、多くの利便性を犠牲にすることなく、各クライアントとピア間で使用するユニークなキーを可能にすべきです。設計者は、今日のワンキー方式と同様の使いやすさの展開特性を持つピアごとのユニークなキーイングメカニズムを提供するために努力すべきです。
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.
オペレータは、多くのピアで同じキーを使用しての結果を理解しなければなりません。同じキーを使用してに対する一つの引数は、複数のデバイスで使用されている同じキー場合は、デバイスのいずれかの妥協がキーを公開するということです。同じ鍵が多くのデバイスでサポートされるので、これはすべてのデバイスにその分布に影響を与える、多くの人々によって知られています。
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).
このセクションでは、ルーティングプロトコルのための鍵交換のためのセキュリティとユースケース考慮事項について説明します。二つの選択肢が存在する：アウトオブバンド機構やKMPを。アウトオブバンドメカニズムは、構成ツールまたは管理方法（例えば、簡易ネットワーク管理プロトコル（SNMP）、ネットワーク構成プロトコル（NETCONF））を介してデバイスのキーを構成する演算子を含みます。 KMPは、オペレータの介入なしで鍵を交換し自動化するプロトコルです。 KMPsは、インバンドルーティングプロトコルまたはアウトオブバンドルーティングプロトコル（すなわち、異なるプロトコル）のいずれかで起こり得ます。
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.
私たちは、さらに2つのルーティングピア間で暗号で保護本人確認、セッションキーのネゴシエーション、およびセキュリティアソシエーションパラメータのネゴシエーションを使用してピア・ツー・ピアKMPを定義します。ピア間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のように、鍵導出材料へのアクセスを得ることができるが、使用中の現在のトラフィックキーにアクセスすることができない場合があります。この例では、これらPSKsは、バウンス、またはまったく既存のセッションに影響を与えることなく、デバイス構成（手動またはOSSを介して）で更新することができます。キーペアがルータで生成され、それらのルータを離れることはないされていたであろうと、生の非対称鍵や証明書、代わりのPSKsを使用する場合には、（データストアから）データの盗難はおそらく、一切の妥協をもたらさないであろう。このような場合には、変更はルータで必要とされません。接続は、妥協のない、安全であることを継続します。また、KMPで、定期的な再入力操作は、任意のオペレータの関与や監督なしに起こります。これは、新鮮なキーを保持します。
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とアウトオブバンドの構成の場合も同じです。 KMPsも失敗又は誤って設定可能なプロトコルおよび構成の複雑さの別の層を追加します。これらの実装と彼らと運用経験が成熟しているので、これはそれほどこれらKMPsが最初に配備された問題のよりだったが、。
One of the goals for KARP is to develop a KMP; an out-of-band configuration protocol for key exchange is out of scope.
カープのための目標の一つは、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.
最初は、ルーティングおよびシグナリングプロトコルとは無関係に実行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.
この文書のテキストの多くは、グレゴリー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.
私たちは、ドキュメントの彼らのコメントのためにサム・ハートマン、エリックレスコラ、ラスホワイト、ショーン・ターナー、スティーブン・ケント、スティーブン・ファレル、エードリアンファレル、ラスHousley、マイケル・バーンズ、およびVishwas Manralに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]アンデション、L.、デイヴィス、E.、およびL.チャン、 "不要なトラフィック月9-10、2006年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.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]マルキン、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]ベーカー、F.、リンデル、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]ブレーデン、R.とL.チャン、 "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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]フェナー、B.、エド。、およびD.マイヤー、エド。、 "は、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]オーマン、H.、およびP.ホフマン、 "対称鍵を交換するために使用公開鍵の強さを測定"、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]アダムス、A.、ニコラス、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]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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、エド。、 "セキュアシェル（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、エド。、 "セキュアシェル（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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]ブレイク・ウィルソン、S.、Bolyard、N.、グプタ、V.、ホーク、C.、およびB.メラー、 "楕円曲線暗号（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]フェナー、B.、ハンドリー、M.、ホルブルック、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]ソング、J.、Poovendran、R.、リー、J.、およびT.岩田、「高度暗号化標準暗号ベースのメッセージ認証コード、擬似ランダム関数-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]ファレル、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]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、エド。、および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]ファレル、A.編、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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。、編、およびJL。ル・ルー、エド。、 "パス計算要素（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]は、RFC 5796、2010年3月アトウッド、W.、イスラム教、S.、およびM. Siami、 "プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージでの認証と機密性"。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]カッツ、D.およびD.区、 "双方向フォワーディング検出（BFD）"、RFC 5880、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、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.レスコラ、RFC 5926、2010年6月 "TCP認証オプション（TCP-AO）の暗号化アルゴリズム"。
[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.、バティア、M.、Jaeggli、J.、およびR.ホワイト、 "ルーティングプロトコルのための既存の暗号化保護方法の問題"、RFC 6039、2010年10月。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6407]ヴァイス、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.とポーク、T.、 "長寿命の対称暗号鍵のデータベース"、進歩、2011年10月での作業
[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
[GDOI-MAC]ヴァイス、B.とS. Rowles、 "GDOIジェネリックメッセージ認証コード政策"、進歩、2011年9月での作業。
[IRR] Merit Network Inc , "Internet Routing Registry Routing Assets Database", 2006, http://www.irr.net/.
[IRR]メリットネットワーク株式会社、「インターネットルーティングレジストリルーティング資産データベース」、2006年、http://www.irr.net/。
[NIST-800-57] US National Institute of Standards & Technology, "Recommendation for Key Management Part 1: General (Revised)", March 2007
、2007年3月：[NIST-800-57]規格と技術の米国国立研究所、「一般（改訂）キー管理パート1のための勧告」
[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
グレゴリーM. Lebovitzアプトス、カリフォルニアUSA 95003
EMail: gregory.ietf@gmail.com
メールアドレス：gregory.ietf@gmail.com
Manav Bhatia Alcatel-Lucent Bangalore India
Manavバティアアルカテル・ルーセントバンガロールインド
EMail: manav.bhatia@alcatel-lucent.com
メールアドレス：manav.bhatia@alcatel-lucent.com