[要約] RFC 7115は、RPKIを基にしたオリジン検証操作に関するものであり、インターネットルーティングのセキュリティを向上させることを目的としています。このRFCは、オリジン検証の手法とプロトコルを提案し、実装と運用のガイドラインを提供しています。
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 7115 Internet Initiative Japan
BCP: 185 January 2014
Category: Best Current Practice
ISSN: 2070-1721
Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)
Resource Public Key Infrastructure（RPKI）に基づくオリジン検証操作
Abstract
概要
Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.
Resource Public Key Infrastructure（RPKI）に基づくBGPオリジン検証の展開には、運用に関する多くの考慮事項があります。このドキュメントでは、最も重要なものを収集して提示しようとしています。 RPKIベースのオリジン検証が引き続き展開され、ダイナミクスがよりよく理解されるようになると、それは進化すると予想されます。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 BCPの詳細については、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/rfc7115.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7115で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
4. Within a Network . . . . . . . . . . . . . . . . . . . . . . 6
5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 6
6. Notes and Recommendations . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
RPKI-based origin validation relies on widespread deployment of the Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and maintained globally is a serious concern from many aspects.
RPKIベースのオリジン検証は、Resource Public Key Infrastructure（RPKI）[RFC6480]の広範な展開に依存しています。 RPKIがどのようにグローバルに配布および維持されるかは、多くの面で深刻な懸念事項です。
While the global RPKI is in the early stages of deployment, there is no single root trust anchor, initial testing is being done by the Regional Internet Registries (RIRs), and there are technical testbeds. It is thought that origin validation based on the RPKI will continue to be deployed incrementally over the next few years. It is assumed that eventually there must be a single root trust anchor for the public address space, see [IAB].
グローバルRPKIは展開の初期段階にありますが、単一のルートトラストアンカーはなく、初期テストは地域インターネットレジストリ（RIR）によって行われており、技術的なテストベッドがあります。 RPKIに基づくオリジン検証は、今後数年間にわたって段階的に導入され続けると考えられています。最終的には、パブリックアドレススペースに対して単一のルートトラストアンカーが存在する必要があると想定されています。[IAB]を参照してください。
Origin validation needs to be done only by an AS's border routers and is designed so that it can be used to protect announcements that are originated by any network participating in Internet BGP routing: large providers, upstream and downstream routers, and by edge networks (e.g., small stub or enterprise networks).
起点の検証は、ASの境界ルーターのみで実行する必要があり、インターネットBGPルーティングに参加している任意のネットワーク（大規模プロバイダー、アップストリームおよびダウンストリームルーター、エッジネットワークなど）によって発信されたアナウンスを保護するために使用できるように設計されています、小規模なスタブまたはエンタープライズネットワーク）。
Origin validation has been designed to be deployed on current routers without significant hardware upgrades. It should be used in border routers by operators from large backbones to small stub/enterprise/ edge networks.
Originの検証は、ハードウェアを大幅にアップグレードすることなく、現在のルーターに導入できるように設計されています。大規模なバックボーンから小さなスタブ/エンタープライズ/エッジネットワークまでの事業者がボーダールーターで使用する必要があります。
RPKI-based origin validation has been designed so that, with prudent local routing policies, there is little risk that what is seen as today's normal Internet routing is threatened by imprudent deployment of the global RPKI; see Section 5.
RPKIベースの発信元検証は、慎重なローカルルーティングポリシーを使用して、今日の通常のインターネットルーティングとして見られるものがグローバルRPKIの不注意な展開によって脅かされるリスクがほとんどないように設計されています。セクション5を参照してください。
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 normative meaning.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は解釈されますRFC 2119 [RFC2119]で説明されているように、すべて大文字で表記されている場合のみ。それらは、規範的な意味なしに、英語の単語として小文字または大文字と小文字が混在して表示される場合もあります。
It is assumed that the reader understands BGP [RFC4271], the RPKI [RFC6480], the RPKI Repository Structure [RFC6481], Route Origin Authorizations (ROAs) [RFC6482], the RPKI to Router Protocol [RFC6810], RPKI-based Prefix Validation [RFC6811], and Ghostbusters Records [RFC6493].
読者がBGP [RFC4271]、RPKI [RFC6480]、RPKIリポジトリ構造[RFC6481]、ルート発信元承認（ROA）[RFC6482]、ルータープロトコルへのRPKI [RFC6810]、RPKIベースのプレフィックス検証を理解していることを前提としています[RFC6811]、Ghostbusters Records [RFC6493]。
The RPKI is a distributed database containing certificates, Certificate Revocation Lists (CRLs), manifests, ROAs, and Ghostbusters Records as described in [RFC6481]. Policies and considerations for RPKI object generation and maintenance are discussed elsewhere.
RPKIは、[RFC6481]で説明されているように、証明書、証明書失効リスト（CRL）、マニフェスト、ROA、およびゴーストバスターレコードを含む分散データベースです。 RPKIオブジェクトの生成と保守に関するポリシーと考慮事項については、別の場所で説明しています。
The RPKI repository design [RFC6481] anticipated a hierarchic organization of repositories, as this seriously improves the performance of relying parties that gather data over a non-hierarchic organization. Publishing parties MUST implement hierarchic directory structures.
RPKIリポジトリー設計[RFC6481]は、リポジトリーの階層的組織を想定していました。これにより、非階層的組織でデータを収集する依存パーティのパフォーマンスが大幅に向上します。パブリッシングパーティは、階層的なディレクトリ構造を実装する必要があります。
A local relying party's valid cache containing all RPKI data may be gathered from the global distributed database using the rsync protocol [RFC5781] and a validation tool such as rcynic [rcynic].
すべてのRPKIデータを含むローカルの証明書利用者の有効なキャッシュは、rsyncプロトコル[RFC5781]とrcynic [rcynic]などの検証ツールを使用して、グローバル分散データベースから収集できます。
A validated cache contains all RPKI objects that the RP has verified to be valid according to the rules for validation RPKI certificates and signed objects; see [RFC6487] and [RFC6488]. Entities that trust the cache can use these RPKI objects without further validation.
検証済みキャッシュには、検証RPKI証明書と署名済みオブジェクトのルールに従ってRPが有効であることが検証されたすべてのRPKIオブジェクトが含まれています。 [RFC6487]と[RFC6488]を参照してください。キャッシュを信頼するエンティティは、さらに検証することなく、これらのRPKIオブジェクトを使用できます。
Validated caches may also be created and maintained from other validated caches. Network operators SHOULD take maximum advantage of this feature to minimize load on the global distributed RPKI database. Of course, the recipient relying parties should re-validate the data.
検証済みキャッシュは、他の検証済みキャッシュから作成および保守することもできます。ネットワークオペレーターは、この機能を最大限に活用して、グローバルな分散RPKIデータベースへの負荷を最小限に抑える必要があります。もちろん、受信者依拠当事者はデータを再検証する必要があります。
As Trust Anchor Locators (TALs) [RFC6490] are critical to the RPKI trust model, operators should be very careful in their initial selection and vigilant in their maintenance.
トラストアンカーロケーター（TAL）[RFC6490]はRPKIの信頼モデルにとって重要であるため、オペレーターは最初の選択に非常に注意し、メンテナンスに注意する必要があります。
Timing of inter-cache synchronization, and synchronization between caches and the global RPKI, is outside the scope of this document, and depends on things such as how often routers feed from the caches, how often the operator feels the global RPKI changes significantly, etc.
キャッシュ間同期、およびキャッシュとグローバルRPKI間の同期のタイミングは、このドキュメントの範囲外であり、ルーターがキャッシュからフィードする頻度、オペレーターがグローバルRPKIの大幅な変化を感じる頻度などに依存します。 。
As inter-cache synchronization within an operator's network does not impact global RPKI resources, an operator may choose to synchronize quite frequently.
オペレーターのネットワーク内のキャッシュ間同期はグローバルRPKIリソースに影響を与えないため、オペレーターはかなり頻繁に同期することを選択できます。
To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol [RFC6810] does not provide object-based security to the router. That is, the router cannot validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data and relies on transport-based security for the data received from the cache. Therefore, the authenticity and integrity of the data from the cache should be well protected; see Section 7 of [RFC6810].
証明書の検証、暗号化操作などを実行する負荷からルーターを解放するために、RPKI-Routerプロトコル[RFC6810]はオブジェクトベースのセキュリティをルーターに提供していません。つまり、ルーターは、既知のトラストアンカーからデータを暗号的に検証できません。ルータはキャッシュを信頼して正しいデータを提供し、キャッシュから受信したデータをトランスポートベースのセキュリティに依存します。したがって、キャッシュからのデータの信頼性と整合性は十分に保護する必要があります。 [RFC6810]のセクション7をご覧ください。
As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One should also consider trust boundaries, routing bootstrap reachability, etc.
RPKIベースのオリジン検証はRPKIデータの可用性に依存しているため、オペレーターは、ローカルルーティング、中間デバイス、長い回線などで発生する可能性のある障害の影響を最小限に抑えるために、これらのデータとサービスを必要とするルーターの近くにRPKIキャッシュを配置する必要があります。信頼境界、ルーティングブートストラップの到達可能性なども考慮する必要があります。
For example, a router should bootstrap from a cache that is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. If a router needs its BGP and/or IGP to converge for the router to reach a cache, once a cache is reachable, the router will then have to reevaluate prefixes already learned via BGP. Such configurations should be avoided if reasonably possible.
たとえば、ルーターは、DNSやルーティングプロトコルなどの他のインフラストラクチャへの依存を最小限に抑えて到達可能なキャッシュからブートストラップする必要があります。ルーターがキャッシュに到達するためにルーターがBGPやIGPに収束する必要がある場合、キャッシュに到達すると、ルーターはBGPを介して学習済みのプレフィックスを再評価する必要があります。このような構成は、合理的に可能であれば回避する必要があります。
If insecure transports are used between an operator's cache and their router(s), the Transport Security recommendations in [RFC6810] SHOULD be followed. In particular, operators MUST NOT use insecure transports between their routers and RPKI caches located in other Autonomous Systems.
オペレーターのキャッシュとルーター間で安全でないトランスポートが使用される場合、[RFC6810]のトランスポートセキュリティの推奨事項に従う必要があります（SHOULD）。特に、オペレーターは、ルーターと他の自律システムにあるRPKIキャッシュとの間で安全でないトランスポートを使用してはなりません（MUST NOT）。
For redundancy, a router should peer with more than one cache at the same time. Peering with two or more, at least one local and others remote, is recommended.
冗長性のために、ルーターは同時に複数のキャッシュとピアリングする必要があります。 2つ以上のピアリング、少なくとも1つのローカルと他のリモートとのピアリングをお勧めします。
If an operator trusts upstreams to carry their traffic, they may also trust the RPKI data those upstreams cache and SHOULD peer with caches made available to them by those upstreams. Note that this places an obligation on those upstreams to maintain fresh and reliable caches and to make them available to their customers. And, as usual, the recipient SHOULD re-validate the data.
オペレーターがアップストリームを信頼してトラフィックを伝送する場合、それらのアップストリームがキャッシュするRPKIデータを信頼し、それらのアップストリームが利用できるキャッシュとピアリングする必要があります。これにより、これらのアップストリームに、フレッシュで信頼性の高いキャッシュを維持し、顧客が利用できるようにする義務が生じます。そして、いつものように、受信者はデータを再検証する必要があります。
A transit provider or a network with peers SHOULD validate origins in announcements made by upstreams, downstreams, and peers. They still should trust the caches provided by their upstreams.
中継プロバイダーまたはピアのあるネットワークは、アップストリーム、ダウンストリーム、およびピアによって行われたアナウンスの発信元を検証する必要があります（SHOULD）。彼らはまだ彼らの上流によって提供されたキャッシュを信頼するべきです。
Before issuing a ROA for a super-block, an operator MUST ensure that all sub-allocations from that block that are announced by other ASes, e.g., customers, have correct ROAs in the RPKI. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be viewed as Invalid; see [RFC6811]. While waiting for all recipients of sub-allocations to register ROAs, the owner of the super-block may use live BGP data to populate ROAs as a proxy, and then safely issue a ROA for the super-block.
スーパーブロックのROAを発行する前に、オペレーターは、他のAS、たとえば顧客によって発表されたそのブロックからのすべてのサブ割り当てがRPKIで正しいROAを持っていることを確認する必要があります。そうでない場合、スーパーブロックにROAを発行すると、ROAのないサブ割り当てのアナウンスが無効と見なされます。 [RFC6811]を参照してください。サブブロックのすべての受信者がROAを登録するのを待っている間、スーパーブロックの所有者は、ライブBGPデータを使用してROAをプロキシとして設定し、スーパーブロックのROAを安全に発行できます。
Use of RPKI-based origin validation removes any need to inject more specifics into BGP to protect against mis-origination of a less specific prefix. Having a ROA for the covering prefix will protect it.
RPKIベースの発信元検証を使用すると、より具体的なプレフィックスの誤発信から保護するために、BGPにより多くの詳細を注入する必要がなくなります。カバーするプレフィックスのROAがあれば保護されます。
To aid translation of ROAs into efficient search algorithms in routers, ROAs should be as precise as possible, i.e., match prefixes as announced in BGP. For example, software and operators SHOULD avoid use of excessive max length values in ROAs unless they are operationally necessary.
ルータでのROAの効率的な検索アルゴリズムへの変換を支援するには、ROAをできるだけ正確にする必要があります。つまり、BGPでアナウンスされたプレフィックスと一致させます。たとえば、ソフトウェアとオペレーターは、運用上必要でない限り、ROAでの最大長の値を過度に使用しないようにする必要があります（SHOULD）。
One advantage of minimal ROA length is that the forged origin attack does not work for sub-prefixes that are not covered by overly long max length. For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.666.0/24. They must attack the whole /16, which is more likely to be noticed because of its size.
最小のROA長さの1つの利点は、過度に長い最大長でカバーされていないサブプレフィックスに対して、偽造オリジン攻撃が機能しないことです。たとえば、10.0.0.0 / 16-24の代わりに10.0.0.0/16と10.0.42.0/24を発行すると、偽造オリジン攻撃は10.0.666.0/24に対して成功しません。彼らは/ 16全体を攻撃する必要があります。これは、サイズが大きいために気付く可能性が高くなります。
Therefore, ROA generation software MUST use the prefix length as the max length if the user does not specify a max length.
したがって、ユーザーが最大長を指定しない場合、ROA生成ソフトウェアは接頭辞の長さを最大長として使用する必要があります。
Operators should be conservative in use of max length in ROAs. For example, if a prefix will have only a few sub-prefixes announced, multiple ROAs for the specific announcements should be used as opposed to one ROA with a long max length.
演算子は、ROAでの最大長の使用に慎重であるべきです。たとえば、プレフィックスで発表されるサブプレフィックスが数個しかない場合、最大長が長い1つのROAではなく、特定のアナウンス用に複数のROAを使用する必要があります。
Operators owning prefix P should issue ROAs for all ASes that may announce P. If a prefix is legitimately announced by more than one AS, ROAs for all of the ASes SHOULD be issued so that all are considered Valid.
プレフィックスPを所有するオペレーターは、Pをアナウンスする可能性のあるすべてのASに対してROAを発行する必要があります。プレフィックスが複数のASによって合法的にアナウンスされる場合、すべてのASのROAを発行して、すべてが有効と見なされるようにする必要があります。
In an environment where private address space is announced in External BGP (eBGP), the operator may have private RPKI objects that cover these private spaces. This will require a trust anchor created and owned by that environment; see [LTA-USE].
プライベートアドレススペースが外部BGP（eBGP）でアナウンスされる環境では、オペレーターはこれらのプライベートスペースをカバーするプライベートRPKIオブジェクトを持っている場合があります。これには、その環境によって作成および所有されるトラストアンカーが必要です。 [LTA-USE]を参照してください。
Operators issuing ROAs may have customers that announce their own prefixes and ASes into global eBGP, but who do not wish to go though the work to manage the relevant certificates and ROAs. Operators SHOULD offer to provision the RPKI data for these customers just as they provision many other things for them.
ROAを発行するオペレーターには、独自のプレフィックスとASをグローバルeBGPにアナウンスするが、関連する証明書とROAを管理するための作業を望まない顧客がいる場合があります。オペレーターは、これらの顧客に他の多くのものをプロビジョニングするのと同じように、これらの顧客にRPKIデータをプロビジョニングすることを提供する必要があります。
An operator using RPKI data MAY choose any polling frequency they wish for ensuring they have a fresh RPKI cache. However, if they use RPKI data as an input to operational routing decisions, they SHOULD ensure local caches inside their AS are synchronized with each other at least every four to six hours.
RPKIデータを使用するオペレーターは、新しいRPKIキャッシュを確保するために希望するポーリング頻度を選択できます。ただし、RPKIデータを運用ルーティング決定への入力として使用する場合、AS内のローカルキャッシュが少なくとも4〜6時間ごとに同期されるようにする必要があります。
Operators should use tools that warn them of any impending ROA or certificate expiry that could affect the validity of their own data. Ghostbusters Records [RFC6493] can be used to facilitate contact with upstream Certification Authorities (CAs) to effect repair.
オペレーターは、自分のデータの有効性に影響を与える可能性のあるすべての差し迫ったROAまたは証明書の期限切れを警告するツールを使用する必要があります。 Ghostbusters Records [RFC6493]を使用して、上流の認証局（CA）との連絡を容易にし、修理を行うことができます。
Origin validation need only be done by edge routers in a network, those which border other networks or ASes.
オリジン検証は、他のネットワークまたはASに隣接するネットワーク内のエッジルーターでのみ行う必要があります。
A validating router will use the result of origin validation to influence local policy within its network; see Section 5. In deployment, this policy should fit into the AS's existing policy, preferences, etc. This allows a network to incrementally deploy validation-capable border routers.
検証ルーターは、起点検証の結果を使用して、ネットワーク内のローカルポリシーに影響を与えます。セクション5を参照してください。展開では、このポリシーはASの既存のポリシー、設定などに適合する必要があります。これにより、ネットワークで検証可能な境界ルーターを段階的に展開できます。
The operator should be aware that RPKI-based origin validation, as any other policy change, can cause traffic shifts in their network. And, as with normal policy shift practice, a prudent operator has tools and methods to predict, measure, modify, etc.
オペレーターは、他のポリシーの変更と同様に、RPKIベースの発信元検証がネットワークでトラフィックシフトを引き起こす可能性があることを認識しておく必要があります。また、通常のポリシーシフトの実践と同様に、賢明なオペレーターには、予測、測定、変更などを行うためのツールと方法があります。
Origin validation based on the RPKI marks a received announcement as having an origin that is Valid, NotFound, or Invalid; see [RFC6811]. How this is used in routing should be specified by the operator's local policy.
RPKIに基づく発信元検証では、受信したアナウンスに、有効、NotFound、または無効の発信元があるとマークします。 [RFC6811]を参照してください。ルーティングでこれをどのように使用するかは、オペレーターのローカルポリシーで指定する必要があります。
Local policy using relative preference is suggested to manage the uncertainty associated with a system in early deployment; local policy can be applied to eliminate the threat of unreachability of prefixes due to ill-advised certification policies and/or incorrect certification data. For example, until the community feels comfortable relying on RPKI data, routing on Invalid origin validity, though at a low preference, MAY occur.
初期導入のシステムに関連する不確実性を管理するために、相対的な優先順位を使用するローカルポリシーが推奨されます。ローカルポリシーを適用して、不適切な認証ポリシーや不適切な認証データが原因で、プレフィックスに到達できないという脅威を排除できます。たとえば、コミュニティがRPKIデータへの依存を快適に感じるまで、無効な発信元の有効性でルーティングしますが、優先度は低くても発生する可能性があります。
Operators should be aware that accepting Invalid announcements, no matter how de-preferenced, will often be the equivalent of treating them as fully Valid. Consider having a ROA for AS 42 for prefix 10.0.0.0/16-24. A BGP announcement for 10.0.666.0/24 from AS 666 would be Invalid. But if policy is not configured to discard it, then longest-match forwarding will send packets toward AS 666, no matter the value of local preference.
オペレーターは、無効なアナウンスを受け入れることは、どのように優先度を低くしても、完全に有効なものとして扱うことと同等であることを認識しておく必要があります。プレフィックス10.0.0.0/16-24のAS 42のROAを検討してください。 AS 666からの10.0.666.0/24のBGPアナウンスは無効です。ただし、ポリシーがそれを破棄するように設定されていない場合、最長一致転送は、ローカルプリファレンスの値に関係なく、AS 666にパケットを送信します。
As origin validation will be rolled out incrementally, coverage will be incomplete for a long time. Therefore, routing on NotFound validity state SHOULD be done for a long time. As the transition moves forward, the number of BGP announcements with validation state NotFound should decrease. Hence, an operator's policy should not be overly strict and should prefer Valid announcements; it should attach a lower preference to, but still use, NotFound announcements, and drop or give a very low preference to Invalid announcements. Merely de-preferencing Invalid announcements is ill-advised; see previous paragraph.
オリジン検証は段階的に展開されるため、カバレッジは長期にわたって不完全になります。したがって、NotFound有効性状態でのルーティングは、長時間行われる必要があります。移行が進むにつれて、検証状態がNotFoundのBGPアナウンスメントの数は減少するはずです。したがって、オペレーターのポリシーは過度に厳格であってはならず、有効なアナウンスを優先する必要があります。 NotFoundアナウンスには低い優先度を付けますが、それでも使用し、Invalidアナウンスを優先するか、ドロップします。無効なアナウンスを単に優先することはお勧めできません。前の段落を参照してください。
Some providers may choose to set Local-Preference based on the RPKI validation result. Other providers may not want the RPKI validation result to be more important than AS_PATH length -- these providers would need to map the RPKI validation result to some BGP attribute that is evaluated in BGP's path selection process after the AS_PATH is evaluated. Routers implementing RPKI-based origin validation MUST provide such options to operators.
一部のプロバイダーは、RPKI検証結果に基づいてLocal-Preferenceを設定することを選択する場合があります。他のプロバイダーは、RPKI検証結果がAS_PATHの長さよりも重要であることを望まない場合があります-これらのプロバイダーは、AS_PATHが評価された後、BGPのパス選択プロセスで評価されるいくつかのBGP属性にRPKI検証結果をマップする必要があります。 RPKIベースの発信元検証を実装するルーターは、そのようなオプションをオペレーターに提供する必要があります。
Local-Preference may be used to carry both the validity state of a prefix along with its traffic engineering (TE) characteristic(s). It is likely that an operator already using Local-Preference will have to change policy so they can encode these two separate characteristics in the same BGP attribute without negative impact or opening privilege escalation attacks. For example, do not encode validation state in higher bits than used for TE.
Local-Preferenceを使用して、プレフィックスの有効性状態とそのトラフィックエンジニアリング（TE）特性の両方を伝達できます。すでにLocal-Preferenceを使用しているオペレーターは、悪影響を与えたり特権昇格攻撃を開始したりせずに、これらの2つの個別の特性を同じBGP属性にエンコードできるようにポリシーを変更する必要があります。たとえば、TEで使用されるよりも高いビットで検証状態をエンコードしないでください。
When using a metric that is also influenced by other local policy, an operator should be careful not to create privilege-upgrade vulnerabilities. For example, if Local Pref is set depending on validity state, peer community signaling SHOULD NOT upgrade an Invalid announcement to Valid or better.
他のローカルポリシーによっても影響を受けるメトリックを使用する場合、オペレーターは特権アップグレードの脆弱性を作成しないように注意する必要があります。たとえば、有効な状態に応じてローカル設定が設定されている場合、ピアコミュニティシグナリングは無効なアナウンスを有効以上にアップグレードするべきではありません（SHOULD NOT）。
Announcements with Valid origins should be preferred over those with NotFound or Invalid origins, if Invalid origins are accepted at all.
無効なオリジンがまったく受け入れられる場合、有効なオリジンのある通知は、NotFoundまたは無効なオリジンのある通知よりも優先されます。
Announcements with NotFound origins should be preferred over those with Invalid origins.
NotFoundオリジンのあるアナウンスは、無効オリジンのあるアナウンスよりも優先されるべきです。
Announcements with Invalid origins SHOULD NOT be used, but may be used to meet special operational needs. In such circumstances, the announcement should have a lower preference than that given to Valid or NotFound.
オリジンが無効なアナウンスは使用すべきではありませんが、特別な運用上のニーズを満たすために使用できます。このような状況では、アナウンスはValidまたはNotFoundに与えられたものよりも低い優先度を持つ必要があります。
When first deploying origin validation, it may be prudent not to drop announcements with Invalid origins until inspection of logs, SNMP, or other data indicates that the correct result would be obtained.
オリジン検証を初めて展開するときは、ログ、SNMP、またはその他のデータを調べて正しい結果が得られることが示されるまで、無効なオリジンのアナウンスを削除しないことが賢明です。
Validity state signaling SHOULD NOT be accepted from a neighbor AS. The validity state of a received announcement has only local scope due to issues such as scope of trust, RPKI synchrony, and management of local trust anchors [LTA-USE].
有効性状態シグナリングは、隣接ASから受け入れられるべきではありません（SHOULD NOT）。信頼の範囲、RPKIの同期、ローカルトラストアンカーの管理[LTA-USE]などの問題により、受信したアナウンスの有効性の状態にはローカルスコープしかありません。
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は、タイミング、更新、フェッチなどに応じて、大まかに整合したビューしか表示しません。したがって、特定のプレフィックスに関するデータが、あるキャッシュまたはルーターに別のキャッシュまたはルーターと異なる場合があります。これに対する「修正」はありません。これは、分散キャッシュを持つ分散データの性質です。
Operators should beware that RPKI caches are loosely synchronized, even within a single AS. Thus, changes to the validity state of prefixes could be different within an operator's network. In addition, there is no guaranteed interval from when an RPKI cache is updated to when that new information may be pushed or pulled into a set of routers via this protocol. This may result in sudden shifts of traffic in the operator's network, until all of the routers in the AS have reached equilibrium with the validity state of prefixes reflected in all of the RPKI caches.
オペレーターは、単一のAS内であっても、RPKIキャッシュが緩やかに同期されていることに注意する必要があります。したがって、プレフィックスの有効性状態の変更は、オペレーターのネットワーク内では異なる可能性があります。また、RPKIキャッシュが更新されてから、このプロトコルを介して一連のルーターに新しい情報がプッシュまたはプルされるまでの間隔は保証されていません。これにより、AS内のすべてのルーターが、すべてのRPKIキャッシュに反映されるプレフィックスの有効性の状態と平衡状態になるまで、オペレーターのネットワークでトラフィックが突然シフトする可能性があります。
It is hoped that testing and deployment will produce advice on cache loading and timing for relying parties.
テストと展開により、キャッシュの読み込みと依存パーティのタイミングに関するアドバイスが得られることが期待されます。
There is some uncertainty about the origin AS of aggregates and what, if any, ROA can be used. The long-range solution to this is the deprecation of AS_SETs; see [RFC6472].
集合体の元のASと、もしあればROAが何を使用できるかについては、不確実性があります。これに対する長期的な解決策は、AS_SETの廃止です。 [RFC6472]を参照してください。
As reliable access to the global RPKI and an operator's caches (and possibly other hosts, e.g., DNS root servers) is important, an operator should take advantage of relying-party tools that report changes in BGP or RPKI data that would negatively affect validation of such prefixes.
グローバルRPKIとオペレーターのキャッシュ（およびおそらくDNSルートサーバーなどの他のホスト）への信頼できるアクセスが重要であるため、オペレーターは、検証に悪影響を与えるBGPまたはRPKIデータの変更を報告する証明書利用者ツールを利用する必要がありますそのような接頭辞。
Operators should be aware that there is a trade-off in placement of an RPKI repository in address space for which the repository's content is authoritative. On one hand, an operator will wish to maximize control over the repository. On the other hand, if there are reachability problems to the address space, changes in the repository to correct them may not be easily accessed by others.
オペレーターは、リポジトリーのコンテンツが信頼できるアドレス空間でのRPKIリポジトリーの配置にはトレードオフがあることを認識しておく必要があります。一方では、オペレーターはリポジトリーの制御を最大化したいと思うでしょう。一方、アドレス空間への到達可能性の問題がある場合、それらを修正するためのリポジトリの変更は、他の人が簡単にアクセスできない可能性があります。
Operators who manage certificates should associate RPKI Ghostbusters Records (see [RFC6493]) with each publication point they control. These are publication points holding the CRL, ROAs, and other signed objects issued by the operator, and made available to other ASes in support of routing on the public Internet.
証明書を管理するオペレーターは、RPKI Ghostbusters Records（[RFC6493]を参照）を、彼らが管理する各公開ポイントに関連付ける必要があります。これらは、CRL、ROA、およびオペレーターによって発行されたその他の署名付きオブジェクトを保持する公開ポイントであり、パブリックインターネットでのルーティングをサポートする他のASが利用できるようになります。
Routers that perform RPKI-based origin validation must support Four-octet AS Numbers (see [RFC6793]), as, among other things, it is not reasonable to generate ROAs for AS 23456.
RPKIベースの発信元検証を実行するルーターは、4オクテットのAS番号（[RFC6793]を参照）をサポートする必要があります。これは、AS 23456のROAを生成することが妥当でないためです。
Software that produces filter lists or other control forms for routers where the target router does not support Four-octet AS Numbers (see [RFC6793]) must be prepared to accept four-octet AS Numbers and generate the appropriate two-octet output.
ターゲットルーターが4オクテットのAS番号（[RFC6793]を参照）をサポートしていないルーターのフィルターリストやその他の制御フォームを作成するソフトウェアは、4オクテットのAS番号を受け入れ、適切な2オクテットの出力を生成できるように準備する必要があります。
As a router must evaluate certificates and ROAs that are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour.
ルーターは時間に依存する証明書とROAを評価する必要があるため、ルーターのクロックは約1時間の許容誤差で正確でなければなりません。
Servers should provide time service, such as NTPv4 [RFC5905], to client routers.
サーバーは、NTPv4 [RFC5905]などのタイムサービスをクライアントルーターに提供する必要があります。
As the BGP origin AS of an update is not signed, origin validation is open to malicious spoofing. Therefore, RPKI-based origin validation is expected to deal only with inadvertent mis-advertisement.
更新のBGPオリジンASは署名されていないため、オリジンの検証は悪意のあるスプーフィングに対して開かれています。したがって、RPKIベースのオリジン検証は、不注意による誤広告のみを処理することが期待されています。
Origin validation does not address the problem of AS_PATH validation. Therefore, paths are open to manipulation, either malicious or accidental.
オリジン検証は、AS_PATH検証の問題に対処していません。したがって、パスは悪意のある、または偶発的な操作の可能性があります。
As BGP does not ensure that traffic will flow via the paths it advertises, the data plane may not follow the control plane.
BGPはアドバタイズするパスを介してトラフィックが流れることを保証しないため、データプレーンがコントロールプレーンをたどらない場合があります。
Be aware of the class of privilege escalation issues discussed in Section 5 above.
上記のセクション5で説明した特権昇格のクラスの問題に注意してください。
The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin, Jay Borkenhagen, Wes George, Seiichi Kawamura, Steve Kent, Pradosh Mohapatra, Chris Morrow, Sandy Murphy, Eric Osterweil, Keyur Patel, Heather and Jason Schiller, John Scudder, Kotikalapudi Sriram, Maureen Stillman, and Dave Ward.
著者は、Shane Amante、Rob Austein、Steve Bellovin、Jay Borkenhagen、Wes George、Seiichi Kawamura、Steve Kent、Pradosh Mohapatra、Chris Morrow、Sandy Murphy、Eric Osterweil、Keyur Patel、Heather and Jason Schiller、John Scudder、Kotikalapudiに感謝します。スリラム、モーリーンスティルマン、デイブワード。
[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月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月。
[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月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490] Huston、G.、Weiler、S.、Michaelson、G。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）Trust Anchor Locator」、RFC 6490、2012年2月。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.
[RFC6493] Bush、R。、「The Resource Public Key Infrastructure（RPKI）Ghostbusters Record」、RFC 6493、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月。
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013.
[RFC6810] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol」、RFC 6810、2013年1月。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、2013年1月。
[LTA-USE] Bush, R., "RPKI Local Trust Anchor Use Cases", Work in Progress, September 2013.
[LTA-USE]ブッシュR。、「RPKI Local Trust Anchor Use Cases」、作業中、2013年9月。
[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月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler、S.、Ward、D。、およびR. Housley、「rsync URIスキーム」、RFC 5781、2010年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
[RFC6472]クマリW.およびK.スリラム、「BGPでAS_SETおよびAS_CONFED_SETを使用しない場合の推奨事項」、BCP 172、RFC 6472、2011年12月
[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月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）の署名付きオブジェクトテンプレート」、RFC 6488、2012年2月。
[IAB] IAB, "IAB statement on the RPKI", January 2010, <http://www.iab.org/documents/ correspondence-reports-documents/docs2010/ iab-statement-on-the-rpki/>.
[IAB] IAB、「RPKIに関するIAB声明」、2010年1月、<http://www.iab.org/documents/correspondation-reports-documents/docs2010/iab-statement-on-the-rpki/>。
[rcynic] "rcynic RPKI validator", November 2013, <http://rpki.net/rcynic>.
[rcynic]「rcynic RPKI validator」、2013年11月、<http://rpki.net/rcynic>。
Author's Address
著者のアドレス
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US
ランディブッシュインターネットイニシアティブ日本5147 Crystal Springsベインブリッジ島、ワシントン98110 US
EMail: randy@psg.com