[要約] RFC 8416は、RPKI（Resource Public Key Infrastructure）を使用した簡素化されたローカルインターネット番号リソース管理（SLURM）に関するものです。このRFCの目的は、RPKIを使用してインターネット番号リソースの管理を簡素化し、セキュリティを向上させることです。
Internet Engineering Task Force (IETF) D. Ma
Request for Comments: 8416 ZDNS
Category: Standards Track D. Mandelberg
ISSN: 2070-1721 Unaffiliated
T. Bruijnzeels
NLnet Labs
August 2018
Simplified Local Internet Number Resource Management with the RPKI (SLURM)
RPKI（SLURM）による簡素化されたローカルインターネット番号リソース管理
Abstract
概要
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.
Resource Public Key Infrastructure（RPKI）は、インターネット認証リソース（INR）の所有者がこれらのリソースについて検証可能なステートメントを作成できるようにするグローバル認証インフラストラクチャです。インターネットサービスプロバイダー（ISP）などのネットワークオペレーターは、RPKIを使用してBGPルート発信元アサーションを検証できます。 ISPは、RPKIを使用してBGPルートのパスを検証することもできます。ただし、ISPは、ローカルフィルターおよび追加の形式で、RPKIデータに対する例外のローカルビューを確立する必要がある場合があります。このドキュメントで説明するメカニズムは、INR保有者がRPKIのローカルのカスタマイズされたビューを確立し、必要に応じてグローバルRPKIリポジトリデータを上書きできるようにする簡単な方法を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8416.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8416で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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
1.1. Terminology ................................................4
2. RP with SLURM ...................................................4
3. SLURM Files and Mechanisms ......................................5
3.1. Use of JSON ................................................5
3.2. SLURM File Overview ........................................5
3.3. Validation Output Filters ..................................6
3.3.1. Validated ROA Prefix Filters ........................6
3.3.2. BGPsec Assertion Filters ............................7
3.4. Locally Added Assertions ...................................9
3.4.1. ROA Prefix Assertions ...............................9
3.4.2. BGPsec Assertions ..................................10
3.5. Example of a SLURM File with Filters and Assertions .......11
4. SLURM File Configuration .......................................13
4.1. SLURM File Atomicity ......................................13
4.2. Multiple SLURM Files ......................................13
5. IANA Considerations ............................................14
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. For example, the holder of a block of IP(v4 or v6) addresses can issue a Route Origin Authorization (ROA) [RFC6482] to authorize an Autonomous System (AS) to originate routes for that block. Internet Service Providers (ISPs) can then use the RPKI to validate BGP routes. (Validation of the origin of a route is described in [RFC6811], and validation of the path of a route is described in [RFC8205].)
Resource Public Key Infrastructure（RPKI）は、インターネット認証リソース（INR）の所有者がこれらのリソースについて検証可能なステートメントを作成できるようにするグローバル認証インフラストラクチャです。たとえば、IP（v4またはv6）アドレスのブロックの所有者は、ルートオリジン認証（ROA）[RFC6482]を発行して、自律システム（AS）がそのブロックのルートを発信することを承認できます。インターネットサービスプロバイダー（ISP）は、RPKIを使用してBGPルートを検証できます。 （ルートの起点の検証は[RFC6811]で説明されており、ルートのパスの検証は[RFC8205]で説明されています。）
However, an RPKI Relying Party (RP) may want to override some of the information expressed via configured Trust Anchors (TAs) and the certificates downloaded from the RPKI repository system. For instance, [RFC6491] recommends the creation of ROAs that would invalidate public routes for reserved and unallocated address space, yet some ISPs might like to use BGP and the RPKI with private address space (see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers (see [RFC1930] and [RFC6996]). Local use of private address space and/or AS numbers is consistent with the RFCs cited above, but such use cannot be verified by the global RPKI. This motivates creation of mechanisms that enable a network operator to publish, at its discretion, an exception to the RPKI in the form of filters and additions (for its own use and that of its customers). Additionally, a network operator might wish to make use of a local override capability to protect routes from adverse actions [RFC8211], until the results of such actions have been addressed. The mechanisms developed to provide this capability to network operators are hereby called "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
ただし、RPKI証明書利用者（RP）は、構成されたトラストアンカー（TA）とRPKIリポジトリシステムからダウンロードされた証明書を介して表現された情報の一部を上書きする場合があります。たとえば、[RFC6491]は、予約済みおよび未割り当てのアドレススペースのパブリックルートを無効にするROAの作成を推奨していますが、一部のISPは、プライベートアドレススペースでBGPおよびRPKIを使用したい場合があります（[RFC1918]、[RFC4193]、および[ RFC6598]）またはプライベートAS番号（[RFC1930]および[RFC6996]を参照）。プライベートアドレススペースやAS番号のローカルでの使用は、上記のRFCと一致していますが、そのような使用はグローバルRPKIでは確認できません。これは、ネットワークオペレーターが独自の裁量でRPKIの例外をフィルターと追加の形式で（独自の用途と顧客の用途で）公開できるようにするメカニズムの作成を動機付けます。さらに、ネットワークオペレータは、ローカルオーバーライド機能を利用して、ルートを有害なアクション[RFC8211]から保護することができます（そのようなアクションの結果が処理されるまで）。この機能をネットワークオペレータに提供するために開発されたメカニズムは、「RPKI（SLURM）による簡略化されたローカルインターネット番号リソース管理」と呼ばれます。
SLURM allows an operator to create a local view of the global RPKI by generating sets of assertions. For origin validation [RFC6811], an assertion is a tuple of {IP prefix, prefix length, maximum length, Autonomous System Number (ASN)} as used by the RPKI-Router protocol, version 0 [RFC6810] and version 1 [RFC8210]. For BGPsec [RFC8205], an assertion is a tuple of {ASN, subject key identifier, router public key} as used by version 1 of the RPKI-Router protocol. (For the remainder of this document, these assertions are called "ROA Prefix Assertions" and "BGPsec Assertions", respectively.)
SLURMを使用すると、オペレーターはアサーションのセットを生成することにより、グローバルRPKIのローカルビューを作成できます。オリジン検証[RFC6811]の場合、アサーションはRPKI-Routerプロトコル、バージョン0 [RFC6810]およびバージョン1 [RFC8210]で使用される{IPプレフィックス、プレフィックス長、最大長、自律システム番号（ASN）}のタプルです。 BGPsec [RFC8205]の場合、アサーションは、RPKI-Routerプロトコルのバージョン1で使用される{ASN、サブジェクトキー識別子、ルーター公開キー}のタプルです。 （このドキュメントの残りの部分では、これらのアサーションはそれぞれ「ROAプレフィックスアサーション」および「BGPsecアサーション」と呼ばれます。）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
SLURM provides a simple way to enable an RP to establish a local, customized view of the RPKI, overriding RPKI repository data if needed. To that end, an RP with SLURM filters out (i.e., removes from consideration for routing decisions) any assertions in the RPKI that are overridden by local ROA Prefix Assertions and BGPsec Assertions.
SLURMは、RPがRPKIのローカルのカスタマイズされたビューを確立し、必要に応じてRPKIリポジトリデータを上書きできるようにする簡単な方法を提供します。そのために、SLURMを備えたRPは、ローカルROAプレフィックスアサーションとBGPsecアサーションによってオーバーライドされたRPKI内のアサーションをフィルターで除外します（つまり、ルーティング決定の考慮から削除します）。
In general, the primary output of an RP is the data it sends to routers over the RPKI-Router protocol [RFC8210]. The RPKI-Router protocol enables routers to query an RP for all assertions it knows about (Reset Query) or for an update of only the changes in assertions (Serial Query). The mechanisms specified in this document are to be applied to the result set for a Reset Query and to both the old and new sets that are compared for a Serial Query. RP software may modify other forms of output in comparable ways, but that is outside the scope of this document.
一般に、RPの主要な出力は、RPKI-Routerプロトコル[RFC8210]を介してルーターに送信するデータです。 RPKI-Routerプロトコルを使用すると、ルーターは、RPに既知のすべてのアサーション（リセットクエリ）またはアサーションの変更のみの更新（シリアルクエリ）をRPに照会できます。このドキュメントで指定されているメカニズムは、リセットクエリの結果セットと、シリアルクエリで比較される古いセットと新しいセットの両方に適用されます。 RPソフトウェアは他の形式の出力を同等の方法で変更する場合がありますが、それはこのドキュメントの範囲外です。
+--------------+ +---------------------------+ +------------+
| | | | | |
| Repositories +--->Local cache of RPKI objects+---> Validation |
| | | | | |
+--------------+ +---------------------------+ +-----+------+
|
+-------------------------------------------------+
|
+------v-------+ +------------+ +-----------+ +-------------+
| | | | | | | |
| SLURM +---> SLURM +--->RPKI-Router+---> BGP Speakers|
| Filters | | Assertions | | Protocol | | |
+--------------+ +------------+ +-----------+ +-------------+
Figure 1: SLURM's Position in the RP Stack
図1：RPスタックでのSLURMの位置
SLURM filters and assertions are specified in JSON format [RFC8259]. JSON members that are not defined here MUST NOT be used in SLURM files. An RP MUST consider any deviations from the specifications to be errors. Future additions to the specifications in this document MUST use an incremented value for the "slurmVersion" member.
SLURMフィルターとアサーションはJSON形式[RFC8259]で指定されます。ここで定義されていないJSONメンバーは、SLURMファイルで使用してはなりません（MUST NOT）。 RPは、仕様からの逸脱をエラーと見なさなければなりません（MUST）。このドキュメントの仕様への今後の追加では、「slurmVersion」メンバーの増分値を使用する必要があります。
A SLURM file consists of a single JSON object containing the following members:
SLURMファイルは、次のメンバーを含む単一のJSONオブジェクトで構成されています。
o A "slurmVersion" member that MUST be set to 1, encoded as a number
o 数値としてエンコードされた1に設定する必要がある「slurmVersion」メンバー
o A "validationOutputFilters" member (Section 3.3), whose value is an object. The object MUST contain exactly two members:
o 値がオブジェクトである「validationOutputFilters」メンバー（セクション3.3）。オブジェクトは正確に2つのメンバーを含まなければなりません：
* A "prefixFilters" member, whose value is described in Section 3.3.1.
* 「prefixFilters」メンバー。その値はセクション3.3.1で説明されています。
* A "bgpsecFilters" member, whose value is described in Section 3.3.2.
* 「bgpsecFilters」メンバー。その値はセクション3.3.2で説明されています。
o A "locallyAddedAssertions" member (Section 3.4), whose value is an object. The object MUST contain exactly two members:
o 「locallyAddedAssertions」メンバー（セクション3.4）。その値はオブジェクトです。オブジェクトは正確に2つのメンバーを含まなければなりません：
* A "prefixAssertions" member, whose value is described in Section 3.4.1.
* 「prefixAssertions」メンバー。その値はセクション3.4.1で説明されています。
* A "bgpsecAssertions" member, whose value is described in Section 3.4.2.
* 「bgpsecAssertions」メンバー。その値はセクション3.4.2で説明されています。
In the envisioned typical use case, an RP uses both Validation Output Filters and Locally Added Assertions. In this case, the resulting assertions MUST be the same as if output filtering were performed before locally adding assertions; that is, Locally Added Assertions MUST NOT be removed by output filtering.
想定される一般的な使用例では、RPは検証出力フィルターとローカルに追加されたアサーションの両方を使用します。この場合、結果のアサーションは、ローカルでアサーションを追加する前に出力フィルタリングが実行された場合と同じでなければなりません。つまり、ローカルに追加されたアサーションは、出力フィルタリングによって削除してはなりません（MUST NOT）。
The following JSON structure with JSON members represents a SLURM file that has no filters or assertions:
JSONメンバーを含む次のJSON構造は、フィルターまたはアサーションのないSLURMファイルを表します。
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [],
"bgpsecFilters": []
},
"locallyAddedAssertions": {
"prefixAssertions": [],
"bgpsecAssertions": []
}
}
Figure 2: Empty SLURM File
図2：空のSLURMファイル
The RP can configure zero or more Validated ROA Prefix Filters ("Prefix Filters" for short). Each Prefix Filter can contain either an IPv4 or IPv6 prefix and/or an ASN. It is RECOMMENDED that an explanatory comment is included with each Prefix Filter so that it can be shown to users of the RP software.
RPは0個以上の検証済みROAプレフィックスフィルター（略して「プレフィックスフィルター」）を構成できます。各プレフィックスフィルターには、IPv4またはIPv6のプレフィックスまたはASN、あるいはその両方を含めることができます。 RPソフトウェアのユーザーに表示できるように、各プレフィックスフィルターに説明コメントを含めることをお勧めします。
The above is expressed as a value of the "prefixFilters" member, as an array of zero or more objects. Each object MUST contain either 1) one of the following members or 2) one of each of the following members.
上記は、「prefixFilters」メンバーの値として、0個以上のオブジェクトの配列として表されます。各オブジェクトには、1）次のメンバーの1つまたは2）以下のメンバーの1つが含まれている必要があります。
o A "prefix" member, whose value is a string representing either an IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see [RFC5952]).
o 値がIPv4プレフィックス（[RFC4632]のセクション3.1を参照）またはIPv6プレフィックス（[RFC5952]を参照）を表す文字列である「プレフィックス」メンバー。
o An "asn" member, whose value is a number.
o 値が数値である「asn」メンバー。
In addition, each object MAY contain one optional "comment" member, whose value is a string.
さらに、各オブジェクトには、値が文字列である1つのオプションの「コメント」メンバーが含まれる場合があります。
The following example JSON structure represents a "prefixFilters" member with an array of example objects for each use case listed above:
次のJSON構造の例は、上記の各ユースケースのサンプルオブジェクトの配列を持つ「prefixFilters」メンバーを表しています。
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
]
Figure 3: "prefixFilters" Examples
図3：「prefixFilters」の例
Any Validated ROA Payload (VRP) [RFC6811] that matches any configured Prefix Filter MUST be removed from the RP's output.
構成済みのプレフィックスフィルターに一致する検証済みのROAペイロード（VRP）[RFC6811]は、RPの出力から削除する必要があります。
A VRP is considered to match with a Prefix Filter if one of the following cases applies:
次のいずれかの場合に該当する場合、VRPはプレフィックスフィルターと一致すると見なされます。
1. If the Prefix Filter only contains an IPv4 or IPv6 prefix, the VRP is considered to match the filter if the VRP prefix is equal to or covered by the Prefix Filter prefix.
1. プレフィックスフィルターにIPv4またはIPv6プレフィックスのみが含まれている場合、VRPプレフィックスがプレフィックスフィルタープレフィックスと等しいか、プレフィックスフィルタープレフィックスでカバーされていれば、VRPはフィルターと一致すると見なされます。
2. If the Prefix Filter only contains an ASN, the VRP is considered to match the filter if the VRP ASN matches the Prefix Filter ASN.
2. プレフィックスフィルターにASNのみが含まれる場合、VRP ASNがプレフィックスフィルターASNと一致すると、VRPはフィルターと一致すると見なされます。
3. If the Prefix Filter contains both an IPv4 or IPv6 prefix and an ASN, the VRP is considered to match if the VRP prefix is equal to or covered by the Prefix Filter prefix and the VRP ASN matches the Prefix Filter ASN.
3. プレフィックスフィルターにIPv4またはIPv6プレフィックスとASNの両方が含まれている場合、VRPプレフィックスがプレフィックスフィルタープレフィックスと等しいかプレフィックスフィルタープレフィックスでカバーされ、VRP ASNがプレフィックスフィルターASNと一致する場合、VRPは一致すると見なされます。
The RP can configure zero or more BGPsec Assertion Filters ("BGPsec Filters" for short). Each BGPsec Filter can contain an ASN and/or the Base64 [RFC4648] encoding of a Router Subject Key Identifier (SKI), as described in [RFC8209] and [RFC6487]. It is RECOMMENDED that an explanatory comment is also included with each BGPsec Filter, so that it can be shown to users of the RP software.
RPは0個以上のBGPsecアサーションフィルター（略して「BGPsecフィルター」）を構成できます。 [RFC8209]と[RFC6487]で説明されているように、各BGPsecフィルターには、ルーターサブジェクトキー識別子（SKI）のASNおよび/またはBase64 [RFC4648]エンコーディングを含めることができます。 RPソフトウェアのユーザーに表示できるように、各BGPsecフィルターに説明コメントも含めることをお勧めします。
The above is expressed as a value of the "bgpsecFilters" member, as an array of zero or more objects. Each object MUST contain one of either, or one each of both following members: o An "asn" member, whose value is a number
上記は、「bgpsecFilters」メンバーの値として、0個以上のオブジェクトの配列として表されます。各オブジェクトには、次のメンバーのいずれか、または両方が含まれている必要があります。o値が数値である「asn」メンバー
o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487]. (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
o [RFC6487]のセクション4.8.2で説明されている、証明書のサブジェクトキー識別子の「=」（[RFC4648]のセクション5）を末尾に残さないBase64エンコーディングである「SKI」メンバー。 （これは、ASN.1タグまたは長さフィールドのないASN.1 OCTET STRINGの値です。）
In addition, each object MAY contain one optional "comment" member, whose value is a string.
さらに、各オブジェクトには、値が文字列である1つのオプションの「コメント」メンバーが含まれる場合があります。
The following example JSON structure represents a "bgpsecFilters" member with an array of example objects for each use case listed above:
次のJSON構造の例は、「bgpsecFilters」メンバーを表しており、上記の各ユースケースのサンプルオブジェクトの配列が含まれています。
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "<Base 64 of some SKI>",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "<Base 64 of some SKI>",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
Figure 4: "bgpsecFilters" Examples
図4：「bgpsecFilters」の例
Any BGPsec Assertion that matches any configured BGPsec Filter MUST be removed from the RP's output. A BGPsec Assertion is considered to match with a BGPsec Filter if one of the following cases applies:
構成済みのBGPsecフィルターと一致するBGPsecアサーションは、RPの出力から削除する必要があります。 BGPsecアサーションは、次のいずれかの場合に該当する場合、BGPsecフィルターと一致すると見なされます。
1. If the BGPsec Filter only contains an ASN, a BGPsec Assertion is considered to match if the Assertion ASN matches the Filter ASN.
1. BGPsecフィルターにASNのみが含まれる場合、アサーションASNがフィルターASNと一致する場合、BGPsecアサーションは一致すると見なされます。
2. If the BGPsec Filter only contains an SKI, a BGPsec Assertion is considered to match if the Assertion Router SKI matches the Filter SKI.
2. BGPsecフィルターにSKIのみが含まれる場合、アサーションルーターSKIがフィルターSKIと一致すると、BGPsecアサーションは一致すると見なされます。
3. If the BGPsec Filter contains both an ASN and a Router SKI, then a BGPsec Assertion is considered to match if both the Assertion ASN matches the Filter ASN and the Assertion Router SKI matches the Filter SKI.
3. BGPsecフィルターにASNとルーターSKIの両方が含まれている場合、アサーションASNがフィルターASNと一致し、アサーションルーターSKIがフィルターSKIと一致する場合、BGPsecアサーションは一致すると見なされます。
Each RP is locally configured with a (possibly empty) array of ROA Prefix Assertions ("Prefix Assertions" for short). Each ROA Prefix Assertion MUST contain an IPv4 or IPv6 prefix and an ASN. It MAY include a value for the maximum length. It is RECOMMENDED that an explanatory comment is also included with each so that it can be shown to users of the RP software.
各RPは、ROAプレフィックスアサーション（略して「プレフィックスアサーション」）の（空の可能性がある）配列でローカルに構成されます。各ROAプレフィックスアサーションには、IPv4またはIPv6プレフィックスとASNが含まれている必要があります。最大長の値を含めることができます。 RPソフトウェアのユーザーに表示できるように、それぞれに説明コメントも含めることをお勧めします。
The above is expressed as a value of the "prefixAssertions" member, as an array of zero or more objects. Each object MUST contain one of each of the following members:
上記は、「prefixAssertions」メンバーの値として、0個以上のオブジェクトの配列として表されます。各オブジェクトには、次のメンバーのいずれかが含まれている必要があります。
o A "prefix" member, whose value is a string representing either an IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see [RFC5952]).
o 値がIPv4プレフィックス（[RFC4632]のセクション3.1を参照）またはIPv6プレフィックス（[RFC5952]を参照）を表す文字列である「プレフィックス」メンバー。
o An "asn" member, whose value is a number.
o 値が数値である「asn」メンバー。
In addition, each object MAY contain one of each of the following members:
さらに、各オブジェクトには、次のメンバーのいずれかが含まれる場合があります。
o A "maxPrefixLength" member, whose value is a number.
o 値が数値である「maxPrefixLength」メンバー。
o A "comment" member, whose value is a string.
o 値が文字列である「コメント」メンバー。
The following example JSON structure represents a "prefixAssertions" member with an array of example objects for each use case listed above:
次のJSON構造の例は、上記の各ユースケースのサンプルオブジェクトの配列を持つ「prefixAssertions」メンバーを表しています。
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
]
Figure 5: "prefixAssertions" Examples
図5：「prefixAssertions」の例
Note that the combination of the prefix, ASN, and optional maximum length describes a VRP as described in [RFC6811]. The RP MUST add all Prefix Assertions found this way to the VRP found through RPKI validation and ensure that it sends the complete set of Protocol Data Units (PDUs), excluding duplicates when using the RPKI-Router protocol (see Sections 5.6 and 5.7 of [RFC8210]).
[RFC6811]で説明されているように、プレフィックス、ASN、およびオプションの最大長の組み合わせがVRPを記述することに注意してください。 RPは、この方法で見つかったすべてのプレフィックスアサーションをRPKI検証を通じて見つかったVRPに追加し、RPKIルータープロトコルを使用する場合の重複を除いて、プロトコルデータユニット（PDU）の完全なセットを送信することを確認する必要があります（[のセクション5.6と5.7を参照] RFC8210]）。
Each RP is locally configured with a (possibly empty) array of BGPsec Assertions. Each BGPsec Assertion MUST contain an AS number, a Router SKI, and the router public key. It is RECOMMENDED that an explanatory comment is also included so that it can be shown to users of the RP software.
各RPは、BGPsecアサーションの（空の可能性がある）配列でローカルに構成されます。各BGPsecアサーションには、AS番号、ルーターSKI、およびルーター公開鍵を含める必要があります。 RPソフトウェアのユーザーに表示できるように、説明コメントも含めることをお勧めします。
The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
上記は、「bgpsecAssertions」メンバーの値として、0個以上のオブジェクトの配列として表されます。各オブジェクトには、次のメンバーのすべてが1つずつ含まれている必要があります。
o An "asn" member, whose value is a number.
o 値が数値である「asn」メンバー。
o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
o [RFC6487]のセクション4.8.2で説明されている、証明書のサブジェクトキー識別子の「=」（[RFC4648]のセクション5）のないBase64エンコーディングである「SKI」メンバー（これはASNの値です） ASN.1タグまたは長さフィールドのない.1 OCTET STRING。）
o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
o [RFC8208]で説明されているように、ルーター証明書の公開鍵のsubjectPublicKeyInfo値と同等の「=」（[RFC4648]のセクション5）なしのBase64エンコーディングである「routerPublicKey」メンバー。これは、subjectPublicKeyInfoの完全なASN.1 DERエンコーディングで、subjectPublicKeyInfo SEQUENCEのASN.1タグと長さの値を含みます。
The following example JSON structure represents a "bgpsecAssertions" member with one object as described above:
次のJSON構造の例は、上記の1つのオブジェクトを持つ「bgpsecAssertions」メンバーを表します。
"bgpsecAssertions": [
{
"asn": 64496,
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>",
"comment": "My known key for my important ASN"
}
]
Figure 6: "bgpsecAssertions" Examples
図6：「bgpsecAssertions」の例
Note that a "bgpsecAssertions" member matches the syntax of the Router Key PDU described in Section 5.10 of [RFC8210]. Relying Parties MUST add any "bgpsecAssertions" member thus found to the set of Router Key PDUs, excluding duplicates, when using the RPKI-Router protocol [RFC8210].
「bgpsecAssertions」メンバーは、[RFC8210]のセクション5.10で説明されているルーターキーPDUの構文と一致することに注意してください。 RPKI-Routerプロトコル[RFC8210]を使用する場合、証明書利用者は、このようにして見つかった「bgpsecAssertions」メンバーをルーターキーPDUのセットに追加する必要があります（重複を除く）。
The following JSON structure represents an example of a SLURM file that uses all the elements described in the previous sections:
次のJSON構造は、前のセクションで説明したすべての要素を使用するSLURMファイルの例を表しています。
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
],
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "Zm9v",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "YmFy",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
},
"locallyAddedAssertions": {
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
],
"bgpsecAssertions": [
{
"asn": 64496,
"comment" : "My known key for my important ASN",
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>"
}
]
}
}
Figure 7: Example of Full SLURM File
図7：完全なSLURMファイルの例
To ensure local consistency, the effect of SLURM MUST be atomic. That is, the output of the RP either MUST be the same as if a SLURM file were not used or MUST reflect the entire SLURM configuration. For an example of why this is required, consider the case of two local routes for the same prefix but different origin ASNs. Both routes are configured with Locally Added Assertions. If neither addition occurs, then both routes could be in the NotFound state [RFC6811]. If both additions occur, then both routes would be in the Valid state. However, if one addition occurs and the other does not, then one could be Invalid while the other is Valid.
ローカルの整合性を確保するために、SLURMの効果はアトミックである必要があります。つまり、RPの出力は、SLURMファイルが使用されなかった場合と同じであるか、SLURM構成全体を反映している必要があります。これが必要な理由の例として、同じプレフィックスであるが元のASNが異なる2つのローカルルートの場合を考えてみます。どちらのルートもローカルに追加されたアサーションで構成されています。どちらの追加も行われない場合、両方のルートがNotFound状態にある可能性があります[RFC6811]。両方の追加が発生した場合、両方のルートが有効な状態になります。ただし、一方の追加が発生し、もう一方の追加が発生しない場合、一方が無効であり、他方が有効である可能性があります。
An implementation MAY support the concurrent use of multiple SLURM files. In this case, the resulting inputs to Validation Output Filters and Locally Added Assertions are the respective unions of the inputs from each file. The envisioned typical use case for multiple files is when the files have distinct scopes. For instance, operators of two distinct networks may resort to one RP system to frame routing decisions. As such, they probably deliver SLURM files to this RP independently. Before an RP configures SLURM files from different sources, it MUST make sure there is no internal conflict among the INR assertions in these SLURM files. To do so, the RP SHOULD check the entries of each SLURM file with regard to overlaps of the INR assertions and report errors to the sources that created the SLURM files in question. The RP gets multiple SLURM files as a set, and the whole set MUST be rejected in case of any overlaps among the SLURM files.
実装は、複数のSLURMファイルの同時使用をサポートしてもよい（MAY）。この場合、検証出力フィルターおよびローカルに追加されたアサーションへの結果の入力は、各ファイルからの入力のそれぞれの和集合です。複数のファイルの想定される一般的な使用例は、ファイルに異なるスコープがある場合です。たとえば、2つの異なるネットワークのオペレータは、1つのRPシステムを使用してルーティングの決定をフレーム化する場合があります。そのため、SLURMファイルをこのRPに個別に配信する可能性があります。 RPがさまざまなソースからのSLURMファイルを構成する前に、これらのSLURMファイル内のINRアサーション間に内部競合がないことを確認する必要があります。そうするために、RPは、INRアサーションの重複に関して各SLURMファイルのエントリをチェックし、問題のSLURMファイルを作成したソースにエラーを報告する必要があります（SHOULD）。 RPは複数のSLURMファイルをセットとして取得します。SLURMファイル間で重複がある場合、セット全体を拒否する必要があります。
If a problem is detected with the INR assertions in these SLURM files, the RP MUST NOT use them and SHOULD issue a warning as error report in the following cases:
これらのSLURMファイルのINRアサーションで問題が検出された場合、RPはそれらを使用してはならず（MUST NOT）、以下の場合にエラーレポートとして警告を発行する必要があります。
1. There may be conflicting changes to ROA Prefix Assertions if an IP address X and distinct SLURM files Y and Z exist such that X is contained by any prefix in any "prefixAssertions" or "prefixFilters" in file Y and X is contained by any prefix in any "prefixAssertions" or "prefixFilters" in file Z.
1. IPアドレスXと個別のSLURMファイルYおよびZが存在し、XがファイルYの「prefixAssertions」または「prefixFilters」の任意のプレフィックスに含まれ、XがファイルYの任意のプレフィックスに含まれる場合、ROAプレフィックスアサーションに変更の競合がある可能性がありますファイルZの「prefixAssertions」または「prefixFilters」。
2. There may be conflicting changes to BGPsec Assertions if an ASN X and distinct SLURM files Y and Z exist such that X is used in any "bgpsecAssertions" or "bgpsecFilters" in file Y and X is used in any "bgpsecAssertions" or "bgpsecFilters" in file Z.
2. ASN Xと個別のSLURMファイルYおよびZが存在し、XがファイルYの「bgpsecAssertions」または「bgpsecFilters」で使用され、Xが「bgpsecAssertions」または「bgpsecFilters」で使用される場合、BGPsecアサーションへの変更が競合する可能性があります。ファイルZ
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The mechanisms described in this document provide a network operator with additional ways to control use of RPKI data while preserving autonomy in address space and ASN management. These mechanisms are only applied locally; they do not influence how other network operators interpret RPKI data. Nonetheless, care should be taken in how these mechanisms are employed. Note that it also is possible to use SLURM to (locally) manipulate assertions about non-private INRs, e.g., allocated address space that is globally routed. For example, a SLURM file may be used to override RPKI data that a network operator believes has been corrupted by an adverse action. Network operators who elect to use SLURM in this fashion should use extreme caution.
このドキュメントで説明されているメカニズムは、アドレススペースとASN管理の自律性を維持しながら、RPKIデータの使用を制御する追加の方法をネットワークオペレーターに提供します。これらのメカニズムはローカルでのみ適用されます。他のネットワークオペレーターがRPKIデータを解釈する方法には影響しません。それにもかかわらず、これらのメカニズムがどのように使用されるかに注意が必要です。 SLURMを使用して、プライベートではないINR（たとえば、グローバルにルーティングされる割り当てられたアドレス空間）に関するアサーションを（ローカルで）操作することもできます。たとえば、SLURMファイルを使用して、ネットワークオペレータが悪意のある操作によって破損したと考えるRPKIデータを上書きできます。この方法でSLURMを使用することを選択するネットワークオペレーターは、細心の注意を払う必要があります。
The goal of the mechanisms described in this document is to enable an RP to create its own view of the RPKI, which is intrinsically a security function. An RP using a SLURM file is trusting the assertions made in that file. Errors in the SLURM file used by an RP can undermine the security offered to that RP by the RPKI. A SLURM file could declare as invalid ROAs that would otherwise be valid, and vice versa. As a result, an RP MUST carefully consider the security implications of the SLURM file being used, especially if the file is provided by a third party.
このドキュメントで説明するメカニズムの目標は、RPが本来はセキュリティ機能であるRPKIの独自のビューを作成できるようにすることです。 SLURMファイルを使用するRPは、そのファイルで作成されたアサーションを信頼しています。 RPが使用するSLURMファイルのエラーは、RPKIがそのRPに提供するセキュリティを損なう可能性があります。 SLURMファイルは、そうでなければ有効である無効なROAとして宣言でき、その逆も同様です。その結果、RPは、特にファイルがサードパーティによって提供されている場合、使用されているSLURMファイルのセキュリティへの影響を慎重に検討する必要があります。
Additionally, each RP using SLURM MUST ensure the authenticity and integrity of any SLURM file that it uses. Initially, the SLURM file may be preconfigured out of band, but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file. The mechanism to update the SLURM file to guarantee authenticity and integrity is out of the scope of this document.
さらに、SLURMを使用する各RPは、使用するすべてのSLURMファイルの信頼性と整合性を保証する必要があります。最初に、SLURMファイルは帯域外で事前構成されている場合がありますが、RPがネットワーク経由でSLURMファイルを更新する場合、更新されたSLURMファイルの信頼性と整合性を確認する必要があります。信頼性と整合性を保証するためにSLURMファイルを更新するメカニズムは、このドキュメントの範囲外です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：// www.rfc-editor.org/info/rfc4632>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<https://www.rfc-editor.org/info/rfc5952> 。
[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>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https：/ /www.rfc-editor.org/info/rfc6811>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[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>。
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]ターナー、S。およびO.ボーチャート、「BGPsecアルゴリズム、キー形式、および署名形式」、RFC 8208、DOI 10.17487 / RFC8208、2017年9月、<https://www.rfc-editor.org/info/ rfc8208>。
[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]レイノルズ、M。、ターナー、S。、およびS.ケント、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <https://www.rfc-editor.org/info/rfc1930>.
[RFC1930] Hawkinson、J。およびT. Bates、「自律システム（AS）の作成、選択、および登録に関するガイドライン」、BCP 6、RFC 1930、DOI 10.17487 / RFC1930、1996年3月、<https：// www .rfc-editor.org / info / rfc1930>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[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>。
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, DOI 10.17487/RFC6491, February 2012, <https://www.rfc-editor.org/info/rfc6491>.
[RFC6491] Manderson、T.、Vegoda、L。、およびS. Kent、「IANAによって発行されるリソース公開鍵インフラストラクチャ（RPKI）オブジェクト」、RFC 6491、DOI 10.17487 / RFC6491、2012年2月、<https：// www。 rfc-editor.org/info/rfc6491>。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、DOI 10.17487 / RFC6598 、2012年4月、<https://www.rfc-editor.org/info/rfc6598>。
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6810] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol」、RFC 6810、DOI 10.17487 / RFC6810、2013年1月、<https://www.rfc-editor.org/ info / rfc6810>。
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <https://www.rfc-editor.org/info/rfc6996>.
[RFC6996] Mitchell、J。、「私的使用のための自律システム（AS）予約」、BCP 6、RFC 6996、DOI 10.17487 / RFC6996、2013年7月、<https://www.rfc-editor.org/info/rfc6996 >。
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.
[RFC8210] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol、Version 1」、RFC 8210、DOI 10.17487 / RFC8210、2017年9月、<https：//www.rfc-editor .org / info / rfc8210>。
[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", RFC 8211, DOI 10.17487/RFC8211, September 2017, <https://www.rfc-editor.org/info/rfc8211>.
[RFC8211] Kent、S。およびD. Ma、「認証局（CA）またはResource Public Key Infrastructure（RPKI）のリポジトリマネージャーによる有害なアクション」、RFC 8211、DOI 10.17487 / RFC8211、2017年9月、<https： //www.rfc-editor.org/info/rfc8211>。
Acknowledgments
謝辞
The authors would like to thank Stephen Kent for his guidance and detailed reviews of this document. The authors would also like to thank Richard Hansen for his careful reviews and Hui Zou and Chunlin An for their editorial assistance.
著者は、このドキュメントのガイダンスと詳細なレビューを提供してくれたStephen Kentに感謝します。著者はまた、彼の注意深いレビューをしてくれたRichard Hansenと編集支援をしてくれたHui ZouとChunlin Anにも感謝したいと思います。
Authors' Addresses
著者のアドレス
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
David Mandelberg Unaffiliated
デビッドマンデルバーグ
Email: david@mandelberg.org
URI: https://david.mandelberg.org
Tim Bruijnzeels NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
Tim Bruijnzeels NLnet Labs Science Park 400アムステルダム1098 XHオランダ
Email: tim@nlnetlabs.nl