[要約] RFC 8211は、RPKIにおける認証機関（CA）またはリポジトリマネージャによる不利な措置に関するガイドラインです。このRFCの目的は、RPKIの信頼性とセキュリティを向上させるために、CAやリポジトリマネージャが不適切な行動を取らないようにすることです。
Internet Engineering Task Force (IETF) S. Kent
Request for Comments: 8211 BBN Technologies
Category: Informational D. Ma
ISSN: 2070-1721 ZDNS
September 2017
Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)
証明機関（CA）またはリソースパブリックキーインフラストラクチャ（RPKI）のリポジトリマネージャーによる有害なアクション
Abstract
概要
This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.
このドキュメントでは、CAまたはその下位CAに関連付けられているインターネット番号リソース（INR）に悪影響を与える可能性のある、RPKI内の証明機関（CA）または独立したリポジトリマネージャーによる、またはそれに対するアクションを分析します。分析は、影響を受けるINR保有者の観点から行われます。分析は、CA（または独立したリポジトリマネージャー）によって制御され、依拠当事者（RP）によってフェッチされた、RPKIリポジトリ内のデータ項目の調査に基づいています。分析は包括的なものではありません。これは、CAまたはリポジトリマネージャーによるエラーまたは攻撃がRPKIおよびRPKIデータに基づくルーティングの決定に影響を与える可能性があるいくつかの方法を分析するための秩序だった方法を表します。
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 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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8211.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8211で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Certificate Revocation List . . . . . . . . . . . . . . . 12
2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 17
2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 18
3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 19
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 22
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
In the context of this document, any change to the Resource Public Key Infrastructure (RPKI) [RFC6480] that diminishes the set of Internet Number Resources (INRs) associated with an INR holder, and that is contrary to the holder's wishes, is termed "adverse". This analysis is done from the perspective of an affected INR holder. An action that results in an adverse charge (as defined above) may be the result of an attack on a CA [RFC7132], an error by a CA, or an error by or an attack on a repository operator. Note that the CA that allocated the affected INRs may be acting in accordance with established policy; thus, the change may be contractually justified even though viewed as adverse by the INR holder. This document examines the implications of adverse actions within the RPKI with respect to INRs, irrespective of the cause of the actions.
このドキュメントのコンテキストでは、INR保有者に関連付けられた一連のインターネット番号リソース（INR）を縮小し、保有者の希望に反するResource Public Key Infrastructure（RPKI）[RFC6480]への変更は、「逆」。この分析は、影響を受けるINR保有者の観点から行われます。 （上記で定義されたように）不利な請求が発生するアクションは、CAへの攻撃[RFC7132]、CAによるエラー、またはリポジトリオペレーターによるエラーまたは攻撃の結果である可能性があります。影響を受けるINRを割り当てたCAは、確立されたポリシーに従って動作している可能性があることに注意してください。したがって、INR保有者から不利であると見なされていても、変更は契約上正当化される可能性があります。このドキュメントでは、アクションの原因に関係なく、RPKI内でのINRに関する有害なアクションの影響を調べます。
Additionally, when a Route Origin Authorization (ROA) or router certificate is created that "competes" with an existing ROA or router certificate (respectively), the creation of the new ROA or router certificate may be adverse. (A newer ROA competes with an older ROA if the newer ROA points to a different Autonomous System Number (ASN), contains the same or a more specific prefix, and is issued by a different CA. A newer router certificate competes with an older router certificate if the newer one contains the same ASN, contains a different public key, and is issued by a different CA.) Note that transferring resources or changing of upstream providers may yield competing ROAs and/or router certificates under some circumstances. Thus, not all instances of competition are adverse actions.
さらに、既存のROAまたはルーター証明書と（それぞれ）競合するルート生成元承認（ROA）またはルーター証明書が作成されると、新しいROAまたはルーター証明書の作成が悪影響を受ける可能性があります。 （新しいROAが異なる自律システム番号（ASN）を指し、同じまたはより具体的なプレフィックスを含み、異なるCAによって発行された場合、新しいROAは古いROAと競合します。新しいルーター証明書は古いルーターと競合します新しいものに同じASNが含まれ、異なる公開鍵が含まれ、別のCAによって発行された場合、証明書。したがって、競争のすべての事例が不利な行動であるとは限りません。
As noted above, adverse changes to RPKI data may arise due to several types of causes. A CA may make a mistake in managing the RPKI objects it signs, or it may be subject to an attack. If an attack allows an adversary to use the private key of that CA to sign RPKI objects, then the effect is analogous to the CA making mistakes. There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to make adverse changes to RPKI data. In many cases, such actions may be hard to distinguish from mistakes or attacks, other than with respect to the time required to remedy the adverse action. (Presumably, the CA will take remedial action when a mistake or an attack is detected, so the effects are similar in these cases. If a CA has been legally compelled to effect an adverse change, remediation will likely not be swift.)
上記のように、RPKIデータへの悪影響は、いくつかのタイプの原因により発生する可能性があります。 CAは、署名したRPKIオブジェクトの管理に誤りを犯したり、攻撃を受けたりする可能性があります。攻撃者がそのCAの秘密鍵を使用してRPKIオブジェクトに署名することを許可する場合、その影響はCAがミスをすることに似ています。また、CAまたはリポジトリオペレーターは、RPKIデータに不利な変更を加えることを強制する法的措置の対象となる可能性もあります。多くの場合、そのようなアクションは、有害なアクションを修正するために必要な時間に関して以外に、ミスや攻撃と区別するのが難しい場合があります。 （おそらく、CAは、ミスや攻撃が検出されたときに是正措置を講じるので、これらの場合でも効果は同じです。CAが法的に不利な変更を強いられている場合、是正は迅速ではありません。）
This document analyzes the various types of actions by a CA (or an independent repository operator) that can adversely affect the INRs associated with that CA, as well as the INRs of subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository operator) and fetched by RPs.
このドキュメントでは、CA（または独立したリポジトリオペレーター）によるさまざまな種類のアクションを分析します。これらのアクションは、そのCAに関連付けられたINR、および下位CAのINRに悪影響を与える可能性があります。分析は、CA（または独立したリポジトリオペレーター）によって制御され、RPによってフェッチされる、RPKIリポジトリ内のデータ項目の調査に基づいています。
This section enumerates the RPKI repository system objects and examines how changes to them affect Route Origin Authorizations (ROAs) and router certificate validation. Identifiers are assigned to errors for reference by later sections of this document. Note that not all adverse actions may be encompassed by this taxonomy.
このセクションでは、RPKIリポジトリシステムオブジェクトを列挙し、それらに対する変更がRoute Origin Authorization（ROA）およびルーター証明書の検証にどのように影響するかを調べます。識別子は、このドキュメントの後のセクションで参照できるようにエラーに割り当てられます。すべての不利な行動がこの分類法に含まれるとは限らないことに注意してください。
The RPKI repository [RFC6481] contains a number of (digitally signed) objects that are fetched and processed by RPs. Until the deployment of BGPsec [RFC8205], the principal goal of the RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds address space to an ASN. A ROA can be used to verify BGP announcements with respect to route origin [RFC6483]. The most important objects in the RPKI for origin validation are ROAs; all of the other RPKI objects exist to enable the validation of ROAs in a fashion consistent with the INR allocation system. Thus, errors that result in changes to a ROA, or to RPKI objects needed to validate a ROA, can cause RPs to reach different (from what was intended) conclusions about the validity of the bindings expressed in a ROA.
RPKIリポジトリ[RFC6481]には、RPによってフェッチおよび処理される多数の（デジタル署名された）オブジェクトが含まれています。 BGPsec [RFC8205]が展開されるまで、RPKIの主な目的は、RPがROAを検証できるようにすることです[RFC6482]。 ROAはアドレス空間をASNにバインドします。 ROAを使用して、ルートの起点に関するBGPアナウンスを検証できます[RFC6483]。起点検証のためのRPKIで最も重要なオブジェクトはROAです。他のすべてのRPKIオブジェクトは、INR割り当てシステムと一貫した方法でROAの検証を可能にするために存在します。したがって、ROA、またはROAの検証に必要なRPKIオブジェクトの変更につながるエラーにより、RPは、ROAで表現されたバインディングの有効性に関する（意図したものとは異なる）結論に到達する可能性があります。
When BGPsec is deployed, router certificates [RFC8209] will be added to repository publication points. These are end entity (EE) certificates used to verify signatures applied to BGP update data and to enable path validation [RFC8205]. Router certificates are as important to path validation as ROAs are to origin validation.
BGPsecが展開されると、ルーター証明書[RFC8209]がリポジトリ公開ポイントに追加されます。これらは、BGP更新データに適用された署名を検証し、パス検証を有効にするために使用されるエンドエンティティ（EE）証明書です[RFC8205]。ルーター証明書は、ROAが発信元検証に対するものであるのと同様に、パス検証にとっても重要です。
The objects contained in the RPKI repository are of two types: conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The latter make use of a common encapsulation format [RFC6488] based on the Cryptographic Message Syntax (CMS) [RFC5652]. A syntax error in this common format will cause an RP to reject the object, e.g., a ROA or manifest, as invalid.
RPKIリポジトリに含まれるオブジェクトには、従来のPKIオブジェクト（証明書と証明書失効リスト（CRL））とRPKI固有の署名付きオブジェクトの2つのタイプがあります。後者は、暗号化メッセージ構文（CMS）[RFC5652]に基づく一般的なカプセル化形式[RFC6488]を利用します。この一般的な形式の構文エラーにより、RPはオブジェクト（ROAまたはマニフェストなど）を無効として拒否します。
Adverse actions take several forms:
有害な行動にはいくつかの形態があります。
* Deletion (D) is defined as removing an object from a publication point, without the permission of the INR holder.
* 削除（D）は、INR所有者の許可なしに、公開ポイントからオブジェクトを削除することと定義されています。
* Suppression (S) is defined as not deleting an object, or not publishing an object, as intended by an INR holder. This action also includes retaining a prior version of an object in a publication point when a newer version is available for publication.
* 抑制（S）は、INR所有者の意図どおりに、オブジェクトを削除しない、またはオブジェクトを公開しないと定義されています。このアクションには、新しいバージョンが発行可能になったときに、オブジェクトの以前のバージョンを発行ポイントに保持することも含まれます。
* Corruption (C) is defined as modification of a signed object in a fashion not requiring access to the private key used to sign the object. Thus, a corrupted object will not carry a valid signature. Implicitly, the corrupted object replaces the legitimate version.
* 破損（C）は、オブジェクトの署名に使用された秘密鍵へのアクセスを必要としない方法での署名付きオブジェクトの変更として定義されます。したがって、破損したオブジェクトには有効な署名がありません。暗黙的に、破損したオブジェクトが正当なバージョンを置き換えます。
* Modification (M) is defined as publishing a syntactically valid, verifiable version of an object that differs from the (existing) version authorized by the INR holder. Implicitly, the legitimate version of the affected object is deleted and replaced by the modified object.
* 変更（M）は、INR保有者によって承認された（既存の）バージョンとは異なるオブジェクトの構文的に有効で検証可能なバージョンを公開することと定義されています。暗黙的に、影響を受けるオブジェクトの正規バージョンが削除され、変更されたオブジェクトに置き換えられます。
* Revocation (R) is defined as revoking a certificate (EE or CA) by placing its Serial Number on the appropriate CRL, without authorization of the INR holder.
* 失効（R）は、INR所有者の許可なしに、適切なCRLにシリアル番号を配置することにより、証明書（EEまたはCA）を失効させることと定義されます。
* Injection (I) is defined as introducing an instance of a signed object into a publication point (without authorization of the INR holder). It assumes that the signature on the object will be viewed as valid by RPs.
* 注入（I）は、署名されたオブジェクトのインスタンスを（INR所有者の許可なしに）公開ポイントに導入することと定義されています。オブジェクトの署名がRPによって有効であると見なされることを前提としています。
The first three of these actions (deletion, suppression, and corruption) can be effected by any entity that manages the publication point of the affected INR holder. Also, an entity with the ability to act as a man-in-the-middle between an RP and a repository can effect these actions with respect to the RP in question.
これらのアクションの最初の3つ（削除、抑制、および破損）は、影響を受けるINR保有者の公開ポイントを管理するエンティティによって影響を受ける可能性があります。また、RPとリポジトリの間の中間者として機能するエンティティは、問題のRPに関してこれらのアクションを実行できます。
The latter three actions (modification, revocation, and injection) nominally require access to the private key of the INR holder.
後者の3つのアクション（変更、取り消し、および挿入）では、名目上、INR所有者の秘密鍵へのアクセスが必要です。
All six of these actions also can be effected by a parent CA. A parent CA could reissue the INR holder's CA certificate, but with a different public key, matching a private key to which the parent CA has access. The CA could generate new signed objects using the private key associated with the reissued certificate and publish these objects at a location of its choosing.
これらの6つのアクションはすべて、親CAからも影響を受ける可能性があります。親CAは、INR所有者のCA証明書を再発行できますが、親CAがアクセスできる秘密キーと一致する別の公開キーを使用します。 CAは、再発行された証明書に関連付けられた秘密キーを使用して新しい署名付きオブジェクトを生成し、選択した場所でこれらのオブジェクトを公開できます。
Most of these actions may be performed independently or in combination with one another. For example, a ROA may be revoked and deleted or revoked and replaced with a modified ROA. Where appropriate, the analysis of adverse actions will distinguish between individual actions, or combinations thereof, that yield different outcomes for RPs. Recall that the focus of the analysis is the impact on ROAs and router certificates, with respect to RP processing.
これらのアクションのほとんどは、独立して、または互いに組み合わせて実行できます。たとえば、ROAは取り消されて削除されるか、取り消されて変更されたROAに置き換えられます。適切な場合、有害作用の分析は、RPに異なる結果をもたらす個々の作用またはそれらの組み合わせを区別します。 RP処理に関して、分析の焦点はROAとルーター証明書への影響であることを思い出してください。
The following sections examine how the actions enumerated above affect objects in the RPKI repository system. Each action is addressed in order (deletion, suppression, corruption, modification, revocation, and injection) for each object, making it easy to see how each action has been considered with regard to each object. (For the Ghostbusters Record [RFC6493], we condensed the discussion of the actions because the impact is the same in each case.)
以下のセクションでは、上記で列挙したアクションがRPKIリポジトリシステム内のオブジェクトにどのように影響するかを調べます。各アクションは、オブジェクトごとに順番に（削除、抑制、破損、変更、取り消し、および挿入）対処されるため、各オブジェクトに関して各アクションがどのように考慮されたかを簡単に確認できます。 （Ghostbusters Record [RFC6493]の場合、影響はどちらの場合も同じであるため、アクションの説明を凝縮しました。）
Every INR holder is represented by one or more CA certificates. An INR holder has multiple CA certificates if it holds resources acquired from different sources. Also, every INR holder has more than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916].
すべてのINR保有者は、1つ以上のCA証明書によって表されます。 INR保有者は、異なるソースから取得したリソースを保持している場合、複数のCA証明書を持っています。また、すべてのINR保有者は、キーのロールオーバー[RFC6489]およびアルゴリズムのロールオーバー[RFC6916]中に複数のCA証明書を持っています。
If a publication point is not a "leaf" in the RPKI hierarchy, then the publication point will contain one or more CA certificates, each representing a subordinate CA. Each subordinate CA certificate contains a Subject Information Access (SIA) pointer to the publication point where the signed objects associated with that CA can be found [RFC6487].
公開ポイントがRPKI階層の「リーフ」でない場合、公開ポイントには、それぞれが下位CAを表す1つ以上のCA証明書が含まれます。各下位CA証明書には、そのCAに関連付けられた署名付きオブジェクトが見つかる公開ポイントへのサブジェクト情報アクセス（SIA）ポインターが含まれています[RFC6487]。
A CA certificate is a complex data structure; thus, errors in that structure may have different implications for RPs depending on the specific data that is in error.
CA証明書は複雑なデータ構造です。したがって、その構造のエラーは、エラーのある特定のデータに応じて、RPに異なる影響を与える可能性があります。
Adverse actions against a CA certificate can cause the following errors:
CA証明書に対する有害なアクションにより、次のエラーが発生する可能性があります。
A-1.1 Deletion
A-1.1削除
A-1.1.1 Deletion of a CA certificate would cause an RP to not be able to locate signed objects generated by that CA, except those that have been cached by the RP. Thus, an RP would be unaware of changed or new (issued after the cached data) INR bindings asserted in subordinate ROAs, and the RP would be unable to validate new or changed router certificates. If the missed objects were intended to replace ROAs or router certificates prior to expiration, then when those objects expire, RPs may cease to view them as valid. As a result, valid routes may be viewed as NotFound or Invalid.
A-1.1.1 CA証明書を削除すると、RPによってキャッシュされたものを除いて、RPはそのCAによって生成された署名付きオブジェクトを見つけることができなくなります。したがって、RPは、下位ROAでアサートされた変更または新規（キャッシュされたデータの後に発行された）INRバインディングを認識せず、RPは新規または変更されたルーター証明書を検証できません。失われたオブジェクトが有効期限の前にROAまたはルーター証明書を置き換えることを意図していた場合、それらのオブジェクトが期限切れになると、RPはそれらを有効と見なさなくなる可能性があります。その結果、有効なルートがNotFoundまたはInvalidと表示される場合があります。
A-1.2 Suppression
A-1.2抑制
A-1.2.1 If publication of a CA certificate is suppressed, the impact depends on what changes appeared in the suppressed certificate. If the SIA value changed, the effect would be the same as in A-1.1 or A-1.4.3. If the [RFC3779] extensions in the suppressed certificate changed, the impact would be the same as in A-1.4.1. If the Authority Information Access (AIA) extension changed in the suppressed certificate, the impact would be the same as in A-1.4.4. Suppression of a renewed/ re-issued certificate may cause an old certificate to expire and thus be rejected by RPs.
A-1.2.1 CA証明書の公開が抑制されている場合、影響は抑制された証明書に表示された変更によって異なります。 SIA値が変更された場合、効果はA-1.1またはA-1.4.3と同じになります。抑制された証明書の[RFC3779]拡張が変更された場合、影響はA-1.4.1と同じです。抑制された証明書で機関情報アクセス（AIA）拡張が変更された場合、影響はA-1.4.4と同じです。更新/再発行された証明書を抑制すると、古い証明書が期限切れになり、RPによって拒否される場合があります。
A-1.3 Corruption
A-1.3破損
A-1.3.1 Corruption of a CA certificate will cause it to be rejected by RPs. In turn, this may cause subordinate signed objects to become invalid. An RP that has cached the subtree under the affected CA certificate may continue to view it as valid, until objects expire. But changed or new objects might not be retrieved, depending on details of the design of the RP software. Thus, this action may be equivalent to suppressing changes to the affected subtree.
A-1.3.1 CA証明書が破損すると、RPによって拒否されます。これにより、下位の署名付きオブジェクトが無効になる可能性があります。影響を受けるCA証明書の下にサブツリーをキャッシュしたRPは、オブジェクトが期限切れになるまで、それを有効であると見なし続ける場合があります。ただし、RPソフトウェアの設計の詳細によっては、変更されたオブジェクトや新しいオブジェクトが取得されない場合があります。したがって、このアクションは、影響を受けるサブツリーへの変更を抑制することと同じです。
A-1.4 Modification
A-1.4変更
A-1.4.1 If a CA certificate is modified but still conforms to the RPKI certificate profile [RFC7935], it will be accepted by RPs. If an [RFC3779] extension in this certificate is changed to exclude INRs that were previously present, then subordinate signed objects will become invalid if they rely on the excised INRs. If these objects are CA certificates, their subordinate signed objects will be treated as invalid. If the objects are ROAs, the binding expressed by the affected ROAs will be ignored by RPs. If the objects are router certificates, BGPsec_PATH attributes [RFC8205] verifiable under these certificates will be considered invalid.
A-1.4.1 CA証明書が変更されても、RPKI証明書プロファイル[RFC7935]に準拠している場合、それはRPによって受け入れられます。この証明書の[RFC3779]拡張機能を変更して、以前存在していたINRを除外すると、削除されたINRに依存している場合、下位の署名付きオブジェクトは無効になります。これらのオブジェクトがCA証明書である場合、下位の署名付きオブジェクトは無効として扱われます。オブジェクトがROAの場合、影響を受けるROAによって表されるバインディングはRPによって無視されます。オブジェクトがルーター証明書の場合、これらの証明書の下で検証可能なBGPsec_PATH属性[RFC8205]は無効と見なされます。
A-1.4.2 If the SIA extension of a CA certificate is modified to refer to another publication point, this will cause an RP to look at another location for subordinate objects. This could cause RPs to not acquire the objects that the INR holder intended to be retrieved -- manifests, ROAs, router certificates, Ghostbuster Records, or any subordinate CA certificates associated with that CA. If the objects at this new location contain invalid signatures or appear to be corrupted, they may be rejected. In this case, cached versions of the objects may be viewed as valid by an RP, until they expire. If the objects at the new location have valid signatures and pass path validation checks, they will replace the cached objects, effectively replacing the INR holder's objects.
A-1.4.2 CA証明書のSIA拡張機能が別の公開ポイントを参照するように変更された場合、RPは下位オブジェクトの別の場所を調べます。これにより、RPは、INRホルダーが取得しようとしたオブジェクト（マニフェスト、ROA、ルーター証明書、Ghostbusterレコード、またはそのCAに関連付けられている下位CA証明書）を取得できなくなる可能性があります。この新しい場所にあるオブジェクトに無効な署名が含まれている、または壊れているように見える場合、それらは拒否される可能性があります。この場合、オブジェクトのキャッシュされたバージョンは、有効期限が切れるまで、RPによって有効と見なされる可能性があります。新しい場所のオブジェクトに有効な署名があり、パス検証チェックに合格すると、キャッシュされたオブジェクトが置き換えられ、INRホルダーのオブジェクトが効果的に置き換えられます。
A-1.4.3 If the AIA extension in a CA certificate is modified, it would point to a different CA certificate, not the parent CA certificate. This extension is used only for path discovery, not path validation. Path discovery in the RPKI is usually performed on a top-down basis, starting with trust anchors (TAs) and recursively descending the RPKI hierarchy. Thus, there may be no impact on the ability of clients to acquire and validate certificates if the AIA is modified.
A-1.4.3 CA証明書のAIA拡張機能が変更された場合、親CA証明書ではなく、別のCA証明書を指します。この拡張機能は、パスの検証ではなく、パスの検出にのみ使用されます。 RPKIでのパス検出は通常、トラストアンカー（TA）から始まり、RPKI階層を再帰的に下降するトップダウンベースで実行されます。したがって、AIAが変更されても、クライアントが証明書を取得して検証する能力に影響はありません。
A-1.4.4 If the Subject Public Key Info (and Subject Key Identifier extension) in a CA certificate is modified to contain a public key corresponding to a private key held by the parent, the parent could sign objects as children of the affected CA certificate. With this capability, the parent could replace the INR holder, issuing new signed objects that would be accepted by RPs (as long as they do not violate the path validation criteria). This would enable the parent to effect modification, revocation, and injection actions against all of the objects under the affected CA certificate, including subordinate CA certificates. (Note that key rollover also yields a new CA certificate. However, the new certificate will coexist with the old one for a while, which may help distinguish this legitimate activity from an adverse action.)
A-1.4.4 CA証明書のサブジェクト公開鍵情報（およびサブジェクト鍵識別子拡張）が、親が保持する秘密鍵に対応する公開鍵を含むように変更された場合、親は影響を受けるCAの子としてオブジェクトに署名できます証明書。この機能を使用すると、親はINRホルダーを置き換えて、RPによって受け入れられる新しい署名付きオブジェクトを発行できます（パス検証基準に違反していない限り）。これにより、親は、影響を受けるCA証明書（下位のCA証明書を含む）の下にあるすべてのオブジェクトに対して変更、取り消し、および注入アクションを実行できます。 （キーのロールオーバーでも新しいCA証明書が生成されることに注意してください。ただし、新しい証明書はしばらくの間古い証明書と共存します。これは、この正当なアクティビティと有害なアクションを区別するのに役立ちます。）
A-1.5 Revocation
A-1.5失効
A-1.5.1 If a CA certificate is revoked, an RP will treat as invalid all subordinate signed objects, both immediate and transitive. The effects are essentially the same as described in A-3.4.2.
A-1.5.1 CA証明書が取り消された場合、RPは、即時および推移の両方のすべての下位の署名付きオブジェクトを無効として扱います。効果は、基本的にA-3.4.2で説明したものと同じです。
A-1.6 Injection
A-1.6注射
A-1.6.1 If a CA certificate is injected, the impact will depend on the data contained in the injected certificate. Changes will generally be equivalent to modification actions as described in A-1.4.
A-1.6.1 CA証明書が挿入された場合の影響は、挿入された証明書に含まれているデータによって異なります。変更は通常、A-1.4で説明されている変更アクションと同等です。
Each repository publication point contains a manifest [RFC6486]. The RPKI incorporates manifests to enable RPs to detect suppression and/ or substitution of (more recent) publication point objects, as the result of a mistake or attack. A manifest enumerates (by filename) all of the other signed objects at the publication point. The manifest also contains a hash of each enumerated file to enable an RP to determine if the named file content matches what the INR holder identified in the manifest.
各リポジトリ公開ポイントには、マニフェスト[RFC6486]が含まれています。 RPKIにはマニフェストが組み込まれており、RPは、ミスや攻撃の結果として、（より新しい）公開ポイントオブジェクトの抑制や置換を検出できます。マニフェストは、公開ポイントにある他のすべての署名付きオブジェクトを（ファイル名で）列挙します。マニフェストには、RPが名前付きファイルのコンテンツがマニフェストで識別されたINR所有者と一致するかどうかを判断できるように、各列挙ファイルのハッシュも含まれています。
A manifest is an RPKI signed object, so it is validated as per [RFC6488]. If a manifest is modified in a way that causes any of these checks to fail, the manifest will be considered invalid. Suppression of a manifest itself (indicated by a stale manifest) can also cause an RP to not detect suppression of other signed objects at the publication point. (Note that if a manifest's EE certificate expires at the time that the manifest is scheduled to be replaced, a delay in publication will cause the manifest to become invalid, not merely stale. This very serious outcome should be avoided, e.g., by making the manifest EE certificate's notAfter value the same as that of the CA certificate under which it was issued). If a signed object at a publication point can be validated (using the rules applicable for that object type), then an RP may accept that object, even if there is no matching entry for it on the manifest. However, it appears that most RP software ignores publication point data that fails to match manifest entries (at the time this document was written).
マニフェストはRPKI署名付きオブジェクトであるため、[RFC6488]に従って検証されます。これらのチェックのいずれかが失敗するような方法でマニフェストが変更された場合、マニフェストは無効と見なされます。マニフェスト自体の抑制（古いマニフェストによって示される）も、RPが公開ポイントで他の署名されたオブジェクトの抑制を検出しない原因となる可能性があります。 （マニフェストの交換が予定されているときにマニフェストのEE証明書が期限切れになると、公開の遅延により、マニフェストが無効になるだけでなく、無効になります。この非常に深刻な結果は、たとえばマニフェストEE証明書のnotAfter値は、それが発行されたCA証明書の値と同じです）。公開ポイントで署名されたオブジェクトを（そのオブジェクトタイプに適用可能なルールを使用して）検証できる場合、マニフェストに一致するエントリがない場合でも、RPはそのオブジェクトを受け入れることがあります。ただし、ほとんどのRPソフトウェアは、マニフェストエントリと一致しない公開ポイントデータを無視しているようです（このドキュメントが作成された時点）。
Corruption, suppression, modification, or deletion of a manifest might not affect RP processing of other publication point objects, as specified in [RFC6486]. However, as noted above, many RP implementations ignore objects that are present at a publication point but not listed in a valid manifest. Thus, the following actions against a manifest can impact RP processing:
[RFC6486]で指定されているように、マニフェストの破損、抑制、変更、または削除は、他の公開ポイントオブジェクトのRP処理に影響を与えない可能性があります。ただし、上記のように、多くのRP実装は、公開ポイントに存在するが有効なマニフェストにリストされていないオブジェクトを無視します。したがって、マニフェストに対する次のアクションはRP処理に影響を与える可能性があります。
A-2.1 Deletion
A-2.1削除
A-2.1.1 A manifest may be deleted from the indicated publication point. In this circumstance, an RP may elect to use the previous manifest (if available) and may ignore any new/changed objects at the publication point. The implications of this action are equivalent to suppression of publication of the objects that are not recognized by RPs because the new objects are not present in the old manifest. For example, a new ROA could be ignored (A-1.2). A newly issued CA certificate might be ignored (A-1.1). A subordinate CA certificate that was revoked might still be viewed as valid by RPs (A-4.1). A new or changed router certificate might be ignored (A-6.2) as would a revised Ghostbusters Record (A-4.1).
A-2.1.1マニフェストは、指定された公開ポイントから削除される場合があります。この状況では、RPは以前のマニフェスト（使用可能な場合）を使用することを選択し、公開ポイントでの新しいオブジェクトまたは変更されたオブジェクトを無視します。このアクションの影響は、新しいオブジェクトが古いマニフェストに存在しないため、RPによって認識されないオブジェクトの公開を抑制することと同じです。たとえば、新しいROAは無視できます（A-1.2）。新しく発行されたCA証明書は無視される場合があります（A-1.1）。取り消された下位CA証明書は、RP（A-4.1）によって引き続き有効と見なされる場合があります。新規または変更されたルーター証明書は、改訂されたゴーストバスターズレコード（A-4.1）と同様に無視される可能性があります（A-6.2）。
A-2.2 Suppression
A-2.2抑制
A-2.2.1 Publication of a newer manifest may be suppressed. Suppression of a newer manifest probably will cause an RP to rely on a cached manifest (if available). The older manifest would not enumerate newly added objects; thus, those objects might be ignored by an RP, which is equivalent to deletion of those objects (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1).
A-2.2.1新しいマニフェストの公開が抑制される場合があります。新しいマニフェストを抑制すると、RPはキャッシュされたマニフェスト（利用可能な場合）に依存するようになります。古いマニフェストは、新しく追加されたオブジェクトを列挙しませんでした。したがって、これらのオブジェクトはRPによって無視される可能性があります。これは、これらのオブジェクト（A-1.1、A-3.1、A-4.1、A-5.1、およびA-6.1）の削除と同等です。
A-2.3 Corruption
A-2.3破損
A-2.3.1 A manifest may be corrupted. A corrupted manifest will be rejected by RPs. This may cause RPs to rely on a previous manifest, with the same impact as A-2.2. If an RP does not revert to using a cached manifest, the impact of this action is very severe, i.e., all publication point objects will probably be viewed as invalid, including subordinate tree objects. This is equivalent to revoking or deleting an entire subtree (see A-4.4.2).
A-2.3.1マニフェストが破損している可能性があります。破損したマニフェストはRPによって拒否されます。これにより、RPは以前のマニフェストに依存する可能性があり、A-2.2と同じ影響があります。 RPがキャッシュされたマニフェストの使用に戻らない場合、このアクションの影響は非常に深刻です。つまり、下位ツリーオブジェクトを含め、すべての公開ポイントオブジェクトはおそらく無効と見なされます。これは、サブツリー全体の取り消しまたは削除と同等です（A-4.4.2を参照）。
A-2.4 Modification
A-2.4変更
A-2.4.1 A manifest may be modified to remove one or more objects. Because the modified manifest is viewed as valid by RPs, any objects that were removed may be ignored by RPs. This is equivalent to deleting these objects from the repository. The impact of this action will vary, depending on which objects are (effectively) removed. However, the impact is equivalent to deletion of the object in question, (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1).
A-2.4.1マニフェストは、1つ以上のオブジェクトを削除するように変更できます。変更されたマニフェストはRPによって有効と見なされるため、削除されたオブジェクトはRPによって無視される場合があります。これは、これらのオブジェクトをリポジトリから削除することと同じです。このアクションの影響は、どのオブジェクトが（効果的に）削除されるかによって異なります。ただし、影響は問題のオブジェクトの削除と同等です（A-1.1、A-3.1、A-4.1、A-5.1、およびA-6.1）。
A-2.4.2 A manifest may be modified to add one or more objects. If an added object has a valid signature (and is not expired), it will be accepted by RPs and processed accordingly. If the added object was previously deleted by the INR holder, this action is equivalent to suppressing deletion of that object. If the object is newly created or modified, it is equivalent to a modification or injection action for the type of object in question and is thus discussed in the relevant section for those actions for the object type.
A-2.4.2マニフェストは、1つ以上のオブジェクトを追加するように変更できます。追加されたオブジェクトに有効な署名がある場合（有効期限が切れていない場合）、RPによって受け入れられ、それに応じて処理されます。追加されたオブジェクトがINR所有者によって以前に削除された場合、このアクションはそのオブジェクトの削除を抑制することと同じです。オブジェクトが新しく作成または変更された場合、それは問題のオブジェクトタイプの変更または注入アクションに相当するため、オブジェクトタイプのそれらのアクションの関連セクションで説明されています。
A-2.4.3 A manifest may be modified to list an incorrect hash for one or more objects. An object with an incorrect hash may be ignored by an RP. Thus, the effect may be equivalent to corrupting the object in question, although the error reported by RP software would differ from that reported for a corrupted object. (The manifest specifications do not require an RP to ignore an object that has a valid signature and that is not revoked or expired, but for which the hash doesn't match the object. However, an RP may elect to do so.)
A-2.4.3マニフェストは、1つ以上のオブジェクトの不正なハッシュをリストするように変更される場合があります。ハッシュが正しくないオブジェクトは、RPによって無視される場合があります。したがって、RPソフトウェアによって報告されるエラーは、破壊されたオブジェクトについて報告されるエラーとは異なりますが、影響は問題のオブジェクトを破壊することと同等です。 （マニフェスト仕様では、有効な署名があり、失効または期限切れではないが、ハッシュがオブジェクトと一致しないオブジェクトをRPが無視することをRPに要求していません。ただし、RPはそうすることを選択する場合があります。）
A-2.5 Revocation
A-2.5失効
A-2.5.1 A manifest may be revoked (by including its EE certificate on the CRL for the publication point). A revoked manifest will be ignored by an RP, which probably would revert to an older (cached) manifest. The implications for RPs are equivalent to A-2.1 with regard to new/changed objects.
A-2.5.1マニフェストは（公開ポイントのCRLにそのEE証明書を含めることにより）取り消される場合があります。取り消されたマニフェストはRPによって無視され、おそらく古い（キャッシュされた）マニフェストに戻ります。 RPの影響は、新規/変更されたオブジェクトに関してはA-2.1と同等です。
A-2.6 Injection
A-2.6注射
A-2.6.1 A manifest representing different objects may be injected into a publication point. The effects are the same as for a modified manifest (see above). The impact will depend on the type of the affected object(s) and is thus discussed in the relevant section(s) for each object type.
A-2.6.1さまざまなオブジェクトを表すマニフェストを公開ポイントに挿入できます。効果は、変更されたマニフェストの場合と同じです（上記を参照）。影響は、影響を受けるオブジェクトのタイプに依存するため、各オブジェクトタイプの関連セクションで説明されています。
Each publication point contains a CRL that enumerates revoked (not yet expired) certificates issued by the CA associated with the publication point [RFC6481].
各公開ポイントには、公開ポイントに関連付けられたCAによって発行された、失効した（まだ期限が切れていない）証明書を列挙するCRLが含まれています[RFC6481]。
Adverse actions against a CRL can cause the following errors:
CRLに対する有害なアクションにより、次のエラーが発生する可能性があります。
A-3.1 Deletion
A-3.1削除
A-3.1.1 If a CRL is deleted, RPs will continue to use an older, previously fetched Certificate Revocation List. As a result, they will not be informed of any changes in revocation status of subordinate CA or router certificates or the EE certificates of signed objects, e.g., ROAs. This action is equivalent to corruption of a CRL, since a corrupted CRL will not be accepted by an RP.
A-3.1.1 CRLが削除された場合、RPは以前にフェッチされた古い証明書失効リストを引き続き使用します。その結果、下位CAまたはルーター証明書の失効ステータス、またはROAなどの署名されたオブジェクトのEE証明書の変更については通知されません。破損したCRLはRPによって受け入れられないため、このアクションはCRLの破損と同等です。
A-3.1.2 Deletion of a CRL could cause an RP to continue to accept a ROA that no longer expresses the intent of an INR holder. As a result, an announcement for the affected prefixes would be viewed as Valid, instead of NotFound or Invalid. In this case, the effect is analogous to A-5.2.
A-3.1.2 CRLを削除すると、RPは、INR保有者の意図を表さなくなったROAを受け入れ続ける可能性があります。その結果、影響を受けるプレフィックスのアナウンスは、NotFoundまたはInvalidではなく、Validと表示されます。この場合、効果はA-5.2に類似しています。
A-3.1.3 If a router certificate were revoked and the CRL were deleted, RPs would not be aware of the revocation. They might continue to accept the old, revoked router certificate. If the certificate had been revoked due to a compromise of the router's private key, RPs would be vulnerable to accepting routes signed by an unauthorized entity.
A-3.1.3ルーター証明書が取り消され、CRLが削除された場合、RPはその取り消しを認識しません。古い失効したルーター証明書を引き続き受け入れる可能性があります。ルーターの秘密キーが侵害されたために証明書が取り消された場合、RPは無許可のエンティティによって署名されたルートを受け入れることに対して脆弱になります。
A-3.1.4 If a subordinate CA certificate were revoked on the deleted CRL, the revocation would not take effect. This could interfere with a transfer of address space from the subordinate CA, adversely affecting routing to the new holder of the space.
A-3.1.4削除されたCRLで下位CA証明書が取り消された場合、取り消しは有効になりません。これは、下位CAからのアドレススペースの転送を妨害し、スペースの新しいホルダーへのルーティングに悪影響を与える可能性があります。
A-3.2 Suppression
A-3.2抑制
A-3.2.1 If publication of the most recent CRL is suppressed, an RP will not be informed of the most recent revocation status of a subordinate CA or router certificates or the EE certificates of signed objects. If an EE certificate has been revoked and the associated signed object is still present in the publication point, an RP might mistakenly treat that object as valid. (This would happen if the object is still in the manifest or if the RP is configured to process valid objects that are not on the manifest.) This type of action is of special concern if the affected object is a ROA, a router certificate, or a subordinate CA certificate. The effects here are equivalent to CRL deletion (A-3.1), but suppression of a new CRL may not even be reported as an error, i.e., if the suppressed CRL were issued before the NextUpdate time (of the previous CRL).
A-3.2.1最新のCRLの公開が抑制されている場合、RPは、下位のCAまたはルーター証明書、または署名されたオブジェクトのEE証明書の最新の失効ステータスを通知されません。 EE証明書が取り消され、関連付けられた署名付きオブジェクトがまだ公開ポイントに存在する場合、RPはそのオブジェクトを誤って有効なものとして扱う可能性があります。 （これは、オブジェクトがまだマニフェスト内にある場合、またはRPがマニフェスト上にない有効なオブジェクトを処理するように構成されている場合に発生します。）このタイプのアクションは、影響を受けるオブジェクトがROA、ルーター証明書、または下位CA証明書。ここでの効果はCRLの削除（A-3.1）と同等ですが、新しいCRLの抑制は、エラーとして報告されない場合もあります。
A-3.3 Corruption
A-3.3破損
A-3.3.1 If a CRL is corrupted, an RP will reject it. If a prior CRL has not yet exceeded its NextUpdate time, an RP will continue to use the prior CRL. Even if the prior CRL has passed the NextUpdate time, an RP may choose to continue to rely on the prior CRL. The effects are essentially equivalent to suppression or deletion of a CRL (A-3.1 and A-3.2).
A-3.3.1 CRLが破損している場合、RPはそれを拒否します。以前のCRLがNextUpdate時間をまだ超えていない場合、RPは引き続き以前のCRLを使用します。以前のCRLがNextUpdate時間を経過した場合でも、RPは以前のCRLに引き続き依存することを選択できます。その効果は、CRLの抑制または削除と本質的に同等です（A-3.1およびA-3.2）。
A-3.4 Modification
A-3.4変更
A-3.4.1 If a CRL is modified to erroneously list a signed object's EE certificate as revoked, the corresponding object will be treated as invalid by RPs, even if it is present in a publication point. If this object is a ROA, the (legitimate) binding expressed by the ROA will be ignored by an RP (see A-5.5). If a CRL is modified to erroneously list a router certificate as revoked, a path signature associated with that certificate will be treated as Not Valid by RPs (see A-6.5).
A-3.4.1署名済みオブジェクトのEE証明書を失効として誤ってリストするようにCRLが変更された場合、対応するオブジェクトは、公開ポイントに存在していても、RPによって無効として扱われます。このオブジェクトがROAの場合、ROAによって表される（正当な）バインディングはRPによって無視されます（A-5.5を参照）。失効したルーター証明書を誤ってリストするようにCRLが変更された場合、その証明書に関連付けられているパス署名は、RPによって無効として扱われます（A-6.5を参照）。
A-3.4.2 If a CRL is modified to erroneously list a CA certificate as revoked, that CA and all subordinate signed objects will be treated as invalid by RPs. Depending on the location of the affected CA in the hierarchy, these effects could be very substantial, causing routes that should be Valid to be treated as NotFound.
A-3.4.2失効したCA証明書を誤ってリストするようにCRLが変更された場合、そのCAおよびすべての下位の署名付きオブジェクトは、RPによって無効として扱われます。影響を受けるCAの階層内の場所によっては、これらの影響が非常に大きくなり、有効であるはずのルートがNotFoundとして扱われる可能性があります。
A-3.4.3 If a CRL is modified to omit a revoked EE, router, or CA certificate, RPs will likely continue to accept the revoked, signed object as valid. This contravenes the intent of the INR holder. If an RP continues to accept a revoked ROA, it may make routing decisions on now-invalid data. This could cause valid routes to be de-preferenced and invalid routes to continue to be accepted.
A-3.4.3失効したEE、ルーター、またはCA証明書を省略するようにCRLが変更された場合、RPは失効した署名済みオブジェクトを有効なものとして受け入れ続ける可能性があります。これは、INR保有者の意図に反します。 RPが取り消されたROAを受け入れ続ける場合、RPは現在無効なデータのルーティングを決定することがあります。これにより、有効なルートが優先されなくなり、無効なルートが引き続き受け入れられる可能性があります。
A-3.5 Revocation
A-3.5失効
A-3.5.1 A CRL cannot be revoked per se, but it will fail validation if the CA certificate under which it was issued is revoked. See A-1.5 for a discussion of that action.
A-3.5.1 CRL自体を取り消すことはできませんが、発行元のCA証明書が取り消された場合、検証は失敗します。そのアクションの説明については、A-1.5を参照してください。
A-3.6 Injection
A-3.6注射
A-3.6.1 Insertion of a bogus CRL can have the same effects as listed above for a modified CRL, depending on how the inserted CRL differs from the correct CRL.
A-3.6.1偽のCRLの挿入は、挿入されたCRLが正しいCRLとどのように異なるかに応じて、変更されたCRLについて上記と同じ効果を持つ可能性があります。
In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistently with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors:
汎用のRPKIオブジェクト構文チェックに加えて、ROA検証では、ROAに埋め込まれたEE証明書の公開鍵を使用してROAの署名を検証できる必要があります[RFC6482]。また、EE証明書は、[RFC6482]および[RFC6487]で説明されている手順と一貫して検証される必要があります。 ROAに対する有害なアクションにより、次のエラーが発生する可能性があります。
A-4.1 Deletion
A-4.1削除
A-4.1.1 A ROA may be deleted from the indicated publication point. The result is to void the binding between the prefix(es) and the Autonomous System (AS) number in the ROA. An RP that previously viewed this binding as authentic will now not have any evidence about its validity. For origin validation, this means that a legitimate route will be treated as NotFound (if there are no other ROAs for the same prefix) or Invalid (if there is another ROA for the same prefix, but with a different AS number).
A-4.1.1 ROAは、示された公開ポイントから削除される場合があります。その結果、ROA内のプレフィックスと自律システム（AS）番号の間のバインディングが無効になります。以前にこのバインディングを本物であると見なしていたRPは、現在、その有効性について何の証拠もありません。起点検証の場合、これは、正当なルートがNotFound（同じプレフィックスに他のROAがない場合）または無効（同じプレフィックスに別のROAがあるが、AS番号が異なる場合）として扱われることを意味します。
A-4.2 Suppression
A-4.2抑制
A-4.2.1 Publication of a newer ROA may be suppressed. If the INR holder intended to change the binding between the prefix(es) and the AS number in the ROA, this change will not be effected. As a result, RPs may continue to believe an old prefix/ ASN binding that is no longer what the INR holder intended.
A-4.2.1新しいROAの公開は抑制される場合があります。 INRホルダーがROAのプレフィックスとAS番号の間のバインディングを変更することを意図していた場合、この変更は影響を受けません。その結果、RPは、INR保有者が意図していたものではなくなった古いプレフィックス/ ASNバインディングを信じ続ける可能性があります。
A-4.2.2 If an INR holder intends to issue and publish two (or more) new ROAs for the same address space, one (or more) of the new ROAs may be suppressed while the other is published. In this case, RPs will de-preference the suppressed prefix/ASN binding. Suppression of the new ROA might cause traffic to flow to an ASN other than the one(s) intended by the INR holder.
A-4.2.2 INR保有者が同じアドレススペースに対して2つ（またはそれ以上）の新しいROAを発行および公開する場合、一方（またはそれ以上）の新しいROAが抑制され、もう一方は公開されます。この場合、RPは抑制されたプレフィックス/ ASNバインディングを優先しません。新しいROAの抑制により、INR保有者が意図したもの以外のASNにトラフィックが流れる可能性があります。
A-4.2.3 If an INR holder intends to delete all ROAs for the same address space, some of them may be retained while the others are deleted. Preventing the deletion of some ROAs can cause traffic to continue to be delivered to the ASNs that were advertised by these ROAs. Deletion of all ROAs is consistent with a transfer of address space to a different INR holder in a phased fashion. Thus, this sort of attack could interfere with the successful transfer of the affected address space (until such time as the prefixes are removed from the previous INR holder's CA certificate).
A-4.2.3 INR所有者が同じアドレススペースのすべてのROAを削除する場合、一部のROAは保持され、他のROAは削除されます。一部のROAの削除を防止すると、これらのROAによってアドバタイズされたASNにトラフィックが引き続き配信される可能性があります。すべてのROAの削除は、別のINR所有者へのアドレス空間の段階的な移行と一致しています。したがって、この種の攻撃は、影響を受けるアドレス空間の正常な転送を妨害する可能性があります（前のINR所有者のCA証明書からプレフィックスが削除されるまで）。
A-4.3 Corruption
A-4.3破損
A-4.3.1 A ROA may be corrupted. A corrupted ROA will be ignored by an RP, so the effect is essentially the same as for A-4.1 and A-4.5. A possible difference is that an RP may be alerted to the fact that the ROA was corrupted, which might attract attention to the attack.
A-4.3.1 ROAが破損している可能性があります。破損したROAはRPによって無視されるため、効果は基本的にA-4.1およびA-4.5と同じです。考えられる違いは、RPがROAが破損しているという事実を警告される可能性があり、攻撃に注意を向けるかもしれません。
A-4.4 Modification
A-4.4変更
A-4.4.1 A ROA may be modified so that the Autonomous System Number (ASN) or one or more of the address blocks in a ROA is different from the values the INR holder intended for this ROA. (This action assumes that the modified ROA's ASN and address ranges are authorized for use by the INR holder.) This attack will cause RPs to de-preference the legitimate prefix/ASN binding intended by the INR holder.
A-4.4.1 ROAは、自律システム番号（ASN）またはROA内の1つ以上のアドレスブロックが、INR所有者がこのROAに意図した値と異なるように変更される場合があります。 （このアクションは、変更されたROAのASNとアドレス範囲がINR保有者による使用を許可されていることを前提としています。）この攻撃により、RPは、INR保有者が意図した正当なプレフィックス/ ASNバインディングを優先しなくなります。
A-4.5 Revocation
A-4.5失効
A-4.5.1 A ROA may be revoked (by placing its EE certificate on the CRL for the publication point). This has the same effect as A-4.1.
A-4.5.1 ROAが取り消される場合があります（そのEE証明書を公開ポイントのCRLに配置することにより）。これはA-4.1と同じ効果があります。
A-4.6 Injection
A-4.6インジェクション
A-4.6.1 A ROA expressing different bindings than those published by the INR holder may be injected into a publication point. This action could authorize an additional ASN to advertise the specified prefix, allowing that ASN to originate routes for the prefix, thus enabling route origin spoofing. In this case, the injected ROA is considered to be in competition with any existing authorized ROAs for the specified prefix.
A-4.6.1 INR保有者によって公開されたものとは異なるバインディングを表現するROAが公開ポイントに注入される場合があります。このアクションは、追加のASNが指定されたプレフィックスをアドバタイズすることを承認し、そのASNがプレフィックスのルートを発信できるようにし、ルート発信元のなりすましを有効にします。この場合、挿入されたROAは、指定されたプレフィックスの既存の承認済みROAと競合していると見なされます。
A-4.6.2 An injected ROA might express a different prefix for an ASN already authorized to originate a route, e.g., a longer prefix, which could enable that ASN to override other advertisements using shorter prefixes. If there are other ROAs that authorize different ASNs to advertise routes to the injected ROA's prefix, then the injected ROA is in competition with these ROAs.
A-4.6.2挿入されたROAは、ルートを開始することをすでに許可されているASNの異なるプレフィックス、たとえば、より長いプレフィックスを表す場合があり、そのASNがより短いプレフィックスを使用して他のアドバタイズをオーバーライドできるようにする可能性があります。注入されたROAのプレフィックスへのルートをアドバタイズするために別のASNを許可する他のROAがある場合、注入されたROAはこれらのROAと競合しています。
The Ghostbusters Record [RFC6493] is a signed object that may be included at a publication point, at the discretion of the INR holder or publication point operator. The record is validated according to [RFC6488]. Additionally, the syntax of the record is verified based on the vCard profile from Section 5 of [RFC6493]. Errors in this record do not affect RP processing. However, if an RP encounters a problem with objects at a publication point, the RP may use information from the record to contact the publication point operator.
ゴーストバスターズレコード[RFC6493]は、INR保有者または公開ポイントの運営者の裁量により、公開ポイントに含めることができる署名付きオブジェクトです。レコードは[RFC6488]に従って検証されます。さらに、レコードの構文は、[RFC6493]のセクション5のvCardプロファイルに基づいて検証されます。このレコードのエラーは、RP処理には影響しません。ただし、RPが公開ポイントでオブジェクトの問題に遭遇した場合、RPはレコードの情報を使用して公開ポイントのオペレーターに連絡する場合があります。
Adverse actions against a Ghostbusters Record can cause the following error:
ゴーストバスターズレコードに対する有害なアクションにより、次のエラーが発生する可能性があります。
A-5.1 Deletion, suppression, corruption, or revocation of a Ghostbusters Record could prevent an RP from contacting the appropriate entity when a problem is detected by the RP. Modification or injection of a Ghostbusters Record could cause an RP to contact the wrong entity, thus delaying remediation of a detected anomaly. All of these actions are viewed as equivalent from an RP processing perspective; they do not alter RP validation of ROAs or router certificates. However, these actions can interfere with remediation of a problem when detected by an RP.
A-5.1ゴーストバスターズレコードを削除、抑制、破損、または取り消すと、RPが問題を検出したときに、RPが適切なエンティティに接続できなくなる可能性があります。ゴーストバスターズレコードを変更または挿入すると、RPが間違ったエンティティに接続し、検出された異常の修復が遅れる可能性があります。これらのアクションはすべて、RP処理の観点からは同等と見なされます。 ROAやルーター証明書のRP検証は変更されません。ただし、これらのアクションは、RPによって検出されたときに問題の修正を妨げる可能性があります。
Router certificates are used by RPs to verify signatures on BGPsec_PATH attributes carried in UPDATE messages.
RPはルーター証明書を使用して、UPDATEメッセージで伝達されるBGPsec_PATH属性の署名を検証します。
Each AS is free to determine the granularity at which router certificates are managed [RFC8209]. Each participating AS is represented by one or more router certificates. During key or algorithm rollover, multiple router certificates will be present in a publication point, even if the AS is normally represented by just one such certificate.
各ASは、ルーター証明書を管理する細かさを自由に決定できます[RFC8209]。参加している各ASは、1つ以上のルーター証明書によって表されます。キーまたはアルゴリズムのロールオーバー中、ASが通常1つの証明書で表されている場合でも、複数のルーター証明書が公開ポイントに存在します。
Adverse actions against router certificates can cause the following errors:
ルーター証明書に対する有害なアクションにより、次のエラーが発生する可能性があります。
A-6.1 Deletion
A-6.1削除
A-6.1.1 Deletion of a router certificate would cause an RP to be unable to verify signatures applied to BGPsec_PATH attributes on behalf of the AS in question. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_PATH attribute signatures. (However, if another router certificate for the affected AS is valid and contains the same AS number and public key, and it is in use by that AS, there would be no effect on routing. This scenario will arise if a router certificate is renewed, i.e., issued with a new validity interval.)
A-6.1.1ルーター証明書を削除すると、RPは問題のASの代わりにBGPsec_PATH属性に適用された署名を検証できなくなります。次に、これにより、ルートは、有効なBGPsec_PATH属性シグネチャを持つ競合するルートよりも低い優先度で処理されます。 （ただし、影響を受けるASの別のルーター証明書が有効で、同じAS番号と公開鍵を含み、そのASによって使用されている場合、ルーティングに影響はありません。このシナリオは、ルーター証明書が更新された場合に発生します、つまり、新しい有効期間で発行されます。）
A-6.2 Suppression
A-6.2抑制
A-6.2.1 Suppression of a router certificate could have the same impact as deletion of a certificate of this type, i.e., if no router certificate was available, BGPsec attributes that should be verified using the certificate would fail validation. If an older certificate existed and has not expired, it would be used by RPs. If the older certificate contained a different ASN, the impact would be the same as in A-6.4.
A-6.2.1ルーター証明書の抑制は、このタイプの証明書の削除と同じ影響を与える可能性があります。つまり、使用可能なルーター証明書がない場合、証明書を使用して検証する必要があるBGPsec属性は検証に失敗します。古い証明書が存在し、有効期限が切れていない場合、RPによって使用されます。古い証明書に異なるASNが含まれている場合、影響はA-6.4と同じです。
A-6.3 Corruption
A-6.3破損
A-6.3.1 Corruption of a router certificate will result in the certificate being rejected by RPs. Absent a valid router certificate, BGPsec_PATH attributes associated with that certificate will be unverifiable. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_PATH attribute signatures.
A-6.3.1ルーター証明書が破損すると、証明書はRPによって拒否されます。有効なルーター証明書がない場合、その証明書に関連付けられているBGPsec_PATH属性は検証できません。次に、これにより、ルートは、有効なBGPsec_PATH属性シグネチャを持つ競合するルートよりも低い優先度で処理されます。
A-6.4 Modification
A-6.4変更
A-6.4.1 If a router certificate is modified to represent a different ASN, but it still passes syntax checks, then this action could cause signatures on BGPsec_PATH attributes to be associated with the wrong AS. This could cause signed routes to be inconsistent with the intent of the INR holder, e.g., traffic might be routed via a different AS than intended.
A-6.4.1ルーター証明書が変更されて別のASNを表す場合でも、構文チェックに合格すると、このアクションによりBGPsec_PATH属性の署名が誤ったASに関連付けられる可能性があります。これにより、署名されたルートがINR所有者の意図と一致しなくなる可能性があります。たとえば、トラフィックが意図したものとは異なるAS経由でルーティングされる可能性があります。
A-6.5 Revocation
A-6.5失効
A-6.5.1 If a router certificate were revoked, BGPsec_PATH attributes verifiable using that certificate would no longer be considered valid. The impact would be the same as for a deleted certificate, as described in A-6.1.
A-6.5.1ルーター証明書が取り消された場合、その証明書を使用して検証可能なBGPsec_PATH属性は、有効とは見なされなくなります。影響は、A-6.1で説明されているように、削除された証明書の場合と同じです。
A-6.6 Injection
A-6.6注射
A-6.6.1 Insertion of a router certificate could authorize additional routers to sign BGPsec traffic for the targeted ASN, and thus undermine fundamental BGPsec security guarantees. If there are existing, authorized router certificates for the same ASN, then the injected router certificate is in competition with these existing certificates.
A-6.6.1ルーター証明書を挿入すると、追加のルーターが対象のASNのBGPsecトラフィックに署名することを承認し、基本的なBGPsecセキュリティ保証を損なう可能性があります。同じASNの既存の承認済みルーター証明書がある場合、挿入されたルーター証明書はこれらの既存の証明書と競合しています。
This section examines the types of problems that can arise in four scenarios described below. We consider mistakes, (successful) attacks against a CA or a publication point, and situations in which a CA or publication point manager is compelled to take action by a law enforcement authority.
このセクションでは、以下に説明する4つのシナリオで発生する可能性のある問題のタイプを調べます。ミス、CAまたは公開ポイントへの（成功した）攻撃、およびCAまたは公開ポイントの管理者が法執行機関によるアクションを強制される状況を考慮します。
We explore the following four scenarios:
次の4つのシナリオについて説明します。
A. An INR holder operates its own CA and manages its own repository publication point.
A. INR所有者は独自のCAを運営し、独自のリポジトリ公開ポイントを管理します。
B. An INR holder operates its own CA, but outsources management of its repository publication point to its parent or another entity.
B. INR保有者は独自のCAを運営していますが、リポジトリ公開ポイントの管理をその親または別のエンティティに外部委託しています。
C. An INR holder outsources management of its CA to its parent, but manages its own repository publication point.
C. INR保有者は、CAの管理をその親に外部委託しますが、独自のリポジトリ公開ポイントを管理します。
D. An INR holder outsources management of its CA and its publication point to its parent.
D. INR保有者は、そのCAとその公開ポイントの管理をその親に外部委託します。
Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action. The most serious cases arise when the INR holder appears as a high-tier CA in the RPKI hierarchy; in such situations, subordinate INR holders may be affected as a result of an action. A mistake by or an attack against a "leaf" has more limited impact because all of the affected INRs belong to the INR holder itself.
これらのシナリオは、当事者が悪影響に直接影響を受けるため、影響を受けるINR保有者に焦点を合わせていることに注意してください。最も深刻なケースは、INR保有者がRPKI階層の上位CAとして表示される場合に発生します。このような状況では、アクションの結果として、従属のINR保有者が影響を受ける可能性があります。影響を受けるすべてのINRは、INR所有者自身に属しているため、「リーフ」によるミスまたは「リーフ」に対する攻撃の影響はより限定的です。
In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.)
シナリオAでは、INR所有者によるアクションは、そのすべてのリソースに、そして推移的には、下位CAのリソースに悪影響を与える可能性があります。 （CAがRPKIの「リーフ」である場合、下位CAはなく、損害は自身のINRに限定されます。）
In Scenario B, actions by the (outsourced) repository operator can also adversely affect the resources of the INR holder and those of any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A and adds a new potential source of adverse actions, i.e., the outsourced repository operator.
シナリオBでは、（アウトソーシングされた）リポジトリオペレーターによるアクションも、INR保有者のリソースと下位CAのリソースに悪影響を与える可能性があります。 （CAがRPKIの「リーフ」である場合、下位CAはなく、シナリオAのように損傷は限定されます。）ここでの悪影響の範囲にはシナリオAの影響が含まれ、新たな潜在的な悪影響源が追加されますアクション、つまり、外部委託されたリポジトリオペレータ。
In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A.
シナリオCでは、INRホルダーに関連付けられたすべての署名付きオブジェクトは、親CAによって生成されますが、自己ホストされます。 （CAの運用をアウトソーシングすることを選択するINR所有者が独自のリポジトリ公開ポイントを管理する可能性は低いため、このシナリオはまれであると予想されます。）そのCAは署名に使用される秘密鍵を持っているため、代替の署名付きオブジェクトを生成できますINR保有者によって承認されていないもの。ただし、親CAによって作成された誤ったオブジェクトは、所有者が最初にチェックした場合、INR所有者によって公開されません。親CAはINR保有者に代わって行動しているため、そのエンティティによるミスまたは攻撃は、シナリオAでINR保有者が行ったものと同等です。
The INR holder is most vulnerable in Scenario D. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C.
INR保有者はシナリオDで最も脆弱です。INR保有者に代わって動作する親CAのアクションは、下位のCA証明書を含め、そのINR保有者に関連付けられたすべての署名付きオブジェクトに悪影響を及ぼす可能性があります。親CAがINR保有者の公開ポイントを管理しているため、これらのアクションはおそらく公開ポイントの変更に直接変換されます。ここでの悪影響の範囲には、シナリオA、B、およびCの悪影響が含まれます。
In this scenario, the INR holder acts as its own CA and it manages its own publication point. Actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.) Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section. (We assume that objects generated by the CA are automatically published). An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section.
このシナリオでは、INR所有者は独自のCAとして機能し、独自の公開ポイントを管理します。 INR保有者によるアクションは、そのすべてのリソースに、そして推移的には、下位CAのリソースに悪影響を与える可能性があります。 （CAがRPKIの「リーフ」である場合、下位CAはなく、損害は自身のINRに限定されます。）INR所有者による間違いは、セクション2に記載されているアクションのいずれかを引き起こす可能性があります。このCAは、そのセクションに記載されているすべての変更、取り消し、または挿入アクションに影響を与える可能性があります。 （CAによって生成されたオブジェクトは自動的に公開されると想定しています）。公開ポイントに対する攻撃は、そのセクションに記載されているすべての削除、抑制、または破損アクションに影響を与える可能性があります。
In this scenario, the INR holder acts as its own CA but it delegates management of it own publication point to a third party. Mistakes by the INR holder can cause any of the modification, revocation, or injection actions described in Section 2. Actions by the repository operator can adversely affect the resources of the INR holder, and those of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the third party repository operator. A successful attack against the CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published). Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2.
このシナリオでは、INR保有者は独自のCAとして機能しますが、自身の公開ポイントの管理をサードパーティに委任します。 INR保有者による間違いは、セクション2で説明されている変更、取り消し、または注入のアクションのいずれかを引き起こす可能性があります。リポジトリオペレータによるアクションは、INR保有者のリソースおよび下位CAのリソースに悪影響を及ぼす可能性があります。 （CAがRPKIの「リーフ」である場合、下位のCAはなく、シナリオAのように損傷は限定されます。）ここでの悪影響の範囲には、シナリオAの影響が含まれ、新しい潜在的なソースが追加されます。不利な行動、すなわち、サードパーティのリポジトリ運営者。 CAに対する攻撃が成功すると、そのセクションに記載されているすべての変更、失効、または挿入アクションに影響を与える可能性があります（CAによって生成されたオブジェクトが自動的に公開されている場合）。ここで、公開ポイント管理者によるアクション（またはそのエンティティに対する攻撃）は、セクション2に記載されているすべての削除、抑制、または破損アクションに影響を与える可能性があります。
In this scenario, the INR holder outsources management of its CA to its parent, but manages its own repository publication point. All signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect, unless the INR holder checks the signed objects before publishing them. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2, unless the INR holder checks the signed objects before publishing them. An attack against the INR holder (in its role as repository operator) can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the INR holder is managing its publication point), unless the INR holder checks the signed objects before publishing them. (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised.)
このシナリオでは、INR所有者はCAの管理をその親に外部委託しますが、独自のリポジトリ公開ポイントを管理します。 INRホルダーに関連付けられたすべての署名付きオブジェクトは、親CAによって生成されますが、自己ホストされます。 （CAの運用をアウトソーシングすることを選択するINR所有者が独自のリポジトリ公開ポイントを管理する可能性は低いため、このシナリオはまれであると予想されます。）そのCAは署名に使用される秘密鍵を持っているため、代替の署名付きオブジェクトを生成できます- INR保有者によって承認されていないもの。ただし、親CAによって作成された誤ったオブジェクトは、所有者が最初にチェックした場合、INR所有者によって公開されません。親CAはINR保有者に代わって行動しているため、そのエンティティによるミスまたは攻撃は、シナリオAでINR保有者が犯したものと同等です。親CAが行動するINR保有者によるミスは、セクション2に記載されているアクション。親CAが一方的に行ったアクションは、INR所有者が署名済みオブジェクトを公開する前にチェックしない限り、同じ効果を持つ可能性があります。親CAに対する攻撃が成功すると、INR所有者が署名済みオブジェクトを公開する前にチェックしない限り、セクション2に記載されているすべての変更、取り消し、または挿入アクションに影響を与える可能性があります。 INR所有者が署名されたオブジェクトをチェックしない限り、（リポジトリオペレーターとしての役割を持つ）INR所有者に対する攻撃は、セクション2に記載されているすべての削除、抑制、または破損アクションに影響を与える可能性があります（INR所有者が公開ポイントを管理しているため）。それらを公開する前に。 （INR所有者に対する攻撃は、親CAにオブジェクトの発行と公開を指示するために使用するパスが侵害されたことを意味します。）
In this scenario, an INR holder outsources management of both its CA and its publication point to its parent. The INR holder is most vulnerable in this scenario. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can also effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the parent CA is managing the INR holder's publication point).
このシナリオでは、INR保有者は、CAとその公開ポイントの両方の管理をその親に外部委託します。 INR保有者は、このシナリオで最も脆弱です。 INR所有者に代わって動作する親CAのアクションは、下位のCA証明書を含め、そのINR所有者に関連付けられたすべての署名付きオブジェクトに悪影響を及ぼす可能性があります。親CAがINR保有者の公開ポイントを管理しているため、これらのアクションはおそらく直接公開ポイントの変更に変換されます。ここでの悪影響の範囲には、シナリオA、B、およびCの悪影響が含まれます。親CAが対処するINR保有者による間違いは、セクション2に記載されたアクションのいずれかを引き起こす可能性があります。親CAが一方的に行うアクションも、同じ効果があります。親CAに対する攻撃が成功すると、セクション2に記載されているすべての変更、失効、または挿入アクションに影響を与える可能性があります。親CAに対する攻撃は、セクション2に記載されているすべての削除、抑制、または破損アクションにも影響を与える可能性があります（親CAがINR所有者の公開ポイントを管理しています）。
This informational document describes a threat model for the RPKI, focusing on mistakes by or attacks against CAs and independent repository managers. It is intended to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions.
この情報ドキュメントでは、CAおよび独立したリポジトリマネージャーによるミスまたは攻撃に焦点を当てた、RPKIの脅威モデルについて説明します。これは、そのようなアクションに関連する懸念に対処しようとする将来のRPKIセキュリティメカニズムの設計の基礎を提供することを目的としています。
The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing Policy Specification Language (RPSL) [RFC2622]. IRR technology exhibits its own set of security problems, which are discussed in [RFC7682].
このドキュメントの分析では、攻撃またはエラーがルーティングに大きな影響を与える可能性のある多くの状況を特定しています。これをRPKIの非難と解釈すべきではありません。これは、RPKIのコンテキストで広範囲の攻撃とエラーの影響を文書化するための試みにすぎません。ルーティング情報を広めるための主要な代替メカニズムは、インターネットルーティングレジストリ（IRR）テクノロジ[RFC2650] [RFC2725]で、ルーティングポリシー仕様言語（RPSL）[RFC2622]を使用しています。 IRRテクノロジーは、[RFC7682]で説明されている一連の独自のセキュリティ問題を示しています。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn、C.、Kent、S.、K。Seo、「X.509 Extensions for IP Addresses and AS Identifiers」、RFC 3779、DOI 10.17487 / RFC3779、2004年6月、<https：//www.rfc -editor.org/info/rfc3779>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480> 。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<https：//www.rfc-editor。 org / info / rfc6481>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：//www.rfc- editor.org/info/rfc6482>。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>.
[RFC6483] Huston、G.およびG. Michaelson、「Validation of Route Origination Using the Resource Certificate Public Key Infrastructure（PKI）and Route Origin Authorizations（ROAs）」、RFC 6483、DOI 10.17487 / RFC6483、2012年2月、<https： //www.rfc-editor.org/info/rfc6483>。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein、R.、Huston、G.、Kent、S。、およびM. Lepinski、「Manifests for the Resource Public Key Infrastructure（RPKI）」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<https： //www.rfc-editor.org/info/rfc6486>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<https：//www.rfc- editor.org/info/rfc6487>。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「Resource Public Key Infrastructure（RPKI）の署名付きオブジェクトテンプレート」、RFC 6488、DOI 10.17487 / RFC6488、2012年2月、<https：// www .rfc-editor.org / info / rfc6488>。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.
[RFC6489] Huston、G.、Michaelson、G。、およびS. Kent、「Certification Authority（CA）Key Rollover in the Resource Public Key Infrastructure（RPKI）」、BCP 174、RFC 6489、DOI 10.17487 / RFC6489、February 2012 、<https://www.rfc-editor.org/info/rfc6489>。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6493] Bush、R。、「The Resource Public Key Infrastructure（RPKI）Ghostbusters Record」、RFC 6493、DOI 10.17487 / RFC6493、2012年2月、<https://www.rfc-editor.org/info/rfc6493>。
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC6916]ガリアーノ、R。、ケント、S。、およびS.ターナー、「リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズムの俊敏性手順」、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<https： //www.rfc-editor.org/info/rfc6916>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston、G。およびG. Michaelson、編、「リソースの公開鍵インフラストラクチャで使用するアルゴリズムと鍵サイズのプロファイル」、RFC 7935、DOI 10.17487 / RFC7935、2016年8月、<https：// www .rfc-editor.org / info / rfc7935>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205]レピンスキー、M。、エド。 K. Sriram、編、「BGPsecプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8205>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209] Reynolds、M.、Turner、S。、およびS. Kent、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/info/rfc2622>.
[RFC2622] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、Meyer、D.、Bates、T.、Karrenberg、D.、and M. Terpstra、 "Routing Policy Specification Language（RPSL ） "、RFC 2622、DOI 10.17487 / RFC2622、1999年6月、<https://www.rfc-editor.org/info/rfc2622>。
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, DOI 10.17487/RFC2650, August 1999, <https://www.rfc-editor.org/info/rfc2650>.
[RFC2650] Meyer、D.、Schmitz、J.、Orange、C.、Prior、M。、およびC. Alaettinoglu、「実際のRPSLの使用」、RFC 2650、DOI 10.17487 / RFC2650、1999年8月、<https：/ /www.rfc-editor.org/info/rfc2650>。
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <https://www.rfc-editor.org/info/rfc2725>.
[RFC2725] Villamizar、C.、Alaettinoglu、C.、Meyer、D。、およびS. Murphy、「ルーティングポリシーシステムセキュリティ」、RFC 2725、DOI 10.17487 / RFC2725、1999年12月、<https：//www.rfc- editor.org/info/rfc2725>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.
[RFC7132] Kent、S。およびA. Chi、「BGPパスセキュリティの脅威モデル」、RFC 7132、DOI 10.17487 / RFC7132、2014年2月、<https://www.rfc-editor.org/info/rfc7132>。
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015, <https://www.rfc-editor.org/info/rfc7682>.
[RFC7682] McPherson、D.、Amante、S.、Osterweil、E.、Blunk、L。、およびD. Mitchell、「インターネットルーティングレジストリ（IRR）およびルーティングポリシー構成に関する考慮事項」、RFC 7682、DOI 10.17487 / RFC7682 、2015年12月、<https://www.rfc-editor.org/info/rfc7682>。
Acknowledgements
謝辞
The authors thank Richard Hansen and David Mandelberg for their extensive review, feedback, and editorial assistance. Thanks also go to Daiming Li for her editorial assistance.
著者は、Richard HansenとDavid Mandelbergの広範なレビュー、フィードバック、および編集支援に感謝します。編集の支援をしてくれたDaiming Liにも感謝します。
Authors' Addresses
著者のアドレス
Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 United States of America
Stephen Kent BBN Technologies 10 Moulton St Cambridge、MA 02138-1119アメリカ合衆国
Email: kent@alum.mit.edu
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China
dim AZ DNS 4 south 4TH St. Z Macro Cu NH AI 、、北京100190中国
Email: madi@zdns.cn