[要約] RFC 6811は、BGPプレフィックスの起源検証に関する標準化された手法を提案しています。その目的は、BGPルーティングのセキュリティを向上させ、偽装されたルートの拡散を防ぐことです。
Internet Engineering Task Force (IETF) P. Mohapatra
Request for Comments: 6811 Cisco Systems
Category: Standards Track J. Scudder
ISSN: 2070-1721 Juniper Networks
D. Ward
Cisco Systems
R. Bush
Internet Initiative Japan
R. Austein
Dragon Research Labs
January 2013
BGP Prefix Origin Validation
BGPプレフィックスオリジン検証
Abstract
概要
To help reduce well-known threats against BGP including prefix mis-announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement.
プレフィックスの誤報や中間者攻撃など、BGPに対するよく知られた脅威を減らすために、セキュリティ要件の1つは、BGPルートの元の自律システム（AS）を検証する機能です。より具体的には、（BGPルートのAS_PATH属性から派生した）アドレスプレフィックスを発信すると主張するAS番号が、実際に発信することをプレフィックスホルダーによって承認されていることを検証する必要があります。このドキュメントでは、この要件を部分的に満たすための簡単な検証メカニズムについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6811.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6811で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . . 4
2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7
5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informational References . . . . . . . . . . . . . . . . . 9
A BGP route associates an address prefix with a set of Autonomous Systems (ASes) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix mis-announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement.
BGPルートは、アドレスプレフィックスを、プレフィックスがBGPアナウンスの形式で通過したドメイン間パスを識別する一連の自律システム（AS）に関連付けます。このセットはBGP [RFC4271]のAS_PATH属性として表され、プレフィックスを発信したASで始まります。プレフィックスの誤報や中間者攻撃など、BGPに対するよく知られた脅威を減らすために、セキュリティ要件の1つは、BGPルートの発信元ASを検証する機能です。より具体的には、（BGPルートのAS_PATH属性から派生した）アドレスプレフィックスを発信すると主張するAS番号が、実際に発信することをプレフィックスホルダーによって承認されていることを検証する必要があります。このドキュメントでは、この要件を部分的に満たすための簡単な検証メカニズムについて説明します。
The Resource Public Key Infrastructure (RPKI) describes an approach to build a formally verifiable database of IP addresses and AS numbers as resources. The overall architecture of RPKI as defined in [RFC6480] consists of three main components:
Resource Public Key Infrastructure（RPKI）は、IPアドレスとAS番号の正式に検証可能なデータベースをリソースとして構築する方法を説明しています。 [RFC6480]で定義されているRPKIの全体的なアーキテクチャは、3つの主要コンポーネントで構成されています。
o a public key infrastructure (PKI) with the necessary certificate objects,
o 必要な証明書オブジェクトを含む公開鍵基盤（PKI）、
o digitally signed routing objects, and
o デジタル署名されたルーティングオブジェクト、および
o a distributed repository system to hold the objects that would also support periodic retrieval.
o 定期的な取得もサポートするオブジェクトを保持する分散リポジトリシステム。
The RPKI system is based on resource certificates that define extensions to X.509 to represent IP addresses and AS identifiers [RFC3779], thus the name RPKI. Route Origin Authorizations (ROAs) [RFC6482] are separate digitally signed objects that define associations between ASes and IP address blocks. Finally, the repository system is operated in a distributed fashion through the IANA, Regional Internet Registry (RIR) hierarchy, and ISPs.
RPKIシステムは、X.509への拡張を定義するリソース証明書に基づいており、IPアドレスとAS識別子[RFC3779]を表すため、RPKIという名前が付けられています。 Route Origin Authorizations（ROA）[RFC6482]は、ASとIPアドレスブロック間の関連付けを定義する個別のデジタル署名付きオブジェクトです。最後に、リポジトリシステムは、IANA、Regional Internet Registry（RIR）階層、およびISPを通じて分散方式で運用されます。
In order to benefit from the RPKI system, it is envisioned that relying parties at either the AS or organization level obtain a local copy of the signed object collection, verify the signatures, and process them. The cache must also be refreshed periodically. The exact access mechanism used to retrieve the local cache is beyond the scope of this document.
RPKIシステムのメリットを享受するために、ASレベルまたは組織レベルの証明書利用者が署名付きオブジェクトコレクションのローカルコピーを取得し、署名を検証して、それらを処理することが想定されています。キャッシュも定期的に更新する必要があります。ローカルキャッシュを取得するために使用される正確なアクセスメカニズムは、このドキュメントの範囲外です。
Individual BGP speakers can utilize the processed data contained in the local cache to validate BGP announcements. The protocol details to retrieve the processed data from the local cache to the BGP speakers is beyond the scope of this document (refer to [RFC6810] for such a mechanism). This document proposes a means by which a BGP speaker can make use of the processed data in order to assign a "validation state" to each prefix in a received BGP UPDATE message.
個々のBGPスピーカーは、ローカルキャッシュに含まれる処理済みデータを利用して、BGPアナウンスを検証できます。処理されたデータをローカルキャッシュからBGPスピーカーに取得するためのプロトコルの詳細は、このドキュメントの範囲外です（そのようなメカニズムについては、[RFC6810]を参照してください）。このドキュメントでは、受信したBGP UPDATEメッセージの各プレフィックスに「検証状態」を割り当てるために、BGPスピーカーが処理されたデータを利用できる方法を提案しています。
Note that the complete path attestation against the AS_PATH attribute of a route is outside the scope of this document.
ルートのAS_PATH属性に対する完全なパスの証明は、このドキュメントの範囲外であることに注意してください。
Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix than another cache or router. There is no 'fix' for this; it is the nature of distributed data with distributed caches.
DNSと同様に、グローバルRPKIは、タイミング、更新、フェッチなどに応じて、大まかに整合したビューしか表示しません。したがって、特定のプレフィックスに関するデータが、あるキャッシュまたはルーターに別のキャッシュまたはルーターと異なる場合があります。これに対する「修正」はありません。これは、分散キャッシュを持つ分散データの性質です。
Although RPKI provides the context for this document, it is equally possible to use any other database that is able to map prefixes to their authorized origin ASes. Each distinct database will have its own particular operational and security characteristics; such characteristics are beyond the scope of this document.
RPKIはこのドキュメントのコンテキストを提供しますが、プレフィックスを許可されたオリジンASにマップできる他のデータベースを使用することも同様に可能です。個別のデータベースごとに、独自の操作およびセキュリティ特性があります。このような特性は、このドキュメントの範囲を超えています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without special meaning.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は解釈されますRFC 2119 [RFC2119]で説明されているように、すべて大文字で表記されている場合のみ。また、特別な意味を持たずに、英語の単語として小文字または大文字と小文字が混在する場合もあります。
The BGP speaker loads validated objects from the cache into local storage. The objects loaded have the content (IP address, prefix length, maximum length, origin AS number). We refer to such a locally stored object as a "Validated ROA Payload" or "VRP".
BGPスピーカーは、検証済みのオブジェクトをキャッシュからローカルストレージにロードします。ロードされたオブジェクトにはコンテンツ（IPアドレス、プレフィックス長、最大長、発信元AS番号）があります。このようなローカルに格納されたオブジェクトを「検証済みROAペイロード」または「VRP」と呼びます。
We define several terms in addition to "VRP". Where these terms are used, they are capitalized:
「VRP」に加えて、いくつかの用語を定義します。これらの用語が使用されている場合、大文字で表記されています。
o Prefix: (IP address, prefix length), interpreted as is customary (see [RFC4632]).
o プレフィックス：（IPアドレス、プレフィックス長）、慣習どおりに解釈されます（[RFC4632]を参照）。
o Route: Data derived from a received BGP UPDATE, as defined in [RFC4271], Section 1.1. The Route includes one Prefix and an AS_PATH; it may include other attributes to characterize the prefix.
o ルート：[RFC4271]、セクション1.1で定義されている、受信したBGP UPDATEから派生したデータ。ルートには1つのプレフィックスとAS_PATHが含まれます。プレフィックスを特徴付ける他の属性を含めることができます。
o VRP Prefix: The Prefix from a VRP.
o VRPプレフィックス：VRPからのプレフィックス。
o VRP ASN: The origin AS number from a VRP.
o VRP ASN：VRPからの元のAS番号。
o Route Prefix: The Prefix derived from a route.
o ルートプレフィックス：ルートから派生したプレフィックス。
o Route Origin ASN: The origin AS number derived from a Route as follows:
o ルート発信元ASN：次のようにルートから導出された発信元AS番号：
* the rightmost AS in the final segment of the AS_PATH attribute in the Route if that segment is of type AS_SEQUENCE, or
* セグメントがAS_SEQUENCEタイプの場合、ルートのAS_PATH属性の最後のセグメントの右端のAS、または
* the BGP speaker's own AS number if that segment is of type AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or
* そのセグメントのタイプがAS_CONFED_SEQUENCEまたはAS_CONFED_SETの場合、またはAS_PATHが空の場合は、BGPスピーカー自身のAS番号、または
* the distinguished value "NONE" if the final segment of the AS_PATH attribute is of any other type.
* AS_PATH属性の最後のセグメントが他のタイプの場合、識別値「NONE」。
o Covered: A Route Prefix is said to be Covered by a VRP when the VRP prefix length is less than or equal to the Route prefix length, and the VRP prefix address and the Route prefix address are identical for all bits specified by the VRP prefix length. (That is, the Route prefix is either identical to the VRP prefix or more specific than the VRP prefix.)
o 対象：VRPプレフィックス長がルートプレフィックス長以下であり、VRPプレフィックスアドレスとルートプレフィックスアドレスがVRPプレフィックス長で指定されたすべてのビットで同一である場合、ルートプレフィックスはVRPでカバーされていると言います。 （つまり、ルートプレフィックスはVRPプレフィックスと同一か、VRPプレフィックスよりも具体的です。）
o Matched: A Route Prefix is said to be Matched by a VRP when the Route Prefix is Covered by that VRP, the Route prefix length is less than or equal to the VRP maximum length, and the Route Origin ASN is equal to the VRP ASN.
o 一致：ルートプレフィックスがVRPによってカバーされ、ルートプレフィックスの長さがVRP最大長以下であり、ルートオリジンASNがVRP ASNに等しい場合、ルートプレフィックスはVRPと一致すると言われます。
Given these definitions, any given BGP Route will be found to have one of the following validation states:
これらの定義を前提として、特定のBGPルートは次の検証状態のいずれかであることがわかります。
o NotFound: No VRP Covers the Route Prefix.
o NotFound：ルートプレフィックスをカバーするVRPはありません。
o Valid: At least one VRP Matches the Route Prefix.
o 有効：少なくとも1つのVRPがルートプレフィックスに一致します。
o Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches it.
o 無効：少なくとも1つのVRPがルートプレフィックスをカバーしていますが、一致するVRPがありません。
We observe that no VRP can have the value "NONE" as its VRP ASN. Thus, a Route whose Origin ASN is "NONE" cannot be Matched by any VRP. Similarly, no valid Route can have an Origin ASN of zero [AS0]. Thus, no Route can be Matched by a VRP whose ASN is zero.
どのVRPもそのVRP ASNとして値「NONE」を持つことができないことがわかります。したがって、発信元ASNが「NONE」であるルートは、どのVRPにも一致しません。同様に、有効なルートはゼロ[AS0]のオリジンASNを持つことができません。したがって、ASNがゼロであるVRPが一致するルートはありません。
When a BGP speaker receives an UPDATE from a neighbor, it SHOULD perform a lookup as described above for each of the Routes in the UPDATE message. The lookup SHOULD also be applied to routes that are redistributed into BGP from another source, such as another protocol or a locally defined static route. An implementation MAY provide configuration options to control which routes the lookup is applied to. The validation state of the Route MUST be set to reflect the result of the lookup. The implementation should consider the validation state as described in the document as a local property or attribute of the Route. If validation is not performed on a Route, the implementation SHOULD initialize the validation state of such a route to "NotFound".
BGPスピーカーがネイバーからUPDATEを受信すると、UPDATEメッセージ内の各ルートに対して上記のようにルックアップを実行する必要があります（SHOULD）。ルックアップは、別のプロトコルやローカルに定義された静的ルートなど、別のソースからBGPに再配布されるルートにも適用する必要があります（SHOULD）。実装は、ルックアップが適用されるルートを制御するための構成オプションを提供する場合があります。ルートの検証状態は、ルックアップの結果を反映するように設定する必要があります。実装では、ドキュメントで説明されている検証状態をルートのローカルプロパティまたは属性と見なす必要があります。ルートで検証が実行されない場合、実装はそのようなルートの検証状態を「NotFound」に初期化する必要があります（SHOULD）。
Use of the validation state is discussed in Sections 3 and 5. An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so.
検証状態の使用については、セクション3と5で説明します。明示的に設定しない限り、実装は、ルートをAdj-RIB-Inから、またはその検証状態の副作用として決定プロセスでの考慮から除外してはなりません。
We observe that a Route can be Matched or Covered by more than one VRP. This procedure does not mandate an order in which VRPs must be visited; however, the validation state output is fully determined.
ルートは複数のVRPで一致またはカバーされる可能性があることがわかります。この手順では、VRPにアクセスする必要がある順序は必須ではありません。ただし、検証状態の出力は完全に決定されます。
The following pseudo-code illustrates the procedure above. In case of ambiguity, the procedure above, rather than the pseudo-code, should be taken as authoritative.
次の疑似コードは、上記の手順を示しています。あいまいな場合は、疑似コードではなく、上記の手順を信頼できるものと見なしてください。
result = BGP_PFXV_STATE_NOT_FOUND;
結果= BGP_PFXV_STATE_NOT_FOUND;
//Iterate through all the Covering entries in the local VRP
//database, pfx_validate_table.
entry = next_lookup_result(pfx_validate_table, route_prefix);
while (entry != NULL) {
prefix_exists = TRUE;
if (route_prefix_length <= entry->max_length) {
if (route_origin_as != NONE
&& entry->origin_as != 0
&& route_origin_as == entry->origin_as) {
result = BGP_PFXV_STATE_VALID;
return (result);
}
}
entry = next_lookup_result(pfx_validate_table, input.prefix);
}
//If one or more VRP entries Covered the route prefix, but
//none Matched, return "Invalid" validation state.
if (prefix_exists == TRUE) {
result = BGP_PFXV_STATE_INVALID;
}
return (result);
リターン（結果）;
An implementation MUST provide the ability to match and set the validation state of routes as part of its route policy filtering function. Use of validation state in route policy is elaborated in Section 5. For more details on operational policy considerations, see [ORIGIN-OPS].
実装は、ルートポリシーフィルタリング機能の一部として、ルートの検証状態を照合および設定する機能を提供する必要があります。ルートポリシーでの検証状態の使用については、セクション5で詳しく説明します。運用ポリシーの考慮事項の詳細については、[ORIGIN-OPS]を参照してください。
An implementation MUST also support four-octet AS numbers [RFC6793].
実装は、4オクテットのAS番号もサポートする必要があります[RFC6793]。
Each BGP speaker supporting prefix validation as described in this document is expected to communicate with one or more RPKI caches, each of which stores a local copy of the global RPKI database. The protocol mechanisms used to gather and validate these data and present them to BGP speakers are described in [RFC6810].
このドキュメントで説明されているように、プレフィックス検証をサポートする各BGPスピーカーは、1つ以上のRPKIキャッシュと通信し、それぞれがグローバルRPKIデータベースのローカルコピーを格納します。これらのデータを収集して検証し、BGPスピーカーに提示するために使用されるプロトコルメカニズムは、[RFC6810]で説明されています。
The prefix-to-AS mappings used by the BGP speaker are expected to be updated over time. When a mapping is added or deleted, the implementation MUST re-validate any affected prefixes and run the BGP decision process if needed. An "affected prefix" is any prefix that was matched by a deleted or updated mapping, or could be matched by an added or updated mapping.
BGPスピーカーが使用するプレフィックスからASへのマッピングは、時間の経過とともに更新されることが予想されます。マッピングが追加または削除されると、実装は影響を受けるプレフィックスを再検証し、必要に応じてBGP決定プロセスを実行する必要があります。 「影響を受けるプレフィックス」とは、削除または更新されたマッピングによって一致した、または追加または更新されたマッピングによって一致した可能性がある任意のプレフィックスです。
Once a Route is selected for validation, it is categorized according the procedure given in Section 2. Subsequently, routing policy as discussed in Section 3 can be used to take action based on the validation state.
検証のためにルートが選択されると、セクション2の手順に従って分類されます。その後、セクション3で説明されているルーティングポリシーを使用して、検証状態に基づいてアクションを実行できます。
Policies that could be implemented include filtering routes based on validation state (for example, rejecting all "invalid" routes) or adjusting a route's degree of preference in the selection algorithm based on its validation state. The latter could be accomplished by adjusting the value of such attributes as LOCAL_PREF. Considering invalid routes for BGP decision process is a purely local policy matter and should be done with utmost care.
実装できるポリシーには、検証状態に基づくルートのフィルタリング（たとえば、すべての「無効な」ルートの拒否）、または検証状態に基づく選択アルゴリズムでのルートの優先度の調整が含まれます。後者は、LOCAL_PREFなどの属性の値を調整することで実現できます。 BGP決定プロセスの無効なルートを考慮することは、純粋にローカルポリシーの問題であり、細心の注意を払って行う必要があります。
In some cases (particularly when the selection algorithm is influenced by the adjustment of a route property that is not propagated into Internal BGP (IBGP)) it could be necessary for routing correctness to propagate the validation state to the IBGP peer. This can be accomplished on the sending side by setting a community or extended community based on the validation state, and on the receiving side by matching the (extended) community and setting the validation state.
場合によっては（特に、選択アルゴリズムが内部BGP（IBGP）に伝達されないルートプロパティの調整の影響を受ける場合）、ルーティングの正確さが検証状態をIBGPピアに伝達する必要がある場合があります。これは、検証状態に基づいてコミュニティまたは拡張コミュニティを設定することで送信側で、（拡張）コミュニティを照合して検証状態を設定することで受信側で実行できます。
Although this specification discusses one portion of a system to validate BGP routes, it should be noted that it relies on a database (RPKI or other) to provide validation information. As such, the security properties of that database must be considered in order to determine the security provided by the overall solution. If "invalid" routes are blocked as this specification suggests, the overall system provides a possible denial-of-service vector; for example, if an attacker is able to inject (or remove) one or more records into (or from) the validation database, it could lead an otherwise valid route to be marked as invalid.
この仕様では、BGPルートを検証するシステムの一部について説明していますが、検証情報を提供するデータベース（RPKIまたはその他）に依存していることに注意してください。そのため、ソリューション全体で提供されるセキュリティを判断するには、そのデータベースのセキュリティプロパティを考慮する必要があります。この仕様が示すように「無効な」ルートがブロックされている場合、システム全体がサービス拒否の可能性を提供します。たとえば、攻撃者が検証データベースに（またはそこから）1つ以上のレコードを挿入（または削除）できる場合、それ以外の場合は有効なルートが無効としてマークされる可能性があります。
In addition, this system is only able to provide limited protection against a determined attacker -- the attacker need only prepend the "valid" source AS to a forged BGP route announcement in order to defeat the protection provided by this system.
さらに、このシステムは、特定の攻撃者に対して限定的な保護しか提供できません。このシステムが提供する保護を無効にするには、攻撃者は「有効な」ソースASを偽造されたBGPルートアナウンスに追加するだけで済みます。
This mechanism does not protect against "AS-in-the-middle attacks" or provide any path validation. It only attempts to verify the origin. In general, this system should be thought of more as a protection against misconfiguration than as true "security" in the strong sense.
このメカニズムは、「中間者攻撃」から保護したり、パス検証を提供したりしません。発信元の確認のみを試みます。一般に、このシステムは、強い意味での真の「セキュリティ」というよりは、設定ミスに対する保護として考えるべきです。
The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, Kannan Varadhan, Wes George, Jay Borkenhagen, and Sandra Murphy. The authors are grateful for the feedback from the members of the SIDR working group.
著者は、レックス・フェルナンド、ハンネス・グレドラー、ムーシン・グエノウン、ラス・ハスリー、ジュナイド・イスラー、河野美弥、宮川真、水口タカ、フセイン・ムーフタ、キール・パテル、吉田知也、カンナン・バラダン、ウェス・ジョージ、ジェイ・ボルケンハーゲン、サンドラ・マーフィーに感謝します。著者はSIDRワーキンググループのメンバーからのフィードバックに感謝しています。
Junaid Israr's contribution to this specification was part of his PhD research work and thesis at University of Ottawa.
Junaid Israrによるこの仕様への貢献は、オタワ大学での彼の博士研究活動と論文の一部でした。
[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月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「X.509 Extensions for IP Addresses and AS Identifiers」、RFC 3779、June 2004。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "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月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、2012年2月。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、2012年12月。
[AS0] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing.", Work in Progress, August 2012.
[AS0]クマリ、W。、ブッシュ、R。、シラー、H。、およびK.パテル、「AS 0処理のコディフィケーション」、Work in Progress、2012年8月。
[ORIGIN-OPS] Bush, R., "RPKI-Based Origin Validation Operation", Work in Progress, August 2012.
[ORIGIN-OPS]ブッシュR。、「RPKIベースのオリジン検証操作」、作業中、2012年8月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RFC6810] Bush, R. and R. Austein, "The RPKI/Router Protocol", RFC 6810, January 2013.
[RFC6810] Bush、R。およびR. Austein、「The RPKI / Router Protocol」、RFC 6810、2013年1月。
Authors' Addresses
著者のアドレス
Pradosh Mohapatra Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Pradosh Mohapatra Cisco Systems 170 Vタスマンドライブ、サンホセの95134
EMail: pmohapat@cisco.com
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 USA
EMail: jgs@juniper.net
David Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
David Ward Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: dward@cisco.com
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 USA
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island、WA 98110 USA
EMail: randy@psg.com
Rob Austein Dragon Research Labs
ロブオースタインドラゴン研究所
EMail: sra@hactrn.net