[要約] RFC 7454は、BGP（Border Gateway Protocol）の運用とセキュリティに関するガイドラインです。このRFCの目的は、BGPの運用におけるセキュリティの問題を理解し、対策を講じるための指針を提供することです。
Internet Engineering Task Force (IETF) J. Durand
Request for Comments: 7454 Cisco Systems, Inc.
BCP: 194 I. Pepelnjak
Category: Best Current Practice NIL
ISSN: 2070-1721 G. Doering
SpaceNet
February 2015
BGP Operations and Security
BGPの操作とセキュリティ
Abstract
概要
The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.
ボーダーゲートウェイプロトコル（BGP）は、ネットワークドメイン間でルーティング情報を交換するためにインターネットでほぼ独占的に使用されるプロトコルです。この中心的な性質のため、偶発的または意図的なルーティング障害を防止するために展開できる、または展開すべきセキュリティ対策を理解することが重要です。
This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.
このドキュメントでは、存続可能時間（TTL）、TCP認証オプション（TCP-AO）、コントロールプレーンフィルタリングなど、BGPセッション自体を保護するための対策について説明します。また、プレフィックスフィルタリングとプレフィックスフィルターの自動化、最大プレフィックスフィルター、自律システム（AS）パスフィルタリング、ルートフラップダンプニング、およびBGPコミュニティスクラブを使用して、ルーティング情報のフローをより適切に制御する方法についても説明します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It 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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7454.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7454で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Protection of the BGP Speaker . . . . . . . . . . . . . . . . 5
5. Protection of BGP Sessions . . . . . . . . . . . . . . . . . 6
5.1. Protection of TCP Sessions Used by BGP . . . . . . . . . 6
5.2. BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . . 6
6. Prefix Filtering . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Definition of Prefix Filters . . . . . . . . . . . . . . 7
6.1.1. Special-Purpose Prefixes . . . . . . . . . . . . . . 7
6.1.2. Unallocated Prefixes . . . . . . . . . . . . . . . . 8
6.1.3. Prefixes That Are Too Specific . . . . . . . . . . . 12
6.1.4. Filtering Prefixes Belonging to the Local AS and
Downstreams . . . . . . . . . . . . . . . . . . . . . 12
6.1.5. IXP LAN Prefixes . . . . . . . . . . . . . . . . . . 12
6.1.6. The Default Route . . . . . . . . . . . . . . . . . . 13
6.2. Prefix Filtering Recommendations in Full Routing Networks 14
6.2.1. Filters with Internet Peers . . . . . . . . . . . . . 14
6.2.2. Filters with Customers . . . . . . . . . . . . . . . 16
6.2.3. Filters with Upstream Providers . . . . . . . . . . . 16
6.3. Prefix Filtering Recommendations for Leaf Networks . . . 17
6.3.1. Inbound Filtering . . . . . . . . . . . . . . . . . . 17
6.3.2. Outbound Filtering . . . . . . . . . . . . . . . . . 17
7. BGP Route Flap Dampening . . . . . . . . . . . . . . . . . . 17
8. Maximum Prefixes on a Peering . . . . . . . . . . . . . . . . 18
9. AS Path Filtering . . . . . . . . . . . . . . . . . . . . . . 18
10. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 20
11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. IXP LAN Prefix Filtering - Example . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The Border Gateway Protocol (BGP), specified in RFC 4271 [2], is the protocol used in the Internet to exchange routing information between network domains. BGP does not directly include mechanisms that control whether the routes exchanged conform to the various guidelines defined by the Internet community. This document intends to both summarize common existing guidelines and help network administrators apply coherent BGP policies.
RFC 4271 [2]で指定されているボーダーゲートウェイプロトコル（BGP）は、ネットワークドメイン間でルーティング情報を交換するためにインターネットで使用されるプロトコルです。 BGPには、交換されたルートがインターネットコミュニティによって定義されたさまざまなガイドラインに準拠しているかどうかを制御するメカニズムが直接含まれていません。このドキュメントは、既存の一般的なガイドラインをまとめ、ネットワーク管理者が一貫したBGPポリシーを適用できるようにすることを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
The guidelines defined in this document are intended for generic Internet BGP peerings. The nature of the Internet is such that Autonomous Systems can always agree on exceptions to a common framework for relevant local needs, and therefore configure a BGP session in a manner that may differ from the recommendations provided in this document. While this is perfectly acceptable, every configured exception might have an impact on the entire inter-domain routing environment, and network administrators SHOULD carefully appraise this impact before implementation.
このドキュメントで定義されているガイドラインは、一般的なインターネットBGPピアリングを対象としています。インターネットの性質上、自律システムは関連するローカルニーズの共通フレームワークの例外に常に同意できるため、このドキュメントで提供されている推奨とは異なる方法でBGPセッションを構成できます。これは完全に許容できますが、構成されたすべての例外はドメイン間ルーティング環境全体に影響を与える可能性があるため、ネットワーク管理者は実装前にこの影響を慎重に評価する必要があります。
o ACL: Access Control List
o ACL：アクセス制御リスト
o ASN: Autonomous System Number
o ASN：自律システム番号
o IRR: Internet Routing Registry
o IRR：インターネットルーティングレジストリ
o IXP: Internet Exchange Point
o IXP：インターネットエクスチェンジポイント
o LIR: Local Internet Registry
o LIR：ローカルインターネットレジストリ
o PMTUD: Path MTU Discovery
o PMTUD：パスMTUディスカバリー
o RIR: Regional Internet Registry
o RIR：地域インターネットレジストリ
o Tier 1 transit provider: an IP transit provider that can reach any network on the Internet without purchasing transit services.
o Tier 1トランジットプロバイダー：トランジットサービスを購入せずにインターネット上の任意のネットワークにアクセスできるIPトランジットプロバイダー。
o uRPF: Unicast Reverse Path Forwarding In addition to the list above, the following terms are used with a specific meaning.
o uRPF：ユニキャストリバースパス転送上記のリストに加えて、次の用語が特定の意味で使用されています。
o Downstream: any network that is downstream; it can be a provider or a customer network.
o ダウンストリーム：ダウンストリームのネットワーク。プロバイダーまたはカスタマーネットワークの場合があります。
o Upstream: any network that is upstream.
o アップストリーム：アップストリームのネットワーク。
The BGP speaker needs to be protected from attempts to subvert the BGP session. This protection SHOULD be achieved by an Access Control List (ACL) that would discard all packets directed to TCP port 179 on the local device and sourced from an address not known or permitted to become a BGP neighbor. Experience has shown that the natural protection TCP should offer is not always sufficient, as it is sometimes run in control-plane software. In the absence of ACLs, it is possible to attack a BGP speaker by simply sending a high volume of connection requests to it.
BGPスピーカーは、BGPセッションを妨害しようとする試みから保護する必要があります。この保護は、ローカルデバイスのTCPポート179に向けられ、BGPネイバーになることが知られていない、または許可されていないアドレスから送信されたすべてのパケットを破棄するアクセスコントロールリスト（ACL）によって実現する必要があります（SHOULD）。経験上、TCPはコントロールプレーンソフトウェアで実行されることもあるので、TCPが提供する自然な保護は必ずしも十分ではないことが示されています。 ACLがない場合、BGPスピーカーに大量の接続要求を送信するだけで、BGPスピーカーを攻撃する可能性があります。
If supported, an ACL specific to the control plane of the router SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid configuration of data-plane filters for packets transiting through the router (and therefore not reaching the control plane). If the hardware cannot do that, interface ACLs can be used to block packets addressed to the local router.
サポートされている場合は、ルーターのコントロールプレーンに固有のACL（受信ACL、コントロールプレーンポリシングなど）を使用して（SHOULD）、ルーターを通過する（したがって、ルーターに到達しない）パケットのデータプレーンフィルターの構成を回避する必要がありますコントロールプレーン）。ハードウェアがそれを実行できない場合、インターフェイスACLを使用して、ローカルルーター宛のパケットをブロックできます。
Some routers automatically program such an ACL upon BGP configuration. On other devices, this ACL should be configured and maintained manually or using scripts.
一部のルーターは、BGP構成時にこのようなACLを自動的にプログラムします。他のデバイスでは、このACLは手動で、またはスクリプトを使用して構成および保守する必要があります。
In addition to strict filtering, rate-limiting MAY be configured for accepted BGP traffic. Rate-limiting BGP traffic consists in permitting only a certain quantity of bits per second (or packets per second) of BGP traffic to the control plane. This protects the BGP router control plane in case the amount of BGP traffic surpasses platform capabilities.
厳格なフィルタリングに加えて、レート制限は受け入れられたBGPトラフィックに対して設定される場合があります。レート制限BGPトラフィックは、コントロールプレーンへのBGPトラフィックのビット/秒（またはパケット/秒）の特定の量のみを許可することにあります。これにより、BGPトラフィックの量がプラットフォームの機能を超えた場合に、BGPルーターコントロールプレーンが保護されます。
Filtering and rate-limiting of control-plane traffic is a wider topic than "just for BGP". (If a network administrator brings down a router by overloading one of the other protocols remotely, BGP is harmed as well.) For a more detailed recommendation on how to protect the router's control plane, see RFC 6192 [11].
コントロールプレーントラフィックのフィルタリングとレート制限は、「BGPのみ」よりも幅広いトピックです。 （ネットワーク管理者が他のプロトコルのいずれかをリモートでオーバーロードしてルーターをダウンさせた場合、BGPも害を受けます。）ルーターのコントロールプレーンを保護する方法の詳細については、RFC 6192 [11]を参照してください。
Current security issues of TCP-based protocols (therefore including BGP) have been documented in RFC 6952 [14]. The following subsections list the major points raised in this RFC and give the best practices related to TCP session protection for BGP operation.
TCPベースのプロトコル（したがってBGPを含む）の現在のセキュリティ問題は、RFC 6952 [14]に文書化されています。次のサブセクションでは、このRFCで提起された主なポイントをリストし、BGP動作のTCPセッション保護に関連するベストプラクティスを示します。
Attacks on TCP sessions used by BGP (aka BGP sessions), for example, sending spoofed TCP RST packets, could bring down a BGP peering. Following a successful ARP spoofing attack (or other similar man-in-the-middle attack), the attacker might even be able to inject packets into the TCP stream (routing attacks).
BGP（別名BGPセッション）によって使用されるTCPセッションへの攻撃（スプーフィングされたTCP RSTパケットの送信など）は、BGPピアリングをダウンさせる可能性があります。 ARPスプーフィング攻撃（またはその他の類似の中間者攻撃）が成功した後、攻撃者はTCPストリームにパケットを注入することもできます（ルーティング攻撃）。
BGP sessions can be secured with a variety of mechanisms. MD5 protection of the TCP session header, described in RFC 2385 [7], was the first such mechanism. It has been obsoleted by the TCP Authentication Option (TCP-AO; RFC 5925 [4]), which offers stronger protection. While MD5 is still the most used mechanism due to its availability in vendors' equipment, TCP-AO SHOULD be preferred when implemented.
BGPセッションは、さまざまなメカニズムで保護できます。 RFC 2385 [7]に記述されているTCPセッションヘッダーのMD5保護は、そのような最初のメカニズムでした。より強力な保護を提供するTCP認証オプション（TCP-AO; RFC 5925 [4]）によって廃止されました。 MD5はベンダーの機器で使用できるため、依然として最も使用されているメカニズムですが、実装する場合はTCP-AOを推奨します。
IPsec could also be used for session protection. At the time of publication, there is not enough experience of the impact of using IPsec for BGP peerings, and further analysis is required to define guidelines.
IPsecは、セッション保護にも使用できます。公開の時点では、BGPピアリングにIPsecを使用した場合の影響については十分な経験がなく、ガイドラインを定義するにはさらに分析が必要です。
The drawback of TCP session protection is additional configuration and management overhead for the maintenance of authentication information (for example, MD5 passwords). Protection of TCP sessions used by BGP is thus NOT REQUIRED even when peerings are established over shared networks where spoofing can be done (like IXPs), but operators are RECOMMENDED to consider the trade-offs and to apply TCP session protection where appropriate.
TCPセッション保護の欠点は、認証情報（たとえば、MD5パスワード）の保守のための追加の構成および管理オーバーヘッドです。したがって、スプーフィングを実行できる共有ネットワーク（IXPなど）でピアリングが確立されている場合でも、BGPで使用されるTCPセッションの保護は必須ではありませんが、トレードオフを考慮し、必要に応じてTCPセッション保護を適用することをお勧めします。
Furthermore, network administrators SHOULD block spoofed packets (packets with a source IP address belonging to their IP address space) at all edges of their network (see RFC 2827 [8] and RFC 3704 [9]). This protects the TCP session used by Internal BGP (IBGP) from attackers outside the Autonomous System.
さらに、ネットワーク管理者は、ネットワークのすべてのエッジでスプーフィングされたパケット（IPアドレス空間に属するソースIPアドレスを持つパケット）をブロックする必要があります（RFC 2827 [8]およびRFC 3704 [9]を参照）。これにより、自律システム外の攻撃者から内部BGP（IBGP）で使用されるTCPセッションが保護されます。
BGP sessions can be made harder to spoof with the Generalized TTL Security Mechanisms (GTSM aka TTL security), defined in RFC 5082 [3]. Instead of sending TCP packets with TTL value of 1, the BGP speakers send the TCP packets with TTL value of 255, and the receiver checks that the TTL value equals 255. Since it's impossible to send an IP packet with TTL of 255 to an IP host that is not directly connected, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers. Network administrators SHOULD implement TTL security on directly connected BGP peerings.
BGPセッションは、RFC 5082 [3]で定義されている一般化TTLセキュリティメカニズム（GTSM、別名TTLセキュリティ）を使用して、なりすましを困難にすることができます。 TTL値が1のTCPパケットを送信する代わりに、BGPスピーカーはTTL値が255のTCPパケットを送信し、レシーバーはTTL値が255に等しいことを確認します。TTLが255のIPパケットをIPに送信することは不可能であるため、直接接続されていないホストの場合、BGP TTLセキュリティは、BGPスピーキングルータと同じサブネットに直接接続されていないサードパーティからのすべてのスプーフィング攻撃を効果的に防止します。ネットワーク管理者は、直接接続されたBGPピアリングにTTLセキュリティを実装する必要があります（SHOULD）。
GTSM could also be applied to multi-hop BGP peering as well. To achieve this, TTL needs to be configured with a proper value depending on the distance between BGP speakers (using the principle described above). Nevertheless, it is not as effective because anyone inside the TTL diameter could spoof the TTL.
GTSMはマルチホップBGPピアリングにも適用できます。これを達成するには、TTLをBGPスピーカー間の距離に応じて適切な値で構成する必要があります（上記の原理を使用）。それでも、TTLの直径の内側にいる人がTTLを偽装する可能性があるため、効果的ではありません。
Like MD5 protection, TTL security has to be configured on both ends of a BGP session.
MD5保護と同様に、TTLセキュリティはBGPセッションの両端で設定する必要があります。
The main aspect of securing BGP resides in controlling the prefixes that are received and advertised on the BGP peerings. Prefixes exchanged between BGP peers are controlled with inbound and outbound filters that can match on IP prefixes (as described in this section), AS paths (as described in Section 9) or any other attributes of a BGP prefix (for example, BGP communities, as described in Section 11).
BGPのセキュリティ保護の主な側面は、BGPピアリングで受信およびアドバタイズされるプレフィックスの制御にあります。 BGPピア間で交換されるプレフィックスは、IPプレフィックス（このセクションで説明）、ASパス（セクション9で説明）、またはBGPプレフィックスのその他の属性（BGPコミュニティなど）に一致する受信フィルターと送信フィルターで制御されます。セクション11で説明）。
This section lists the most commonly used prefix filters. The following sections will clarify where these filters should be applied.
このセクションでは、最も一般的に使用されるプレフィックスフィルターを一覧表示します。次のセクションでは、これらのフィルターをどこに適用するかを明確にします。
The IANA IPv4 Special-Purpose Address Registry [23] maintains the list of IPv4 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.
IANA IPv4特別目的アドレスレジストリ[23]は、IPv4特別目的プレフィックスとそのルーティングスコープのリストを維持し、プレフィックスフィルター構成に使用する必要があります（SHOULD）。列「グローバル」の値が「False」のプレフィックスは、インターネットBGPピアリングでは破棄する必要があります（SHOULD）。
The IANA IPv6 Special-Purpose Address Registry [24] maintains the list of IPv6 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Only prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.
IANA IPv6特別目的アドレスレジストリ[24]は、IPv6特別目的プレフィックスとそのルーティングスコープのリストを維持し、プレフィックスフィルター構成に使用する必要があります（SHOULD）。列「グローバル」の値が「False」のプレフィックスのみがインターネットBGPピアリングで破棄される必要があります。
IANA allocates prefixes to RIRs that in turn allocate prefixes to LIRs (Local Internet Registries). It is wise not to accept routing table prefixes that are not allocated by IANA and/or RIRs. This section details the options for building a list of allocated prefixes at every level. It is important to understand that filtering unallocated prefixes requires constant updates, as prefixes are continually allocated. Therefore, automation of such prefix filters is key for the success of this approach. Network administrators SHOULD NOT consider solutions described in this section if they are not capable of maintaining updated prefix filters: the damage would probably be worse than the intended security policy.
IANAは、プレフィックスをRIRに割り当て、次にプレフィックスをLIR（ローカルインターネットレジストリ）に割り当てます。 IANAやRIRによって割り当てられていないルーティングテーブルプレフィックスを受け入れないのが賢明です。このセクションでは、すべてのレベルで割り当てられたプレフィックスのリストを作成するためのオプションについて詳しく説明します。プレフィックスは継続的に割り当てられるため、割り当てられていないプレフィックスをフィルタリングするには、一定の更新が必要であることを理解することが重要です。したがって、このようなプレフィックスフィルターの自動化は、このアプローチを成功させるための鍵となります。ネットワーク管理者は、更新されたプレフィックスフィルターを維持できない場合、このセクションで説明されているソリューションを考慮すべきではありません。おそらく、意図したセキュリティポリシーよりも損害が大きくなるでしょう。
IANA has allocated all the IPv4 available space. Therefore, there is no reason why network administrators would keep checking that prefixes they receive from BGP peers are in the IANA-allocated IPv4 address space [25]. No specific filters need to be put in place by administrators who want to make sure that IPv4 prefixes they receive in BGP updates have been allocated by IANA.
IANAはすべてのIPv4利用可能スペースを割り当てました。したがって、ネットワーク管理者がBGPピアから受信したプレフィックスがIANAで割り当てられたIPv4アドレス空間にあることを常にチェックする理由はありません[25]。 BGP更新で受信するIPv4プレフィックスがIANAによって割り当てられていることを確認する管理者は、特定のフィルターを設定する必要はありません。
For IPv6, given the size of the address space, it can be seen as wise to accept only prefixes derived from those allocated by IANA. Administrators can dynamically build this list from the IANA-allocated IPv6 space [26]. As IANA keeps allocating prefixes to RIRs, the aforementioned list should be checked regularly against changes, and if they occur, prefix filters should be computed and pushed on network devices. The list could also be pulled directly by routers when they implement such mechanisms. As there is delay between the time a RIR receives a new prefix and the moment it starts allocating portions of it to its LIRs, there is no need for doing this step quickly and frequently. However, network administrators SHOULD ensure that all IPv6 prefix filters are updated within a maximum of one month after any change in the list of IPv6 prefixes allocated by IANA.
IPv6の場合、アドレススペースのサイズを考えると、IANAによって割り当てられたプレフィックスから派生したプレフィックスのみを受け入れることが賢明であると見なすことができます。管理者は、IANAが割り当てたIPv6スペースからこのリストを動的に作成できます[26]。 IANAはプレフィックスをRIRに割り当て続けるため、前述のリストは変更に対して定期的にチェックする必要があります。変更が発生した場合は、プレフィックスフィルターを計算してネットワークデバイスにプッシュする必要があります。このようなメカニズムを実装しているルーターは、リストを直接取得することもできます。 RIRが新しいプレフィックスを受信してから、その一部をLIRに割り当て始めるまでの間に遅延があるため、この手順を迅速かつ頻繁に行う必要はありません。ただし、ネットワーク管理者は、IANAによって割り当てられたIPv6プレフィックスのリストを変更した後、すべてのIPv6プレフィックスフィルターが最大1か月以内に更新されるようにする必要があります（SHOULD）。
If the process in place (whether manual or automatic) cannot guarantee that the list is updated regularly, then it's better not to configure any filters based on allocated networks. The IPv4 experience has shown that many network operators implemented filters for prefixes not allocated by IANA but did not update them on a regular basis. This created problems for the latest allocations, and required extra work for RIRs that had to "de-bogonize" the newly allocated prefixes. (See [18] for information on de-bogonizing.)
適切なプロセス（手動または自動）でリストが定期的に更新されることを保証できない場合は、割り当てられたネットワークに基づいてフィルターを構成しないことをお勧めします。 IPv4エクスペリエンスは、多くのネットワークオペレーターがIANAによって割り当てられていないプレフィックスのフィルターを実装したが、定期的にそれらを更新しなかったことを示しています。これにより、最新の割り当てに問題が生じ、新しく割り当てられたプレフィックスを「de-bogonize」する必要のあるRIRに追加の作業が必要になりました。 （de-bogonizingについては、[18]を参照してください。）
A more precise check can be performed when one would like to make sure that prefixes they receive are being originated or transited by Autonomous Systems (ASes) entitled to do so. It has been observed in the past that an AS could easily advertise someone else's prefix (or more specific prefixes) and create black holes or security threats. To partially mitigate this risk, administrators would need to make sure BGP advertisements correspond to information located in the existing registries. At this stage, two options can be considered: short- and long-term options. They are described in the following subsections.
受信したプレフィックスが、その権限を持つ自律システム（AS）によって発信または転送されていることを確認したい場合は、より正確なチェックを実行できます。 ASが他の誰かのプレフィックス（またはより具体的なプレフィックス）を容易にアドバタイズし、ブラックホールまたはセキュリティの脅威を作成する可能性があることが以前に観察されていました。このリスクを部分的に軽減するには、管理者はBGPアドバタイズが既存のレジストリにある情報に対応していることを確認する必要があります。この段階では、2つのオプションを検討できます。短期オプションと長期オプションです。以下のサブセクションで説明します。
6.1.2.2.1. Prefix Filters Created from Internet Routing Registries (IRRs)
6.1.2.2.1. インターネットルーティングレジストリ（IRR）から作成されたプレフィックスフィルター
An Internet Routing Registry (IRR) is a database containing Internet routing information, described using Routing Policy Specification Language objects as described in RFC 4012 [10]. Network administrators are given privileges to describe routing policies of their own networks in the IRR, and that information is published, usually publicly. A majority of Regional Internet Registries do also operate an IRR and can control whether registered routes conform to the prefixes that are allocated or directly assigned. However, it should be noted that the list of such prefixes is not necessarily a complete list, and as such the list of routes in an IRR is not the same as the set of RIR-allocated prefixes.
インターネットルーティングレジストリ（IRR）は、RFC 4012 [10]に記述されているルーティングポリシー仕様言語オブジェクトを使用して記述されたインターネットルーティング情報を含むデータベースです。ネットワーク管理者には、IRRで自分のネットワークのルーティングポリシーを説明する特権が与えられており、その情報は通常公開されています。地域インターネットレジストリの大部分はIRRも運用しており、登録されたルートが、割り当てられたプレフィックスまたは直接割り当てられたプレフィックスに準拠するかどうかを制御できます。ただし、そのようなプレフィックスのリストは必ずしも完全なリストではなく、IRR内のルートのリストはRIRで割り当てられたプレフィックスのセットと同じではないことに注意してください。
It is possible to use the IRR information to build, for a given neighbor AS, a list of originated or transited prefixes that one may accept. This can be done relatively easily using scripts and existing tools capable of retrieving this information from the registries. This approach is exactly the same for both IPv4 and IPv6.
IRR情報を使用して、特定のネイバーASについて、受け入れることができる発信または通過プレフィックスのリストを作成することができます。これは、レジストリからこの情報を取得できるスクリプトと既存のツールを使用して比較的簡単に行うことができます。このアプローチは、IPv4とIPv6の両方でまったく同じです。
The macro-algorithm for the script is as follows. For the peer that is considered, the distant network administrator has provided the AS and may be able to provide an AS-SET object (aka AS-MACRO). An AS-SET is an object that contains AS numbers or other AS-SETs. An operator may create an AS-SET defining all the AS numbers of its customers. A Tier 1 transit provider might create an AS-SET describing the AS-SET of connected operators, which in turn describe the AS numbers of their customers. Using recursion, it is possible to retrieve from an AS-SET the complete list of AS numbers that the peer is likely to announce. For each of these AS numbers, it is also easy to look in the corresponding IRR for all associated prefixes. With these two mechanisms, a script can build, for a given peer, the list of allowed prefixes and the AS number from which they should be originated. One could decide not use the origin information and only build monolithic prefix filters from fetched data.
スクリプトのマクロアルゴリズムは次のとおりです。考慮されるピアについては、遠方のネットワーク管理者がASを提供しており、AS-SETオブジェクト（別名AS-MACRO）を提供できる場合があります。 AS-SETは、AS番号または他のAS-SETを含むオブジェクトです。オペレーターは、顧客のすべてのAS番号を定義するAS-SETを作成できます。 Tier 1輸送プロバイダーは、接続されたオペレーターのAS-SETを記述したAS-SETを作成し、次に、それらの顧客のAS番号を記述します。再帰を使用すると、ピアがアナウンスする可能性のあるAS番号の完全なリストをAS-SETから取得できます。これらの各AS番号について、関連するすべてのプレフィックスの対応するIRRを調べることも簡単です。これらの2つのメカニズムにより、スクリプトは、特定のピアに対して、許可されたプレフィックスのリストと、それらの発信元であるAS番号を作成できます。発信元情報を使用せず、フェッチされたデータからモノリシックプレフィックスフィルターのみを構築することもできます。
As prefixes, AS numbers, and AS-SETs may not all be under the same RIR authority, it is difficult to choose for each object the appropriate IRR to poll. Some IRRs have been created and are not restricted to a given region or authoritative RIR. They allow RIRs to publish information contained in their IRR in a common place. They also make it possible for any subscriber (probably under contract) to publish information too. When doing requests inside such an IRR, it is possible to specify the source of information in order to have the most reliable data. One could check a popular IRR containing many sources (such as RADb [27], the Routing Assets Database) and only select as sources some desired RIRs and trusted major ISPs (Internet Service Providers).
プレフィックス、AS番号、およびAS-SETがすべて同じRIR権限下にあるとは限らないため、オブジェクトごとにポーリングする適切なIRRを選択することは困難です。一部のIRRが作成されており、特定のリージョンまたは権威あるRIRに制限されていません。これにより、RIRはIRRに含まれる情報を共通の場所に公開できます。また、（おそらく契約中の）サブスクライバーが情報を公開することもできます。そのようなIRR内で要求を行う場合、最も信頼できるデータを取得するために情報のソースを指定することが可能です。多くのソース（RADb [27]、ルーティングアセットデータベースなど）を含む一般的なIRRをチェックし、ソースとして、いくつかの必要なRIRと信頼できる主要ISP（インターネットサービスプロバイダー）のみを選択できます。
As objects in IRRs may frequently vary over time, it is important that prefix filters computed using this mechanism are refreshed regularly. Refreshing the filters on a daily basis SHOULD be considered because routing changes must sometimes be done in an emergency and registries may be updated at the very last moment. Note that this approach significantly increases the complexity of the router configurations, as it can quickly add tens of thousands of configuration lines for some important peers. To manage this complexity, network administrators could use, for example, IRRToolSet [30], a set of tools making it possible to simplify the creation of automated filter configuration from policies stored in an IRR.
IRRのオブジェクトは時間の経過とともに頻繁に変化する可能性があるため、このメカニズムを使用して計算されたプレフィックスフィルターを定期的に更新することが重要です。緊急時にルーティングの変更を行う必要があり、レジストリが最後に更新される可能性があるため、フィルタを毎日更新することを検討してください。この方法では、重要なピアに数万の構成行をすばやく追加できるため、ルーター構成の複雑さが大幅に増加することに注意してください。この複雑さを管理するために、ネットワーク管理者は、たとえばIRRToolSet [30]を使用できます。IRRToolSet[30]は、IRRに保存されたポリシーからの自動フィルター構成の作成を簡素化できるツールのセットです。
Last but not least, network administrators SHOULD publish and maintain their resources properly in the IRR database maintained by their RIR, when available.
最後に重要なことですが、ネットワーク管理者は、利用可能な場合、RIRによって維持されるIRRデータベースにリソースを適切に公開および維持する必要があります（SHOULD）。
An infrastructure called SIDR (Secure Inter-Domain Routing), described in RFC 6480 [12], has been designed to secure Internet advertisements. At the time of writing this document, many documents have been published and a framework with a complete set of protocols is proposed so that advertisements can be checked against signed routing objects in RIRs. There are basically two services that SIDR offers:
RFC 6480 [12]に記述されているSIDR（Secure Inter-Domain Routing）と呼ばれるインフラストラクチャは、インターネット広告を保護するように設計されています。このドキュメントの執筆時点では、多くのドキュメントが公開されており、アドバタイズをRIR内の署名されたルーティングオブジェクトに対してチェックできるように、プロトコルの完全なセットを備えたフレームワークが提案されています。 SIDRが提供するサービスは基本的に2つあります。
o Origin validation, described in RFC 6811 [5], seeks to make sure that attributes associated with routes are correct. (The major point is the validation of the AS number originating a given route.) Origin validation is now operational (Internet registries, protocols, implementations on some routers), and in theory it can be implemented knowing that the number of signed resources is still low at the time of writing this document.
o RFC 6811 [5]に記述されているオリジン検証は、ルートに関連付けられた属性が正しいことを確認しようとします。 （主なポイントは、特定のルートを発信するAS番号の検証です。）発信元の検証が機能するようになり（インターネットレジストリ、プロトコル、一部のルーターでの実装）、理論的には、署名されたリソースの数がまだ残っていることを知って実装できます。このドキュメントの執筆時点では低い。
o Path validation provided by BGPsec [29] seeks to make sure that no one announces fake/wrong BGP paths that would attract traffic for a given destination; see RFC 7132 [16]. BGPsec is still an ongoing work item at the time of writing this document and therefore cannot be implemented.
o BGPsec [29]によって提供されるパス検証は、特定の宛先へのトラフィックを引き付ける偽/間違ったBGPパスを誰もアナウンスしないことを確認することを目指しています。 RFC 7132 [16]を参照してください。 BGPsecは、このドキュメントの執筆時点ではまだ進行中の作業項目であるため、実装できません。
Implementing SIDR mechanisms is expected to solve many of the BGP routing security problems in the long term, but it may take time for deployments to be made and objects to become signed. Also, note that the SIDR infrastructure is complementing (not replacing) the security best practices listed in this document. Therefore, network administrators SHOULD implement any SIDR proposed mechanism (for example, route origin validation) on top of the other existing mechanisms even if they could sometimes appear to be targeting the same goal.
SIDRメカニズムを実装すると、長期的にはBGPルーティングのセキュリティ問題の多くが解決されると予想されますが、デプロイメントが行われ、オブジェクトが署名されるまでに時間がかかる場合があります。また、SIDRインフラストラクチャは、このドキュメントに記載されているセキュリティのベストプラクティスを補完する（置き換えない）ことに注意してください。したがって、ネットワーク管理者は、同じ目標をターゲットにしているように見える場合でも、他の既存のメカニズムの上にSIDR提案メカニズム（たとえば、ルートオリジン検証）を実装する必要があります（SHOULD）。
If route origin validation is implemented, the reader SHOULD refer to the rules described in RFC 7115 [15]. In short, each external route received on a router SHOULD be checked against the Resource Public Key Infrastructure (RPKI) data set:
ルート起点検証が実装されている場合、リーダーはRFC 7115 [15]に記述されているルールを参照する必要があります（SHOULD）。つまり、ルーターで受信した各外部ルートは、リソース公開鍵インフラストラクチャ（RPKI）データセットに対してチェックする必要があります（SHOULD）。
o If a corresponding ROA (Route Origin Authorization) is found and is valid, then the prefix SHOULD be accepted.
o 対応するROA（Route Origin Authorization）が見つかり、それが有効な場合、接頭辞を受け入れる必要があります（SHOULD）。
o If the ROA is found and is INVALID, then the prefix SHOULD be discarded.
o ROAが見つかり、それが無効な場合は、プレフィックスを破棄する必要があります（SHOULD）。
o If a ROA is not found, then the prefix SHOULD be accepted, but the corresponding route SHOULD be given a low preference.
o ROAが見つからない場合、プレフィックスは受け入れられるべきですが（SHOULD）、対応するルートは低い優先度を与えられるべきです（SHOULD）。
In addition to this, network administrators SHOULD sign their routing objects so their routes can be validated by other networks running origin validation.
これに加えて、ネットワーク管理者はルーティングオブジェクトに署名する必要があります（SHOULD）。そのため、オリジン検証を実行している他のネットワークによってルートを検証できます。
One should understand that the RPKI model brings new, interesting challenges. The paper "On the Risk of Misbehaving RPKI Authorities" [31] explains how the RPKI model can impact the Internet if authorities don't behave as they are supposed to. Further analysis is certainly required on RPKI, which carries part of BGP security.
RPKIモデルは新しく興味深い課題をもたらすことを理解する必要があります。ペーパー「RPKI当局の不正行為のリスクについて」[31]は、当局が想定どおりに行動しない場合、RPKIモデルがインターネットにどのように影響するかを説明しています。 BGPセキュリティの一部であるRPKIについては、さらに分析が必要です。
Most ISPs will not accept advertisements beyond a certain level of specificity (and in return, they do not announce prefixes they consider to be too specific). That acceptable specificity is decided for each peering between the two BGP peers. Some ISP communities have tried to document acceptable specificity. This document does not make any judgement on what the best approach is, it just notes that there are existing practices on the Internet and recommends that the reader refer to them. As an example, the RIPE community has documented that, at the time of writing of this document, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet [20] [21]. These values may change in the future.
ほとんどのISPは、特定のレベルの特定性を超える広告を受け入れません（その代わりに、特定性が高すぎると見なされるプレフィックスをアナウンスしません）。その許容可能な特異性は、2つのBGPピア間のピアリングごとに決定されます。一部のISPコミュニティは、受け入れ可能な特異性を文書化しようとしました。このドキュメントは、最善のアプローチが何であるかを判断するものではなく、インターネット上に既存の慣行があることを示し、読者にそれらを参照することを勧めています。例として、RIPEコミュニティは、このドキュメントの執筆時点で、/ 24より長いIPv4プレフィックスと/ 48より長いIPv6プレフィックスは、一般にインターネットで発表も受け入れもされていないことを文書化しています[20] [21]。これらの値は将来変更される可能性があります。
A network SHOULD filter its own prefixes on peerings with all its peers (inbound direction). This prevents local traffic (from a local source to a local destination) from leaking over an external peering, in case someone else is announcing the prefix over the Internet. This also protects the infrastructure that may directly suffer if the backbone's prefix is suddenly preferred over the Internet.
ネットワークは、すべてのピアとのピアリングで独自のプレフィックスをフィルタリングする必要があります（インバウンド方向）。これにより、他の誰かがインターネット経由でプレフィックスを発表した場合に、ローカルトラフィック（ローカルソースからローカル宛先へ）が外部ピアリングを介してリークするのを防ぎます。これにより、バックボーンのプレフィックスがインターネットよりも突然優先された場合に直接影響を受ける可能性のあるインフラストラクチャも保護されます。
In some cases, for example, multihoming scenarios, such filters SHOULD NOT be applied, as this would break the desired redundancy.
場合によっては、たとえば、マルチホーミングシナリオでは、このようなフィルターを適用しないでください。これは、必要な冗長性が失われるためです。
To an extent, such filters can also be configured on a network for the prefixes of its downstreams in order to protect them, too. Such filters must be defined with caution as they can break existing redundancy mechanisms. For example, when an operator has a multihomed customer, it should keep accepting the customer prefix from its peers and upstreams. This will make it possible for the customer to keep accessing its operator network (and other customers) via the Internet even if the BGP peering between the customer and the operator is down.
ある程度まで、そのようなフィルタは、それらを保護するために、そのダウンストリームのプレフィックスに対してもネットワーク上で構成できます。このようなフィルターは、既存の冗長メカニズムを壊す可能性があるため、注意して定義する必要があります。たとえば、オペレーターがマルチホームの顧客を持っている場合、オペレーターはピアとアップストリームから顧客プレフィックスを受け入れ続ける必要があります。これにより、顧客とオペレーター間のBGPピアリングがダウンしている場合でも、顧客はインターネットを介してオペレーターネットワーク（および他の顧客）にアクセスし続けることができます。
When a network is present on an IXP and peers with other IXP members over a common subnet (IXP LAN prefix), it SHOULD NOT accept more-specific prefixes for the IXP LAN prefix from any of its external BGP peers. Accepting these routes may create a black hole for connectivity to the IXP LAN.
ネットワークがIXPに存在し、共通のサブネット（IXP LANプレフィックス）を介して他のIXPメンバーとピアしている場合、そのネットワークは、外部BGPピアのいずれかからのIXP LANプレフィックスのより具体的なプレフィックスを受け入れてはなりません（SHOULD NOT）。これらのルートを受け入れると、IXP LANへの接続にブラックホールが生じる可能性があります。
If the IXP LAN prefix is accepted as an "exact match", care needs to be taken to prevent other routers in the network from sending IXP traffic towards the externally learned IXP LAN prefix (recursive route lookup pointing into the wrong direction). This can be achieved by preferring IGP routes over External BGP (EBGP), or by using "BGP next-hop-self" on all routes learned on that IXP.
IXP LANプレフィックスが「完全一致」として受け入れられる場合、ネットワーク内の他のルーターが外部から学習したIXP LANプレフィックスに向けてIXPトラフィックを送信しないように注意する必要があります（間違った方向を指す再帰ルートルックアップ）。これは、外部BGP（EBGP）よりもIGPルートを優先するか、そのIXPで学習されたすべてのルートで「BGP next-hop-self」を使用することで実現できます。
If the IXP LAN prefix is accepted at all, it SHOULD only be accepted from the ASes that the IXP authorizes to announce it -- this will usually be automatically achieved by filtering announcements using the IRR database.
IXP LANプレフィックスがまったく受け入れられる場合、それはIXPがアナウンスすることを承認したASからのみ受け入れられる必要があります-これは通常、IRRデータベースを使用してアナウンスをフィルタリングすることによって自動的に達成されます。
In order to have PMTUD working in the presence of loose uRPF, it is necessary that all the networks that may source traffic that could flow through the IXP (i.e., IXP members and their downstreams) have a route for the IXP LAN prefix. This is necessary as "packet too big" ICMP messages sent by IXP members' routers may be sourced using an address of the IXP LAN prefix. In the presence of loose uRPF, this ICMP packet is dropped if there is no route for the IXP LAN prefix or a less specific route covering IXP LAN prefix.
緩やかなuRPFの存在下でPMTUDを機能させるには、IXPを介して流れる可能性のあるトラフィックを発信する可能性のあるすべてのネットワーク（つまり、IXPメンバーとそのダウンストリーム）に、IXP LANプレフィックスのルートが必要です。 IXPメンバーのルーターによって送信される「パケットが大きすぎる」ICMPメッセージは、IXP LANプレフィックスのアドレスを使用して送信される可能性があるため、これは必要です。緩やかなuRPFが存在する場合、IXP LANプレフィックスへのルートがないか、またはIXP LANプレフィックスをカバーする特定性の低いルートがない場合、このICMPパケットはドロップされます。
In that case, any IXP member SHOULD make sure it has a route for the IXP LAN prefix or a less specific prefix on all its routers and that it announces the IXP LAN prefix or the less specific route (up to a default route) to its downstreams. The announcements done for this purpose SHOULD pass IRR-generated filters described in Section 6.1.2.2.1 as well as "prefixes that are too specific" filters described in Section 6.1.3. The easiest way to implement this is for the IXP itself to take care of the origination of its prefix and advertise it to all IXP members through a BGP peering. Most likely, the BGP route servers would be used for this, and the IXP would send its entire prefix, which would be equal to or less specific than the IXP LAN prefix.
その場合、すべてのIXPメンバーは、すべてのルーターにIXP LANプレフィックスまたはそれほど具体的でないプレフィックスへのルートがあり、IXP LANプレフィックスまたはあまり具体的でないルート（デフォルトルートまで）をそのルートに通知する必要があります（SHOULD）。下流。この目的で行われたアナウンスは、セクション6.1.2.2.1で説明されているIRRで生成されたフィルターと、セクション6.1.3で説明されている「具体的すぎるプレフィックス」フィルターを渡す必要があります（SHOULD）。これを実装する最も簡単な方法は、IXP自体がそのプレフィックスの生成を処理し、BGPピアリングを通じてすべてのIXPメンバーにそれを通知することです。ほとんどの場合、これにはBGPルートサーバーが使用され、IXPはそのプレフィックス全体を送信します。これは、IXP LANプレフィックスと同じかそれよりも限定的ではありません。
Appendix A gives an example of guidelines regarding IXP LAN prefix.
付録Aに、IXP LANプレフィックスに関するガイドラインの例を示します。
Typically, the 0.0.0.0/0 prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.
通常、0.0.0.0 / 0プレフィックスは、特定の顧客/プロバイダー構成を除いて、受け入れたりアドバタイズしたりすることを意図していません。これら以外の一般的なフィルタリングは推奨されます。
Typically, the ::/0 prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.
通常、:: / 0プレフィックスは、特定の顧客/プロバイダーの構成を除いて、受け入れまたはアドバタイズされることを意図していません。これら以外の一般的なフィルタリングは推奨されます。
For networks that have the full Internet BGP table, some policies should be applied on each BGP peer for received and advertised routes. It is RECOMMENDED that each Autonomous System configures rules for advertised and received routes at all its borders, as this will protect the network and its peer even in case of misconfiguration. The most commonly used filtering policy is proposed in this section and uses prefix filters defined in Section 6.1.
完全なインターネットBGPテーブルがあるネットワークでは、受信およびアドバタイズされたルートの各BGPピアにいくつかのポリシーを適用する必要があります。各自律システムは、すべての境界でアドバタイズおよび受信されたルートのルールを設定することをお勧めします。これにより、設定が誤っている場合でもネットワークとそのピアが保護されます。このセクションでは、最も一般的に使用されるフィルタリングポリシーを提案し、セクション6.1で定義されたプレフィックスフィルターを使用します。
There are basically two options -- the loose one where no check will be done against RIR allocations and the strict one where it will be verified that announcements strictly conform to what is declared in routing registries.
基本的に2つのオプションがあります。RIR割り当てに対してチェックが行われないルーズなオプションと、アナウンスがルーティングレジストリで宣言されているものに厳密に準拠していることが確認される厳密なオプションです。
In this case, the following prefixes received from a BGP peer will be filtered:
この場合、BGPピアから受信した次のプレフィックスがフィルタリングされます。
o prefixes that are not globally routable (Section 6.1.1)
o グローバルにルーティングできないプレフィックス（セクション6.1.1）
o prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1)
o IANAによって割り当てられていないプレフィックス（IPv6のみ）（セクション6.1.2.1）
o routes that are too specific (Section 6.1.3)
o 特定度が高すぎるルート（セクション6.1.3）
o prefixes belonging to the local AS (Section 6.1.4)
o ローカルASに属するプレフィックス（セクション6.1.4）
o IXP LAN prefixes (Section 6.1.5)
o IXP LANプレフィックス（セクション6.1.5）
o the default route (Section 6.1.6)
o デフォルトルート（セクション6.1.6）
In this case, filters are applied to make sure advertisements strictly conform to what is declared in routing registries (Section 6.1.2.2). Warning is given as registries are not always
この場合、アドバタイズがルーティングレジストリで宣言されている内容に厳密に準拠するようにフィルタが適用されます（セクション6.1.2.2）。レジストリは常にではないため、警告が表示されます
accurate (prefixes missing, wrong information, etc.). This varies across the registries and regions of the Internet. Before applying a strict policy, the reader SHOULD check the impact on the filter and make sure the solution is not worse than the problem.
正確（接頭辞の欠落、誤った情報など）。これは、インターネットのレジストリや地域によって異なります。厳密なポリシーを適用する前に、読者はフィルターへの影響をチェックして、ソリューションが問題よりも悪くないことを確認する必要があります。
Also, in case of script failure, each administrator may decide if all routes are accepted or rejected depending on routing policy. While accepting the routes during that time frame could break the BGP routing security, rejecting them might re-route too much traffic on transit peers, and could cause more harm than what a loose policy would have done.
また、スクリプトが失敗した場合、各管理者はルーティングポリシーに応じて、すべてのルートを受け入れるか拒否するかを決定できます。この期間中にルートを受け入れると、BGPルーティングのセキュリティが損なわれる可能性がありますが、ルートを拒否すると、トランジットピアのトラフィックが再ルーティングされる可能性があり、緩いポリシーよりも害が大きくなる可能性があります。
In addition to this, network administrators could apply the following filters beforehand in case the routing registry that's used as the source of information by the script is not fully trusted:
これに加えて、ネットワーク管理者は、スクリプトによって情報のソースとして使用されるルーティングレジストリが完全に信頼されていない場合に備えて、事前に次のフィルターを適用することができます。
o prefixes that are not globally routable (Section 6.1.1)
o グローバルにルーティングできないプレフィックス（セクション6.1.1）
o routes that are too specific (Section 6.1.3)
o 特定度が高すぎるルート（セクション6.1.3）
o prefixes belonging to the local AS (Section 6.1.4)
o ローカルASに属するプレフィックス（セクション6.1.4）
o IXP LAN prefixes (Section 6.1.5)
o IXP LANプレフィックス（セクション6.1.5）
o the default route (Section 6.1.6)
o デフォルトルート（セクション6.1.6）
The configuration should ensure that only appropriate prefixes are sent. These can be, for example, prefixes belonging to both the network in question and its downstreams. This can be achieved by using BGP communities, AS paths, or both. Also, it may be desirable to add the following filters before any policy to avoid unwanted route announcements due to bad configuration:
構成では、適切なプレフィックスのみが送信されるようにする必要があります。これらは、たとえば、問題のネットワークとそのダウンストリームの両方に属するプレフィックスにすることができます。これは、BGPコミュニティ、ASパス、またはその両方を使用して実現できます。また、不適切な構成による不要なルートのアナウンスを回避するために、ポリシーの前に次のフィルターを追加することが望ましい場合があります。
o Prefixes that are not globally routable (Section 6.1.1)
o グローバルにルーティングできないプレフィックス（セクション6.1.1）
o Routes that are too specific (Section 6.1.3)
o 具体的すぎるルート（セクション6.1.3）
o IXP LAN prefixes (Section 6.1.5)
o IXP LANプレフィックス（セクション6.1.5）
o The default route (Section 6.1.6)
o デフォルトルート（セクション6.1.6）
If it is possible to list the prefixes to be advertised, then just configuring the list of allowed prefixes and denying the rest is sufficient.
アドバタイズするプレフィックスを一覧表示することが可能な場合は、許可されたプレフィックスのリストを構成し、残りを拒否するだけで十分です。
The inbound policy with end customers is pretty straightforward: only customer prefixes SHOULD be accepted, all others SHOULD be discarded. The list of accepted prefixes can be manually specified, after having verified that they are valid. This validation can be done with the appropriate IP address management authorities.
エンドカスタマーとのインバウンドポリシーは非常に単純です。カスタマープレフィックスだけが受け入れられるべきであり、他のすべては破棄されるべきです（SHOULD）。受け入れられた接頭辞のリストは、有効であることを確認した後、手動で指定できます。この検証は、適切なIPアドレス管理機関を使用して行うことができます。
The same rules apply when the customer is a network connecting other customers (for example, a Tier 1 transit provider connecting service providers). An exception is when the customer network applies strict inbound/outbound prefix filtering, and there are too many prefixes announced by that network to list them in the router configuration. In that case, filters as in Section 6.2.1.1 can be applied.
顧客が他の顧客を接続するネットワーク（たとえば、サービスプロバイダーを接続するTier 1輸送プロバイダー）である場合、同じルールが適用されます。例外は、カスタマーネットワークが厳密なインバウンド/アウトバウンドプレフィックスフィルタリングを適用し、そのネットワークによってプレフィックスが多すぎてルーター構成にリストできない場合です。その場合、セクション6.2.1.1のようなフィルターを適用できます。
The outbound policy with customers may vary according to the routes the customer wants to receive. In the simplest possible scenario, the customer may want to receive only the default route; this can be done easily by applying a filter with the default route only.
顧客とのアウトバウンドポリシーは、顧客が受け取りたいルートによって異なる場合があります。最も単純なシナリオでは、顧客はデフォルトルートのみを受け取りたい場合があります。これは、デフォルトルートのみでフィルターを適用することで簡単に実行できます。
In case the customer wants to receive the full routing (if it is multihomed or if it wants to have a view of the Internet table), the following filters can be applied on the BGP peering:
顧客が完全なルーティングを受信したい場合（マルチホームである場合、またはインターネットテーブルを表示したい場合）、次のフィルターをBGPピアリングに適用できます。
o prefixes that are not globally routable (Section 6.1.1)
o グローバルにルーティングできないプレフィックス（セクション6.1.1）
o routes that are too specific (Section 6.1.3)
o 特定度が高すぎるルート（セクション6.1.3）
o the default route (Section 6.1.6)
o デフォルトルート（セクション6.1.6）
In some cases, the customer may desire to receive the default route in addition to the full BGP table. This can be done by the provider simply by removing the filter for the default route. As the default route may not be present in the routing table, network administrators may decide to originate it only for peerings where it has to be advertised.
場合によっては、完全なBGPテーブルに加えて、デフォルトルートを受信したい場合があります。これは、デフォルトルートのフィルターを削除するだけでプロバイダーが実行できます。デフォルトルートがルーティングテーブルに存在しない場合があるため、ネットワーク管理者は、アドバタイズする必要があるピアリングに対してのみルートを発信することを決定できます。
If the full routing table is desired from the upstream, the prefix filtering to apply is the same as the one for peers Section 6.2.1.1 with the exception of the default route. Sometimes, the default route (in addition to the full BGP table) can be desired from an upstream provider. If the upstream provider is supposed to announce only the default route, a simple filter will be applied to accept only the default prefix and nothing else.
アップストリームから完全なルーティングテーブルが必要な場合、適用するプレフィックスフィルタリングは、デフォルトルートを除いて、ピアセクション6.2.1.1のものと同じです。場合によっては、（完全なBGPテーブルに加えて）デフォルトルートがアップストリームプロバイダーから要求されることがあります。アップストリームプロバイダーがデフォルトルートのみをアナウンスすることになっている場合、単純なフィルターが適用され、デフォルトプレフィックスのみを受け入れ、それ以外は何も受け入れません。
The filters to be applied would most likely not differ much from the ones applied for Internet peers (Section 6.2.1.2). However, different policies could be applied if a particular upstream should not provide transit to all the prefixes.
適用されるフィルターは、インターネットピアに適用されるフィルター（セクション6.2.1.2）とほとんど変わらないでしょう。ただし、特定のアップストリームがすべてのプレフィックスへの通過を提供するべきではない場合、異なるポリシーが適用される可能性があります。
The leaf network will deploy the filters corresponding to the routes it is requesting from its upstream. If a default route is requested, a simple inbound filter can be applied to accept only the default route (Section 6.1.6). If the leaf network is not capable of listing the prefixes because there are too many (for example, if it requires the full Internet routing table), then it should configure the following filters to avoid receiving bad announcements from its upstream:
リーフネットワークは、上流から要求しているルートに対応するフィルターを展開します。デフォルトルートが要求された場合、デフォルトルートのみを受け入れるように単純な受信フィルターを適用できます（セクション6.1.6）。リーフネットワークでプレフィックスが多すぎるためにプレフィックスを一覧表示できない場合（たとえば、完全なインターネットルーティングテーブルが必要な場合）、次のフィルターを構成して、アップストリームから悪いアナウンスを受信しないようにする必要があります。
o prefixes not routable (Section 6.1.1)
o プレフィックスがルーティングできない（セクション6.1.1）
o routes that are too specific (Section 6.1.3)
o 特定度が高すぎるルート（セクション6.1.3）
o prefixes belonging to local AS (Section 6.1.4)
o ローカルASに属するプレフィックス（セクション6.1.4）
o the default route (Section 6.1.6) depending on whether or not the route is requested
o ルートが要求されているかどうかに応じたデフォルトルート（セクション6.1.6）
A leaf network will most likely have a very straightforward policy: it will only announce its local routes. It can also configure the prefix filters described in Section 6.2.1.2 to avoid announcing invalid routes to its upstream provider.
リーフネットワークは、非常に単純なポリシーを持つ可能性が最も高く、ローカルルートのみをアナウンスします。セクション6.2.1.2で説明されているプレフィックスフィルターを構成して、上流のプロバイダーへの無効なルートのアナウンスを回避することもできます。
The BGP route flap dampening mechanism makes it possible to give penalties to routes each time they change in the BGP routing table. Initially, this mechanism was created to protect the entire Internet from multiple events that impact a single network. Studies have shown that implementations of BGP route flap dampening could cause more harm than benefit; therefore, in the past, the RIPE community has recommended against using BGP route flap dampening [19]. Later, studies were conducted to propose new route flap dampening thresholds in order to make the solution "usable"; see RFC 7196 [6] and [22] (in which RIPE reviewed its recommendations). This document RECOMMENDS following IETF and RIPE recommendations and using BGP route flap dampening with the adjusted configured thresholds.
BGPルートフラップダンプニングメカニズムにより、BGPルーティングテーブルでルートが変更されるたびにペナルティを与えることができます。当初、このメカニズムは、単一のネットワークに影響を与える複数のイベントからインターネット全体を保護するために作成されました。研究によると、BGPルートフラップダンプニングの実装は、利益よりも害をもたらす可能性があります。したがって、これまで、RIPEコミュニティはBGPルートフラップダンプニングの使用を推奨していませんでした[19]。その後、ソリューションを「使用可能」にするために、新しいルートフラップダンプニングしきい値を提案するための調査が行われました。 RFC 7196 [6]および[22]（RIPEがその推奨事項を検討したもの）を参照してください。このドキュメントは、IETFとRIPEの推奨事項に従い、調整された構成済みのしきい値でBGPルートフラップダンプニングを使用することを推奨します。
It is RECOMMENDED to configure a limit on the number of routes to be accepted from a peer. The following rules are generally RECOMMENDED:
ピアから受け入れるルートの数に制限を設定することをお勧めします。以下のルールが一般的に推奨されます：
o From peers, it is RECOMMENDED to have a limit lower than the number of routes in the Internet. This will shut down the BGP peering if the peer suddenly advertises the full table. Network administrators can also configure different limits for each peer, according to the number of routes they are supposed to advertise, plus some headroom to permit growth.
o ピアからは、インターネットのルート数よりも制限を少なくすることをお勧めします。これにより、ピアが突然テーブル全体をアドバタイズした場合、BGPピアリングがシャットダウンされます。ネットワーク管理者は、アドバタイズすることになっているルートの数に応じて、ピアごとに異なる制限を設定することもできます。
o From upstreams that provide full routing, it is RECOMMENDED to have a limit higher than the number of routes in the Internet. A limit is still useful in order to protect the network (and in particular, the routers' memory) if too many routes are sent by the upstream. The limit should be chosen according to the number of routes that can actually be handled by routers.
o 完全なルーティングを提供するアップストリームからは、インターネットのルート数よりも高い制限を設定することをお勧めします。アップストリームによって送信されるルートが多すぎる場合、ネットワーク（特にルーターのメモリ）を保護するために制限は依然として役立ちます。制限は、実際にルーターで処理できるルートの数に応じて選択する必要があります。
It is important to regularly review the limits that are configured as the Internet can quickly change over time. Some vendors propose mechanisms to have two thresholds: while the higher number specified will shut down the peering, the first threshold will only trigger a log and can be used to passively adjust limits based on observations made on the network.
インターネットは時間とともに急速に変化する可能性があるため、構成されている制限を定期的に確認することが重要です。一部のベンダーは、2つのしきい値を設定するメカニズムを提案しています。指定した数値が大きいとピアリングがシャットダウンしますが、最初のしきい値はログをトリガーするだけであり、ネットワークで行われた観察に基づいて受動的に制限を調整するために使用できます。
This section lists the RECOMMENDED practices when processing BGP AS paths.
このセクションでは、BGP ASパスを処理する際の推奨プラクティスを示します。
o Network administrators SHOULD accept from customers only 2-byte or 4-byte AS paths containing ASNs belonging to (or authorized to transit through) the customer. If network administrators cannot build and generate filtering expressions to implement this, they SHOULD consider accepting only path lengths relevant to the type of customer they have (as in, if these customers are a leaf or have customers of their own) and SHOULD try to discourage excessive prepending in such paths. This loose policy could be combined with filters for specific 2-byte or 4-byte AS paths that must not be accepted if advertised by the customer, such as upstream transit providers or peer ASNs.
oネットワーク管理者は、顧客に属する（または通過を許可された）ASNを含む2バイトまたは4バイトのASパスのみを顧客から受け入れる必要があります（SHOULD）。ネットワーク管理者がこれを実装するためのフィルタリング式を作成および生成できない場合は、所有している顧客のタイプに関連するパス長のみを受け入れることを検討する必要があります（これらの顧客がリーフまたは独自の顧客である場合など）。そのようなパスで過度の前置。この緩やかなポリシーは、アップストリームのトランジットプロバイダーやピアASNなど、顧客がアドバタイズした場合に受け入れられない特定の2バイトまたは4バイトのASパスのフィルターと組み合わせることができます。
o Network administrators SHOULD NOT accept prefixes with private AS numbers in the AS path unless the prefixes are from customers. An exception could occur when an upstream is offering some particular service like black-hole origination based on a private AS number: in that case, prefixes SHOULD be accepted. Customers should be informed by their upstream in order to put in place ad hoc policy to use such services.
o ネットワーク管理者は、プレフィックスが顧客からのものでない限り、ASパスにプライベートAS番号を含むプレフィックスを受け入れるべきではありません（SHOULD NOT）。アップストリームがプライベートAS番号に基づくブラックホール発信などの特定のサービスを提供している場合、例外が発生する可能性があります。その場合、プレフィックスを受け入れる必要があります（SHOULD）。このようなサービスを使用するためのアドホックポリシーを導入するには、顧客にアップストリームから通知する必要があります。
o Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server.
o 透過的なASパス処理を備えたBGPルートサーバー[17]（たとえば、IXP上）に対してピアリングが行われない限り、ASパスの最初のAS番号がピアのものではない場合、ネットワーク管理者はプレフィックスを受け入れないでください。その場合、最初のAS番号がIXPメンバーの1つになるのに対し、ピアAS番号はBGPルートサーバーの1つになるため、この検証を無効にする必要があります。
o Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for these prefixes.
o ネットワーク管理者は、プレフィックスの通過を提供するつもりでない限り、空でないASパスでプレフィックスをアドバタイズすべきではありません（SHOULD NOT）。
o Network administrators SHOULD NOT advertise prefixes with upstream AS numbers in the AS path to their peering AS unless they intend to provide transit for these prefixes.
o ネットワーク管理者は、これらのプレフィックスの中継を提供するつもりでない限り、ピアリングASへのASパスにアップストリームAS番号を持つプレフィックスをアドバタイズしないでください。
o Private AS numbers are conventionally used in contexts that are "private" and SHOULD NOT be used in advertisements to BGP peers that are not party to such private arrangements, and they SHOULD be stripped when received from BGP peers that are not party to such private arrangements.
o プライベートAS番号は、通常、「プライベート」のコンテキストで使用され、そのようなプライベートな取り決めに関係のないBGPピアへのアドバタイズメントでは使用すべきではなく、そのようなプライベートな取り決めに関係のないBGPピアから受信されたときに削除する必要があります（SHOULD） 。
o Network administrators SHOULD NOT override BGP's default behavior, i.e., they should not accept their own AS number in the AS path. When considering an exception, the impact (which may be severe on routing) should be studied carefully.
o ネットワーク管理者は、BGPのデフォルトの動作をオーバーライドしてはなりません。つまり、ASパスで自分のAS番号を受け入れないようにする必要があります。例外を検討するときは、影響（ルーティングに重大な影響を与える可能性があります）を慎重に検討する必要があります。
AS path filtering should be further analyzed when ASN renumbering is done. Such an operation is common, and mechanisms exist to allow smooth ASN migration [28]. The usual migration technique, local to a router, consists in modifying the AS path so it is presented to a peer with the previous ASN, as if no renumbering was done. This makes it possible to change the ASN of a router without reconfiguring all EBGP peers at the same time (as that operation would require synchronization with all peers attached to that router). During this renumbering operation, the rules described above may be adjusted.
ASパスのフィルタリングは、ASN再番号付けが行われたときにさらに分析する必要があります。このような操作は一般的であり、スムーズなASN移行を可能にするメカニズムが存在します[28]。ルーターに対してローカルな通常の移行方法は、ASパスを変更することであり、再番号付けが行われていないかのように、以前のASNを持つピアに提示されます。これにより、すべてのEBGPピアを同時に再構成せずにルーターのASNを変更できます（その操作には、ルーターに接続されているすべてのピアとの同期が必要になるため）。この再番号付け操作中に、上記のルールを調整できます。
If peering on a shared network, like an IXP, BGP can advertise prefixes with a third-party next hop, thus directing packets not to the peer announcing the prefix but somewhere else.
IXPのような共有ネットワークでピアリングする場合、BGPはプレフィックスをサードパーティのネクストホップでアドバタイズすることができるため、パケットをピアにではなくプレフィックスを通知する他の場所に送信します。
This is a desirable property for BGP route-server setups [17], where the route server will relay routing information but has neither the capacity nor the desire to receive the actual data packets. So, the BGP route server will announce prefixes with a next-hop setting pointing to the router that originally announced the prefix to the route server.
これは、ルートサーバーがルーティング情報を中継しますが、実際のデータパケットを受信する容量も欲求もないBGPルートサーバーセットアップ[17]にとって望ましいプロパティです。したがって、BGPルートサーバーは、最初にルートサーバーにプレフィックスをアナウンスしたルーターを指すネクストホップ設定でプレフィックスをアナウンスします。
In direct peerings between ISPs, this is undesirable, as one of the peers could trick the other one into sending packets into a black hole (unreachable next hop) or to an unsuspecting third party who would then have to carry the traffic. Especially for black-holing, the root cause of the problem is hard to see without inspecting BGP prefixes at the receiving router of the IXP.
ISP間の直接ピアリングでは、これは望ましくありません。ピアの1つをだまして、パケットをブラックホール（到達不能なネクストホップ）に送信したり、トラフィックを運ばなければならない疑わしい第三者にパケットを送信したりする可能性があるためです。特にブラックホーリングの場合、問題の根本的な原因は、IXPの受信ルーターでBGPプレフィックスを検査しないとわかりません。
Therefore, an inbound route policy SHOULD be applied on IXP peerings in order to set the next hop for accepted prefixes to the BGP peer IP address (belonging to the IXP LAN) that sent the prefix (which is what "next-hop-self" would enforce on the sending side).
したがって、受け入れられたプレフィックスのネクストホップを、プレフィックスを送信したBGPピアIPアドレス（IXP LANに属する）に設定するために、インバウンドルートポリシーをIXPピアリングに適用する必要があります（これは "next-hop-self"です）。送信側に適用されます）。
This policy SHOULD NOT be used on route-server peerings or on peerings where network administrators intentionally permit the other side to send third-party next hops.
このポリシーは、ルートサーバーピアリングまたはネットワーク管理者が意図的に相手側にサードパーティのネクストホップの送信を許可しているピアリングでは使用しないでください。
This policy also SHOULD be adjusted if the best practice of Remote Triggered Black Holing (aka RTBH as described in RFC 6666 [13]) is implemented. In that case, network administrators would apply a well-known BGP next hop for routes they want to filter (if an Internet threat is observed from/to this route, for example). This well-known next hop will be statically routed to a null interface. In combination with a unicast RPF check, this will discard traffic from and toward this prefix. Peers can exchange information about black holes using, for example, particular BGP communities. Network administrators could propagate black-hole information to their peers using an agreed-upon BGP community: when receiving a route with that community, a configured policy could change the next hop in order to create the black hole.
このポリシーは、リモートトリガーブラックホリング（RFC 6666 [13]で説明されているRTBHとも呼ばれます）のベストプラクティスが実装されている場合にも調整する必要があります。その場合、ネットワーク管理者は、フィルタリングするルートに既知のBGPネクストホップを適用します（このルートから/へのインターネットの脅威が観察された場合など）。このよく知られたネクストホップは、ヌルインターフェイスに静的にルーティングされます。ユニキャストRPFチェックと組み合わせると、このプレフィックスからのトラフィックとこのプレフィックスへのトラフィックが破棄されます。ピアは、たとえば特定のBGPコミュニティを使用して、ブラックホールに関する情報を交換できます。ネットワーク管理者は、合意されたBGPコミュニティを使用して、ブラックホール情報をピアに伝播できます。そのコミュニティとのルートを受信すると、構成されたポリシーがブラックホールを作成するためにネクストホップを変更できます。
Optionally, we can consider the following rules on BGP AS paths:
オプションで、BGP ASパスに関する以下のルールを検討できます。
o Network administrators SHOULD scrub inbound communities with their number in the high-order bits, and allow only those communities that customers/peers can use as a signaling mechanism
o ネットワーク管理者は、インバウンドコミュニティを上位ビットの番号でスクラブし、顧客/ピアがシグナリングメカニズムとして使用できるコミュニティのみを許可する必要があります（SHOULD）。
o Networks administrators SHOULD NOT remove other communities applied on received routes (communities not removed after application of the previous statement). In particular, they SHOULD keep original communities when they apply a community. Customers might need them to communicate with upstream providers. In particular, network administrators SHOULD NOT (generally) remove the no-export community, as it is usually announced by their peer for a certain purpose.
o ネットワーク管理者は、受信したルートに適用された他のコミュニティを削除してはなりません（前のステートメントの適用後に削除されなかったコミュニティ）。特に、コミュニティを適用するときは、元のコミュニティを維持する必要があります。顧客は上流のプロバイダーと通信するためにそれらを必要とするかもしれません。特に、ネットワーク管理者は、通常、特定の目的のためにピアによって発表されるため、（一般に）非エクスポートコミュニティを削除しないでください（SHOULD NOT）。
This document is entirely about BGP operational security. It depicts best practices that one should adopt to secure BGP infrastructure: protecting BGP router and BGP sessions, adopting consistent BGP prefix and AS path filters, and configuring other options to secure the BGP network.
このドキュメントは、完全にBGPの運用セキュリティに関するものです。これは、BGPインフラストラクチャを保護するために採用すべきベストプラクティスを示しています。BGPルーターとBGPセッションの保護、一貫したBGPプレフィックスとASパスフィルターの採用、およびBGPネットワークを保護するための他のオプションの構成です。
This document does not aim to describe existing BGP implementations, their potential vulnerabilities, or ways they handle errors. It does not detail how protection could be enforced against attack techniques using crafted packets.
このドキュメントは、既存のBGP実装、それらの潜在的な脆弱性、またはエラーの処理方法を説明することを目的としていません。巧妙に細工されたパケットを使用した攻撃手法に対して保護を実施する方法については詳しく説明していません。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[2] Rekhter,, Y., Li,, T., and S. Hares,, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[2] Rekhter、Y、Li、T、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月、<http://www.rfc-editor.org/ info / rfc4271>。
[3] Gill, V., Heasley, J., Meyer, D., Savola,, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[3] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月、<http：// www。 rfc-editor.org/info/rfc5082>。
[4] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[4] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月、<http://www.rfc-editor.org/info/rfc5925>。
[5] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013, <http://www.rfc-editor.org/info/rfc6811>.
[5] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、2013年1月、<http://www.rfc-editor.org / info / rfc6811>。
[6] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, May 2014, <http://www.rfc-editor.org/info/rfc7196>.
[6] Pelsser、C.、Bush、R.、Patel、K.、Mohapatra、P。、およびO. Maennel、「Making Route Flap Damping Usable」、RFC 7196、2014年5月、<http：//www.rfc-editor。 org / info / rfc7196>。
[7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998, <http://www.rfc-editor.org/info/rfc2385>.
[7] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月、<http://www.rfc-editor.org/info/rfc2385>。
[8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[8] ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の打破」、RFC 2827、2000年5月、<http://www.rfc-editor.org/info/rfc2827> 。
[9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[9] ベイカー、F。、およびP.サボラ、「マルチホームネットワークのイングレスフィルタリング」、RFC 3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704>。
[10] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005, <http://www.rfc-editor.org/info/rfc4012>.
[10] Blunk、L.、Damas、J.、Parent、F.、and A. Robachevsky、 "Routing Policy Specification Language next generation（RPSLng）"、RFC 4012、March 2005、<http://www.rfc-editor.org / info / rfc4012>。
[11] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>.
[11] Dugal、D.、Pignataro、C。、およびR. Dunn、「Protecting the Router Control Plane」、RFC 6192、2011年3月、<http://www.rfc-editor.org/info/rfc6192>。
[12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[12] Lepinski、M.およびS. Kent、「An Internet to Support Secure Internet Routing」、RFC 6480、2012年2月、<http://www.rfc-editor.org/info/rfc6480>。
[13] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC 6666, August 2012, <http://www.rfc-editor.org/info/rfc6666>.
[13] Hilliard、N.およびD. Freedman、「A Discard Prefix for IPv6」、RFC 6666、2012年8月、<http://www.rfc-editor.org/info/rfc6666>。
[14] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[14] Jethanandani、M.、Patel、K。、およびL. Zheng、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるBGP、LDP、PCEP、およびMSDPの問題の分析」、RFC 6952、2013年5月、< http://www.rfc-editor.org/info/rfc6952>。
[15] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", RFC 7115, January 2014, <http://www.rfc-editor.org/info/rfc7115>.
[15] Bush、R。、「Resource Public Key Infrastructure（RPKI）に基づく元の検証操作」、RFC 7115、2014年1月、<http://www.rfc-editor.org/info/rfc7115>。
[16] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014, <http://www.rfc-editor.org/info/rfc7132>.
[16] Kent、S。およびA. Chi、「BGPパスセキュリティの脅威モデル」、RFC 7132、2014年2月、<http://www.rfc-editor.org/info/rfc7132>。
[17] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange Route Server", Work in Progress, draft-ietf-idr-ix-bgp-route-server-06, December 2014.
[17] Jasinska、E.、Hilliard、N.、Raszuk、R。、およびN. Bakker、「Internet Exchange Route Server」、Work in Progress、draft-ietf-idr-ix-bgp-route-server-06、2014年12月。
[18] Karrenberg, D., "RIPE-351 - De-Bogonising New Address Blocks", October 2005.
[18] Karrenberg、D。、「RIPE-351-De-Bogonising New Address Blocks」、2005年10月。
[19] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group Recommendations On Route-flap Damping", May 2006.
[19] スミス、P。およびC.パニグル、「RIPE-378-ルートフラップダンピングに関するRIPEルーティングワーキンググループの推奨事項」、2006年5月。
[20] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation", December 2006.
[20] Smith、P.、Evans、R。、およびM. Hughes、「RIPE-399-ルート集約に関するRIPEルーティングワーキンググループの推奨事項」、2006年12月。
[21] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation", November 2011.
[21] Smith、P。およびR. Evans、「RIPE-532-IPv6 Route Aggregationに関するRIPEルーティングワーキンググループの推奨事項」、2011年11月。
[22] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE Routing Working Group Recommendations On Route-flap Damping", January 2013.
[22] Smith、P.、Bush、R.、Kuhne、M.、Pelsser、C.、Maennel、O.、Patel、K.、Mohapatra、P。、およびR. Evans、「RIPE-580-RIPE Routing Working Group Recommendationsルートフラップダンピングについて」、2013年1月。
[23] IANA, "IANA IPv4 Special-Purpose Address Registry", <http://www.iana.org/assignments/iana-ipv4-special-registry>.
[23] IANA、「IANA IPv4 Special-Purpose Address Registry」、<http://www.iana.org/assignments/iana-ipv4-special-registry>。
[24] IANA, "IANA IPv6 Special-Purpose Address Registry", <http://www.iana.org/assignments/iana-ipv6-special-registry>.
[24] IANA、「IANA IPv6 Special-Purpose Address Registry」、<http://www.iana.org/assignments/iana-ipv6-special-registry>。
[25] IANA, "IANA IPv4 Address Space Registry", <http://www.iana.org/assignments/ipv4-address-space>.
[25] IANA、「IANA IPv4 Address Space Registry」、<http://www.iana.org/assignments/ipv4-address-space>。
[26] IANA, "Internet Protocol Version 6 Address Space", <http://www.iana.org/assignments/ipv6-address-space>.
[26] IANA、「インターネットプロトコルバージョン6アドレススペース」、<http://www.iana.org/assignments/ipv6-address-space>。
[27] Merit Network Inc., "Merit RADb", <http://www.radb.net>.
[27] Merit Network Inc。、「Merit RADb」、<http://www.radb.net>。
[28] George, W. and S. Amante, "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Work in Progress, draft-ga-idr-as-migration-03, January 2014.
[28] ジョージW.およびS.アマンテ、「自律システム（AS）移行機能とBGP AS_PATH属性への影響」、進行中の作業、draft-ga-idr-as-migration-03、2014年1月。
[29] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, August 2014, <http://www.rfc-editor.org/info/rfc7353>.
[29] Bellovin、S.、Bush、R。、およびD. Ward、「BGPパス検証のセキュリティ要件」、RFC 7353、2014年8月、<http://www.rfc-editor.org/info/rfc7353>。
[30] "IRRToolSet project page", <http://irrtoolset.isc.org>.
[30] 「IRRToolSetプロジェクトページ」、<http://irrtoolset.isc.org>。
[31] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. Goldberg, "On the Risk of Misbehaving RPKI Authorities", <http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>.
[31] クーパー、D。、ハイルマン、E。、ブローグル、K。、レイジン、L。、およびS.ゴールドバーグ、「RPKI当局の不正行為のリスクについて」、<http://www.cs.bu.edu/~goldbe /papers/hotRPKI.pdf>。
An IXP in the RIPE region is allocated an IPv4 /22 prefix by RIPE NCC (X.Y.0.0/22 in this example) and uses a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP LAN prefix is the one used by IXP members to configure EBGP peerings. The IXP could also be allocated an AS number (AS64496 in our example).
RIPE領域のIXPには、RIPE NCC（この例ではX.Y.0.0 / 22）によってIPv4 / 22プレフィックスが割り当てられ、この/ 22の/ 23をIXP LANに使用します（X.Y.0.0 / 23としましょう）。このIXP LANプレフィックスは、EBGPピアリングを構成するためにIXPメンバーによって使用されるものです。 IXPにはAS番号を割り当てることもできます（この例ではAS64496）。
Any IXP member SHOULD make sure it filters prefixes more specific than X.Y.0.0/23 from all its EBGP peers. If it received X.Y.0.0/24 or X.Y.1.0/24 this could seriously impact its routing.
IXPメンバーは、すべてのEBGPピアからX.Y.0.0 / 23よりも具体的なプレフィックスをフィルタリングする必要があります（SHOULD）。 X.Y.0.0 / 24またはX.Y.1.0 / 24を受け取った場合、ルーティングに深刻な影響を与える可能性があります。
The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members through an EBGP peering (most likely from its BGP route servers, configured with AS64496).
IXPはX.Y.0.0 / 22を発信し、EBGPピアリングを介してそのメンバーにアドバタイズする必要があります（ほとんどの場合、AS64496で構成されたBGPルートサーバーから）。
The IXP members SHOULD accept the IXP prefix only if it passes the IRR generated filters (see Section 6.1.2.2.1)
IXPメンバーは、IRPで生成されたフィルターを通過する場合にのみ、IXPプレフィックスを受け入れる必要があります（セクション6.1.2.2.1を参照）。
IXP members SHOULD then advertise X.Y.0.0/22 prefix to their downstreams. This announce would pass IRR based filters as it is originated by the IXP.
IXPメンバーは、ダウンストリームにX.Y.0.0 / 22プレフィックスをアドバタイズする必要があります（SHOULD）。このアナウンスはIXPによって発信されたため、IRRベースのフィルターを通過します。
Acknowledgements
謝辞
The authors would like to thank the following people for their comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, and Matsuzaki Yoshinobu.
著者は、コメントとサポートを提供してくれた次の人々に感謝します：マークブランシェ、ロンボニカ、ランディブッシュ、デビッドフリードマン、ウェスリージョージ、ダニエルギンズバーグ、デビッドグローブ、マイクヒューグ、ジョエルジャグリ、ティムクリーファス、ウォーレンクマリ、ジャックラトゥール、ライオネル・モランド、ジェローム・ニコル、ハーゲン・ポール・ファイファー、トーマス・ピノー、カルロス・ピニャタロ、ジャン・レビフ、ドナルド・スミス、コティカラプディ・スリラム、マチャズ・シュトラウス、トニー・タウバー、ギュンター・ヴァン・デ・ヴェルデ、セバスチャン・ヴィージンガー、そして松崎吉信。
The authors would like to thank once again Gunter Van de Velde for presenting the document at several IETF meetings in various working groups, indeed helping dissemination of this document and gathering of precious feedback.
著者は、様々なワーキンググループのいくつかのIETFミーティングでこのドキュメントを発表してくれたこと、そしてこのドキュメントの普及と貴重なフィードバックの収集に本当に貢献してくれたGunter Van de Veldeに改めて感謝したいと思います。
Authors' Addresses
著者のアドレス
Jerome Durand Cisco Systems, Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX France
Jerome Durand Cisco Systems、Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX France
EMail: jerduran@cisco.com
Ivan Pepelnjak NIL Data Communications Tivolska 48 Ljubljana 1000 Slovenia
Ivan Pepelnjak NIL Data Communications Tivolska 48 Ljubljana 1000スロベニア
EMail: ip@ipspace.net
Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen D-80807 Germany
Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14ミュンヘンD-80807ドイツ
EMail: gert@space.net