[要約] 要約：RFC 7682は、インターネットルーティングレジストリ（IRRs）とルーティングポリシーの設定に関する考慮事項を提供しています。 目的：このRFCの目的は、IRRsとルーティングポリシーの設定に関するベストプラクティスとガイドラインを提供し、インターネットルーティングの効率性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 7682 Verisign, Inc.
Category: Informational S. Amante
ISSN: 2070-1721 Apple, Inc.
E. Osterweil
Verisign, Inc.
L. Blunk
Merit Network, Inc.
D. Mitchell
Singularity Networks
December 2015
Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration
インターネットルーティングレジストリ（IRR）とルーティングポリシーの構成に関する考慮事項
Abstract
概要
The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.
このドキュメントの目的は、過去20年間のグローバルルーティングシステムにおけるドメイン間ルーティングポリシーの仕様とアプリケーションのインターネットルーティングレジストリ（IRR）の有効性に影響を与えた問題をカタログ化することです。さらに、これらの問題のどれが実際にまだ問題であり、もはや適用されないアーティファクトであるかについての議論を提供しますが、プロバイダー間でのポリシーベースのフィルタリングの採用とIRRユーティリティは今日まで抑制されています。
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 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（Internet Engineering Task Force）の製品です。これは、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/rfc7682.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7682で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3
4. Accuracy and Integrity of Data Contained within the IRR . . . 4
4.1. Lack of Resource Certification . . . . . . . . . . . . . 4
4.2. Incentives to Maintain Data within the IRR . . . . . . . 5
4.3. Inability for Third Parties to Remove (Stale) Information
from the IRRs . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7
4.5. Client-Side Considerations . . . . . . . . . . . . . . . 8
4.6. Conclusions with Respect to Data in the IRR . . . . . . . 8
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8
5.1. Replication of Resources among IRRs . . . . . . . . . . . 8
5.2. Updating Routing Policies from Updated IRR Resources . . 10
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11
7. Historical Limitations of Routers . . . . . . . . . . . . . . 13
7.1. Incremental Updates to Policy on Routers . . . . . . . . 13
7.2. Storage Requirements for Policy on Routers . . . . . . . 13
7.3. Updating Configuration on Routers . . . . . . . . . . . . 14
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The purpose of this document is to catalog issues influencing the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues still pose problems in practice, and which are no longer obstacles, but whose perceived drawbacks continue to stifle inter-provider policy-based filtering support and IRR utility to this day.
このドキュメントの目的は、過去20年間のグローバルルーティングシステムにおけるドメイン間ルーティングポリシーの仕様とアプリケーションのインターネットルーティングレジストリ（IRR）の有効性に影響を与える問題をカタログ化することです。さらに、これらの問題のどれが実際に問題を引き起こし、もはや障害ではないが、その認識された欠点がプロバイダー間でのポリシーベースのフィルタリングサポートとIRRユーティリティを今日まで抑制し続けているかについての議論を提供します。
IRRs can be used to express a multitude of Internet number bindings and policy objectives, i.e., to include bindings between 1) an origin AS and a given prefix, 2) a given AS and its AS and community import and export policies, as well as 3) a given AS and the AS macros (as-sets in Routing Policy Specification Language (RPSL)) that convey the set of ASes that it intends to include in some common group.
IRRは、多数のインターネット番号バインディングとポリシー目標を表現するために使用できます。つまり、1）起点ASと特定のプレフィックス、2）特定のASとそのAS、およびコミュニティのインポートとエクスポートのポリシー間のバインディングを含めることができます。 3）特定のASおよびASマクロ（ルーティングポリシー仕様言語（RPSL）のas-sets）。これは、いくつかの共通グループに含める予定のASのセットを伝達します。
As quoted from Section 7 of "Routing in a Multi-Provider Internet" [RFC1787]:
「マルチプロバイダーインターネットでのルーティング」[RFC1787]のセクション7からの引用：
While ensuring Internet-wide coordination may be more and more difficult, as the Internet continues to grow, stability and consistency of the Internet-wide routing could significantly benefit if the information about routing requirements of various organizations could be shared across organizational boundaries. Such information could be used in a wide variety of situations ranging from troubleshooting to detecting and eliminating conflicting routing requirements. The scale of the Internet implies that the information should be distributed. Work is currently underway to establish depositories of this information (Routing Registries), as well as to develop tools that analyze, as well as utilize this information.
インターネット全体の調整を確保することはますます困難になる可能性がありますが、インターネットが成長し続けるにつれ、さまざまな組織のルーティング要件に関する情報を組織の境界を越えて共有できる場合、インターネット全体のルーティングの安定性と一貫性が大幅に向上します。このような情報は、トラブルシューティングから競合するルーティング要件の検出および排除まで、さまざまな状況で使用できます。インターネットの規模は、情報が配布されるべきであることを意味します。現在、この情報（ルーティングレジストリ）の保管場所を確立し、この情報を分析および利用するツールを開発する作業が進行中です。
The term IRR is often used, incorrectly, as a broad catch-all term to categorize issues related to the accuracy of data in the IRR, RPSL, and the operational deployment of policy (derived from RPSL contained within the IRR) to routers. It is important to classify these issues into distinct categories so that the reader can understand which categories of issues are historical artifacts that are no longer applicable and which categories of issues still exist and might be addressed by the IETF.
IRRという用語は、誤って、IRR、RPSL、およびポリシーへの運用展開（IRRに含まれるRPSLから派生）からルーターへのデータの正確性に関連する問題を分類するための広範なキャッチオール用語として誤って使用されます。これらの問題を異なるカテゴリに分類することは重要です。これにより、読者はどのカテゴリの問題が過去のアーチファクトであり、もはや適用できず、どのカテゴリの問題がまだ存在し、IETFによって対処される可能性があるかを理解できます。
The following sections will separate out challenges related to the IRR into the following categories: first, accuracy and integrity of data contained within the IRR; second, operation of the IRR infrastructure, i.e., synchronization of resources from one IRR to other IRRs; and finally, this document covers the methods related to extraction of policy from the IRR and the input, plus activation of that policy within routers.
次のセクションでは、IRRに関連する課題を次のカテゴリに分けます。最初に、IRRに含まれるデータの正確性と整合性。第二に、IRRインフラストラクチャの操作、つまり、あるIRRから他のIRRへのリソースの同期。最後に、このドキュメントでは、IRRと入力からのポリシーの抽出、およびルーター内でのそのポリシーのアクティブ化に関連する方法について説明します。
The following section will examine issues related to accuracy and integrity of data contained within the IRR.
次のセクションでは、IRRに含まれるデータの正確性と整合性に関連する問題について説明します。
Internet number resources include IPv4 addresses, IPv6 addresses, Autonomous System Numbers (ASNs), and more. While these resources are generally allocated by hierarchical authorities, a general mechanism for formally verifying (such as through cryptographic mechanisms) when parties have been allocated resources remains an open challenge. We generally call such a system a Resource Certification System, and we note that some candidate examples of how such a general system might be implemented and deployed exist -- [TASRS], [RC_HotNetsX], and [RFC6480].
インターネット番号リソースには、IPv4アドレス、IPv6アドレス、自律システム番号（ASN）などが含まれます。これらのリソースは通常、階層的機関によって割り当てられますが、パーティにリソースが割り当てられたときに（暗号化メカニズムなどを介して）正式に確認するための一般的なメカニズムは未解決の課題です。私たちは一般にそのようなシステムをリソース認証システムと呼び、そのような一般的なシステムがどのように実装および配備されるかについてのいくつかの候補例が存在することに注意します-[TASRS]、[RC_HotNetsX]、および[RFC6480]。
One of the largest weaknesses often cited with the IRR system is that the data contained within the IRRs is out of date or lacks integrity. This is largely attributable to the fact that existing IRR mechanisms do not provide ways for a relying party to (cryptographically) verify the validity of an IRR object. That is, there has never existed a resource certification infrastructure that enables a resource holder to authorize a particular autonomous system to originate network-layer reachability advertisements for a given IPv4 or IPv6 prefix. It should be noted that this is not a weakness of the underlying RPSL [RFC2622], but rather, was largely the result of no clear demand by the operator community for Internet Number Resource Registries to provide sufficient resource certification infrastructure that would enable a resource holder to develop a cryptographic binding between, for example, a given AS number and an IP prefix.
IRRシステムでよく引用される最大の弱点の1つは、IRRに含まれるデータが古くなっている、または整合性が欠けていることです。これは主に、既存のIRRメカニズムでは、依存パーティがIRRオブジェクトの有効性を（暗号で）確認する方法を提供していないという事実に起因します。つまり、リソース所有者が特定の自律システムに特定のIPv4またはIPv6プレフィックスのネットワーク層到達可能性アドバタイズメントを発信することを許可できるようにするリソース認証インフラストラクチャは、これまで存在していませんでした。これは根本的なRPSL [RFC2622]の弱点ではなく、リソースホルダーを可能にする十分なリソース認証インフラストラクチャを提供するためのインターネット番号リソースレジストリに対するオペレーターコミュニティによる明確な要求がなかった結果であることに注意してください。たとえば、特定のAS番号とIPプレフィックスの間の暗号バインディングを開発するため。
Another noteworthy (but slightly different) deficiency in the IRR system is the absence of a tangible tie between the resource and the resource holder. That is, generally there is no assurance of the validity of objects at their creation time (except for a subset of, for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE address holders and RIPE ASN holders). If a resource holder's authorization cannot be certified, then consumers cannot verify attestations made. In effect, without resource certification, consumers are basically only certifying the assertions that the creator/maintainer of the resource object has made (not if that assertion is valid).
IRRシステムのもう1つの注目すべき（ただしわずかに異なる）欠点は、リソースとリソースホルダーの間に具体的な結びつきがないことです。つまり、一般に、オブジェクトの作成時にオブジェクトの有効性が保証されません（たとえば、RPSS [RFC2725]がRIPEアドレスホルダーとRIPE ASNホルダーを証明するRIPE IRRのサブセットを除く）。リソース所有者の承認を証明できない場合、消費者は作成された証明書を検証できません。実際には、リソース認証がない場合、コンシューマは基本的に、リソースオブジェクトの作成者/保守者が作成したアサーションのみを認証します（そのアサーションが有効である場合は認証されません）。
The RIPE community addressed this last issue by putting in a foundation policy [RIPE638], which requires a contractual link between the RIPE NCC and the end user in direct assignment + ASN assignment cases, which weren't previously covered by Local Internet Registry (LIR) contracts for address allocations. There were a couple of intentions with this policy:
RIPEコミュニティは、これまでローカルインターネットレジストリ（LIR）でカバーされていなかった直接割り当て+ ASN割り当ての場合に、RIPE NCCとエンドユーザー間の契約上のリンクを必要とする基本ポリシー[RIPE638]を組み込むことで、この最後の問題に対処しました。 ）アドレス割り当ての契約。このポリシーには2つの意図があります。
1. There was an encumbrance placed in the policy for the LIR to charge the end user for provider-independent (PI) resources. This action created a collection mechanism for PI address resources (IPv4/IPv6 space, ASNs).
1. LIRがプロバイダーに依存しない（PI）リソースに対してエンドユーザーに課金するというポリシーの制約がありました。このアクションにより、PIアドレスリソース（IPv4 / IPv6スペース、ASN）の収集メカニズムが作成されました。
2. It guaranteed that all RIPE NCC allocated/assigned space would be subject to a contractual link, and that this contractual chain might end up actually meaning something when it came to the issue of who made what claim about what number resource.
2. それは、すべてのRIPE NCCが割り当てられた/割り当てられたスペースが契約リンクの対象となること、および誰がどの数のリソースについて何を主張したかという問題に関しては、この契約チェーンが実際に何かを意味することになることを保証しました。
3. It tied into the RIPE NCC's object grandfathering policy that ties the registration details of the end user to the object registered in the IRR database.
3. これは、エンドユーザーの登録の詳細をIRRデータベースに登録されているオブジェクトに結び付けるRIPE NCCのオブジェクトの祖先設定ポリシーに結び付けられています。
While this policy specifically addressed PI/portable space holders, other regions address this issue, too. Further, a tangible tie between the resource and the resource holder is indeed a prerequisite for resource certification, though it does not directly address the IRR deficiencies.
このポリシーは特にPI /ポータブルスペースホルダーに対処しましたが、他の地域もこの問題に対処しています。さらに、リソースとリソースホルダーの間の具体的な結びつきは、IRRの欠陥に直接対処するものではありませんが、実際にはリソース認証の前提条件です。
One of the central observations of this policy was that without a chain-of-ownership functionality in IRR databases, the discussion of certifying their contents becomes moot.
このポリシーの主な見解の1つは、IRRデータベースに所有権のチェーン機能がないと、そのコンテンツの認証に関する議論が根本的に難しくなるということでした。
A second problem with data contained in the IRRs is that the incentives for resource holders to maintain both accurate and up-to-date information in one or more IRRs (including deletion of out-of-date or stale data from the IRRs) can diminish rapidly when changing their peering policies (such as switching transit providers). Specifically, there is a very strong incentive for an ISP's customers to register new routing information in the IRR, because some ISPs enforce a strict policy that they will only build or update a customer's prefix-lists applied to the customer's inbound eBGP sessions based off information found within the IRRs. Unfortunately, there is little incentive for an ISP's customers to remove out-of- date information from an IRR, most likely attributed to the fact that some ISPs do not use, or enforce use of, data contained within the IRRs to automatically build incoming policy applied to the customer's eBGP sessions. For example, if a customer is terminating service from one ISP that requires use of IRR data to build incoming policy and, at the same time, enabling service with another ISP that does not require use of IRR data, then that customer will likely let the data in the IRR become stale or inaccurate.
IRRに含まれるデータの2番目の問題は、リソースホルダーが1つまたは複数のIRRで正確かつ最新の情報を維持するインセンティブ（IRRからの古いデータや古いデータの削除を含む）が減少する可能性があることです。ピアリングポリシーを変更すると（トランジットプロバイダーの切り替えなど）、迅速に。具体的には、一部のISPは情報に基づいて顧客のインバウンドeBGPセッションに適用される顧客のプレフィックスリストのみを作成または更新するという厳格なポリシーを実施するため、ISPの顧客がIRRに新しいルーティング情報を登録する非常に強いインセンティブがありますIRR内で見つかりました。残念ながら、ISPの顧客がIRRから古い情報を削除するインセンティブはほとんどありません。これは、一部のISPが、IRRに含まれるデータを使用しない、または使用を強制して、着信ポリシーを自動的に構築しないことが原因です。顧客のeBGPセッションに適用されます。たとえば、顧客が受信ポリシーを構築するためにIRRデータの使用を必要とする1つのISPからのサービスを終了し、同時にIRRデータの使用を必要としない別のISPとのサービスを有効にする場合、その顧客はおそらくIRRのデータが古くなったり不正確になったりします。
Further, policy filters are almost exclusively generated based on the origin AS information contained within IRR route objects and used by providers to filter downstream transit customers. Since providers only look for route objects containing the origin AS of their downstream customer(s), stale route objects with historical and, possibly, incorrect origin AS information are ignored. Assuming that the downstream customer(s) do not continue to announce those routes with historical, or incorrect, origin AS information in BGP to the upstream provider, there is no significant incentive to remove them as they do not impact offline policy filter generation nor routing on the Internet. On the other hand, the main incentive that causes the Service Provider to work with downstream customer(s) is when the resultant filter list becomes so large that it is difficult for it to be stored on PE routers; however, this is more practically an operational issue with very old, legacy PE routers, not more modern PE router hardware with more robust control-plane engines.
さらに、ポリシーフィルターは、IRRルートオブジェクトに含まれる元のAS情報に基づいてほぼ独占的に生成され、プロバイダーがダウンストリームのトランジット顧客をフィルターするために使用します。プロバイダーは下流の顧客のオリジンASを含むルートオブジェクトのみを検索するため、履歴の、場合によっては不正なオリジンAS情報を持つ古いルートオブジェクトは無視されます。ダウンストリームの顧客がBGPの履歴または不正確な発信元AS情報を含むこれらのルートをアップストリームプロバイダーにアナウンスし続けないと仮定すると、オフラインポリシーフィルターの生成やルーティングに影響を与えないため、それらを削除する大きな動機はありません。インターネット上で。一方、サービスプロバイダーがダウンストリームの顧客と連携する主な動機は、結果のフィルターリストが非常に大きくなり、PEルーターに格納することが困難になった場合です。ただし、これは実際には非常に古いレガシーPEルータの運用上の問題であり、より堅牢なコントロールプレーンエンジンを備えた最新のPEルータハードウェアではありません。
4.3. Inability for Third Parties to Remove (Stale) Information from the IRRs
4.3. 第三者がIRRから（古い）情報を削除できない
A third challenge with data contained in IRRs is that it is not possible for IRR operators, and ISPs who use them, to proactively remove (perceived) out-of-date or "stale" resources in an IRR, on behalf of resource holders who may not be diligent in maintaining this information themselves. The reason is that, according to the RPSL [RFC2622], only the resource holder ('mntner') specified in a 'mnt-by' value field of an RPSL resource is authorized to add, modify, or delete their own resources within the IRR. To address this issue, the 'auth-override' mechanism [RFC2725] was later developed that would have enabled a third party to update and/or remove "stale" resources from the IRR. While it is unclear if this was ever implemented or deployed, it does provide language semantics needed to overcome this obstacle.
IRRに含まれるデータの3番目の課題は、IRRオペレーター、およびそれらを使用するISPが、IRR内の古いリソースまたは「古くなった」リソースを、IRR内のリソースホルダーに代わって積極的に削除できないことです。この情報自体を維持するために勤勉ではないかもしれません。その理由は、RPSL [RFC2622]によると、RPSLリソースの「mnt-by」値フィールドで指定されたリソースホルダー（「mntner」）のみが、内部利益率。この問題に対処するために、「auth-override」メカニズム[RFC2725]が後に開発され、サードパーティがIRRから「古い」リソースを更新または削除できるようになりました。これが実装または展開されたかどうかは不明ですが、この障害を克服するために必要な言語セマンティクスを提供します。
Nevertheless, with such a mechanism in place, there is still a risk that the original RPSL resource holder would not receive notifications (via the 'notify' attribute in various RPSL resources) about the pending or actual removal of a resource from the IRR in time to halt that action if those resources were still being used.
それにもかかわらず、そのようなメカニズムが配置されていても、元のRPSLリソースホルダーがIRRからのリソースの保留中または実際の削除に関する通知を（さまざまなRPSLリソースの「通知」属性を介して）受信しないというリスクがあります。それらのリソースがまだ使用されている場合は、そのアクションを停止します。
In this case, if the removal of a resource was not suspended, it could potentially result in an unintentional denial of service for the RPSL resource holder when, for example, ISPs automatically generated and deployed a new policy based on the newly removed resources from the IRR, thus dropping any reachability announcement for the removed resource in eBGP.
この場合、リソースの削除が一時停止されなかった場合、たとえば、ISPが新しく削除されたリソースに基づいて新しいポリシーを自動的に生成および展開したときに、RPSLリソースホルダーに意図しないサービス拒否が発生する可能性があります。 IRR。これにより、eBGPで削除されたリソースの到達可能性アナウンスがドロップされます。
According to [RFC2622], within an RPSL resource "the source attribute specifies the registry where the object is registered." Note that this source attribute only exists within the RPSL resource itself. Unfortunately, given a specific resource (e.g., a specific IPv4 or IPv6 prefix), most of the time it is impossible to determine a priori the authoritative IRR where to query and retrieve an authoritative copy of that resource.
[RFC2622]によれば、RPSLリソース内で、「ソース属性は、オブジェクトが登録されているレジストリを指定します。」このソース属性はRPSLリソース自体にのみ存在することに注意してください。残念ながら、特定のリソース（たとえば、特定のIPv4またはIPv6プレフィックス）が与えられた場合、ほとんどの場合、そのリソースの信頼できるコピーを照会および取得するための信頼できるIRRを事前に決定することは不可能です。
This makes it difficult for consumers of data from the IRR to automatically know the authoritative IRR of a resource holder that will contain the most up-to-date set of resources. This is typically not a problem for an ISP that has a direct (customer) relationship with the resource holder, because the ISP will ask the resource holder which (authoritative) IRR to pull their resources from on, for example, a "Customer BGP Order Form". However, third parties that do not have a direct relationship with the resource holder have a difficult time attempting to infer the authoritative IRR, preferred by the resource holder, that likely contains the most up-to-date set of resources. As a result, it would be helpful for third parties if there were a robust referral mechanism so that a query to one IRR would be automatically redirected toward the authoritative IRR for the most up-to-date and authoritative copy of that particular resource. This problem is worked around by individual IRR operators storing a local copy of other IRRs' resources, through periodic mirroring, which allows the individual IRR to respond to a client's query with all registered instances of a particular IRR resource that exist in both the local IRR and all other IRRs. Of course, the problem with this approach is that an individual IRR operator is under no obligation to mirror all other IRRs and, in practice, some IRRs do not mirror the resources from all other IRRs. This could lead to the false impression that a particular resource is not registered or maintained at a particular IRR. Furthermore, the authentication process of accepting updates by any given IRR may or may not be robust enough to overcome impersonation attacks. As a result, there is no rigorous assurance that a mirrored RPSL statement was actually made by the authorized resource holder.
これにより、IRRからのデータの消費者が、最新のリソースセットを含むリソースホルダーの信頼できるIRRを自動的に知ることが困難になります。これは通常、リソースホルダーと直接（顧客）の関係にあるISPの問題ではありません。ISPは、リソースホルダーに、どの「権限のある」IRRからリソースをプルするかを尋ねるからです。たとえば、「Customer BGP Order形"。ただし、リソースホルダーと直接関係のないサードパーティは、リソースホルダーが好む、最新のリソースのセットを含む可能性のある信頼できるIRRを推測しようとするのが困難です。その結果、1つのIRRへのクエリがその特定のリソースの最新かつ信頼できるコピーの信頼できるIRRに自動的にリダイレクトされるように、堅牢な参照メカニズムがあった場合、サードパーティにとって役立ちます。この問題は、定期的なミラーリングを通じて他のIRRのリソースのローカルコピーを格納する個々のIRRオペレーターによって回避されます。これにより、個々のIRRは、両方のローカルIRRに存在する特定のIRRリソースのすべての登録済みインスタンスを使用してクライアントのクエリに応答できます。および他のすべてのIRR。もちろん、このアプローチの問題は、個々のIRRオペレーターが他のすべてのIRRをミラーリングする義務がないことであり、実際には、一部のIRRは他のすべてのIRRからのリソースをミラーリングしません。これは、特定のリソースが特定のIRRで登録または維持されていないという誤った印象をもたらす可能性があります。さらに、特定のIRRによる更新を受け入れる認証プロセスは、偽装攻撃を克服するのに十分なほど堅牢ではない場合があります。その結果、ミラーリングされたRPSLステートメントが実際に許可されたリソースホルダーによって作成されたという厳密な保証はありません。
There are no provisions in the IRR mode for ensuring the confidentiality component for clients issuing queries. The overall Confidentiality, Integrity, and Availability (CIA) model of the system does lack this component, because the interface to IRRs is over an unencrypted TCP connection to port 43. This leaves the transaction open to inspection such that an adversary could be able to inspect the query and the response. However, the IRR system is intended to be composed of public policy information, and protection of queries was not part of the protection calculus when it was designed, though the use of Transport Layer Security (TLS) [RFC5246] would address protections of query information.
IRRモードには、クエリを発行するクライアントの機密コンポーネントを保証するための規定はありません。 IRRへのインターフェースはポート43への暗号化されていないTCP接続を介しているため、システムの全体的な機密性、整合性、可用性（CIA）モデルにはこのコンポーネントがありません。クエリと応答を調べます。ただし、IRRシステムは公共政策情報で構成されることが意図されており、クエリの保護は設計時に保護計算の一部ではありませんでしたが、トランスポート層セキュリティ（TLS）[RFC5246]を使用するとクエリ情報の保護に対処します。
All of the aforementioned issues related to integrity and accuracy of data within the IRR stem from a distinct lack of resource certification for resources contained within the IRR. Only now is an experimental testbed that reports to provide this function (under the auspices of the Resource PKI [RFC6480]) being formally discussed; this could also aid in certification of resources within the IRR. It should be noted that the RPKI is only currently able to support signing of Route Origin Authorization (ROA) resources that are the equivalent of 'route' resources in the IRR. There has been some sentiment that the RPKI currently is not scoped to address the same set of issues and the nuanced policy applications that providers leverage in RPSL. It is unclear if, in the future, the RPKI will be extended to support additional resources that already exist in the IRR, e.g., aut-num, as-net, route-set, etc. Finally, a seemingly equivalent resource certification specification for all resources in the IRR has already been developed [RFC2725]; however, it is unclear how widely it was ever implemented or deployed.
IRR内のデータの整合性と正確性に関連する前述の問題はすべて、IRR内に含まれるリソースのリソース認証が明確に欠如していることが原因です。現在、この機能を提供することを報告する実験的なテストベッドが（Resource PKI [RFC6480]の後援により）正式に議論されています。これは、IRR内のリソースの認証にも役立ちます。 RPKIが現在サポートできるのは、IRRの「ルート」リソースに相当するRoute Origin Authorization（ROA）リソースの署名のみであることに注意してください。 RPKIは現在、プロバイダーがRPSLで活用する同じ問題のセットと微妙なポリシーアプリケーションに対処するためにスコープされていないという意見がありました。将来、RPKIが拡張され、IRRに既に存在する追加のリソース（aut-num、as-net、route-setなど）をサポートするかどうかは不明です。最後に、 IRRのすべてのリソースはすでに開発されています[RFC2725]。ただし、これまでにどれほど広く実装または展開されたかは不明です。
Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring (NRTM) protocol to replicate each other's contents. However, this protocol has several weaknesses. Namely, there is no way to validate that the copy of mirrored source is correct, and synchronization issues have often resulted. Furthermore, the NRTM protocol does not employ any security mechanisms. The NRTM protocol relies on a pull mechanism and is generally configured with a poll interval of 5 to 10 minutes. There is currently no mechanism to notify an IRR when an update has occurred in a mirrored IRR so that an immediate update can be made.
現在、いくつかのIRR [IRR_LIST]は、Near-Real-Time Mirroring（NRTM）プロトコルを使用して互いのコンテンツを複製しています。ただし、このプロトコルにはいくつかの弱点があります。つまり、ミラーリングされたソースのコピーが正しいことを検証する方法はなく、同期の問題が頻繁に発生しています。さらに、NRTMプロトコルはセキュリティメカニズムを採用していません。 NRTMプロトコルはプルメカニズムに依存しており、通常は5〜10分のポーリング間隔で構成されます。現在、ミラーリングされたIRRで更新が発生したときにIRRに通知するメカニズムがないため、すぐに更新できます。
Some providers employ a process of mirroring an instance of an IRR that involves downloading a flat text file copy of the IRR that is made available via FTP [RFC959]. These FTP files are exported at regular intervals of typically anywhere between 2 and 24 hours by the IRRs. When a provider fetches those text files, it will process them to identify any updates and reflect changes within its own internally maintained database. The use of an internally maintained database is out of scope for this document but is generally used to assist with more straightforward access to or modification of data by the IRR operator. Providers typically employ a 24-hour cycle to pull updated resources from IRRs. Thus, depending on when resource holders submitted their changes to an IRR, it may take up to 24 hours for those changes to be reflected in their policy configurations. In practice, it appears that the RPKI will also employ a 24-hour cycle whereby changes in resources are pushed out to other RPKI caches [RPKI_SIZING].
一部のプロバイダーは、IRRのインスタンスをミラーリングするプロセスを採用しています。このプロセスでは、FTPを介して利用できるようになったIRRのフラットテキストファイルのコピーをダウンロードします[RFC959]。これらのFTPファイルは、IRRによって通常2〜24時間の定期的な間隔でエクスポートされます。プロバイダーがこれらのテキストファイルをフェッチすると、プロバイダーはそれらを処理して更新を識別し、内部で維持されている独自のデータベース内の変更を反映します。内部で維持されているデータベースの使用はこのドキュメントの範囲外ですが、通常は、IRRオペレーターによるデータへのより簡単なアクセスまたはデータの変更を支援するために使用されます。プロバイダーは通常、更新されたリソースをIRRからプルするために24時間のサイクルを採用しています。したがって、リソースホルダーがIRRに変更を送信した時期によっては、それらの変更がポリシー構成に反映されるまでに最大24時間かかる場合があります。実際には、RPKIも24時間サイクルを使用し、リソースの変更が他のRPKIキャッシュにプッシュされる[RPKI_SIZING]ようです。
IRRs originated from Section 7 of [RFC1787], specifically: "The scale of the Internet implies that the [routing requirements] information should be distributed." Regardless, the practical effect of an organization maintaining its own local cache of IRR resources is an increase in resource resiliency (due to multiple copies of the same resource being geographically distributed), a reduction in query time for resources, and, likely, a reduction in inter-domain bandwidth consumption and associated costs. This is particularly beneficial when, for example, an ISP is evaluating resources in an IRR just to determine if there are any modifications to those resources that will ultimately be reflected in a new routing policy that will get propagated to (edge) routers in the ISP's network. Cache locality results in reduced inter-domain bandwidth utilization for each round trip.
[RFC1787]のセクション7に由来するIRRは、具体的には次のとおりです。「インターネットの規模は、[ルーティング要件]情報が配布されることを意味します。」いずれにしても、IRRリソースの独自のローカルキャッシュを維持している組織の実際的な効果は、（同じリソースの複数のコピーが地理的に分散されているため）リソースの復元力の向上、リソースのクエリ時間の削減、そしておそらく削減です。ドメイン間の帯域幅の消費と関連コスト。これは、たとえば、ISPがIRRのリソースを評価して、最終的にISPの（エッジ）ルーターに伝達される新しいルーティングポリシーに反映される変更がリソースにあるかどうかを判断する場合に特に有益です。通信網。キャッシュの局所性により、ラウンドトリップごとにドメイン間の帯域幅の使用率が低下します。
On the other hand, it is unclear from where the current provider replication interval of 24 hours originated or even whether it still provides enough freshness in the face of available resources, particularly in today's environment where a typical IRR system consists of a (multi-core) multi-GHz CPU connected to a network via a physical connection of 100 Mbps or, more likely, higher bandwidth. In addition, due to demand for bandwidth, circuit sizes used by ISPs have increased to 10 Gbps, thus eliminating bandwidth as a significant factor in the transfer of data between IRRs. Furthermore, it should be noted that Merit's Internet Routing Registry Daemon (IRRd) [MERIT-IRRD] uses 10 minutes as its default for "irr_mirror_interval".
一方、24時間という現在のプロバイダーのレプリケーション間隔がどこから始まったのか、あるいは、特に典型的なIRRシステムが（マルチコア）100 Mbps以上の帯域幅の物理接続を介してネットワークに接続されたマルチGHz CPU。さらに、帯域幅の需要により、ISPで使用される回路サイズは10 Gbpsに増加し、IRR間のデータ転送における重要な要素として帯域幅を排除しています。さらに、メリットのインターネットルーティングレジストリデーモン（IRRd）[MERIT-IRRD]は、「irr_mirror_interval」のデフォルトとして10分を使用することに注意してください。
Lastly, it should be noted that "Routing Policy System Replication" [RFC2769] attempted to offer a more methodical solution for distributed replication of resources between IRRs. It is unclear why that RFC failed to gain traction, but it is suspected that this was due to its reliance on "Routing Policy System Security" [RFC2725], which addressed "the need to assure integrity of the data by providing an authentication and authorization model." Indeed, [RFC2725] attempts to add an otherwise absent security model to the integrity of policy statements made in RPSL. Without formal protections, it is possible for anyone to author a policy statement about an arbitrary set of resources, and publish it (as discussed above in Section 4.1.
最後に、「ルーティングポリシーシステムレプリケーション」[RFC2769]は、IRR間のリソースの分散レプリケーションのためのより体系的なソリューションを提供しようとしたことに注意してください。 RFCが牽引力を獲得できなかった理由は不明ですが、これは「ルーティングポリシーシステムセキュリティ」[RFC2725]への依存が原因であると疑われ、「認証と承認を提供することによってデータの整合性を保証する必要性に対処しました」モデル。」実際、[RFC2725]は、RPSLで作成されたポリシーステートメントの整合性に、通常は存在しないセキュリティモデルを追加しようとします。正式な保護がなければ、誰でも任意のリソースセットに関するポリシーステートメントを作成して公開することができます（セクション4.1で説明したとおり）。
Ultimately, the length of time it takes to replicate resources among IRRs is, generally, the dominant factor in reflecting changes to resources in policy that is eventually applied within the control plane of routers. The length of time to update network elements will vary considerably depending on the size of the ISP and the number of IRR resources that were updated during any given interval. However, there are a variety of common techniques, that are outside the scope of this document, that allow for this automated process to be optimized to considerably reduce the length of time it takes to update policies in the ISP's network.
最終的に、IRR間でリソースを複製するのにかかる時間の長さは、通常、最終的にルーターのコントロールプレーン内に適用されるポリシーのリソースへの変更を反映するための主要な要素です。ネットワーク要素を更新する時間の長さは、ISPのサイズと、指定された間隔で更新されたIRRリソースの数によって大きく異なります。ただし、この自動化されたプロセスを最適化して、ISPのネットワークでポリシーを更新するのにかかる時間を大幅に短縮できるようにする、このドキュメントの範囲外のさまざまな一般的な手法があります。
An ISP will begin the process of updating the policy in its network, first by fetching IRR resources associated with, for example, a customer ASN attached to its network. Next, the ISP constructs a new policy associated to that customer and then evaluates if that new policy is different from existing policy associated with that same customer. If there are no changes between the new and existing policy associated with that customer, then the ISP does not make any changes to the policy in their routers specific to that customer. On the other hand, if the new policy does reflect changes from the existing policy for that customer, then the ISP begins a process of uploading the new policy to the routers attached to that customer.
ISPは、まずネットワークに接続されている顧客のASNなどに関連付けられているIRRリソースを取得することにより、ネットワークのポリシーを更新するプロセスを開始します。次に、ISPはその顧客に関連付けられた新しいポリシーを作成し、その新しいポリシーが同じ顧客に関連付けられた既存のポリシーと異なるかどうかを評価します。その顧客に関連付けられた新しいポリシーと既存のポリシーの間に変更がない場合、ISPはその顧客に固有のルーターのポリシーに変更を加えません。一方、新しいポリシーがその顧客の既存のポリシーからの変更を反映している場合、ISPはその顧客に接続されているルーターに新しいポリシーをアップロードするプロセスを開始します。
The process of constructing a new policy involves use of a set of programs, e.g., IRRtoolset, that performs recursive expansion of an RPSL aut-num resource that comprises an arbitrary combination of other RPSL aut-num, as-set, route, and route-set resources, according to procedures defined by RPSL. The end result of this process is, traditionally, a vendor-dependent configuration snippet that defines the routing policy for that customer. This routing policy may consist of the set of IPv4 or IPv6 prefixes, associated prefix lengths, and AS_PATHs that are supposed to be accepted from a customer's eBGP session. However, if indicated in the appropriate RPSL resource, the policy may also set certain BGP Attributes, such as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the incoming eBGP session from the customer or on static routes that are originated by the resource holder.
新しいポリシーを構築するプロセスには、他のRPSL aut-num、as-set、route、およびrouteの任意の組み合わせで構成されるRPSL aut-numリソースの再帰的拡張を実行する一連のプログラム（IRRtoolsetなど）の使用が含まれます-RPSLで定義された手順に従ってリソースを設定します。このプロセスの最終結果は、従来、その顧客のルーティングポリシーを定義するベンダー依存の構成スニペットです。このルーティングポリシーは、IPv4またはIPv6プレフィックスのセット、関連付けられたプレフィックス長、およびお客様のeBGPセッションから受け入れられることになっているAS_PATHで構成されます。ただし、適切なRPSLリソースで示されている場合、ポリシーは、MED、AS_PATHプリペンド値、LOCAL_PREFなどの特定のBGP属性を、顧客からの着信eBGPセッション、またはリソースホルダー。
An ISP's customers may not adequately plan for pre-planned maintenance, or, more likely, they may need to rapidly begin announcing a new IP prefix as a result of, for example, an emergency turn-up of the ISP customer's new downstream customer. Unfortunately, the routine, automated process employed by the ISP means that it may not begin updating its routing policy on its network for up to 24 hours, because the ISP or the IRRs the ISP uses might only mirror changes to IRR resources once every 24 hours. The time interval for the routine/automated process is not responsive to the needs of directly paying customer(s) who need rapid changes in their policy in rare situations. In these situations, when a customer has an urgent need for updates to take effect immediately, they will call the Network Operations Center (NOC) of their ISP and request that the ISP immediately fetch new IRR objects and push those changes out to its network. This is often accomplished in as little as 5 minutes from the time a customer contacts their ISP's NOC to the time a new filtering policy is pushed out to the Provider Edge (PE) routers that are attached to that customer's Attachment Circuits (ACs). It is conceivable that some ISPs automate this using out-of-band mechanisms as well, although the authors are unaware of any existing mechanisms that support this.
ISPの顧客は、事前に計画されたメンテナンスを適切に計画していない可能性があります。あるいは、ISP顧客の新しいダウンストリーム顧客の緊急ターンアップなどの結果として、新しいIPプレフィックスの発表を迅速に開始する必要がある場合があります。残念ながら、ISPが採用しているルーチンの自動プロセスでは、ISPまたはISPが使用するIRRはIRRリソースへの変更を24時間に1回しかミラーリングできないため、ネットワーク上のルーティングポリシーの更新を最大24時間開始できない可能性があります。 。ルーチン/自動化プロセスの時間間隔は、まれな状況でポリシーの迅速な変更を必要とする直接支払いの顧客のニーズに対応していません。これらの状況では、お客様が更新をすぐに有効にする緊急の必要がある場合、ISPのネットワークオペレーションセンター（NOC）を呼び出し、ISPが新しいIRRオブジェクトをすぐにフェッチしてそれらの変更をネットワークにプッシュするように要求します。これは多くの場合、顧客がISPのNOCに連絡してから、新しいフィルタリングポリシーがその顧客の接続回路（AC）に接続されているプロバイダーエッジ（PE）ルーターにプッシュされるまで、わずか5分で完了します。著者がこれをサポートする既存のメカニズムを知らない場合でも、一部のISPは帯域外メカニズムを使用してこれを自動化することも考えられます。
Ultimately, the aforementioned latency with respect to "emergency changes" in IRR resources that need to be reflected in near-real-time in the network is compounded if the IRR resources were being used by third-party ISPs to perform filtering on their peering circuits, where typically no such policies are employed today for this very reason. It is likely that the length of time that it takes IRRs to mirror changes will have to be dramatically reduced. There will need to be a corresponding reduction in the time required by ISPs to evaluate whether those changes should be recompiled and reflected in router policies that would then get pushed out to Autonomous System Border Routers (ASBRs) connected to peering circuits on their network.
最終的に、IRRリソースがピアリング回線でフィルタリングを実行するためにサードパーティのISPによって使用されていた場合、ネットワーク内のほぼリアルタイムで反映される必要があるIRRリソースの「緊急変更」に関する前述のレイテンシが悪化します。このような理由から、通常、そのようなポリシーは現在採用されていません。 IRRが変更をミラーリングするのにかかる時間を大幅に短縮する必要がある可能性があります。 ISPがこれらの変更を再コンパイルしてルーターポリシーに反映し、ネットワーク上のピアリング回線に接続されている自律システムボーダールーター（ASBR）にプッシュする必要があるかどうかを評価するために、ISPが必要とする時間を対応して短縮する必要があります。
As mentioned previously, after a resource holder made changes to their resources in an IRR, those changes would automatically be distributed to other IRRs, ISPs would then learn of those changes, generate new BGP policies, and then apply those to the appropriate subset of routers in their ASes. However, in the past, one additional step is necessary in order to have any of those new BGP policies take effect in the control plane and to allow/deny the updated resource from a customer to their ISP and from their immediately upstream ISP to the ISP's peers. It was necessary (often manually) to actually induce BGP on each router to apply the new policy within the control plane, thus learning of a newly announced/ changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, most of these methods not only were highly impactful operationally, but they also affected traffic forwarding to IP destinations that were unrelated to the most recent changes to the BGP policy.
前述のように、リソースホルダーがIRRのリソースに変更を加えた後、それらの変更は自動的に他のIRRに配布され、ISPはそれらの変更を認識し、新しいBGPポリシーを生成して、ルーターの適切なサブセットに適用しますASで。ただし、以前は、これらの新しいBGPポリシーのいずれかをコントロールプレーンで有効にして、更新されたリソースを顧客からISPへ、およびすぐ上流のISPからISPへ許可/拒否するには、追加の手順が1つ必要でした仲間。コントロールプレーン内で新しいポリシーを適用するために、実際には各ルーターでBGPを実際に誘導する必要がありました。これにより、新しくアナウンスされた/変更されたIPプレフィックスを学習（または削除されたIPプレフィックスをドロップ）します。残念ながら、これらの方法のほとんどは、運用上非常に影響があっただけでなく、BGPポリシーに対する最新の変更とは無関係のIP宛先へのトラフィック転送にも影響を与えました。
Historically, a customer would have to (re-)announce the new IP prefix toward their ISP, but only after the ISP had put the new BGP policies into effect. Alternatively, the ISP would have to reset the entire eBGP session from Provider Edge to Customer Edge either by: a) bouncing the entire interface toward the customer (e.g., shutdown / no shutdown) or b) clearing the eBGP session toward the customer (e.g., clear ip bgp neighbor <IP address of CE router>, where <IP address of CE router> represents a specific IP address). The latter two cases were, of course, the most highly impactful impact and thus could generally only be performed off-hours during a maintenance window.
従来、顧客は新しいIPプレフィックスをISPに向けて（再）アナウンスする必要がありましたが、これはISPが新しいBGPポリシーを有効にした後でのみでした。または、ISPは次のいずれかの方法でeBGPセッション全体をプロバイダーエッジからカスタマーエッジにリセットする必要があります。a）インターフェイス全体をカスタマーに向けてバウンスする（シャットダウン/シャットダウンなしなど）、またはb）eBGPセッションをカスタマーに向けてクリアする（例： 、clear ip bgp neighbor <CEルーターのIPアドレス>、<CEルーターのIPアドレス>は特定のIPアドレスを表します）。もちろん、後者の2つのケースは最も影響が大きいため、通常、メンテナンスウィンドウの時間外にのみ実行できます。
Once the new IP prefix has been successfully announced by the customer and permitted by the newly updated policy at the ISP's PEs (attached to that customer), it would be propagated to that ISP's ASBRs, attached to peers, at the perimeter of the ISP network. Unfortunately, if those peers had either not yet learned of the changes to resources in the IRR or pushed out new BGP policies (and, reset their BGP sessions immediately afterward) incorporating those changes, then the newly announced route would also get dropped at the ingress ASBRs of the peers.
新しいIPプレフィックスが顧客によって正常に通知され、ISPのPE（その顧客に接続されている）で新しく更新されたポリシーによって許可されると、ISPネットワークの境界で、ピアに接続されているそのISPのASBRに伝播されます。 。残念ながら、それらのピアがIRRのリソースの変更をまだ認識していないか、それらの変更を組み込んだ新しいBGPポリシーをプッシュした（そしてすぐにBGPセッションをリセットした）場合、新しくアナウンスされたルートも入口でドロップされますピアのASBR。
Ultimately, either of the two scenarios above further lengthens the effective time it would take for changes in IRR resources to take effect within BGP in the network. Fortunately, BGP has been enhanced over the last several years in order that changes within BGP policy will take effect without requiring a service-impacting reset of BGP sessions. Specifically, BGP soft-reconfiguration (Section 1 of [RFC2918]) and, later, Route Refresh Capability for BGP-4 [RFC2918] were developed so that ISPs, or their customers, could induce BGP to apply a new policy while leaving both the existing eBGP session active as well as (unaffected) routes active in both the Loc-RIB and, more importantly, FIB of the router. Thus, using either of these mechanisms, an ISP or its peers currently will deploy a newly generated BGP policy, based on changes to resources within the IRR, and immediately trigger a notification -- which does not impact service -- to the BGP process to have those changes take effect in their control plane, either allowing a new IP prefix to be announced or an old IP prefix to be dropped. This dramatically reduces the length of time from when changes are propagated throughout the IRRs to when those changes are actually operational within BGP policy in an ISP's network.
最終的に、上記の2つのシナリオのいずれかにより、IRRリソースの変更がネットワークのBGP内で有効になるまでにかかる有効時間がさらに長くなります。幸い、BGPセッション内のサービスに影響を与えるリセットを必要とせずにBGPポリシー内の変更を有効にするために、過去数年にわたってBGPが強化されています。具体的には、BGPソフト再構成（[RFC2918]のセクション1）および後で、BGP-4 [RFC2918]のルートリフレッシュ機能が開発され、ISPまたはその顧客はBGPに新しいポリシーを適用させ、両方の既存のeBGPセッションがアクティブであると同時に、ルーターのLoc-RIBと、さらに重要なことにFIBの両方でアクティブな（影響を受けない）ルート。したがって、これらのメカニズムのいずれかを使用して、ISPまたはそのピアは現在、IRR内のリソースへの変更に基づいて新しく生成されたBGPポリシーを展開し、サービスに影響しないBGPプロセスへの通知を直ちにトリガーします。これらの変更をコントロールプレーンで有効にして、新しいIPプレフィックスをアナウンスするか、古いIPプレフィックスを削除できるようにします。これにより、変更がIRR全体に伝達されてから、変更がISPのネットワークのBGPポリシー内で実際に機能するまでの時間が大幅に短縮されます。
Routers in the mid 1990s rarely supported incrementally updatable prefix filters for BGP; therefore, if new information was received from a policy or internal configuration database that would impact a policy applied to a given eBGP peer, the entire prefix list or access list would need to be deleted and rewritten, compiled, and installed. This was very tedious and commonly led to leaked routes during the time when the policy was being rewritten, compiled, and applied on a router. Furthermore, application of a new policy would not automatically result in new ingress or egress reachability advertisements from that new policy, because routers at the time would require a reset of the eBGP sessions for routing information to be evaluated by the new policy. Of course, resetting of an eBGP session had implications on traffic forwarding during the time the eBGP session was reestablished and new routing information was learned.
1990年代半ばのルーターは、BGPの段階的に更新可能なプレフィックスフィルターをサポートすることはめったにありません。したがって、特定のeBGPピアに適用されるポリシーに影響を与える新しい情報がポリシーまたは内部構成データベースから受信された場合、プレフィックスリストまたはアクセスリスト全体を削除し、再書き込み、コンパイル、およびインストールする必要があります。これは非常に退屈な作業であり、ポリシーが書き換えられ、コンパイルされ、ルーターに適用されているときに、ルートが漏洩することがよくありました。さらに、その時点でルーターはルーティング情報を新しいポリシーで評価するためにeBGPセッションをリセットする必要があるため、新しいポリシーを適用しても、その新しいポリシーからの新しい入力または出力到達可能性アドバタイズメントは自動的には発生しません。もちろん、eBGPセッションのリセットは、eBGPセッションが再確立され、新しいルーティング情報が学習されている間、トラフィック転送に影響を与えました。
Routers now support the ability to perform incremental, and in situ, updates to filter lists consisting of IP prefixes and/or AS_PATHs that are used within an ingress or egress BGP policy. In addition, routers also can apply those incremental updates to policy, with no traffic disruption, using BGP soft-reconfiguration or BGP Route Refresh, as discussed in the previous section.
ルーターは、入力または出力BGPポリシー内で使用されるIPプレフィックスまたはAS_PATH、あるいはその両方で構成されるフィルターリストへの増分更新をその場で実行する機能をサポートするようになりました。さらに、ルーターは、前のセクションで説明したように、BGPソフト再構成またはBGPルートリフレッシュを使用して、トラフィックを中断することなく、これらの増分更新をポリシーに適用することもできます。
Historically, routers had very limited storage capacity and would have difficulty in storing an extremely large BGP policy on-board. This was typically the result of router hardware vendors using an extremely limited amount of NVRAM for storage of router configurations.
従来、ルーターのストレージ容量は非常に限られており、非常に大きなBGPポリシーをオンボードで保存することは困難でした。これは通常、ルーターハードウェアベンダーがルーター構成のストレージに非常に限られた量のNVRAMを使用したことが原因でした。
Another challenge with historical router hardware was that writing to NVRAM was extremely slow. For example, when the router configuration had changed as a result of updating a BGP policy that needed to accommodate changes in IRR resources, this would result in extremely long times to write out these configuration changes. Sometimes, due to bugs, this would result in loss of protocol keep-alives. This would cause an impact to routing or forwarding of packets through the platform.
従来のルーターハードウェアのもう1つの課題は、NVRAMへの書き込みが非常に遅いことでした。たとえば、IRRリソースの変更に対応する必要があるBGPポリシーを更新した結果、ルーター構成が変更された場合、これらの構成変更を書き込むのに非常に長い時間がかかります。バグが原因で、プロトコルのキープアライブが失われる場合があります。これは、プラットフォームを介したパケットのルーティングまたは転送に影響を及ぼします。
The above limitations have largely been resolved with equipment from the last few years that ships with increasing amounts of non-volatile storage such as PCMCIA or USB flash cards, hard disk drives, or solid-state disk drives.
上記の制限は、PCMCIAやUSBフラッシュカード、ハードディスクドライブ、ソリッドステートディスクドライブなどの不揮発性ストレージの量が増加して出荷されている過去数年間の機器でほぼ解決されました。
However, as capacities and technologies have evolved on modern routing hardware, so have some of the scaling requirements of the data. In some large networks, configuration growth has begun to "pose challenges" [IEPG89_NTT]. While the enhancements of hardware have overcome some historical limitations, evidence suggests that further optimizations in configuration processing may be needed in some cases. Some of the more recent operational issues include scheduler slips and protracted commit times. This suggests that even though many historical hurdles have been overcome, there are still motivations to optimize and modernize IRR technologies.
ただし、最新のルーティングハードウェアで容量とテクノロジが進化するにつれて、データのスケーリング要件の一部も進化しています。一部の大規模ネットワークでは、構成の増加が「課題」を引き起こし始めています[IEPG89_NTT]。ハードウェアの拡張により、いくつかの歴史的な制限が克服されましたが、場合によっては、構成処理のさらなる最適化が必要になる可能性があるという証拠が示されています。最近の運用上の問題には、スケジューラーのスリップやコミット時間の長期化などがあります。これは、多くの歴史的なハードルが克服されたとしても、IRRテクノロジーを最適化および近代化する動機がまだあることを示唆しています。
Historically, there has not been a standardized modeling language for network configuration or an associated method to update router configurations. When an ISP detected a change in resources within the IRR, it would fashion a vendor-dependent BGP policy and upload that to the router usually via the following method.
歴史的に、ネットワーク構成またはルーター構成を更新するための関連する方法のための標準化されたモデリング言語はありませんでした。 ISPがIRR内のリソースの変更を検出すると、ベンダーに依存するBGPポリシーを作成し、それを通常は次の方法でルーターにアップロードします。
First, an updated BGP policy configuration snippet is generated via processes running on an out-of-band server. Next, the operator uses either telnet or SSH [RFC4253] to log in to the CLI of a target router and issue vendor-dependent CLI commands that will trigger the target router to fetch the new configuration snippet via TFTP, FTP, or Secure Copy (SCP) stored on the out-of-band server. The target router will then perform syntax checking on that configuration snippet and, if that passes, merge that configuration snippet into the running configuration of the router's control software. At this point, the new BGP policy configuration snippet is active within the control plane of the router. One last step remains -- the operator will issue a CLI command to induce the router to perform a "soft reset", via BGP soft-reconfiguration or BGP Route Refresh, of the associated BGP session in order to trigger the router to apply the new policy to routes learned from that BGP session without disrupting traffic forwarding.
最初に、更新されたBGPポリシー構成スニペットが、帯域外サーバーで実行されているプロセスを介して生成されます。次に、オペレーターはtelnetまたはSSH [RFC4253]を使用してターゲットルーターのCLIにログインし、ベンダー依存のCLIコマンドを発行して、ターゲットルーターがTFTP、FTP、またはセキュアコピーを介して新しい構成スニペットをフェッチするようにします（ SCP）帯域外サーバーに保存されます。次に、ターゲットルーターはその構成スニペットに対して構文チェックを実行し、それが成功した場合は、その構成スニペットをルーターの制御ソフトウェアの実行中の構成にマージします。この時点で、新しいBGPポリシー構成スニペットは、ルーターのコントロールプレーン内でアクティブです。最後の1つのステップが残ります。オペレーターはCLIコマンドを発行して、関連するBGPセッションのBGPソフト再構成またはBGPルートリフレッシュを介してルーターに「ソフトリセット」を実行させ、ルーターをトリガーして新しいトラフィック転送を中断せずに、そのBGPセッションから学習したルートへのポリシー。
More recently, operators have the ability to use NETCONF [RFC6241] / SSH (or, TLS) from an out-of-band server to push a BGP configuration snippet from an out-of-band server toward a target router that has that capability. However, this activity is still dependent on generating, via the out-of-band server, a vendor-dependent XML configuration snippet that would get uploaded via SSH or TLS to the target router.
最近では、オペレーターは帯域外サーバーからNETCONF [RFC6241] / SSH（またはTLS）を使用して、帯域外サーバーからその機能を持つターゲットルーターにBGP構成スニペットをプッシュする機能を持っています。ただし、このアクティビティは、アウトオブバンドサーバーを介して、SSHまたはTLS経由でターゲットルーターにアップロードされるベンダー依存のXML構成スニペットを生成することに依存しています。
In the future, the ability to upload new Route Origin Authorization (ROA) information may be provided from the RPKI to routers via the RPKI-RTR [RFC6810] protocol. However, this will not allow operators the ability to upload other configuration information such as BGP policy information (AS_PATHs, BGP communities, etc.) that might be associated with that ROA information, as they can from IRR-generated BGP policies.
将来的には、RPKI-RTR [RFC6810]プロトコルを介して、RPKIからルーターに新しいRoute Origin Authorization（ROA）情報をアップロードする機能が提供される可能性があります。ただし、IRRで生成されたBGPポリシーから取得できるため、ROA情報に関連付けられている可能性があるBGPポリシー情報（AS_PATH、BGPコミュニティなど）などの他の構成情報をオペレーターがアップロードすることはできません。
As discussed above, many of the problems that have traditionally stifled IRR deployment have, themselves, become historical. However, there are still real operational considerations that limit IRR usage from realizing its full effectiveness. The potential for IRRs to express inter-domain routing policy, and to allow relying parties to learn policy, has always positioned them as a strong candidate to aid the security postures of operators. However, while routing density and complexity have grown, so have some of the challenges facing IRRs (even today). Because of this state increase, the potential to model all policies for all ASes in all routers may still remain illusive. In addition, without an operationally deployed resource certification framework that can tie policies to resource holders, there is a fundamental limitation that still exists.
上で説明したように、伝統的にIRRの展開を妨げてきた問題の多くは、それ自体が歴史的なものになっています。ただし、IRRの使用を完全な効果の実現から制限する実際の運用上の考慮事項がまだあります。 IRRがドメイン間ルーティングポリシーを表現し、証明書利用者がポリシーを学習できるようになる可能性により、IRRは常にオペレーターのセキュリティ体制を支援する有力な候補として位置付けられてきました。ただし、ルーティングの密度と複雑さが増大する一方で、IRRが直面しているいくつかの課題も増加しています（現在でも）。この状態の増加により、すべてのルーターのすべてのASのすべてのポリシーをモデル化する可能性は、依然として幻想のままである可能性があります。さらに、ポリシーをリソースホルダーに結び付けることができる運用上配備されたリソース認証フレームワークがなければ、根本的な制限が依然として存在します。
One of the central concerns with IRRs is the ability of an IRR operator to remotely influence the routing operations of an external consumer. Specifically, if the processing of IRR contents can become burdensome, or if the policy statements can be crafted to introduce routing problems or anomalies, then operators may want to be circumspect about ingesting contents from external parties. A resource certification framework should be used to address the authorization of IRR statements to make attestations and assertions (as mentioned in Section 4.1, and discussed in Section 5.1).
IRRの中心的な問題の1つは、IRRオペレーターが外部のコンシューマーのルーティング操作にリモートで影響を与える能力です。具体的には、IRRコンテンツの処理が重荷になる可能性がある場合、またはポリシーステートメントを作成してルーティングの問題や異常を引き起こす可能性がある場合、オペレーターは外部関係者からのコンテンツの取り込みについて慎重になる必要がある場合があります。資源証明フレームワークを使用して、IRRステートメントの認証に対応し、アサーションとアサーションを作成する必要があります（セクション4.1で述べ、セクション5.1で説明）。
Additionally, the external and systemic dependencies introduced by IRRs and other such systems employed to inform routing policy, and how tightly or loosely coupled those systems are to the global routing system and operational networks, introduce additional vectors that operators and system architects should consider when evaluating attack surface and service dependencies associated with those elements. These attributes and concerns are certainly not unique to IRRs, and operators should evaluate the implications of external systems and the varying degrees of coupling and operational buffers that might be installed in their environments.
さらに、ルーティングポリシーを通知するために採用されたIRRやその他のそのようなシステムによって導入される外部および体系的な依存関係、およびそれらのシステムがグローバルルーティングシステムおよび運用ネットワークにどの程度緊密または疎結合であるかを評価するために、オペレーターおよびシステムアーキテクトが評価する際に考慮すべき追加のベクトルを導入しますこれらの要素に関連する攻撃面とサービスの依存関係。これらの属性と懸念事項はIRRに固有のものではありません。オペレーターは、外部システムの影響と、環境にインストールされている可能性のあるさまざまな程度の結合および運用バッファーを評価する必要があります。
[IEPG89_NTT] Mauch, J., "NTT BGP Configuration Size and Scope", IEPG meeting before IETF 89, March 2014, <http://iepg.org/2014-03-02-ietf89/ ietf89_iepg_jmauch.pdf>.
[IEPG89_NTT] Mauch、J。、「NTT BGP Configuration Size and Scope」、IETF 89の前のIEPGミーティング、2014年3月、<http://iepg.org/2014-03-02-ietf89/ ietf89_iepg_jmauch.pdf>。
[IRR_LIST] Merit Network, Inc., "List of Routing Registries", <http://www.irr.net/docs/list.html>.
[IRR_LIST] Merit Network、Inc。、「List of Routing Registry」、<http://www.irr.net/docs/list.html>。
[MERIT-IRRD] Merit, "IRRd - Internet Routing Registry Daemon", <http://www.irrd.net>.
[MERIT-IRRD] Merit、「IRRd-Internet Routing Registry Daemon」、<http://www.irrd.net>。
[RC_HotNetsX] Osterweil, E., Amante, S., Massey, D., and D. McPherson, "The Great IPv4 Land Grab: Resource Certification for the IPv4 Grey Market", DOI 10.1145/2070562.2070574, <http://dl.acm.org/citation.cfm?id=2070574>.
[RC_HotNetsX] Osterweil、E.、Amante、S.、Massey、D。、およびD. McPherson、「Great IPv4 Land Grab：Resource Certification for the IPv4 Gray Market」、DOI 10.1145 / 2070562.2070574、<http：// dl .acm.org / citation.cfm？id = 2070574>。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、DOI 10.17487 / RFC0959、1985年10月、<http://www.rfc-editor.org/info/rfc959>。
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, DOI 10.17487/RFC1787, April 1995, <http://www.rfc-editor.org/info/rfc1787>.
[RFC1787] Rekhter、Y。、「Routing in a multi-provider Internet」、RFC 1787、DOI 10.17487 / RFC1787、1995年4月、<http://www.rfc-editor.org/info/rfc1787>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc2622>。
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <http://www.rfc-editor.org/info/rfc2725>.
[RFC2725] Villamizar、C.、Alaettinoglu、C.、Meyer、D。、およびS. Murphy、「ルーティングポリシーシステムセキュリティ」、RFC 2725、DOI 10.17487 / RFC2725、1999年12月、<http：//www.rfc- editor.org/info/rfc2725>。
[RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. Meyer, "Routing Policy System Replication", RFC 2769, DOI 10.17487/RFC2769, February 2000, <http://www.rfc-editor.org/info/rfc2769>.
[RFC2769] Villamizar、C.、Alaettinoglu、C.、Govindan、R。、およびD. Meyer、「ルーティングポリシーシステムレプリケーション」、RFC 2769、DOI 10.17487 / RFC2769、2000年2月、<http：//www.rfc- editor.org/info/rfc2769>。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <http://www.rfc-editor.org/info/rfc2918>.
[RFC2918]チェンE。、「BGP-4のルートリフレッシュ機能」、RFC 2918、DOI 10.17487 / RFC2918、2000年9月、<http://www.rfc-editor.org/info/rfc2918>。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC4253] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<http://www.rfc-editor.org / info / rfc4253>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<http://www.rfc-editor.org/info/rfc6480> 。
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <http://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月、<http://www.rfc-editor.org/ info / rfc6810>。
[RIPE638] RIPE NCC, "Autonomous System (AS) Number Assignment Policies", March 2015, <https://www.ripe.net/publications/docs/ripe-638>.
[RIPE638] RIPE NCC、「自律システム（AS）番号割り当てポリシー」、2015年3月、<https://www.ripe.net/publications/docs/ripe-638>。
[RPKI_SIZING] Osterweil, E., Manderson, T., White, R., and D. McPherson, "Sizing Estimates for a Fully Deployed RPKI", Verisign Labs Technical Report 1120005 version 2, December 2012, <http://techreports.verisignlabs.com/ tr-lookup.cgi?trid=1120005&rev=2>.
[RPKI_SIZING] Osterweil、E.、Manderson、T.、White、R。、およびD. McPherson、「完全に展開されたRPKIのサイジング見積もり」、Verisign Labsテクニカルレポート1120005バージョン2、2012年12月、<http：// techreports .verisignlabs.com / tr-lookup.cgi？trid = 1120005＆rev = 2>。
[TASRS] Osterweil, E., Amante, S., and D. McPherson, "TASRS: Towards a Secure Routing System Through Internet Number Resource Certification", Verisign Labs Technical Report 1130009, February 2013, <http://techreports.verisignlabs.com/ tr-lookup.cgi?trid=1130009&rev=1>.
[TASRS] Osterweil、E.、Amante、S。、およびD. McPherson、「TASRS：Towards a Secure Routing System Through Internet Number Resource Certification」、Verisign Labs Technical Report 1130009、2013年2月、<http：//techreports.verisignlabs .com / tr-lookup.cgi？trid = 1130009＆rev = 1>。
Acknowledgements
謝辞
The authors would like to acknowledge and thank Chris Morrow, Jeff Haas, Wes George, and John Curran for their help and constructive feedback.
著者らは、Chris Morrow、Jeff Haas、Wes George、およびJohn Curranの協力と建設的なフィードバックに感謝し、感謝します。
Authors' Addresses
著者のアドレス
Danny McPherson Verisign, Inc.
ダニー・マクファーソン・ベリサイン社
Email: dmcpherson@verisign.com
Shane Amante Apple, Inc.
シェーンアマンテアップル社
Email: amante@apple.com
Eric Osterweil Verisign, Inc.
Eric Osterweil Verisign、Inc.
Email: eosterweil@verisign.com
Larry J. Blunk Merit Network, Inc.
Larry J. Blunk Merit Network、Inc.
Email: ljb@merit.edu
Dave Mitchell Singularity Networks
Dave Mitchell Singularity Networks
Email: dave@singularity.cx