[要約] 要約：RFC 6862は、ルーティングプロトコルのキー交換と認証に関する情報を提供し、セキュリティの脅威と要件を明確にします。 目的：ルーティングプロトコルのセキュリティを向上させ、キー交換と認証のためのベストプラクティスを提供すること。
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6862
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
B. Weis
Cisco Systems
March 2013
Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
ルーティングプロトコルのキーイングと認証（KARP）の概要、脅威、および要件
Abstract
概要
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.
ルーティングプロトコルが異なれば、ネットワーク上のプロトコルパケットを保護するためのメカニズムも異なります。ほとんどの場合、暗号化メッセージ認証を実行するためのいくつかの方法がすでにありますが、多くの場合、既存の方法は古くなっており、攻撃に対して脆弱であり、廃止された暗号化アルゴリズムを採用しています。 「ルーティングプロトコルのキーイングと認証」（KARP）の取り組みは、これらのメカニズムの見直しと改善を目的としています。このドキュメントにはプロトコル仕様は含まれていません。代わりに、プロトコル仕様の作業が必要な領域を定義します。このドキュメントは、RFC 6518「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドライン」の関連ドキュメントです。一緒になって、KARP設計チームがルーティングプロトコルトランスポートセキュリティの確認とオーバーホールに使用するガイダンスと指示を形成します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6862.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6862で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. KARP Effort Overview . . . . . . . . . . . . . . . . . . . . . 7
2.1. KARP Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Incremental Approach . . . . . . . . . . . . . . . . . . . 8
2.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Threat Sources . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. OUTSIDERS . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Unauthorized Key Holder . . . . . . . . . . . . . . . 14
3.1.2.1. Terminated Employee . . . . . . . . . . . . . . . 15
3.1.3. BYZANTINE . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Threat Actions In Scope . . . . . . . . . . . . . . . . . 16
3.3. Threat Actions Out of Scope . . . . . . . . . . . . . . . 17
4. Requirements for KARP Work Phase 1: Update to a Routing
Protocol's Existing Transport Security . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic "Unwanted Internet Traffic". The report from that workshop is documented in [RFC4948]. Section 8.1 of that document states, "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）は、「不要なインターネットトラフィック」というトピックに関するワークショップを開催しました。そのワークショップからの報告は[RFC4948]に文書化されています。そのドキュメントのセクション8.1は、「単純なリスク分析は、コストが最小であり、中断が最大の理想的な攻撃ターゲットがコアルーティングインフラストラクチャであることを示唆します」と述べています。セクション8.2では、「コアルーティングインフラストラクチャのセキュリティを強化する」ことが求められています。その引き締めのために4つの主要なステップが確認されました。
o Create secure mechanisms and practices for operating routers.
o ルーターを操作するための安全なメカニズムとプラクティスを作成します。
o Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access to it, so that it can be used for routing verification.
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 other efforts within the IETF. For example, BGP message content validity is being addressed in the SIDR working group.
最初の箇条書きは、OPSECワーキンググループで対処されています。 2番目の弾丸は、IRRをグローバルに運営している関係者との連絡を通じて対処する必要があります。 3番目の箇条書きは、IETF内の他の取り組みで対処されています。たとえば、BGPメッセージコンテンツの有効性は、SIDRワーキンググループで対処されています。
This document addresses the last item in the list above, securing the transmission of routing protocol packets on the wire. More precisely, it focuses on securing the transport systems employed by routing protocols, including any mechanisms built into the protocols themselves to authenticate packets. This effort is referred to as Keying and Authentication for Routing Protocols, or "KARP". KARP is concerned with issues and techniques for protecting the messages between directly communicating peers. This type of protection may overlap with, but is strongly distinct from, protection designed to ensure that routing information is properly authorized relative to the source of the information. Such assurances are provided by other mechanisms and are outside the scope of this document.
このドキュメントでは、上記のリストの最後の項目を取り上げ、ワイヤ上でのルーティングプロトコルパケットの送信を保護します。より正確には、パケットを認証するためにプロトコル自体に組み込まれたメカニズムを含む、ルーティングプロトコルによって使用されるトランスポートシステムのセキュリティ保護に焦点を当てています。この取り組みは、ルーティングプロトコルのキーイングおよび認証、または「KARP」と呼ばれます。 KARPは、直接通信するピア間のメッセージを保護するための問題と手法に関係しています。このタイプの保護は、ルーティング情報が情報のソースに対して適切に承認されるように設計された保護と重複する場合がありますが、大きく異なります。このような保証は他のメカニズムによって提供され、このドキュメントの範囲外です。
This document is one of two that together form the guidance and instructions for KARP design teams working to overhaul routing protocol transport security. The other document is the KARP Design Guide [RFC6518].
このドキュメントは、ルーティングプロトコルトランスポートセキュリティのオーバーホールに取り組んでいるKARP設計チームのためのガイダンスと指示を形成する2つの1つです。もう1つのドキュメントはKARP設計ガイド[RFC6518]です。
This document does not contain protocol specifications. Instead, its goal is to define the areas where protocol specification work is needed and to provide a set of requirements for KARP design teams to follow as they update a routing protocol's existing transport security (see Work Phase 1 in Section 4.1 of [RFC6518]).
このドキュメントにはプロトコル仕様は含まれていません。代わりに、プロトコルの仕様作業が必要な領域を定義し、ルーティングプロトコルの既存のトランスポートセキュリティを更新する際にKARP設計チームが従う一連の要件を提供することが目的です（[RFC6518]のセクション4.1の作業フェーズ1を参照）。 。
This document has three main parts. The first part, found in Section 2, provides an overview of the KARP effort. The second part, in Section 3, lists the threats from "Generic Threats To Routing Protocols" [RFC4593] that are in scope for per-packet authentication for routing protocol transport systems. Therefore, this document does not contain a complete threat model; it simply points to the parts of the governing threat model that KARP design teams must address and explicitly states which parts are out of scope for KARP design teams. The third part, in Section 4, enumerates the requirements that routing protocol specifications must meet when addressing the threats related to KARP's Work Phase 1, the update to a routing protocol's existing transport security. ("Work Phase 2", a framework and usage of a Key Management Protocol (KMP), will be addressed in a future document[s]).
このドキュメントには3つの主要な部分があります。セクション2にある最初の部分では、KARPの取り組みの概要を説明します。セクション3の2番目の部分は、ルーティングプロトコルトランスポートシステムのパケットごとの認証の対象となる「ルーティングプロトコルへの一般的な脅威」[RFC4593]からの脅威を示しています。したがって、このドキュメントには完全な脅威モデルは含まれていません。 KARP設計チームが対処しなければならない統治脅威モデルの部分を単に指し示し、KARP設計チームの範囲外である部分を明示的に述べます。セクション4の3番目の部分では、ルーティングプロトコルの既存のトランスポートセキュリティの更新であるKARPの作業フェーズ1に関連する脅威に対処するときにルーティングプロトコルの仕様が満たす必要がある要件を列挙します。 （「作業フェーズ2」、キー管理プロトコル（KMP）のフレームワークと使用法については、今後のドキュメントで取り上げます）。
This document uses the terminology "on the wire" to refer to the information used by routing protocols' transport 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. Individual protocol analysis documents will need to be more specific in their use of this phrase.
このドキュメントでは、ルーティングプロトコルのトランスポートシステムで使用される情報を参照するために、「ネットワーク上」という用語を使用しています。この用語はRFCで広く使用されていますが、いくつかの異なる方法で使用されています。このドキュメントでは、ルーティングプロトコルインスタンス間で交換される情報と、特定の状況で保護する必要がある可能性のある基礎となるプロトコルの両方を指すために使用されます。個々のプロトコル分析ドキュメントは、このフレーズの使用においてより具体的である必要があります。
Additionally, within the scope of this document, the following words, when beginning with a capital letter, or spelled in all capital letters, hold the meanings described in this section. If the same word is used uncapitalized, then it is intended to have its common English definition.
さらに、このドキュメントの範囲内で、次の単語は、大文字で始まる場合、またはすべて大文字で綴られている場合、このセクションで説明されている意味を持ちます。同じ単語が大文字で使用されていない場合、その英語の一般的な定義を意図しています。
Identifier The type and value used by a peer of an authenticated message exchange to signify who it is to another peer. The Identifier is used by the receiver as an index into a table containing further information about the peer that is required to continue processing the message, for example a Security Association (SA) or keys.
Identifier認証されたメッセージ交換のピアが別のピアに対してだれであるかを示すために使用するタイプと値。識別子は、セキュリティアソシエーション（SA）やキーなど、メッセージの処理を続行するために必要なピアに関する詳細情報を含むテーブルへのインデックスとして、受信者によって使用されます。
Identity Authentication Once the identity is verified, there must be a cryptographic proof of that identity, to ensure that the peer really is who it asserts to be. Proof of identity can be arranged among peers in a few ways, for example, symmetric and asymmetric pre-shared keys, or an asymmetric key contained in a certificate. Certificates can be used in ways that require no additional supporting systems external to the routers themselves. An example of this is using self-signed certificates and a flat file list of "approved thumbprints". The different identity verification mechanisms vary in ease of deployment, ease of ongoing management, startup effort, security strength, and consequences from loss of secrets from one part of the system to the rest of the system. For example, they differ in resistance to a security breach, and the effort required to recover in the event of such a breach. The point here is that there are options, many of which are quite simple to employ and deploy.
アイデンティティー認証アイデンティティーが検証されたら、そのアイデンティティーの暗号化された証明がなければなりません。これにより、ピアが実際に主張するとおりの人物であることが保証されます。 IDの証明は、ピア間でいくつかの方法で調整できます。たとえば、対称および非対称の事前共有キー、または証明書に含まれる非対称キーです。証明書は、ルーター自体の外部にある追加のサポートシステムを必要としない方法で使用できます。この例は、自己署名証明書と「承認済みの拇印」のフラットファイルリストを使用することです。 ID検証メカニズムの違いは、展開の容易さ、継続的な管理の容易さ、起動時の作業、セキュリティの強さ、システムの一部からシステムの残りの部分への秘密の喪失による影響などです。たとえば、セキュリティ違反に対する耐性と、そのような違反が発生した場合に回復するために必要な労力は異なります。ここで重要なのは、オプションがあり、その多くは使用および導入が非常に簡単なことです。
KDF (Key Derivation Function) A KDF is a function in which an input key and other input data are used to generate keying material that can be employed by cryptographic algorithms. The key that is input to a KDF is called a key derivation key. KDFs can be used to generate one or more keys from (i) a random or pseudorandom seed value, or (ii) the result of the Diffie-Hellman exchange, or (iii) a non-uniform random source (e.g., from a non-deterministic random bit generator), or (iv) a pre-shared key that may or may not be memorable by a human.
KDF（Key Derivation Function）KDFは、入力アルゴリズムとその他の入力データを使用して、暗号アルゴリズムで使用できるキー生成情報を生成する機能です。 KDFに入力されるキーは、キー派生キーと呼ばれます。 KDFを使用して、（i）ランダムまたは疑似ランダムシード値、または（ii）Diffie-Hellman交換の結果、または（iii）不均一なランダムソース（たとえば、非-決定論的ランダムビットジェネレータ）、または（iv）人間が覚えやすいかどうかに関係なく、事前共有キー。
KMP (Key Management Protocol) KMP is a protocol that establishes a shared symmetric key between a pair (or among a group) of users. It determines how secret keys are made available to the users, and in some cases also determines how the secret keys are generated. In some routing protocols, the routing protocol derives the traffic keys from a master key. In this case, KMP is responsible for the master-key generation and for determining when the master key should be renewed. In other cases, there are only traffic keys (and no master key); in such a case, KMP is responsible for the traffic key generation and renewal mechanism.
KMP（キー管理プロトコル）KMPは、ユーザーのペア間（またはグループ間）の共有対称キーを確立するプロトコルです。ユーザーが秘密鍵を使用できるようにする方法を決定し、場合によっては、秘密鍵を生成する方法も決定します。一部のルーティングプロトコルでは、ルーティングプロトコルはマスターキーからトラフィックキーを取得します。この場合、KMPはマスターキーの生成と、マスターキーをいつ更新するかを決定します。他の場合では、トラフィックキーのみがあります（マスターキーはありません）。このような場合、KMPはトラフィックキーの生成と更新メカニズムを担当します。
KMP Function Any KMP used in the general KARP solution framework.
KMP関数一般的なKARPソリューションフレームワークで使用されるKMP。
Peer Key Peer keys are keys that are used among peers as a basis for identifying one another. These keys may or may not be connection specific, depending on how they were established, and what forms of identity and identity authentication mechanism are used in the system. A peer key generally would be provided by a KMP and would later be used to derive fresh traffic keys.
ピアキーピアキーは、ピアを相互に識別するための基礎としてピア間で使用されるキーです。これらのキーは、それらがどのように確立されたか、およびシステムで使用されるIDとID認証メカニズムの形式に応じて、接続固有である場合とそうでない場合があります。ピアキーは一般にKMPによって提供され、後で新しいトラフィックキーを導出するために使用されます。
PSK (Pre-Shared Key) A PSK is a key used to communicate with one or more peers in a secure configuration. It is always distributed out of band prior to a first connection.
PSK（事前共有キー）PSKは、安全な構成で1つ以上のピアと通信するために使用されるキーです。最初の接続の前に、常に帯域外で配布されます。
Replayed Messages Replayed messages are genuine messages that have been re-sent by an attacker. Messages may be replayed within a session (i.e., intra-session) or replayed from a different session (i.e., inter-session). For non-TCP-based protocols like OSPF [RFC2328] and IS-IS [RFC1195], two routers are said to have a session up if they are able to exchange protocol packets (i.e., the peers have an adjacency). Messages replayed during an adjacency are intra-session replays, while a message replayed between two peers who re-establish an adjacency after a reboot or loss of connectivity are inter-session replays.
リプレイメッセージリプレイメッセージは、攻撃者によって再送信された本物のメッセージです。メッセージは、セッション内（つまり、セッション内）で再生されるか、別のセッション（つまり、セッション間）から再生されます。 OSPF [RFC2328]やIS-IS [RFC1195]のような非TCPベースのプロトコルの場合、2つのルーターがプロトコルパケットを交換できる場合（つまり、ピアに隣接関係がある場合）、セッションはアップしていると言われます。隣接の間に再生されるメッセージはセッション内の再生ですが、再起動または接続の喪失後に隣接を再確立する2つのピア間で再生されるメッセージは、セッション間の再生です。
Routing Protocol This term refers to a Routing Protocol on which a KARP team is working to improve the security of its packets on the wire.
ルーティングプロトコルこの用語は、KARPチームがネットワーク上のパケットのセキュリティを向上させるために取り組んでいるルーティングプロトコルを指します。
SA (Security Association) An SA is a relationship established between two or more entities to enable them to protect the data they exchange. Examples of attributes that may be associated with an SA include Identifier, PSK, Traffic Key, cryptographic algorithms, and key lifetimes.
SA（セキュリティアソシエーション）SAは、2つ以上のエンティティ間で確立される関係であり、エンティティが交換するデータを保護できるようにします。 SAに関連付けることができる属性の例には、識別子、PSK、トラフィックキー、暗号化アルゴリズム、およびキーの有効期間が含まれます。
Threat Source A threat source is a motivated, capable adversary.
脅威源脅威源は、やる気があり、有能な敵です。
Traffic Key A Traffic Key is the key (or one of a set of keys) used for protecting the routing protocol traffic. A traffic key should not be a fixed value in a device configuration. A traffic key should be known only to the participants in a connection, so that a compromise of a stored key (possibly available to a terminated or turned employee) does not result in disclosure of traffic keys. If a server or other data store is stolen or compromised, the attackers gain no access to current traffic keys. They may gain access to key-derivation material, like a PSK, but not traffic keys currently in use.
トラフィックキートラフィックキーは、ルーティングプロトコルトラフィックを保護するために使用されるキー（またはキーセットの1つ）です。トラフィックキーは、デバイス構成で固定値であってはなりません。トラフィックキーは、接続の参加者だけが知っている必要があります。そのため、保存されたキーの侵害（終了または変更された従業員が利用できる可能性があります）によってトラフィックキーが漏洩することはありません。サーバーまたはその他のデータストアが盗難または侵害された場合、攻撃者は現在のトラフィックキーにアクセスできません。彼らはPSKのような鍵導出資料にアクセスできますが、現在使用されているトラフィック鍵にはアクセスできません。
Additional terminology specific to threats are listed and defined below in Section 3.
脅威に固有の追加の用語は、以下のセクション3にリストされ、定義されています。
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]で説明されているように解釈されます。
When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC 2119.
小文字で使用する場合、これらの単語は一般的な言語での一般的な使用法を示しており、RFC 2119で説明されているように解釈されません。
Three basic principles can be used to secure any piece of data as it is transmitted over the wire: confidentiality, authenticity, and integrity. The focus for the KARP working group will be message authentication and message integrity only. At this time, this work explicitly excludes confidentiality. Non-repudiation is also excluded as a goal at this time. Since the objective of most routing protocols is to broadly advertise the routing topology, routing protocol packets are commonly sent in the clear; confidentiality is not normally required for routing protocols. However, ensuring that routing peers are authentically identified and that no rogue peers or unauthenticated packets can compromise the stability of the routing environment are critical and thus in scope. Confidentiality and non-repudiation may be addressed in future work.
3つの基本原則を使用して、データがネットワーク経由で送信されるときにデータのセキュリティを保護できます。機密性、信頼性、および整合性です。 KARPワーキンググループの焦点は、メッセージ認証とメッセージ整合性のみです。現時点では、この作業では機密性が明示的に除外されています。現在、否認防止も目標として除外されています。ほとんどのルーティングプロトコルの目的はルーティングトポロジを広くアドバタイズすることなので、ルーティングプロトコルパケットは通常、クリアテキストで送信されます。ルーティングプロトコルでは通常、機密性は必要ありません。ただし、ルーティングピアが確実に識別され、不正なピアや認証されていないパケットがルーティング環境の安定性を損なう可能性がないことを確認することは重要であり、範囲内です。機密性と否認防止は、今後の作業で対処される可能性があります。
OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP [RFC2453] [RFC4822] already incorporate mechanisms for cryptographically authenticating and integrity checking the messages on the wire. Products and code that incorporate these mechanisms have been produced and have been optimized for these existing security mechanisms. Rather than turn away from these mechanisms, this document aims to enhance them, updating them to modern and more secure levels.
OSPF [RFC5709]、IS-IS [RFC5310]、LDP [RFC5036]、およびRIP [RFC2453] [RFC4822]には、暗号化された認証と回線上のメッセージの整合性チェックのメカニズムがすでに組み込まれています。これらのメカニズムを組み込んだ製品とコードが作成され、これらの既存のセキュリティメカニズム用に最適化されています。このドキュメントは、これらのメカニズムを回避するのではなく、それらを強化し、最新のより安全なレベルに更新することを目的としています。
Therefore, the scope of KARP's roadmap of work includes:
したがって、KARPの作業ロードマップの範囲には次のものが含まれます。
o Making use of existing routing protocol transport security mechanisms, where they have been specified, and enhancing or updating them as necessary for modern cryptographic best practices. [RFC6518], Section 4.1 labels this KARP's Work Phase 1.
o 指定されている既存のルーティングプロトコルトランスポートセキュリティメカニズムを利用し、最新の暗号化のベストプラクティスのために必要に応じてそれらを拡張または更新します。 [RFC6518]のセクション4.1は、このKARPの作業フェーズ1を示しています。
o Developing a framework for using automatic key management in order to ease deployment, lower cost of operation, and allow for rapid responses to security breaches. [RFC6518], Section 4.1 labels this KARP's Work Phase 2.
o 展開を容易にし、運用コストを削減し、セキュリティ違反への迅速な対応を可能にするために、自動キー管理を使用するためのフレームワークを開発します。 [RFC6518]のセクション4.1は、このKARPの作業フェーズ2にラベルを付けています。
o Specifying an automated key management protocol that may be combined with Routing Protocol mechanisms. [RFC6518], Section 4.1 labels this KARP's Work Phase 2.
o ルーティングプロトコルメカニズムと組み合わせることができる自動キー管理プロトコルを指定する。 [RFC6518]のセクション4.1は、このKARPの作業フェーズ2にラベルを付けています。
Neither this document nor [RFC6518] contains protocol specifications. Instead, they define the areas in which protocol specification work is needed, and they set a direction, a set of requirements, and priorities for addressing that specification work.
このドキュメントにも[RFC6518]にもプロトコル仕様は含まれていません。代わりに、プロトコル仕様の作業が必要な領域を定義し、その仕様作業に取り組むための方向、要件のセット、および優先順位を設定します。
There are a set of threats to routing protocols that are considered in scope for KARP, and a set considered out of scope. These are described in detail in Section 3.
ルーティングプロトコルに対する一連の脅威には、KARPのスコープ内と見なされているものと、スコープ外と見なされているものがあります。これらについては、セクション3で詳しく説明します。
This document serves as an agreement between the Routing Area and the Security Area about the priorities and work plan for incrementally delivering the work described in the KARP roadmap above. The principle of "crawl, walk, run" will be employed. Thus routing protocol authentication mechanisms may not go immediately from their current state to a state reflecting the best possible, most modern security practices. This point is important as there will be times when the best security possible will give way to security that is vastly improved over current security but that is admittedly not the best security possible, in order that incremental progress toward a more secure Internet may be achieved. As such, this document will call out places where agreement has been reached on such trade-offs.
このドキュメントは、上記のKARPロードマップで説明されている作業を段階的に提供するための優先順位と作業計画について、ルーティングエリアとセキュリティエリアの間の合意として機能します。 「這う、歩く、走る」の原則を採用します。したがって、ルーティングプロトコル認証メカニズムは、現在の状態から、可能な限り最高の最新のセキュリティプラクティスを反映した状態にすぐには移行しない場合があります。この点は重要です。可能な限り最高のセキュリティが、現在のセキュリティより大幅に改善されたセキュリティに取って代わる場合がありますが、より安全なインターネットへの段階的な進歩を実現するために、可能な最高のセキュリティではありません。そのため、このドキュメントでは、そのようなトレードオフについて合意に達した場所を示します。
Incremental steps will need to be taken for a few very practical reasons. First, there are a considerable number of deployed routing devices in operating networks that will not be able to run the most modern cryptographic mechanisms without significant and unacceptable performance penalties. The roadmap for any routing protocol MUST allow for incremental improvements on existing operational devices. Second, current routing protocol performance on deployed devices has been achieved over the last 20 years through extensive tuning of software and hardware elements, and is a constant focus for improvement by vendors and operators alike. The introduction of new security mechanisms affects this performance balance. The performance impact of any incremental security improvement will need to be weighed by the community and introduced in such a way that allows the vendor and operator community a path to adoption that upholds reasonable performance metrics. Therefore, certain specification elements may be introduced carrying the "SHOULD" guidance, with the intention that the same mechanism will carry a "MUST" in a future release of the specification. This approach gives the vendors and implementors the guidance they need to tune their software and hardware appropriately over time. Last, some security mechanisms require the build-out of other operational support systems, which will take time.
いくつかの非常に実用的な理由から、段階的なステップを踏む必要があります。第1に、動作中のネットワークにはかなりの数のルーティングデバイスが配備されており、これらのデバイスは最新の暗号化メカニズムを実行できず、パフォーマンスが大幅に低下します。ルーティングプロトコルのロードマップでは、既存の運用デバイスの段階的な改善を可能にする必要があります。第2に、展開されたデバイスの現在のルーティングプロトコルパフォーマンスは、ソフトウェアおよびハードウェア要素の広範なチューニングを通じて過去20年間で達成されており、ベンダーとオペレーターの両方が常に改善に焦点を当てています。新しいセキュリティメカニズムの導入は、このパフォーマンスバランスに影響を与えます。増分セキュリティの改善によるパフォーマンスへの影響は、コミュニティによって評価され、ベンダーおよびオペレーターコミュニティが妥当なパフォーマンスメトリックを維持する採用への道を可能にするような方法で導入される必要があります。したがって、仕様の将来のリリースでは同じメカニズムに「必須」が含まれることを意図して、特定の仕様要素が「SHOULD」ガイダンスとともに導入される可能性があります。このアプローチにより、ベンダーと実装者は、ソフトウェアとハードウェアを長期にわたって適切に調整するために必要なガイダンスを得ることができます。最後に、一部のセキュリティメカニズムでは、他の運用サポートシステムを構築する必要があり、これには時間がかかります。
An example where these three steps were at play in an incremental improvement roadmap was the improvement of BGP's [RFC4271] security via the TCP Authentication Option (TCP-AO) [RFC5925] effort. It would have been ideal, and would have reflected best common security practice, to have a fully specified key management protocol for negotiating the TCP-AO keying material, e.g., using certificates for peer authentication. However, in the spirit of incremental deployment, the IETF first addressed issues like cryptographic algorithm agility, replay attacks, and the resetting of TCP sessions in the base TCP-AO protocol, and then later began work to layer key management on top of these.
これら3つのステップが段階的な改善のロードマップで機能した例は、TCP認証オプション（TCP-AO）[RFC5925]によるBGPの[RFC4271]セキュリティの改善でした。ピア認証に証明書を使用するなど、TCP-AOキーイングマテリアルをネゴシエートするための完全に指定されたキー管理プロトコルを持つことが理想的であり、最も一般的なセキュリティ慣行を反映しているはずです。ただし、段階的な展開の精神で、IETFは最初に暗号化アルゴリズムの俊敏性、リプレイ攻撃、および基本TCP-AOプロトコルでのTCPセッションのリセットなどの問題に対処し、その後、これらの上にキー管理を階層化する作業を開始しました。
The goals and general guidance for the KARP work follow:
KARP作業の目標と一般的なガイダンスは次のとおりです。
1. Provide authentication and integrity protection for messages on the wire for existing routing protocols.
1. 既存のルーティングプロトコルのネットワーク上のメッセージに認証と整合性保護を提供します。
2. Define a path to incrementally improve security of the routing infrastructure as explained in Section 2.2.
2. セクション2.2で説明されているように、ルーティングインフラストラクチャのセキュリティを段階的に改善するためのパスを定義します。
3. Ensure that the improved security solutions are deployable on current routing infrastructure. This requires consideration of the current state of processing power available on routers in the network today.
3. 改善されたセキュリティソリューションが現在のルーティングインフラストラクチャに展開可能であることを確認します。これには、今日のネットワーク内のルーターで利用可能な処理能力の現在の状態を考慮する必要があります。
4. Operational deployability - A solution's acceptability also will be measured by how deployable the solution is by operator teams, with consideration for their deployment processes and infrastructures. Specifically, KARP design teams will try to make these solutions fit as well as possible into current operational practices and router deployment methodologies. Doing so will depend heavily on operator input during KARP design efforts. Hopefully, operator input will lead to a more deployable solution, which will, in turn, lead to more production deployments. Deployment of incrementally more secure routing infrastructure in the Internet is the final measure of success. We would like to see an increase in the number of respondents to surveys such as [ISR2008] to report deployment of the updated authentication and integrity mechanisms in their networks, as well as see a sharp rise in usage of these mechanisms across a greater percentage of their network's routers.
4. 運用展開可能性-ソリューションの受け入れ可能性も、展開プロセスとインフラストラクチャを考慮して、オペレーターチームによるソリューションの展開可能性によって測定されます。具体的には、KARP設計チームは、これらのソリューションを可能な限り現在の運用方法とルーターの展開方法に適合させるよう努めます。そうすることは、KARP設計作業中のオペレーター入力に大きく依存します。うまくいけば、オペレーターの入力がより展開可能なソリューションにつながり、それが今度はより多くの運用展開につながります。インターネットでの段階的により安全なルーティングインフラストラクチャの展開は、成功の最終的な尺度です。更新された認証および整合性メカニズムのネットワークへの展開を報告するための[ISR2008]などの調査への回答者数の増加を確認するとともに、これらのメカニズムの使用率が彼らのネットワークのルーター。
Interviews with operators show several points about routing security. First, according to [ISR2008], over 70% of operators have deployed transport connection protection via TCP MD5 [RFC3562] on their External Border Gateway Protocol (eBGP) sessions. Over 55% also deploy TCP MD5 on their Internal Border Gateway Protocol (iBGP) connections, and 50% make use of TCP MD5 offered on some other internal gateway protocol (IGP). The same survey states that "a considerable increase was observed over previous editions of the survey for use of TCP MD5 with external peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs." Though the data is not captured in the report, the authors believe anecdotally that of those who have deployed TCP MD5 somewhere in their network, only about 25-30% of the routers in their network are deployed with the authentication enabled. None report using IPsec [RFC4301] to protect the routing protocol, which was a decline from the few that reported doing so in the previous year's report. Anecdotal evidence from operators using MD5 shows that almost all report using one manually distributed key throughout the entire network. These same operators report that the single key has not been changed since it was originally installed, sometimes five or more years ago. When asked why, particularly for the case of protecting BGP sessions using TCP MD5, the following reasons were often given:
オペレーターへのインタビューは、ルーティングのセキュリティに関するいくつかのポイントを示しています。まず、[ISR2008]によれば、70％を超えるオペレーターが、外部ボーダーゲートウェイプロトコル（eBGP）セッションでTCP MD5 [RFC3562]を介したトランスポート接続保護を展開しています。 55％以上が内部境界ゲートウェイプロトコル（iBGP）接続にTCP MD5を展開し、50％が他の内部ゲートウェイプロトコル（IGP）で提供されるTCP MD5を利用しています。同じ調査では、「外部ピア（eBGP）、内部ピア（iBGP）、およびIGPのMD5拡張でのTCP MD5の使用について、以前のエディションの調査と比べてかなりの増加が観察された」と述べています。レポートにはデータは含まれていませんが、TCP MD5をネットワーク内のどこかに展開している人たちの事例では、認証が有効になっているネットワーク内のルーターの約25〜30％しか展開されていません。ルーティングプロトコルを保護するためにIPsec [RFC4301]を使用した報告はありません。これは、昨年の報告でそうしたと報告した少数の報告からの減少でした。 MD5を使用しているオペレーターの事例証拠は、ほぼすべてのレポートが、ネットワーク全体に1つの手動で配布されたキーを使用していることを示しています。これらの同じオペレーターは、単一のキーが最初にインストールされてから変更されていないことを報告しています。5年以上前の場合もあります。理由を尋ねられたとき、特にTCP MD5を使用してBGPセッションを保護する場合について、次の理由がよく示されました。
A. Changing the keys triggers a TCP reset, and thus the links/ adjacencies bounce, undermining Service Level Agreements (SLAs).
A.キーを変更すると、TCPリセットがトリガーされ、リンク/隣接がバウンスし、サービスレベルアグリーメント（SLA）が損なわれます。
B. For external peers, it is difficult to coordinate with the other organization, and in practice the coordination is very cumbersome and tedious to execute. Once the operator finds the correct contact at the other organization (not always so easy), the coordination function is serialized and performed on a per-peer or per-AS basis.
B.外部のピアにとって、他の組織と調整することは困難であり、実際には調整は非常に面倒で面倒です。オペレーターが他の組織で正しい連絡先を見つけると（常にそれほど簡単ではない）、調整機能がシリアル化され、ピアごとまたはASごとに実行されます。
C. Keys must be changed at precisely the same time, or at least within 60 seconds (as supported by two major vendors) in order to limit the duration of a connectivity outage. This is incredibly difficult to do, operationally, especially between different organizations.
C.接続の停止期間を制限するために、キーは正確に同時に、または少なくとも60秒以内に（2つの主要ベンダーによってサポートされているように）変更する必要があります。これは、運用上、特に異なる組織間で行うのが非常に困難です。
D. Key change is perceived as a relatively low priority compared to other operational issues.
D.主要な変更は、他の運用上の問題と比較して比較的低い優先度として認識されています。
E. Staff levels are insufficient to implement the changes on a device-by-device basis.
E.スタッフレベルは、デバイスごとに変更を実装するには不十分です。
F. There are three use cases for operational peering at play: peers and interconnection with other operators, iBGP and other routing sessions within a single operator, and operator-to-customer devices. All three have very different properties, and all are reported as cumbersome to manage securely. One operator reported that the same key is used for all customer premise equipment (CPE). The same operator reported that if the customer mandated it, a unique key could be created, although the last time this occurred, it created such an operational headache that the administrators now usually tell customers that the option doesn't even exist, to avoid the difficulties. These customer-unique keys are never changed, unless the customer demands so. The main threat here is that a terminated employee from such an operator who had access to the one (or several) keys used for authentication in these environments could wage an attack. Alternatively, the operator could offer the keys to others who would wage the attack. In either case, the attacker could then bring down many of the adjacencies, thus destabilizing the routing system.
F.運用時のピアリングの使用には、ピアと他の事業者との相互接続、単一の事業者内のiBGPと他のルーティングセッション、および事業者から顧客へのデバイスの3つの使用例があります。 3つすべてのプロパティは大きく異なり、安全に管理するのは面倒であると報告されています。あるオペレーターは、すべての顧客宅内機器（CPE）に同じキーが使用されていると報告しました。同じオペレーターは、顧客がそれを義務付けた場合、一意のキーが作成される可能性があると報告しましたが、これが最後に発生したとき、管理者は通常、オプションが存在しないことを顧客に伝え、困難。これらの顧客固有のキーは、顧客が要求しない限り、決して変更されません。ここでの主な脅威は、これらの環境で認証に使用される1つ（または複数）のキーにアクセスできたそのようなオペレーターから退職した従業員が攻撃を仕掛けることです。あるいは、オペレーターは攻撃を行う他の人に鍵を提供することができます。どちらの場合も、攻撃者は多くの隣接関係を停止させ、ルーティングシステムを不安定にする可能性があります。
5. Whatever mechanisms KARP specifies need to be easier to deploy than the current methods and should provide obvious operational efficiency gains along with significantly better security. This combination of value may be enough to drive much broader adoption.
5. KARPが指定するメカニズムが何であれ、現在の方法よりも展開が容易である必要があり、運用効率が明らかに向上し、セキュリティが大幅に向上するはずです。この価値の組み合わせは、はるかに広範な採用を推進するのに十分かもしれません。
6. Address the threats enumerated below in "Threats" (Section 3) for each routing protocol. Not all threats may be able to be addressed in the first specification update for any one protocol. Roadmaps will be defined so that both the Security Area and the Routing Area agree on how the threats will be addressed completely over time.
6. 各ルーティングプロトコルについて、以下の「脅威」（セクション3）に列挙されている脅威に対処します。 1つのプロトコルの最初の仕様更新では、すべての脅威に対処できるとは限りません。ロードマップは、セキュリティエリアとルーティングエリアの両方が脅威が時間とともに完全に対処される方法について合意するように定義されます。
7. Create a reusable architecture, framework, and guidelines for various IETF working groups that will address these security improvements for various Routing Protocols. The crux of the KARP work is to reuse the architecture, framework, and guidelines as much as possible across relevant Routing Protocols. For example, designers should aim to reuse the key management protocol that will be defined for BGP, which will establish keys for TCP-AO, for as many other routing protocols with similar characteristics and properties as possible.
7. さまざまなルーティングプロトコルのこれらのセキュリティ強化に対処するさまざまなIETFワーキンググループの再利用可能なアーキテクチャ、フレームワーク、およびガイドラインを作成します。 KARP作業の要点は、関連するルーティングプロトコル全体で、アーキテクチャ、フレームワーク、およびガイドラインを可能な限り再利用することです。たとえば、設計者は、TCP-AOのキーを確立するBGPに定義されるキー管理プロトコルを、同様の特性とプロパティを持つ他の多くのルーティングプロトコルにできるだけ再利用することを目指す必要があります。
8. Bridge any gaps between the IETF Routing and Security Areas by recording agreements on work items, roadmaps, and guidance from the cognizant Area Directors and the Internet Architecture Board (IAB).
8. 作業領域に関する合意、ロードマップ、および認知エリアディレクターとインターネットアーキテクチャボード（IAB）からのガイダンスを記録することにより、IETFルーティングとセキュリティエリア間のギャップを埋めます。
The following goals are considered out of scope for this effort:
次の目標は、この取り組みの範囲外と見なされます。
o Confidentiality and non-repudiation of the packets on the wire. Once the goals of this roadmap are realized, work on confidentiality may be considered.
o 回線上のパケットの機密性と否認防止。このロードマップの目標が実現したら、機密保持に関する作業を検討することができます。
o Non-repudiation of the packets on the wire.
o ワイヤー上のパケットの否認防止。
o Message content validity (routing database validity). This work is being addressed in other IETF efforts. For example, BGP message content validity is being addressed in the SIDR working group.
o メッセージコンテンツの有効性（ルーティングデータベースの有効性）。この作業は、他のIETFの取り組みで対処されています。たとえば、BGPメッセージコンテンツの有効性は、SIDRワーキンググループで対処されています。
The audience for this document includes:
このドキュメントの対象読者は次のとおりです。
o Routing Area working group chairs and participants - These people are charged with updating Routing Protocol specifications. Any and all cryptographic authentication work on these specifications will occur in Routing Area working groups, in close partnership with the Security Area. Co-advisors from the Security Area may often be named for these partnership efforts.
o ルーティングエリアワーキンググループの議長と参加者-これらの人々は、ルーティングプロトコルの仕様の更新を担当しています。これらの仕様に関するすべての暗号化認証作業は、セキュリティエリアと密接に連携してルーティングエリアワーキンググループで行われます。セキュリティエリアの共同アドバイザーは、これらのパートナーシップの取り組みにちなんでしばしば指名されることがあります。
o Security Area reviewers of Routing Area documents - These people are tasked by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. Their particular attention to the use of cryptographic authentication and newly specified security mechanisms for the routing protocols is appreciated. They also help to ensure that incremental security improvements are being made, in line with this roadmap.
o ルーティングエリアドキュメントのセキュリティエリアレビューア-これらの人々は、セキュリティエリアディレクターによって、ワーキンググループの最後の呼び出しまたはIESGレビューを通過するときに、ルーティングプロトコル仕様のレビューを実行するように任されています。ルーティングプロトコルの暗号化認証と新しく指定されたセキュリティメカニズムの使用に対する彼らの特別な注意は高く評価されます。また、このロードマップに沿って、段階的なセキュリティの改善が行われていることを確認するのにも役立ちます。
o Security Area engineers - These people partner with Routing Area authors/designers on the security mechanisms in routing protocol specifications. Some of these Security Area engineers will be assigned by the Security Area Directors, while others will be interested parties in the relevant working groups.
o セキュリティエリアエンジニア-これらの人々は、ルーティングプロトコル仕様のセキュリティメカニズムについて、ルーティングエリアの作成者/設計者と提携しています。これらのセキュリティエリアエンジニアの一部は、セキュリティエリアディレクターによって割り当てられ、その他は関連するワーキンググループの関係者になります。
o Operators - The operators are a key audience for this work, as the work is considered to have succeeded only if operators deploy the technology. It is anticipated that deployment will take place only if operators perceive that the improved security offered by the Routing Protocol updates warrants the complexity and cost of deployment and operation. Conversely, the work will be considered a failure if operators do not deploy it, either due to a lack of perceived value or due to perceived operational complexity. As a result, the GROW and OPSEC working groups should be kept squarely in the loop as well.
oオペレーター-オペレーターがテクノロジーを展開した場合にのみ作業が成功したと見なされるため、オペレーターはこの作業の主要な対象者です。ルーティングプロトコルの更新によって提供されるセキュリティの向上により、展開と運用の複雑さとコストが保証されるとオペレーターが認識した場合にのみ、展開が行われることが予想されます。逆に、知覚された価値の欠如または知覚された操作の複雑さのために、オペレーターがそれを展開しない場合、その作業は失敗と見なされます。その結果、GROWおよびOPSECワーキンググループもループ内で正直に維持する必要があります。
This document uses the definition of "threat" from RFC 4949 [RFC4949]: "[a] potential for violation of security, which exists when there is an entity, circumstance, capability, action, or event that could cause harm."
このドキュメントでは、RFC 4949 [RFC4949]の「脅威」の定義を使用しています。「[a]危害を及ぼす可能性のあるエンティティ、状況、機能、アクション、またはイベントがある場合に存在する、セキュリティ違反の可能性。」
This section defines the threats that are in scope for the KARP effort. It also lists those threats that are explicitly out of scope for the KARP effort. Threats are discussed assuming that no protection (i.e., message authentication and message integrity) has been applied to routing protocol messages.
このセクションでは、KARPの取り組みの対象となる脅威を定義します。また、KARPの取り組みの範囲から明示的に除外されている脅威も示します。脅威は、ルーティングプロトコルメッセージに保護（つまり、メッセージ認証とメッセージの整合性）が適用されていないと想定して説明されています。
This document leverages the model described in "Generic Threats to Routing Protocols" [RFC4593]. Specifically, the threats listed below were derived by reviewing [RFC4593], analyzing how the threats applied to the KARP problem space, and listing the threats that are applicable to the work for the KARP design team. This document categorizes [RFC4593] threats into those in scope and those out of scope for KARP. Each in-scope threat is discussed below, and its applicability to the KARP problem space is described. As such, the following text intentionally is not a comprehensive threat analysis. Rather, it describes the applicability of the existing threat analysis in [RFC4593] to KARP.
このドキュメントは、「ルーティングプロトコルに対する一般的な脅威」[RFC4593]で説明されているモデルを活用しています。具体的には、[RFC4593]を確認し、脅威がどのようにKARP問題空間に適用されたかを分析し、KARP設計チームの作業に適用可能な脅威をリストすることで、以下の脅威を導き出しました。このドキュメントでは、[RFC4593]の脅威をKARPの範囲内と範囲外に分類しています。対象範囲内の各脅威について以下で説明し、KARP問題空間への適用性について説明します。そのため、次のテキストは意図的な包括的な脅威分析ではありません。むしろ、[RFC4593]の既存の脅威分析のKARPへの適用性について説明しています。
Note: terms from [RFC4593] appear capitalized below -- e.g. OUTSIDERS -- so as to make explicit the term's origin, and to enable rapid cross referencing to the source RFC.
注：[RFC4593]の用語は、以下のように大文字で表示されます。 OUTSIDERS-用語の出所を明示し、ソースRFCへの迅速な相互参照を可能にするため。
For convenience, a terse definition of most [RFC4593] terms is offered here. Those interested in a more thorough description of routing protocol threat sources, motivations, consequences, and actions will want to read [RFC4593] before continuing here.
便宜上、ほとんどの[RFC4593]用語の簡潔な定義をここに示します。ルーティングプロトコルの脅威の発生源、動機、結果、およびアクションの詳細な説明に興味がある人は、ここに進む前に[RFC4593]を読むことをお勧めします。
One of the threats that will be addressed in this roadmap is the situation in which the source is an OUTSIDER. An OUTSIDER attacker may reside anywhere in the Internet, may have the ability to send IP traffic to the router, may be able to observe the router's replies, and may even control the path for a legitimate peer's traffic. OUTSIDERS are not legitimate participants in the routing protocol.
このロードマップで対処される脅威の1つは、ソースがOUTSIDERである状況です。 OUTSIDER攻撃者は、インターネットのどこにでもいる可能性があり、ルーターにIPトラフィックを送信する能力を持っている可能性があり、ルーターの応答を監視でき、正当なピアのトラフィックのパスを制御する可能性さえあります。 OUTSIDERSは、ルーティングプロトコルの正当な参加者ではありません。
The use of message authentication and integrity protection specifically aims to identify packets originating from OUTSIDERS.
メッセージ認証と整合性保護の使用は、特にOUTSIDERSから発信されたパケットを識別することを目的としています。
KARP design teams will consider two specific use cases of OUTSIDERS: those on path, and those off path.
KARPの設計チームは、OUTSIDERSの2つの特定の使用例を検討します。
o On Path - These attackers have control of a network resource or a tap that sits along the path between two routing peers. A "Man in the Middle" (MitM) is an on-path attacker. From this vantage point, the attacker can conduct either active or passive attacks. An active attack occurs when the attacker places packets on the network as part of the attack. One active MitM attack relevant to KARP, an active wiretapping attack, occurs when the attacker tampers with packets moving between two legitimate router peers in such a way that both peers think they are talking to each other directly, when in fact they are actually talking to the attacker. Protocols conforming to this roadmap will use cryptographic mechanisms to detect MitM attacks and reject packets from such attacks (i.e., discard them as being not authentic). Passive on-path attacks occur when the attacker silently gathers data and analyzes it to gain advantage. Passive activity by an on-path attacker may lead to an active attack.
o パス上-これらの攻撃者は、2つのルーティングピア間のパスに沿って座っているネットワークリソースまたはタップを制御します。 「中間者」（MitM）はパス上の攻撃者です。この視点から、攻撃者はアクティブまたはパッシブ攻撃を実行できます。攻撃者が攻撃の一部としてパケットをネットワークに配置すると、アクティブな攻撃が発生します。 KARPに関連するアクティブなMitM攻撃の1つであるアクティブな盗聴攻撃は、攻撃者が2つの正当なルータピア間を移動するパケットを改ざんして、両方のピアが実際に互いに通信していると見なすような方法で発生します攻撃者。このロードマップに準拠するプロトコルは、暗号化メカニズムを使用してMitM攻撃を検出し、そのような攻撃からのパケットを拒否します（つまり、それらを信頼できないものとして破棄します）。パッシブオンパス攻撃は、攻撃者がサイレントデータを収集し、それを分析して有利になると発生します。パス上の攻撃者によるパッシブアクティビティは、アクティブな攻撃につながる可能性があります。
o Off Path - These attackers sit on some network outside of that over which the packets between two routing peers run. The source may be one or several hops away. Off-path attackers can launch active attacks, such as SPOOFING or denial-of-service (DoS) attacks, to name a few.
o オフパス-これらの攻撃者は、2つのルーティングピア間のパケットが実行されるネットワーク外のネットワークに座っています。ソースは1ホップまたは数ホップ離れている場合があります。パスを離れた攻撃者は、スプーフィングやサービス拒否（DoS）攻撃などのアクティブな攻撃を仕掛けることができます。
This threat source exists when an unauthorized entity somehow manages to gain access to keying material. Using this material, the attacker could send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The resulting traffic might appear to come from router A and be destined for router B, and thus the attacker could impersonate an authorized peer. The attacker could then adversely affect network behavior by sending bogus messages that appear to be authentic. The attack source possessing the unauthorized keys could be on path, off path, or both.
この脅威の原因は、不正なエンティティがなんとかしてキー情報へのアクセスを獲得したときに存在します。攻撃者はこの資料を使用して、メッセージ認証コード（MAC）に基づく認証チェックに合格したパケットを送信する可能性があります。結果のトラフィックはルーターAから送信され、ルーターB宛てに送信される可能性があるため、攻撃者は承認されたピアになりすますことができます。次に、攻撃者は、本物に見える偽のメッセージを送信することにより、ネットワークの動作に悪影響を及ぼす可能性があります。不正なキーを所持している攻撃元は、パス上、パス外、またはその両方である可能性があります。
The obvious mitigation for an unauthorized key holder is to change the keys currently in use by the legitimate routing peers. This mitigation can be either reactive or proactive. Reactive mitigation occurs when keys are changed only after one has discovered that the previous keys have fallen into the possession of unauthorized users. The reactive mitigation case is highlighted here in order to explain a common operational situation where new keying material will need to be put in place with little or no advanced warning. In such a case, new keys must be able to be installed and put into use very quickly, and with little operational expense. Proactive mitigation occurs when an operator assumes that unauthorized possession will occur from time to time without being discovered, and the operator moves to new keying material in order to cut short an attacker's window of opportunity to use the stolen keys effectively.
無許可のキーホルダーの明らかな緩和策は、正当なルーティングピアによって現在使用されているキーを変更することです。この緩和策は、対処的または予防的のいずれかです。以前のキーが権限のないユーザーの所持に陥っていることを発見した後にのみキーが変更されると、事後対応策が発生します。ここでは、事前の警告をほとんど、またはまったく行わずに新しいキーイング情報を配置する必要がある一般的な運用状況を説明するために、対処的緩和のケースを強調表示しています。そのような場合、新しいキーを非常に迅速にインストールして使用できるようにする必要があり、運用コストはほとんどかかりません。不正な所有が発見されることなく随時発生するとオペレーターが想定する場合に予防的緩和が発生し、オペレーターは盗まれたキーを効果的に使用する機会の攻撃者の時間枠を短縮するために新しいキーイング資料に移動します。
KARP design teams can address this type of attack by creating specifications that make it practical for the operator to quickly change keys without disruption to the routing system and with minimal operational overhead. Operators can further mitigate threats from unauthorized key holders by regularly changing keys.
KARP設計チームは、オペレーターがルーティングシステムを中断することなく、操作のオーバーヘッドを最小限に抑えてキーをすばやく変更できるようにする仕様を作成することで、この種の攻撃に対処できます。オペレーターは、定期的にキーを変更することにより、権限のないキーホルダーからの脅威をさらに軽減できます。
A terminated employee is an important example of an unauthorized key holder. Staff attrition is a reality in routing operations and is therefore a potential threat source. The threat source risk arises when a network operator who had been granted access to keys ceases to be an employee. If new keys are deployed immediately, the situation of a terminated employee can become an "unauthorized key holder, proactive" case, as described above, rather than an "unauthorized key holder, reactive mitigation" case. It behooves the operator to change the keys, to enforce the revocation of authorization of the old keys, in order to minimize the threat source's window of opportunity.
解雇された従業員は、不正なキー所有者の重要な例です。スタッフの減少はルーティング操作の現実であり、したがって潜在的な脅威の発生源です。脅威源のリスクは、キーへのアクセスを許可されていたネットワークオペレーターが従業員でなくなったときに発生します。新しいキーがすぐに展開されると、解雇された従業員の状況は、「不正なキーホルダー、事後対応」ケースではなく、上記の「不正なキーホルダー、事前対応」ケースになる可能性があります。脅威の発信元の機会ウィンドウを最小限に抑えるために、オペレーターがキーを変更し、古いキーの承認の取り消しを強制するようになっている必要があります。
A terminated employee is a valid unauthorized key holder threat source for KARP, and designs should address the associated threats. For example, new keys must be able to be installed and made operational in the routing protocols very quickly, with zero impact to the routing system, and with little operational expense. The threat actions associated with a terminated employee also motivate the need to change the keys quickly, also with little operational expense.
解雇された従業員はKARPの有効な不正なキーホルダーの脅威源であり、設計は関連する脅威に対処する必要があります。たとえば、新しいキーは、ルーティングシステムに影響を与えず、運用コストをほとんどかけずに、ルーティングプロトコルに非常に迅速にインストールして操作できる必要があります。また、解雇された従業員に関連する脅威のアクションは、運用コストをほとんどかけずにキーをすばやく変更する必要性を動機付けます。
According to [RFC4593], Section 3.1.1.2, BYZANTINE "attackers are faulty, misconfigured, or subverted routers; i.e., legitimate participants in the routing protocol", whose messages cause routing to malfunction.
[RFC4593]のセクション3.1.1.2、BYZANTINEによると、「攻撃者はルーターに欠陥があるか、設定が間違っているか、破壊されています。つまり、ルーティングプロトコルの正当な参加者」であり、そのメッセージによりルーティングが誤動作します。
[RFC4593] goes on to say that "[s]ome adversaries can subvert routers, or the management workstations used to control these routers. These Byzantine failures represent the most serious form of attack capability in that they result in emission of bogus traffic by legitimate routers."
[RFC4593]は続けて、「[s]一部の攻撃者はルーター、またはこれらのルーターを制御するために使用される管理ワークステーションを破壊することができます。これらのビザンチン障害は、合法的なトラフィックによる偽のトラフィックの放出を引き起こすという点で、最も深刻な攻撃機能を表しています。ルーター。」
[RFC4593] explains that "[d]eliberate attacks are mimicked by failures that are random and unintentional. In particular, a Byzantine failure in a router may occur because the router is faulty in hardware or software or is misconfigured", and thus routing malfunctions unintentionally. Although not malicious, such occurrences still disrupt network operation.
[RFC4593]は、「[d]詳細な攻撃は、ランダムで意図的ではない障害によって模倣されます。特に、ルーターのハードウェアまたはソフトウェアに欠陥があるか、ルーターの設定が誤っているため、ルーターのビザンチン障害が発生する可能性があります。意図せず。悪意はありませんが、このような事態が発生しても、ネットワークの運用は中断されます。
Whether faulty, misconfigured, or subverted, Byzantine routers have an empowered position from which to provide believable yet bogus routing messages that are damaging to the network.
欠陥があるか、誤って設定されているか、破壊されているかに関係なく、ビザンチンルーターは、ネットワークに損傷を与えている信頼できるが、偽のルーティングメッセージを提供する権限を与えられています。
The following THREAT ACTIONS are in scope for KARP:
以下の脅威アクションはKARPの対象です。
o SPOOFING - when an unauthorized device assumes the identity of an authorized one. Spoofing is special in that it can be used to carry out other threat actions that cause other threat consequences. SPOOFING can be used, for example, to inject malicious routing information that causes the disruption of network services. SPOOFING can also be used to cause a neighbor relationship to form that subsequently denies the formation of the relationship with a legitimate router.
o スプーフィング-許可されていないデバイスが許可されたデバイスのIDを装う場合。なりすましは、他の脅威の結果を引き起こす他の脅威のアクションを実行するために使用できるという点で特別です。スプーフィングは、たとえば、ネットワークサービスの中断を引き起こす悪意のあるルーティング情報を挿入するために使用できます。スプーフィングを使用して、ネイバー関係を形成させ、正当なルータとの関係の形成を拒否することもできます。
o DoS attacks
o DoS攻撃
A. At the transport layer - This occurs when an attacker sends packets aimed at halting or preventing the underlying protocol over which the routing protocol runs. The attacker could use SPOOFING, FALSIFICATION, or INTERFERENCE (see below) to produce the DoS attack. For example, BGP running over Transport Layer Security (TLS) will still not solve the problem of an attacker being able to send a spoofed TCP FIN or TCP RST and causing the BGP session to go down. Since these attacks depend on spoofing, operators are encouraged to deploy proper authentication mechanisms to prevent them. Specification work should ensure that Routing Protocols can operate over transport subsystems in a fashion that is resilient to such DoS attacks.
A.トランスポート層-これは、攻撃者がルーティングプロトコルを実行する基盤となるプロトコルを停止または防止することを目的としたパケットを送信したときに発生します。攻撃者は、なりすまし、偽造、または干渉（下記参照）を使用して、DoS攻撃を行う可能性があります。たとえば、トランスポート層セキュリティ（TLS）で実行されているBGPは、攻撃者がスプーフィングされたTCP FINまたはTCP RSTを送信でき、BGPセッションがダウンするという問題を解決しません。これらの攻撃はスプーフィングに依存しているため、オペレーターは適切な認証メカニズムを導入して攻撃を防ぐことが推奨されます。仕様作成作業では、ルーティングプロトコルが、このようなDoS攻撃に耐性のある方法でトランスポートサブシステム上で動作できることを確認する必要があります。
B. Using the authentication mechanism - This includes an attacker causing INTERFERENCE, which inhibits exchanges of legitimate routers. The attack is often perpetrated by sending packets that confuse or overwhelm a security mechanism itself. An example is initiating an overwhelming load of spoofed routing protocol packets that contain a MAC (i.e., INSERTING MESSAGES), so that the receiver spends substantial CPU resources on the processing cycles to check the MAC, only to discard the spoofed packet. Other types of INTERFERENCE include REPLAYING OUT-DATED PACKETS, CORRUPTING MESSAGES, and BREAKING SYNCHRONIZATION.
B.認証メカニズムの使用-これには、正当なルーターの交換を妨げる干渉を引き起こす攻撃者が含まれます。攻撃は、セキュリティメカニズム自体を混乱させる、または圧倒するパケットを送信することによって行われることがよくあります。例としては、MACを含むスプーフィングされたルーティングプロトコルパケット（INSERTING MESSAGES）の圧倒的な負荷を開始し、レシーバーが処理サイクルにかなりのCPUリソースを費やしてMACをチェックし、スプーフィングされたパケットを破棄するだけです。他の種類の干渉には、古くなったパケットの再生、メッセージの破損、同期の中断などがあります。
o FALSIFICATION - An action whereby an attacker sends false routing information. This document targets only FALSIFICATION from OUTSIDERS that may occur from tampering with packets in flight or sending entirely false messages. FALSIFICATION from BYZANTINES (see Section 3.3) are not addressed by the KARP effort.
o 偽造-攻撃者が偽のルーティング情報を送信するアクション。このドキュメントは、飛行中のパケットの改ざんまたは完全に偽のメッセージの送信から発生する可能性があるOUTSIDERSからの偽造のみを対象としています。ビザンチンからの改造（セクション3.3を参照）はKARPの取り組みでは扱われていません。
o Brute-Force Attacks Against Password/Keys - This includes either online or offline attacks in which attempts are made repeatedly using different keys/passwords until a match is found. While it is impossible to make brute-force attacks on keys completely unsuccessful, proper design can make it much harder for such attacks to succeed. For example, current guidance for the security strength of an algorithm with a particular key length should be deemed acceptable for a period of 10 years. (Section 10 of [SP.800-131A] is one source for guidance.) Using per-session keys is another widely used method for reducing the number of brute-force attacks, as this would make it difficult to guess the keys.
o パスワード/キーに対するブルートフォース攻撃-これには、一致するものが見つかるまでさまざまなキー/パスワードを使用して繰り返し試行されるオンラインまたはオフラインの攻撃が含まれます。キーに対するブルートフォース攻撃を完全に失敗させることは不可能ですが、適切な設計により、そのような攻撃が成功するのをはるかに困難にする可能性があります。たとえば、特定のキー長のアルゴリズムのセキュリティ強度に関する現在のガイダンスは、10年間受け入れられると見なされます。 （[SP.800-131A]のセクション10はガイダンスの1つの情報源です。）セッションごとのキーを使用することは、ブルートフォース攻撃の数を減らすために広く使用されているもう1つの方法です。これは、キーの推測を困難にするためです。
BYZANTINE sources -- be they faulty, misconfigured, or subverted -- are out of scope for this roadmap. KARP works to cryptographically ensure that received routing messages originated from authorized peers and that the message was not altered in transit. Formation of a bogus message by a valid and authorized peer falls outside the KARP scope. Any of the attacks described in Section 3.2 that may be levied by a BYZANTINE source are therefore also out of scope, e.g. FALSIFICATION from BYZANTINE sources or unauthorized message content by a legitimate authorized peer.
BYZANTINEのソース-欠陥があるか、設定が間違っているか、破壊されているかにかかわらず、このロードマップの対象外です。 KARPは、受信したルーティングメッセージが許可されたピアから発信されたこと、およびメッセージが送信中に変更されていないことを暗号で確認するように機能します。有効で承認されたピアによる偽のメッセージの形成は、KARPの範囲外です。したがって、BYZANTINEソースによって課される可能性のあるセクション3.2で説明されている攻撃も、範囲外です。 BYZANTINEソースからの改ざんまたは正当な許可されたピアによる許可されていないメッセージコンテンツ。
In addition, these other attack actions are out of scope for this work:
さらに、これらの他の攻撃アクションはこの作業の範囲外です。
o SNIFFING (passive wiretapping) - Passive observation of route message contents in flight. Data confidentiality, as achieved by data encryption, is the common mechanism for preventing SNIFFING. While useful, especially to prevent the gathering of data needed to perform an off-path packet injection attack, data encryption is out of scope for KARP.
o SNIFFING（パッシブ盗聴）-飛行中のルートメッセージコンテンツのパッシブ監視。データの暗号化によって達成されるデータの機密性は、SNIFFINGを防ぐための一般的なメカニズムです。特にオフパスパケットインジェクション攻撃を実行するために必要なデータの収集を防ぐのに役立ちますが、データの暗号化はKARPの範囲外です。
o INTERFERENCE due to:
o 干渉：
A. NOT FORWARDING PACKETS - Cannot be prevented with cryptographic authentication. Note: If sequence numbers with sliding windows are used in the solution (as is done, for example, in Bidirectional Forwarding Detection (BFD) [RFC5880]), a receiver can at least detect the occurrence of this attack.
A.パケットを転送しない-暗号化認証では防止できません。注：スライディングウィンドウ付きのシーケンス番号がソリューションで使用されている場合（たとえば、双方向転送検出（BFD）[RFC5880]で行われているように）、受信側は少なくともこの攻撃の発生を検出できます。
B. DELAYING MESSAGES - Cannot be prevented with cryptographic authentication. Note: Timestamps can be used to detect delays.
B.遅延メッセージ-暗号化認証では防止できません。注：タイムスタンプを使用して遅延を検出できます。
C. DENIAL OF RECEIPT (non-repudiation) - Cannot be prevented with cryptographic authentication.
C. DENIAL OF RECEIPT（否認防止）-暗号認証では防止できません。
D. UNAUTHORIZED MESSAGE CONTENT - Covered by the work of the IETF's SIDR working group (http://www.ietf.org/html.charters/sidr-charter.html).
D.未承認のメッセージコンテンツ-IETFのSIDRワーキンググループ（http://www.ietf.org/html.charters/sidr-charter.html）の作業によりカバーされています。
E. DoS attacks not involving the routing protocol. For example, a flood of traffic that fills the link ahead of the router, so that the router is rendered unusable and unreachable by valid packets is NOT an attack that KARP will address. Many such examples could be contrived.
E.ルーティングプロトコルを含まないDoS攻撃。たとえば、ルーターの前のリンクを満たし、有効なパケットによってルーターが使用できなくなったり到達できなくなったりするトラフィックのフラッドは、KARPが対処する攻撃ではありません。多くのそのような例が考案される可能性があります。
4. Requirements for KARP Work Phase 1: Update to a Routing Protocol's Existing Transport Security
4. KARP作業フェーズ1の要件：ルーティングプロトコルの既存のトランスポートセキュリティへの更新
Section 4.1 of the KARP Design Guide [RFC6518] describes two distinct work phases for the KARP effort. This section addresses requirements for the first work phase only, Work Phase 1, the update to a routing protocol's existing transport security. Work Phase 2, the framework and usage of a KMP, will be addressed in a future document(s).
KARP設計ガイド[RFC6518]のセクション4.1では、KARPの取り組みに関する2つの異なる作業フェーズについて説明しています。このセクションでは、ルーティングプロトコルの既存のトランスポートセキュリティに対する更新である、最初の作業フェーズのみである作業フェーズ1の要件について説明します。作業フェーズ2、KMPのフレームワークと使用法は、将来のドキュメントで対処されます。
The following list of requirements SHOULD be addressed by a KARP Work Phase 1 security update to any Routing Protocol (according to section 4.1 of the KARP Design Guide [RFC6518]document). IT IS RECOMMENDED that any Work Phase 1 security update to a Routing Protocol contain a section of the specification document that describes how each of the following requirements are met. It is further RECOMMENDED that justification be presented for any requirements that are NOT addressed.
以下の要件のリストは、ルーティングプロトコルに対するKARP作業フェーズ1のセキュリティ更新で対処する必要があります（KARP設計ガイド[RFC6518]ドキュメントのセクション4.1に従って）。ルーティングプロトコルに対する作業フェーズ1のセキュリティ更新には、次の各要件がどのように満たされているかを説明する仕様ドキュメントのセクションが含まれていることをお勧めします。対処されていない要件については、根拠を提示することがさらに推奨されます。
1. Clear definitions of which elements of the transmitted data (frame, packet, segment, etc.) are protected by an authentication/integrity mechanism.
1. 送信されたデータのどの要素（フレーム、パケット、セグメントなど）が認証/整合性メカニズムによって保護されているかを明確に定義します。
2. Strong cryptographic algorithms, as defined and accepted by the IETF security community, MUST be specified. The use of non-standard or unpublished algorithms MUST be avoided.
2. IETFセキュリティコミュニティで定義および承認されている強力な暗号化アルゴリズムを指定する必要があります。非標準または未公開のアルゴリズムの使用は避けなければなりません。
3. Algorithm agility for the cryptographic algorithms used in the authentication MUST be specified, and protocol specifications MUST be clear regarding how new algorithms are specified and used within the protocol. This requirement exists because research identifying weaknesses in cryptographic algorithms can cause the security community to reduce confidence in some algorithms. Breaking a cipher isn't a matter of if, but when it will occur. Having the ability to specify alternate algorithms (algorithm agility) within the protocol specification to support such an event is essential. Additionally, more than one algorithm MUST be specified. Mandating support for two algorithms (i.e., one mandatory to implement algorithm and one or more backup algorithms to guide transition) provides both redundancy, and a mechanism for enacting that redundancy.
3. 認証で使用される暗号アルゴリズムのアルゴリズムの俊敏性を指定する必要があり、プロトコルの仕様では、新しいアルゴリズムがプロトコル内でどのように指定および使用されるかについて明確でなければなりません。この要件が存在するのは、暗号アルゴリズムの弱点を特定する研究により、セキュリティコミュニティが一部のアルゴリズムの信頼性を低下させる可能性があるためです。暗号を破ることは、問題ではありませんが、いつ発生するかです。このようなイベントをサポートするために、プロトコル仕様内で代替アルゴリズム（アルゴリズムの俊敏性）を指定する機能が不可欠です。さらに、複数のアルゴリズムを指定する必要があります。 2つのアルゴリズム（つまり、アルゴリズムの実装に必須の1つと移行をガイドする1つ以上のバックアップアルゴリズム）のサポートを必須にすることで、冗長性とその冗長性を実現するメカニズムの両方が提供されます。
4. Secure use of PSKs, offering both operational convenience and a baseline level of security, MUST be specified.
4. 運用の利便性とベースラインレベルのセキュリティの両方を提供するPSKの安全な使用を指定する必要があります。
5. Routing Protocols (or the transport or network mechanism protecting routing protocols) SHOULD be able to detect and reject replayed intra-session and inter-session messages. Packets captured from one session MUST NOT be able to be resent and accepted during a later session (i.e., inter-session replay). Additionally, replay mechanisms MUST work correctly even in the presence of routing protocol packet prioritization by the router.
5. ルーティングプロトコル（またはルーティングプロトコルを保護するトランスポートまたはネットワークメカニズム）は、再生されたセッション内およびセッション間メッセージを検出して拒否できる必要があります（SHOULD）。 1つのセッションからキャプチャされたパケットは、後のセッション（つまり、セッション間リプレイ）中に再送信および受け入れられてはなりません（MUST NOT）。さらに、ルーターによるルーティングプロトコルパケットの優先順位付けがある場合でも、再生メカニズムは正しく機能する必要があります。
There is a specific case of replay attack combined with spoofing that must be addressed. Several routing protocols (e.g., OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453], etc.), require all speakers to share the same authentication and message association key on a broadcast segment. It is important that an integrity check associated with a message fail if an attacker has replayed the message with a different origin.
対処する必要があるスプーフィングと組み合わされたリプレイ攻撃の特定のケースがあります。いくつかのルーティングプロトコル（OSPF [RFC2328]、IS-IS [RFC1195]、BFD [RFC5880]、RIP [RFC2453]など）では、すべてのスピーカーがブロードキャストセグメントで同じ認証とメッセージの関連付けキーを共有する必要があります。攻撃者が別の発信元でメッセージを再生した場合、メッセージに関連付けられた整合性チェックが失敗することが重要です。
6. A change of security parameters MUST force a change of session traffic keys. The specific security parameters for the various routing protocols will differ and will be defined by each protocol design team. Some examples may include master key, key lifetime, and cryptographic algorithm. If one of these configured parameters changes, then a new session traffic key MUST immediately be established using the updated parameters. The routing protocol security mechanisms MUST support this behavior.
6. セキュリティパラメータの変更は、セッショントラフィックキーの変更を強制する必要があります。さまざまなルーティングプロトコルに固有のセキュリティパラメータは異なり、各プロトコル設計チームによって定義されます。いくつかの例には、マスターキー、キーの有効期間、および暗号化アルゴリズムが含まれます。これらの構成済みパラメーターのいずれかが変更された場合、新しいパラメーターを使用して、新しいセッショントラフィックキーをすぐに確立する必要があります。ルーティングプロトコルセキュリティメカニズムは、この動作をサポートする必要があります。
7. Security mechanisms MUST specify a means to affect intra-session rekeying without disrupting a routing session. This should be accomplished without data loss, if possible. Keys may need to be changed periodically based on policy or when an administrator who had access to the keys leaves an organization. A rekeying mechanism enables the operators to execute the change without productivity loss.
7. セキュリティメカニズムは、ルーティングセッションを中断することなく、セッション内のキー更新に影響を与える手段を指定する必要があります。これは、可能であれば、データを失うことなく実行する必要があります。ポリシーに基づいて、またはキーへのアクセス権を持っていた管理者が退職したときに、キーを定期的に変更する必要がある場合があります。鍵の再生成メカニズムにより、オペレーターは生産性を損なうことなく変更を実行できます。
8. Rekeying SHOULD be supported in such a way that it can occur during a session without the peer needing to use multiple keys to validate a given packet. The rare exception will occur if a routing protocol's design team can find no other way to rekey and still adhere to the other requirements in this section. The specification SHOULD include a key identifier, which allows receivers to choose the correct key (or determine that they are not in possession of the correct key).
8. キー再生成は、ピアが複数のキーを使用して特定のパケットを検証する必要なく、セッション中に発生できるようにサポートする必要があります（SHOULD）。まれな例外は、ルーティングプロトコルの設計チームがキーを再生成する他の方法を見つけられず、このセクションの他の要件を順守できない場合に発生します。仕様には、受信者が正しいキーを選択できるようにする（または正しいキーを所有していないと判断できる）キー識別子を含める必要があります（SHOULD）。
9. New mechanisms MUST resist DoS attacks described as in scope in Section 3.2. Routers protect the control plane by implementing mechanisms to reject completely or rate-limit traffic not required at the control-plane level (i.e., unwanted traffic). Typically, line-rate packet-filtering capabilities look at information in the IP and transport (TCP or UDP) headers, but do not include higher-layer information. Therefore, the new mechanisms should neither hide nor encrypt the information carried in the IP and transport layers in control-plane packets.
9. 新しいメカニズムは、セクション3.2で範囲として説明されているDoS攻撃に抵抗する必要があります。ルーターは、コントロールプレーンレベルで不要なトラフィック（つまり、不要なトラフィック）を完全に拒否またはレート制限するメカニズムを実装することにより、コントロールプレーンを保護します。通常、ラインレートパケットフィルタリング機能は、IPおよびトランスポート（TCPまたはUDP）ヘッダーの情報を調べますが、上位層の情報は含みません。したがって、新しいメカニズムでは、コントロールプレーンパケットのIPおよびトランスポート層で運ばれる情報を隠したり暗号化したりすることはできません。
10. Mandatory cryptographic algorithms and mechanisms MUST be specified for each routing protocol security mechanism. Further, the protocol specification MUST define default security mechanism settings for all implementations to use when no explicit configuration is provided. To understand the need for this requirement, consider the case where a routing protocol mandates three different cryptographic algorithms for a MAC operation. If company A implements algorithm 1 as the default for this protocol, while company B implements algorithm 2 as the default, then two operators who enable the security mechanism with no explicit configuration other than a PSK will experience a connection failure. It is not enough that each implementation implement the three mandatory algorithms; one default must further be specified in order to gain maximum out-of-the-box interoperability.
10. 必須の暗号アルゴリズムとメカニズムは、ルーティングプロトコルのセキュリティメカニズムごとに指定する必要があります。さらに、プロトコル仕様では、明示的な構成が提供されていない場合に使用するすべての実装に対して、デフォルトのセキュリティメカニズム設定を定義する必要があります。この要件の必要性を理解するために、ルーティングプロトコルが3つの異なる暗号化アルゴリズムをMAC操作に要求する場合を考えます。会社Aがアルゴリズム1をこのプロトコルのデフォルトとして実装し、会社Bがアルゴリズム2をデフォルトとして実装する場合、PSK以外の明示的な構成なしでセキュリティメカニズムを有効にする2人のオペレーターは、接続障害を経験します。各実装が3つの必須アルゴリズムを実装するだけでは十分ではありません。デフォルトの相互運用性を最大限に高めるには、さらに1つのデフォルトを指定する必要があります。
11. For backward-compatibility reasons, manual keying MUST be supported.
11. 下位互換性の理由から、手動キーイングをサポートする必要があります。
12. The specification MUST consider and allow for future use of a KMP.
12. 仕様では、KMPの将来の使用を考慮して許可する必要があります。
13. The authentication mechanism in a Routing Protocol MUST be decoupled from the key management system used. The authentication protocol MUST include a specification for agreeing on keying material. This will accommodate both manual keying and the use of KMPs.
13. ルーティングプロトコルの認証メカニズムは、使用されるキー管理システムから切り離されている必要があります。認証プロトコルには、キー情報に同意するための仕様を含める必要があります。これにより、手動キーイングとKMPの使用の両方に対応できます。
14. Convergence times of the Routing Protocols SHOULD NOT be materially affected. Changes in the convergence time will be immediately and independently verifiable by convergence performance test beds already in use (e.g. those maintained by router vendors, service providers, and researchers). An increase in convergence time in excess of 5% is likely to be considered to have materially affected convergence by network operators. A number of other factors can also change convergence over time (e.g., speed of processors used on individual routing peers, processing power increases due to Moore's law, and implementation specifics), and implementors will need to take into account the effect of an authentication mechanism on Routing Protocols. Protocol designers should consider the impact on convergence times as a function of both the total number of protocol packets that must be exchanged and the required computational processing of individual messages in the specification, understanding that the operator community's threshold for an increase in convergence times is very low, as stated above.
14. ルーティングプロトコルの収束時間は実質的に影響されるべきではありません。コンバージェンス時間の変更は、すでに使用されているコンバージェンスパフォーマンステストベッド（たとえば、ルーターベンダー、サービスプロバイダー、およびリサーチャーによって維持されているもの）によって、即座に独立して検証できます。コンバージェンス時間が5％を超えて増加すると、ネットワークオペレーターによるコンバージェンスに重大な影響を与えたと考えられます。他の多くの要因も時間の経過とともに収束を変える可能性があり（たとえば、個々のルーティングピアで使用されるプロセッサの速度、ムーアの法則による処理能力の向上、実装の詳細など）、実装者は認証メカニズムの影響を考慮する必要があります。ルーティングプロトコル。プロトコル設計者は、交換が必要なプロトコルパケットの総数と、仕様内の個々のメッセージに必要な計算処理の両方の関数としてコンバージェンス時間への影響を考慮し、オペレーターコミュニティのコンバージェンス時間の増加に対するしきい値は非常に高いことを理解する必要があります。上記のように低い。
15. The changes to or addition of security mechanisms SHOULD NOT cause a refresh of route advertisements or cause additional route advertisements to be generated.
15. セキュリティメカニズムの変更または追加により、ルートアドバタイズメントが更新されたり、追加のルートアドバタイズメントが生成されたりしてはなりません（SHOULD NOT）。
16. Router implementations provide prioritized treatment for certain protocol packets. For example, OSPF Hello and Acknowledgement packets are prioritized for processing above other OSPF packets. The security mechanism SHOULD NOT interfere with the ability to observe and enforce such prioritization. Any effect on such priority mechanisms MUST be explicitly documented and justified. Replay protection mechanisms provided by the routing protocols MUST work even if certain protocol packets are offered prioritized treatment.
16. ルーターの実装は、特定のプロトコルパケットに優先順位を付けた処理を提供します。たとえば、OSPF Helloパケットと確認応答パケットは、他のOSPFパケットよりも処理が優先されます。セキュリティメカニズムは、このような優先順位付けを監視および強制する機能を妨げるべきではありません。そのような優先メカニズムへの影響は、明示的に文書化され、正当化されなければなりません。ルーティングプロトコルによって提供されるリプレイ保護メカニズムは、特定のプロトコルパケットが優先的に処理される場合でも機能する必要があります。
17. The Routing Protocol MUST send minimal information regarding the authentication mechanisms and associated parameters in its protocol packets. This keeps the Routing Protocols as clean and focused as possible, and loads security negotiations into the KMP as much as possible. This also avoids exposing any security negotiation information unnecessarily to possible attackers on the path.
17. ルーティングプロトコルは、認証メカニズムとそのプロトコルパケット内の関連パラメータに関する最小限の情報を送信する必要があります。これにより、ルーティングプロトコルが可能な限りクリーンで集中的な状態に保たれ、セキュリティネゴシエーションがKMPに可能な限り読み込まれます。これにより、パス上の潜在的な攻撃者に不必要にセキュリティネゴシエーション情報が公開されることも回避されます。
18. Routing Protocols that rely on the IP header (or information separate from routing protocol payload) to identify the neighbor that originated the packet MUST either protect the IP header or provide some other means to authenticate the neighbor. [RFC6039] describes some attacks that motivate this requirement.
18. パケットを発信したネイバーを識別するためにIPヘッダー（またはルーティングプロトコルペイロードとは別の情報）に依存するルーティングプロトコルは、IPヘッダーを保護するか、ネイバーを認証する他の手段を提供する必要があります。 [RFC6039]は、この要件を動機付けるいくつかの攻撃について説明しています。
19. Every new KARP-developed security mechanisms MUST support incremental deployment. It will not be feasible to deploy a new Routing Protocol authentication mechanism throughout a network instantaneously. Indeed, it may not actually be feasible to deploy such a mechanism to all routers in a large autonomous system (AS) in a bounded timeframe. Proposed solutions MUST support an incremental deployment method that benefits those who participate. Because of this, there are several requirements that any proposed KARP mechanism should consider.
19. KARPが開発したすべての新しいセキュリティメカニズムは、増分展開をサポートする必要があります。新しいルーティングプロトコル認証メカニズムをネットワーク全体に瞬時に展開することはできません。実際、このようなメカニズムを大規模な自律システム（AS）内のすべてのルーターに限られた時間枠で展開することは実際には実現可能ではない場合があります。提案されたソリューションは、参加者に利益をもたらす段階的な展開方法をサポートする必要があります。このため、提案されているKARPメカニズムが考慮すべきいくつかの要件があります。
A. The Routing Protocol security mechanism MUST enable each router to configure use of the security mechanism on a per-peer basis where the communication is peer to peer (unicast).
A.ルーティングプロトコルセキュリティメカニズムは、各ルーターが通信がピアツーピア（ユニキャスト）であるピアごとにセキュリティメカニズムの使用を構成できるようにする必要があります。
B. Every new KARP-developed security mechanism MUST provide backward compatibility with respect to message formatting, transmission, and processing of routing information carried through secure and non-secure security environments. Message formatting in a fully secured environment MAY be handled in a non-backward-compatible fashion, though care must be taken to ensure that routing protocol packets can traverse intermediate routers that don't support the new format.
B. KARPが開発したすべての新しいセキュリティメカニズムは、メッセージのフォーマット、送信、および安全なセキュリティ環境と安全でないセキュリティ環境で運ばれるルーティング情報の処理に関して、下位互換性を提供する必要があります。完全に保護された環境でのメッセージのフォーマットは、下位互換性のない方法で処理される場合がありますが、ルーティングプロトコルパケットが新しいフォーマットをサポートしない中間ルーターを通過できるように注意する必要があります。
C. In an environment where both secured and non-secured routers are interoperating, a mechanism MUST exist for secured systems to identify whether a peer intended the messages to be secured.
C.保護されたルーターと保護されていないルーターの両方が相互運用している環境では、ピアがメッセージの保護を意図していたかどうかを識別するために、保護されたシステムにメカニズムが存在しなければなりません。
D. In an environment where secured service is in the process of being deployed, a mechanism MUST exist to support a transition free of service interruption (caused by the deployment per se).
D.セキュリティで保護されたサービスが展開中の環境では、サービスの中断のない移行をサポートするメカニズムが存在する必要があります（展開自体が原因）。
20. The introduction of mechanisms to improve routing security may increase the processing performed by a router. Since most of the currently deployed routers do not have hardware to accelerate cryptographic operations, these operations could impose a significant processing burden under some circumstances. Thus, proposed solutions SHOULD be evaluated carefully with regard to the processing burden they may impose, since deployment may be impeded if network operators perceive that a solution will impose a processing burden that either incurs substantial capital expense or threatens to degrade router performance.
20.ルーティングのセキュリティを向上させるメカニズムを導入すると、ルーターによって実行される処理が増える場合があります。現在展開されているルーターのほとんどには、暗号化操作を高速化するハードウェアがないため、これらの操作は状況によっては大きな処理負荷をかける可能性があります。したがって、提案されたソリューションは、それらが課す可能性のある処理負担に関して慎重に評価する必要があります。これは、ネットワークオペレーターがソリューションが実質的な資本支出を招くか、ルーターのパフォーマンスを低下させる恐れのある処理負担を課すと認識した場合、展開が妨げられる可能性があるためです。
21. New authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding) in order for the routing system to be secure. In order to ensure the rapid initialization and/or return to service of failed nodes, it is important to reduce reliance on these external systems to the greatest extent possible. Proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is, however, acceptable for the proposed solutions to require post-initialization synchronization with external systems in order to fully synchronize security associations.
21. 新しい認証およびセキュリティメカニズムは、ルーティングシステムのセキュリティを確保するために、ルーティングシステムの外部のシステム（転送を実行している機器）に依存するべきではありません。障害が発生したノードの迅速な初期化および/またはサービスへの復帰を確実にするために、これらの外部システムへの依存を可能な限り減らすことが重要です。提案されたソリューションは、完全なサービスに戻るために、ピアリング関係に直接関与しているシステム以外の外部システムへの接続を必要としません。ただし、提案されたソリューションでは、セキュリティアソシエーションを完全に同期させるために、初期化後の外部システムとの同期を必要とすることは許容されます。
If authentication and security mechanisms rely on systems external to the routing system, then there MUST be one or more options available to avoid circular dependencies. It is not acceptable to have a routing protocol (e.g., unicast routing) depend upon correct operation of a security protocol that, in turn, depends upon correct operation of the same instance of that routing protocol (i.e., the unicast routing). However, it is acceptable to have operation of a routing protocol (e.g., multicast routing) depend upon operation of a security protocol, which depends upon an independent routing protocol (e.g., unicast routing). Similarly, it would be okay to have the operation of a routing protocol depend upon a security protocol, which in turn uses an out-of-band network to exchange information with remote systems.
認証およびセキュリティメカニズムがルーティングシステムの外部のシステムに依存している場合、循環依存を回避するために1つ以上のオプションを使用できる必要があります。ルーティングプロトコル（ユニキャストルーティングなど）がセキュリティプロトコルの正しい動作に依存し、そのルーティングプロトコルの同じインスタンス（ユニキャストルーティング）の正しい動作に依存することは許容されません。しかしながら、ルーティングプロトコル（例えば、マルチキャストルーティング）の動作が、独立したルーティングプロトコル（例えば、ユニキャストルーティング）に依存するセキュリティプロトコルの動作に依存することは許容できる。同様に、ルーティングプロトコルの動作をセキュリティプロトコルに依存させることは問題ありません。セキュリティプロトコルは、帯域外ネットワークを使用してリモートシステムと情報を交換します。
This document is mostly about security considerations for the KARP efforts, both threats and the requirements for addressing those threats. More detailed security considerations are provided in the Security Considerations section of the KARP Design Guide [RFC6518]document.
このドキュメントは主に、KARPの取り組みに関するセキュリティの考慮事項、脅威とそれらの脅威に対処するための要件の両方についてです。セキュリティに関する考慮事項の詳細については、KARP設計ガイド[RFC6518]ドキュメントの「セキュリティに関する考慮事項」セクションを参照してください。
The use of a group key between a set of Routing Protocol peers has special security considerations. Possession of the group key itself is used for identity validation; no other identity check is used. Under these conditions, an attack exists when one peer masquerades as a neighbor by using the neighbor's source IP address. This type of attack has been well documented in the group-keying problem space, and it is non-trivial to solve. Solutions exist within the group- keying realm, but they come with significant increases in complexity and computational intensity.
ルーティングプロトコルピアのセット間でのグループキーの使用には、特別なセキュリティ上の考慮事項があります。グループキー自体の所有は、ID検証に使用されます。他のIDチェックは使用されません。これらの状況では、1つのピアがネイバーの送信元IPアドレスを使用してネイバーになりすますときに攻撃が存在します。このタイプの攻撃は、グループキーイング問題の領域で十分に文書化されており、解決するのは簡単ではありません。ソリューションはグループキーイング領域内に存在しますが、複雑さと計算強度が大幅に増加します。
The majority of the text for initial draft of this document was taken from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz.
このドキュメントの最初のドラフトのテキストの大部分は、Gregory M. Lebovitzが作成した「ワイヤ上のルーティングプロトコルパケットの暗号化認証のロードマップ」から抜粋したものです。
Brian Weis provided significant assistance in handling the many comments that came back during IESG review, including making textual edits directly to the XML. For his extensive efforts he was added as an author.
Brian Weisは、直接XMLをテキストで編集するなど、IESGレビュー中に返された多くのコメントの処理に大きな支援を提供しました。彼の多大な努力により、彼は著者として追加されました。
We would like to thank the following people for their thorough reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent, Vishwas Manral, Barry Leiba, Sean Turner, and Uma Chunduri.
ブライアンワイス、西田喜文、スティーブンケント、ヴィシュワスマナール、バリーレイバ、ショーンターナー、ウマチャンドゥリの各氏の徹底したレビューとコメントに感謝します。
Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for much of the time he worked on this document, though not at the time of its publishing. Thus, Juniper sponsored much of this effort.
著者Gregory M. Lebovitzは、このドキュメントの作成時にはほとんどの時間、ジュニパーネットワークス社で働いていましたが、発行時ではありませんでした。したがって、ジュニパーはこの取り組みの多くを後援しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日のIABワークショップからの不要なトラフィックに関するレポート」、RFC 4948、2007年8月。
[ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure Security Report", October 2008, <http://pages.arbornetworks.com/rs/arbor/images/ ISR2008_EN.pdf>.
[ISR2008] McPherson、D.およびC. Labovitz、「Worldwide Infrastructure Security Report」、2008年10月、<http://pages.arbornetworks.com/rs/arbor/images/ ISR2008_EN.pdf>。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、M。、「TCP MD5署名オプションのキー管理に関する考慮事項」、RFC 3562、2003年7月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y。、編、Li、T。、編、およびS. Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、2007年8月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、2010年10月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518] Lebovitz、G。およびM. Bhatia、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」、RFC 6518、2012年2月。
[SP.800-131A] Barker, E. and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", United States of America, National Institute of Science and Technology, NIST Special Publication 800-131A, January 2011.
[SP.800-131A] Barker、E。およびA. Roginsky、「移行：暗号化アルゴリズムとキーの長さの使用を移行するための推奨事項」、アメリカ合衆国、国立科学技術研究所、NIST特別刊行物800-131A 、2011年1月。
Authors' Addresses
著者のアドレス
Gregory Lebovitz Aptos, California 95003 United States
Gregory Lebovitz Aptos、California 95003アメリカ
EMail: gregory.ietf@gmail.com
Manav Bhatia Alcatel-Lucent Bangalore, India
Manav Bhatiaアルカテルルーセントバンガロール、インド
EMail: manav.bhatia@alcatel-lucent.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose、California 95134-1706 United States
EMail: bew@cisco.com
URI: http://www.cisco.com