[要約] RFC 6483は、リソース証明書公開鍵基盤（PKI）とルートオリジン認証（ROA）を使用したルート発信元の検証に関するものです。このRFCの目的は、インターネットルーティングのセキュリティを向上させるために、ルートオリジンの正当性を確認する仕組みを提供することです。
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 6483 G. Michaelson
Category: Informational APNIC
ISSN: 2070-1721 February 2012
Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)
リソース証明書公開キーインフラストラクチャ（PKI）およびルートオリジン認証（ROA）を使用したルートオリジネーションの検証
Abstract
概要
This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.
このドキュメントは、Border Gateway Protocolで宣伝されているルートの発信を検証するために、リソース公開キーインフラストラクチャの適用のコンテキストの観点から、ルート起源認証（ROA）のセマンティクスを定義します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6483.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6483で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. ROA Validation Outcomes for a Route .............................3
3. Applying Validation Outcomes to Route Selection .................5
4. Disavowal of Routing Origination ................................6
5. Route Validation Lifetime .......................................6
6. Security Considerations .........................................7
7. Acknowledgements ................................................7
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure (RPKI) [RFC6480] to validate the origination of routes advertised in the Border Gateway Protocol (BGP) [RFC4271].
このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）[RFC6480]の適用のコンテキストの観点から、ルートオリジン認証（ROA）のセマンティクスを定義して、Border Gateway Protocol（BGP）[RFC4271で宣伝されているルートの発信を検証します。]。
The RPKI is based on a hierarchy of resource certificates that are aligned to the Internet Number Resource allocation structure. Resource certificates are X.509 certificates that conform to the PKIX profile [RFC5280], and to the extensions for IP addresses and AS identifiers [RFC3779]. A resource certificate describes an action by an issuer that binds a list of IP address blocks and Autonomous System (AS) numbers to the subject of a certificate, identified by the unique association of the subject's private key with the public key contained in the resource certificate. The RPKI is structured such that each current resource certificate matches a current resource allocation or assignment. This is further described in [RFC6480].
RPKIは、インターネット番号のリソース割り当て構造に合わせたリソース証明書の階層に基づいています。リソース証明書は、PKIXプロファイル[RFC5280]に準拠するX.509証明書、およびIPアドレスの拡張および識別子[RFC3779]に準拠しています。リソース証明書は、被験者の秘密鍵のユニークな関連付けによってリソース証明書に含まれる公開鍵と識別される、証明書の主題にIPアドレスブロックと自律システム（AS）番号のリストをバインドする発行者によるアクションを説明します。。RPKIは、現在の各リソース証明書が現在のリソース割り当てまたは割り当てと一致するように構成されています。これは[RFC6480]でさらに説明されています。
ROAs are digitally signed objects that bind an address to an AS number, and are signed by the address holder. A ROA provides a means of verifying that an IP address block holder has authorized a particular AS to originate routes in the inter-domain routing environment for that address block. ROAs are described in [RFC6482]. ROAs are intended to fit within the requirements for adding security to inter-domain routing.
ROASは、アドレスをAS番号にバインドするデジタル署名されたオブジェクトであり、アドレスホルダーによって署名されます。ROAは、IPアドレスブロックホルダーが、そのアドレスブロックのドメイン間ルーティング環境のルートを発生するように特定のことを許可していることを確認する手段を提供します。ROASは[RFC6482]で説明されています。ROASは、ドメイン間ルーティングにセキュリティを追加するための要件に適合することを目的としています。
This document describes the semantic interpretation of a ROA, with particular reference to application in inter-domain routing relating to the origination of routes, and the intended scope of the authority that is conveyed in the ROA.
このドキュメントでは、ROAのセマンティック解釈について説明します。特に、ルートの起源に関連するドメイン間ルーティングのアプリケーションと、ROAで伝えられる当局の意図された範囲について説明します。
A "route" is unit of information that associates a set of destinations described by an IP address prefix with a set of attributes of a path to those destinations, as defined in Section 1.1 of [RFC4271].
「ルート」は、[RFC4271]のセクション1.1で定義されているように、IPアドレスのプレフィックスによって記述された一連の目的地をそれらの目的地へのパスの属性のセットに関連付ける情報の単位です。
A route's "origin AS" is defined as follows: If the final path segment of the AS_PATH is of type AS_SEQUENCE, the origin AS is the first element of the sequence (i.e., the AS in the rightmost position with respect to the position of octets in the protocol message). If the AS_PATH contains a path segment of type AS_SET, indicating that the route is an aggregate, then the origin AS cannot be determined. In terms of validation of a route in the context of a routing environment, the address prefix value and the origin AS are used in the ROA validation operation.
ルートの「起源として」は次のように定義されます。AS_PATHの最終パスセグメントがタイプAS_シーケンスの場合、シーケンスの最初の要素と同様の原点（すなわち、オクテットの位置に関する右端の位置のASプロトコルメッセージ）。AS_PATHにAS_SETのタイプのパスセグメントが含まれている場合、ルートが集計であることを示している場合、原点は決定できません。ルーティング環境のコンテキストでのルートの検証に関しては、ROA検証操作で使用されているアドレスのプレフィックス値と起源。
It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) The RP needs to match a route to one or more valid candidate ROAs in order to determine a validation outcome, which, in turn, can be used to determine the appropriate local actions to perform on the route.
ここでは、頼る当事者（RP）が、ルートの検証を実行する際に、有効なROAの完全なセットのローカルキャッシュにアクセスできると想定されています。（有効なROAは、[RFC6482]で説明されているように、RPKIを使用して検証できる署名を使用して、構文的に正しいと判断され、署名されたROAとして定義されます。）RPは、1つ以上の有効な候補RoASにルートを一致させる必要があります。検証結果を決定するために、これを使用して、ルートで実行する適切なローカルアクションを決定できます。
This approach to route origination validation uses a generic model of "positive" attestation that has an associated inference that routes that cannot be validated within the RPKI framework would conventionally be interpreted by an RP as "invalid". However, the considerations of accommodating environments of partial adoption of the use of ROAs, where only a subset of validly advertised address prefixes have associated published ROAs within the structure of the RPKI, imply some modification to this model of positive attestation. In the context of route validation, it is assumed that once an address prefix is described in a ROA, then this ROA specifically encompasses all address prefixes that are more specific than that described in the ROA. Thus, any route for a more specific address prefix than that described by any valid ROA that does not itself have a matching valid ROA can be considered "invalid". However, routes for address prefixes that are not fully described by any single ROA (i.e., those routes whose address prefixes may be an aggregate of address prefixes described in a valid ROA, or have address prefixes where there is no intersection with any valid ROA), and are not matched by any valid ROA and do not have an address prefix that is a more specific address prefix described in any valid ROA, cannot be reliably classified as "invalid" in a partial deployment scenario. Such routes have a validation outcome of "unknown".
ルーティングオリジネーション検証へのこのアプローチは、RPKIフレームワーク内で検証できないルートが従来、RPによって「無効」と解釈されるという関連する推論を持つ「ポジティブ」証明の一般的なモデルを使用します。ただし、有効に宣伝されたアドレスプレフィックスのサブセットのみがRPKIの構造内で公開されたROASを関連付けているROAの使用の部分的な採用の環境に対応することの考慮事項は、この肯定的な認証のこのモデルの修正を暗示しています。ルート検証のコンテキストでは、アドレスプレフィックスがROAで説明されると、このROAは、ROAで説明されているものよりも具体的なすべてのアドレスプレフィックスを特別に網羅すると想定されています。したがって、それ自体が一致する有効なROAを持っていない有効なROAで説明されているものよりも、より具体的なアドレスプレフィックスのルートは「無効」と見なすことができます。ただし、単一のROAによって完全に記述されていないアドレスプレフィックスのルート（つまり、アドレスプレフィックスが有効なROAで説明されているアドレスプレフィックスの集合体であるか、有効なROAとの交差点がないアドレスプレフィックスを持っているルートのルート） 、また、有効なROAによって一致しておらず、有効なROAで説明されているより具体的なアドレスプレフィックスであるアドレスプレフィックスはありませんが、部分展開シナリオでは「無効」として確実に分類できません。このようなルートには、「不明」の検証結果があります。
An abstract attribute of a route can be determined as the outcome of this validation procedure, namely a "validity state" [BGP-PFX]. The validity state of a route, with a prefix and an origin AS as defined above, when using single ROA for determining this validity state, is summarized in the following table:
ルートの抽象属性は、この検証手順の結果、つまり「有効性状態」[BGP-PFX]として決定できます。この有効性状態を決定するために単一ROAを使用する場合、上記のようにプレフィックスと起源を備えたルートの妥当性状態を次の表にまとめます。
Route matching non-matching
Prefix AS-> AS AS
V +---------+---------+
Non- | unknown | unknown |
Intersecting | | |
+---------+---------+
Covering | unknown | unknown |
Aggregate | | |
+---------+---------+
match ROA | valid | invalid |
prefix | | |
+---------+---------+
More | | |
Specific | invalid | invalid |
than ROA | | |
+---------+---------+
Route's Validity State
ルートの有効性状態
In an environment of a collection of valid ROAs, a route's validity state is considered to be "valid" if any ROA provides a "valid" outcome. It's validity state is considered to be "invalid" if one (or more) ROAs provide an "invalid" outcome and no ROAs provide a "valid" outcome. Its validity state is considered to be "unknown" (or, synonymously, "not found" [BGP-PFX]) when no valid ROA can produce either a "valid" or an "invalid" validity state outcome.
有効なROAのコレクションの環境では、ROAが「有効な」結果を提供する場合、ルートの有効性状態は「有効」であると見なされます。1つ（またはそれ以上）のROAが「無効な」結果を提供し、「有効な」結果を提供しない場合、それは「無効」であると見なされます。有効なROAが「有効」または「無効な」有効性状態の結果を生成できない場合、その有効性状態は「不明」（または同義語では「BGP-PFX] [BGP-PFX]）と見なされます。
A route validity state is defined by the following procedure:
ルートの有効性状態は、次の手順で定義されます。
1. Select all valid ROAs that include a ROAIPAddress value that either matches, or is a covering aggregate of, the address prefix in the route. This selection forms the set of "candidate ROAs".
1. ルート内のアドレスのプレフィックスを一致させるか、カバーする集約であるロアイパドレス値を含むすべての有効なロアを選択します。この選択は、「候補ロア」のセットを形成します。
2. If the set of candidate ROAs is empty, then the procedure stops with an outcome of "unknown" (or, synonymously, "not found", as used in [BGP-PFX]).
2. 候補ROASのセットが空の場合、[BGP-PFX]で使用されるように、「不明」（または同義語で「見つかりません」）の結果で手順が停止します。
3. If the route's origin AS can be determined and any of the set of candidate ROAs has an asID value that matches the origin AS in the route, and the route's address prefix matches a ROAIPAddress in the ROA (where "match" is defined as where the
3. ルートの起源を決定できるようにし、候補ROASのセットのいずれかがルートのように原点と一致するASID値を持ち、ルートのアドレスのプレフィックスがROAのRoaipAddressと一致する場合（「一致」は、ここで定義されます。
route's address precisely matches the ROAIPAddress, or where the ROAIPAddress includes a maxLength element, and the route's address prefix is a more specific prefix of the ROAIPAddress, and the route's address prefix length value is less than or equal to the ROAIPAddress maxLength value), then the procedure halts with an outcome of "valid".
ルートのアドレスは、RoaipAddressまたはRoaipAddressが最大長要素を含む場所と正確に一致し、ルートのアドレスのプレフィックスはRoaipAddressのより具体的なプレフィックスであり、ルートのアドレスのプレフィックス長値はRoaipAddress maxlength値以下です）、この手順は、「有効」の結果で停止します。
4. Otherwise, the procedure halts with an outcome of "invalid".
4. それ以外の場合、手順は「無効」の結果で停止します。
Within the framework of the abstract model of the operation of inter-domain routing using BGP [RFC4271], a received prefix announcement from a routing peer is compared to all announcements for this prefix received from other routing peers, and a route selection procedure is used to select the "best" route from this candidate set.
BGP [RFC4271]を使用したドメイン間ルーティングの操作の抽象モデルのフレームワーク内で、ルーティングピアから受信したプレフィックスの発表は、他のルーティングピアから受信したこのプレフィックスのすべての発表と比較され、ルート選択手順が使用されます。この候補セットから「最適」ルートを選択するには。
The route's validity state, described in Section 2, of "valid", "invalid", or "unknown" may be used as part of the determination of the local degree of preference, in which case the local order of preference is as follows:
「有効」、「無効」、または「不明」のセクション2で説明されているルートの有効性状態は、局所選好度の決定の一部として使用できます。
"valid" is to be preferred over "unknown", which is to be preferred over "invalid".
「有効」は、「未知」よりも好まれる必要があります。これは、「無効」よりも優先されます。
It is a matter of local routing policy as to the actions to be undertaken by a routing entity in processing those routes with "unknown" validity states. Due to considerations of partial use of ROAs in heterogeneous environments, such as in the public Internet, it is advised that local policy settings should not result in "unknown" validity state outcomes being considered as sufficient grounds to reject a route outright from further consideration as a local best route.
「不明な」妥当性状態でそれらのルートを処理する際にルーティングエンティティによって行われるアクションに関するローカルルーティングポリシーの問題です。パブリックインターネットなどの不均一な環境でのROAの部分的な使用の考慮事項により、ローカルポリシーの設定は、「未知の」妥当性の状態の結果をもたらさないことをお勧めします。地元の最高のルート。
It is a matter of local routing policy as to whether routes with an "invalid" validity state are considered to be ineligible for further consideration in a route selection process. Potential circular dependence is a consideration here: if the authoritative publication point of the repository of ROAs, or that of any certificate used in relation to an address prefix, is located at an address that lies within the address prefix described in a ROA, then the repository can only be accessed by the RP once a route for the prefix has been accepted by the RP's local routing domain. It is also noted that the propagation time of RPKI objects may be different to the propagation time of routes, and that routes may be learned by an RP's routing system before the RP's local RPKI repository cache picks up the
「無効な」妥当性状態を持つルートがルート選択プロセスでさらなる検討の対象となると見なされているかどうかについてのローカルルーティングポリシーの問題です。潜在的な円形依存性はここでの考慮事項です。ROASのリポジトリの権威ある公開ポイント、またはアドレスプレフィックスに関連して使用される証明書のものが、ROAで説明されているアドレスプレフィックス内にあるアドレスにある場合、次に、リポジトリは、RPのローカルルーティングドメインによってプレフィックスのルートが受け入れられると、RPによってのみアクセスできます。また、RPKIオブジェクトの伝播時間は、ルートの伝播時間とは異なる場合があり、RPのローカルRPKIリポジトリキャッシュがピックアップする前にRPのルーティングシステムによってルートが学習できることにも注意してください。
associated ROAs and recognizes them as having a validity state of "valid" within the RPKI.
RPKI内の「有効」の妥当性状態を持っていると認識し、RPKI内で認識します。
A ROA is a positive attestation that a prefix holder has authorized an AS to originate a route for this prefix into the inter-domain routing system. It is possible for a prefix holder to construct an authorization where no valid AS has been granted any such authority to originate a route for an address prefix. This is achieved by using a ROA where the ROA's subject AS is one that must not be used in any routing context. Specifically, AS 0 is reserved by the IANA such that it may be used to identify non-routed networks [IANA-AS].
ROAは、プレフィックスホルダーがこのプレフィックスのルートをドメイン間ルーティングシステムに発信することを許可したという肯定的な証明です。プレフィックスホルダーは、アドレスプレフィックスのルートを発生させるそのような権限が付与されているように有効な認可を構築することができます。これは、ROAを使用して達成されます。ここでは、ROAの主題は、ルーティングコンテキストで使用してはなりません。具体的には、0はIANAによって予約されているため、非ルーティングネットワークを識別するために使用されるようにします[IANA-AS]。
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
AS 0（AS 0 ROA）の主題を持つROAは、ROAで説明されているプレフィックスとより特定のプレフィックスをルーティングコンテキストで使用しないでください。
The route validation procedure, described in Section 2, will provide a "valid" outcome if any ROA matches the address prefix and origin AS, even if other valid ROAs would provide an "invalid" validation outcome if used in isolation. Consequently, an AS 0 ROA has a lower relative preference than any other ROA that has a routable AS as its subject. This allows a prefix holder to use an AS 0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered "invalid", while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes.
セクション2で説明されているルート検証手順は、他の有効なROAが分離して使用された場合に「無効」検証結果を提供する場合でも、ROAがアドレスプレフィックスとオリジンと一致する場合、「有効な」結果を提供します。その結果、AS 0 ROAは、その主題と同様にルーティング可能な他のROAよりも相対的な好みが低くなります。これにより、プレフィックスホルダーはAS 0 ROAを使用して、接頭辞以外のルートが「無効」と見なされると見なされるデフォルトの条件を宣言し、他の同時に発行されたROAが有効な発信承認をより詳細に説明できるようにすることができます。特定のプレフィックス。
By convention, an AS 0 ROA should have a maxLength value of 32 for IPv4 addresses and a maxlength value of 128 for IPv6 addresses; although, in terms of route validation, the same outcome would be achieved with any valid maxLength value, or even if the maxLength element were to be omitted from the ROA.
慣習により、AS 0 ROAは、IPv4アドレスの最大値は32、IPv6アドレスでは最大値128を持つ必要があります。ただし、ルート検証の観点から、有効な最大値で同じ結果が達成されるか、最大長要素がROAから省略された場合でも、同じ結果が達成されます。
Also by convention, an AS 0 ROA should be the only ROA issued for a given address prefix; although again, this is not a strict requirement. An AS 0 ROA may coexist with ROAs that have different subject AS values; although in such cases, the presence or lack of presence of the AS 0 ROA does not alter the route's validity state in any way.
また、慣習により、特定のアドレスプレフィックスに対して発行された唯一のROAである必要があります。繰り返しますが、これは厳格な要件ではありません。AS 0 ROAは、値として異なる主題を持つROAと共存する可能性があります。そのような場合は、AS 0 ROAの存在または存在の存在または欠如は、いかなる方法でもルートの妥当性状態を変更しません。
The "lifetime" of a validation outcome refers to the time period during which the original validation outcome can be still applied. The implicit assumption here is that when the validation lifetime "expires", the route should be re-tested for validity.
検証結果の「生涯」は、元の検証結果を適用できる期間を指します。ここでの暗黙の仮定は、検証寿命が「期限切れ」になる場合、ルートは有効性のために再テストされるべきであるということです。
The validation lifetime for a ROA is controlled by the Valid times specified in the end-entity (EE) certificate used to sign the ROA, and the valid times of those certificates in the certification path used to validate the EE certificate. A ROA validation expires at the notAfter field of the signing EE certificate, or at such a time when there is no certification path that can validate the ROA. A ROA issuer may elect to prematurely invalidate a ROA by revoking the EE certificate that was used to sign the ROA.
ROAの検証寿命は、ROAに署名するために使用されるエンドエンティティ（EE）証明書で指定された有効な時間と、EE証明書の検証に使用される認定パスのそれらの証明書の有効な時間によって制御されます。ROA検証は、署名EE証明書のNotafterフィールド、またはROAを検証できる認定パスがない場合に期限切れになります。ROA発行者は、ROAに署名するために使用されたEE証明書を取り消すことにより、ROAを早期に無効にすることを選択できます。
ROA issuers should be aware of the validation implication in issuing a ROA, in that a ROA implicitly invalidates all routes that have more specific prefixes with a prefix length greater than maxLength, and all originating AS's other than the AS listed in the collection of ROAs for this prefix.
ROA発行者は、ROAの発行における検証の意味を認識する必要があります。これは、ROAが最大長よりも大きい接頭辞の長さを持つより特定の接頭辞を持つすべてのルートを暗黙的に無効にし、ROAのコレクションにリストされているAS以外のAS以外のすべてのルートを無効にする必要があります。このプレフィックス。
A conservative operational practice would be to ensure the issuing of ROAs for all more specific prefixes with distinct origination ASes prior to the issuing of ROAs for larger encompassing address blocks, in order to avoid inadvertent invalidation of valid routes during ROA generation.
保守的な運用慣行は、ROA生成中の有効なルートの不注意な無効化を回避するために、より大きな包括的アドレスブロックのROAを発行する前に、明確なオリジネーションASEを備えた、より特定のすべての具体的なプレフィックスのROAの発行を確保することです。
ROA issuers should also be aware that if they generate a ROA for one origin AS, then if the address prefix holder authorizes multiple ASes to originate routes for a given address prefix, then is necessary for a ROA be generated for every such authorized AS.
ROA発行者は、1つの原点としてROAを生成する場合、アドレスプレフィックスホルダーが特定のアドレスプレフィックスのルートを発信するように複数のASESを許可する場合、そのような許可されたすべての承認のすべてのROAを生成する必要があることに注意する必要があります。
The authors would like to acknowledge the helpful contributions of John Scudder and Stephen Kent in preparing this document, and also the contributions of many members of the SIDR working group in response to presentations of this material in SIDR WG sessions. The authors also acknowledge prior work undertaken by Tony Bates, Randy Bush, Tony Li, and Yakov Rekhter as the validation outcomes described here reflect the authentication outcomes and semantics of origin AS verification described in [NLRI-ORIG]. A number of validation concepts relating to a route's validity state presented in [BGP-PFX], edited by Pradosh Mohapatra, et al., have be used in this document.
著者は、この文書の準備におけるジョン・スカダーとスティーブン・ケントの有益な貢献と、SIDR WGセッションのこの資料のプレゼンテーションに応じてSIDRワーキンググループの多くのメンバーの貢献を認めたいと考えています。著者はまた、ここで説明した検証結果が[NLRI-Orig]に記載されている検証としての認証結果と起源の意味論を反映しているため、トニー・ベイツ、ランディ・ブッシュ、トニー・リー、ヤコフ・レクターが行った以前の研究を認めています。Pradosh Mohapatra et al。によって編集された[BGP-PFX]で提示されたルートの有効性状態に関連する多くの検証概念は、このドキュメントで使用されています。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としてのX.509拡張」、RFC 3779、2004年6月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「Route Origin Authorizations（ROAS）のプロファイル」、RFC 6482、2012年2月。
[BGP-PFX] Mohapatra, P., Ed., Scudder, J., Ed., Ward, D., Ed., Bush, R., Ed., and R. Austein, Ed., "BGP Prefix Origin Validation", Work in Progress, October 2011.
[BGP-PFX] Mohapatra、P.、ed。、Scudder、J.、Ed。、Ward、D.、Ed。、Bush、R.、Ed。、およびR. Austein、ed。、 "BGP Prefix Origin Validation"、2011年10月に進行中の作業。
[IANA-AS] IANA, "Autonomous System (AS) Numbers",
http://http://www.iana.org/assignments/as-numbers
[NLRI-ORIG] Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based NLRI origin AS verification in BGP", Work in Progress, January 1998.
[NLRI-Orig] Bates、T.、Bush、R.、Li、T。、およびY. Rekhter、「BGPの検証としてのDNSベースのNLRI起源」、1998年1月の作業進行中。
Authors' Addresses
著者のアドレス
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
George Michaelson APNIC
ジョージ・マイケルソン・アペニック
EMail: ggm@apnic.net