[要約] RFC 7789は、BGPフィルタリングがインタードメインルーティングポリシーに与える影響についての要約です。その目的は、BGPフィルタリングの実践とその影響を理解し、インタードメインルーティングポリシーの改善に役立てることです。
Internet Engineering Task Force (IETF) C. Cardona
Request for Comments: 7789 IMDEA Networks/UC3M
Category: Informational P. Francois
ISSN: 2070-1721 P. Lucente
Cisco Systems
April 2016
Impact of BGP Filtering on Inter-Domain Routing Policies
ドメイン間ルーティングポリシーに対するBGPフィルタリングの影響
Abstract
概要
This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it.
このドキュメントでは、他の自律システムがより具体的なプレフィックスの伝播をフィルタリングまたは制限した結果、自律システム全体に予期しないトラフィックフローが発生する可能性について説明します。この問題の発生を検出して防御するための手法のレビューを提供します。
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/rfc7789.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7789で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
2.1. Local Filtering . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of
More-Specific Prefixes . . . . . . . . . . . . . . . 5
2.2. Remote Filtering . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered
Filtering of More-Specific Prefixes . . . . . . . . . 7
3. Techniques to Detect Unexpected Traffic Flows Caused by
Filtering of More-Specific Prefixes . . . . . . . . . . . . . 8
3.1. Existence of Unexpected Traffic Flows within an AS . . . 8
3.2. Contribution to the Existence of Unexpected Traffic Flows
in Another AS . . . . . . . . . . . . . . . . . . . . . . 9
4. Techniques to Traffic Engineer Unexpected Flows . . . . . . . 10
4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
4.2. Proactive Measures . . . . . . . . . . . . . . . . . . . 12
4.2.1. Access Lists . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Neighbor-Specific Forwarding . . . . . . . . . . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
It is common practice for network operators to propagate a more-specific prefix in the BGP routing system along with the less-specific prefix that they originate. It is also possible for some Autonomous Systems (ASes) to apply different policies to the more specific and the less-specific prefix.
ネットワークオペレーターが、BGPルーティングシステムでより固有性の高いプレフィックスを、それらが発信する固有性の低いプレフィックスと共に伝搬することは一般的な慣例です。一部の自律システム（AS）は、より具体的なプレフィックスとそれほど具体的でないプレフィックスに異なるポリシーを適用することもできます。
Although BGP makes independent, policy-driven decisions for the selection of the best path to be used for a given IP prefix, routers must forward packets using the longest-prefix-match rule, which "precedes" any BGP policy [RFC1812]. The existence of a prefix p that is more specific than a prefix p' in the Forwarding Information Base (FIB) will let packets whose destination matches p be forwarded according to the next hop selected as best for p (the more-specific prefix). This process takes place by disregarding the policies applied in the control plane for the selection of the best next hop for p'. When an AS filters more-specific prefixes and forwards packets according to the less-specific prefix, the discrepancy among the routing policies applied to the less and the more-specific prefixes can create unexpected traffic flows. These may infringe on the policies of other ASes still holding a path towards the more-specific prefix.
BGPは、特定のIPプレフィックスに使用する最適なパスを選択するための独立したポリシー主導の決定を行いますが、ルーターは、BGPポリシー[RFC1812]に「先行する」最長プレフィックス一致ルールを使用してパケットを転送する必要があります。 Forwarding Information Base（FIB）のプレフィックスp 'よりも特定性の高いプレフィックスpが存在する場合、宛先がpと一致するパケットは、pに最適なものとして選択されたネクストホップ（より具体的なプレフィックス）に従って転送されます。このプロセスは、p 'に最適なネクストホップを選択するためにコントロールプレーンで適用されるポリシーを無視することによって行われます。 ASがより具体的なプレフィックスをフィルタリングし、より具体的でないプレフィックスに従ってパケットを転送する場合、より具体的ではないプレフィックスに適用されるルーティングポリシー間の不一致により、予期しないトラフィックフローが作成される可能性があります。これらは、より具体的なプレフィックスへのパスをまだ保持している他のASのポリシーに違反する可能性があります。
The objective of this document is to shed light on possible side effects associated with more-specific prefix filtering. Such actions can be explained by traffic engineering action, misconfiguration, or malicious intent. This document presents examples of such side effects and discusses approaches towards solutions to the problem.
このドキュメントの目的は、より具体的なプレフィックスフィルタリングに関連する可能性のある副作用を明らかにすることです。このようなアクションは、トラフィックエンジニアリングアクション、設定ミス、または悪意によって説明できます。このドキュメントでは、そのような副作用の例を示し、問題の解決に向けたアプローチについて説明します。
The rest of the document is organized as follows: in Section 2 we provide some scenarios in which the filtering of more-specific prefixes leads to the creation of unexpected traffic flows; Section 3 and Section 4 discuss some techniques that ASes can use for, respectively, detecting and reacting to unexpected traffic flows; and the document concludes in Section 5.
ドキュメントの残りの部分は次のように構成されています。セクション2では、より具体的なプレフィックスのフィルタリングが予期しないトラフィックフローの作成につながるいくつかのシナリオを示します。セクション3とセクション4では、ASがそれぞれ予期しないトラフィックフローの検出と対応に使用できるいくつかの手法について説明します。そして、ドキュメントはセクション5で終わります。
More-specific prefix: A prefix in the routing table with an address range that is covered by a shorter prefix also present in the routing table.
より具体的なプレフィックス：ルーティングテーブルに存在する短いプレフィックスでカバーされるアドレス範囲を持つルーティングテーブルのプレフィックス。
Less-specific prefix: A prefix in the routing table with an address range partially covered by other prefixes.
より限定的でないプレフィックス：アドレス範囲が他のプレフィックスで部分的にカバーされているルーティングテーブル内のプレフィックス。
Customer-provider peering: A peering arrangement in which a transit network provides connectivity to a customer in exchange of a fee, as derived from RFC 4384 [RFC4384].
顧客プロバイダーピアリング：RFC 4384 [RFC4384]から派生した、トランジットネットワークが料金と引き換えに顧客への接続を提供するピアリング配置。
Settlement-free peering: A peering arrangement in which two networks agree on a settlement-free traffic exchange, typically covering only their customer traffic, as derived from RFC 4384 [RFC4384].
決済なしのピアリング：RFC 4384 [RFC4384]から派生した、通常は顧客のトラフィックのみをカバーする、決済なしのトラフィック交換に2つのネットワークが同意するピアリングの配置。
Selective advertisement: The behavior of only advertising a self originated BGP path for a prefix over a strict subset of the External BGP (eBGP) sessions of the AS.
選択的アドバタイズメント：ASの外部BGP（eBGP）セッションの厳密なサブセットを介したプレフィックスの自己発信BGPパスのみをアドバタイズする動作。
Selective propagation: The behavior of only propagating a BGP path for a prefix over a strict subset of the eBGP sessions of an AS.
選択的伝播：ASのeBGPセッションの厳密なサブセットを介して、プレフィックスのBGPパスのみを伝播する動作。
Local filtering: The behavior of explicitly ignoring a BGP path received over an eBGP session.
ローカルフィルタリング：eBGPセッションで受信したBGPパスを明示的に無視する動作。
Remote filtering: The behavior of triggering selective propagation of a BGP path at a distant AS. Note that this is typically achieved by tagging a self-originated path with BGP communities defined by the distant AS.
リモートフィルタリング：離れたASでBGPパスの選択的な伝播をトリガーする動作。これは通常、遠隔のASによって定義されたBGPコミュニティを使用して自己発信パスにタグを付けることによって達成されることに注意してください。
Unexpected traffic flow: Traffic flowing between two neighboring ASes of an AS, although the transit policy of that AS is to not provide connectivity between these two neighbors. A traffic flow across an AS between two of its transit providers or between a transit provider and one of its settlement-free peers are classic examples of unexpected traffic flows.
予期しないトラフィックフロー：ASの2つの隣接するAS間を流れるトラフィック。ただし、そのASのトランジットポリシーは、これら2つのネイバー間の接続を提供しないことです。 2つのトランジットプロバイダー間、またはトランジットプロバイダーとその決済フリーピアの1つとの間のAS間のトラフィックフローは、予期しないトラフィックフローの典型的な例です。
In this section, we describe how more-specific prefix filtering can lead to unexpected traffic flows in other, remote, ASes. We differentiate cases in which the filtering is performed locally from those where the filtering is triggered remotely.
このセクションでは、より具体的なプレフィックスフィルタリングによって、他のリモートASで予期しないトラフィックフローが発生する可能性について説明します。フィルタリングがローカルで実行される場合と、フィルタリングがリモートでトリガーされる場合とを区別します。
Different reasons motivate local filtering, for example:
たとえば、次のようなさまざまな理由により、ローカルフィルタリングが行われます。
Traffic engineering: An ISP can decide to filter more-specific prefixes when it wants to control their local outbound traffic distribution using only the policy applied to the less-specific prefix. Such a practice was notably documented in a presentation by Init7 [INIT7-RIPE63].
トラフィックエンジニアリング：ISPは、特定性の低いプレフィックスに適用されたポリシーのみを使用してローカルの発信トラフィック分散を制御する必要がある場合、特定性の高いプレフィックスをフィルタリングすることを決定できます。このような慣行は、特にInit7 [INIT7-RIPE63]によるプレゼンテーションで文書化されました。
Enforcing contract compliance: An ISP can decide to filter more-specific prefixes to enforce clauses of their peering agreements. For instance, a settlement-free peer of an ISP can use selective advertisement of more-specific prefixes to attract traffic to one link. If this practice is not allowed by their peering agreement, the ISP can filter the more-specific prefixes to prevent it.
契約コンプライアンスの実施：ISPは、より具体的なプレフィックスをフィルタリングして、ピアリング契約の条項を実施することを決定できます。たとえば、ISPの和解のないピアは、より具体的なプレフィックスの選択的アドバタイズメントを使用して、1つのリンクにトラフィックを引き付けることができます。この慣行がピアリング契約で許可されていない場合、ISPは、より具体的なプレフィックスをフィルターして防止します。
Memory preservation: An ISP can decide to filter more-specific prefixes in order to preserve FIB memory of their routers.
メモリの保持：ISPは、ルーターのFIBメモリを保持するために、より具体的なプレフィックスをフィルタリングすることを決定できます。
Figure 1 illustrates a scenario where one AS performs local filtering due to outbound traffic engineering. The figure depicts AS64504 and two of its neighboring ASes, AS64502 and AS64505. AS64504 has a settlement-free peering with AS64502 and is a customer of AS64505. AS64504 receives from AS64505 prefixes 2001:DB8::/32 and 2001:DB8::/34. AS64504 only receives the less-specific prefix 2001:DB8::/32 from AS64502.
図1は、アウトバウンドトラフィックエンジニアリングのために1つのASがローカルフィルタリングを実行するシナリオを示しています。この図は、AS64504およびその隣接ASの2つであるAS64502とAS64505を示しています。 AS64504には、AS64502との和解のないピアリングがあり、AS64505の顧客です。 AS64504は、AS64505プレフィックス2001：DB8 :: / 32および2001：DB8 :: / 34から受信します。 AS64504は、AS64502からあまり限定的でないプレフィックス2001：DB8 :: / 32のみを受け取ります。
,-----.
/ \
( AS64505 )
\ /
`--+--'
2001:DB8::/32 | |
2001:DB8::/34 v |
|
,--+--. 2001:DB8::/32 ,-----.
/ \ <-- / \
( AS64504 )-------------( AS64502 )
\ / \ /
`-----' `-----'
Figure 1: Local Filtering
図1：ローカルフィルタリング
Due to economic reasons, AS64504 might prefer to send traffic to AS64502 instead of AS64505. However, even if paths received from AS64502 are given a large local preference, routers in AS64504 will still send traffic to prefix 2001:DB8::/34 via neighbor AS64505. This situation may push AS64504 to apply an inbound filter for the more-specific prefix, 2001:DB8::/34, on the session with AS64505. After applying the filter, AS64504 will send traffic for the more-specific prefix to AS64502.
経済的な理由により、AS64504はAS64505ではなくAS64502にトラフィックを送信することを好むかもしれません。ただし、AS64502から受信したパスに大きなローカルプリファレンスが与えられている場合でも、AS64504のルーターは、ネイバーAS64505を介してトラフィックをプレフィックス2001：DB8 :: / 34に送信します。この状況により、AS64504をプッシュして、AS64505とのセッションで、より具体的なプレフィックス2001：DB8 :: / 34のインバウンドフィルターを適用できます。フィルターを適用した後、AS64504はより具体的なプレフィックスのトラフィックをAS64502に送信します。
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of More-Specific Prefixes
2.1.1. より具体的なプレフィックスのローカルフィルタリングによって引き起こされる予期しないトラフィックフロー
In this section, we show how the decision of AS64504 to perform local filtering creates unexpected traffic flows in AS64502. Figure 2 shows the whole picture of the scenario where AS64501 is a customer of AS64503 and AS64502. AS64503 is a settlement-free peer with AS64502. AS64503 and AS64502 are customers of AS64505. The AS originating the two prefixes, AS64501, performs selective advertisement with the more-specific prefix and only announces it to AS64503.
このセクションでは、ローカルフィルタリングを実行するAS64504の決定が、AS64502で予期しないトラフィックフローを作成する方法を示します。図2は、AS64501がAS64503およびAS64502の顧客であるシナリオの全体像を示しています。 AS64503は、AS64502との和解のないピアです。 AS64503およびAS64502は、AS64505の顧客です。 2つのプレフィックスAS64501を発信するASは、より具体的なプレフィックスを使用して選択的なアドバタイズを実行し、それをAS64503に通知するだけです。
After AS64504 locally filters the more-specific prefix, traffic from AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502. Because AS64502 receives the more-specific prefix from AS64503, traffic from AS64504 to 2001:DB8::/34 follows the path AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are implemented to avoid transporting traffic between AS64504 and AS64503. However, due to the discrepancies of routes between the more and the less-specific prefixes, unexpected traffic flows between AS64504 and AS64503 exist in AS64502's network.
AS64504がより具体的なプレフィックスをローカルでフィルタリングした後、AS64504からプレフィックス2001：DB8 :: / 34へのトラフィックはAS64502に転送されます。 AS64502はAS64503からより具体的なプレフィックスを受信するため、AS64504から2001：DB8 :: / 34へのトラフィックはパスAS64504-AS64502-AS64503-AS64501に従います。 AS64502のBGPポリシーは、AS64504とAS64503の間のトラフィックの転送を回避するために実装されています。ただし、特定度の高いプレフィックスとあまり具体的でないプレフィックスの間のルートの不一致のため、AS64504とAS64503の間の予期しないトラフィックフローがAS64502のネットワークに存在します。
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| |________| |
| | /32 | |/32 /32| |
'. ,' . ,' /34 . ,'
`. ,' `. ,' +-> <-+ `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 2: Unexpected Traffic Flows Due to Local Filtering
図2：ローカルフィルタリングによる予期しないトラフィックフロー
ISPs can tag the BGP paths that they propagate to neighboring ASes with communities in order to tweak the propagation behavior of the ASes that handle these paths; see a paper from 2008 by Donnet and Bonaventure [on_BGP_communities]. Some ISPs allow their customers to use such communities to let the receiving AS not export the path to some selected neighboring ASes. By combining communities, the prefix could be advertised only to a given peer of the AS providing this feature. A network operator can leverage remote filtering to, for instance, limit the scope of prefixes and hence perform more granular inbound traffic engineering.
ISPは、隣接するASに伝播するBGPパスにコミュニティをタグ付けして、これらのパスを処理するASの伝播動作を微調整することができます。 DonnetとBonaventureによる2008年の論文[on_BGP_communities]を参照してください。一部のISPは、顧客がそのようなコミュニティを使用して、受信側のASが一部の選択された隣接ASへのパスをエクスポートしないようにすることができます。コミュニティを組み合わせると、この機能を提供するASの特定のピアにのみプレフィックスをアドバタイズできます。ネットワークオペレーターは、リモートフィルタリングを利用して、たとえば、プレフィックスのスコープを制限し、より詳細なインバウンドトラフィックエンジニアリングを実行できます。
Figure 3 illustrates a scenario in which an AS uses BGP communities to command its provider to selectively propagate a more-specific prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501 originates prefix 2001:DB8::/32, which it advertises to AS64502 and AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501 do selective advertisement and only propagate 2001:DB8::/34 over AS64503. AS64503 would normally propagate this prefix to its customers, providers, and peers, including AS64502.
図3は、ASがBGPコミュニティを使用して、より具体的なプレフィックスを選択的に伝播するようにプロバイダーに命令するシナリオを示しています。 AS64501をAS64502およびAS64503の顧客とします。 AS64501は、プレフィックス2001：DB8 :: / 32から始まり、AS64502およびAS64503にアドバタイズします。 AS64502とAS64503は、決済のないピアです。 AS64501に選択的なアドバタイズを実行させ、AS：64503を介して2001：DB8 :: / 34のみを伝播させます。 AS64503は、通常、このプレフィックスをその顧客、プロバイダー、およびピア（AS64502を含む）に伝達します。
Let us consider that AS64501 decides to limit the scope of the more-specific prefix. AS64501 can make this decision based on its traffic engineering strategy. To achieve this, AS64501 can tag the more-specific prefix with a set of communities that leads AS64503 to only propagate the path to AS64502.
AS64501がより具体的なプレフィックスのスコープを制限することを決定したと考えてみましょう。 AS64501は、トラフィックエンジニアリング戦略に基づいてこの決定を行うことができます。これを達成するために、AS64501は、AS64503がAS64502へのパスのみを伝播するように導く一連のコミュニティで、より具体的なプレフィックスにタグを付けることができます。
^ \ / ^ ^ \ / ^
| /32 \ / /32 | | /32 \ / /32 |
,-----. ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' -> /34 `. ,'
'-----; <- / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +-- / AS64501 \ --+
( )
\ /
`. ,'
'-----'
Figure 3: Remote-Triggered Filtering
図3：リモートトリガーフィルタリング
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered Filtering of More-Specific Prefixes
2.2.1. より特定されたプレフィックスのフィルタリングをリモートでトリガーすることによって引き起こされる予期しないトラフィックフロー
Figure 4 expands the scenario from Figure 3 and includes other ASes peering with AS64502 and AS64503. Due to the limitation on the scope performed on the more-specific prefix, ASes that are not customers of AS64502 will not receive a path for 2001:DB8::/34. These ASes will forward packets destined to 2001:DB8::/34 according to their routing state for 2001:DB8::/32. Let us assume that AS64505 is such an AS and that its best path towards 2001:DB8::/32 is through AS64502.
図4は、図3のシナリオを拡張したもので、AS64502およびAS64503とピアリングする他のASが含まれています。より具体的なプレフィックスで実行されるスコープの制限により、AS64502の顧客ではないASは2001：DB8 :: / 34のパスを受け取りません。これらのASは、2001：DB8 :: / 32のルーティング状態に従って、2001：DB8 :: / 34宛てのパケットを転送します。 AS64505がそのようなASであり、2001：DB8 :: / 32への最良のパスがAS64502を経由するとします。
Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. However, in the data plane of the nodes of AS64502, the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached through AS64503, a settlement-free peer of AS64502. Since AS64505 is not in the customer branch of AS64502, traffic flows between two noncustomer ASes in AS64502.
AS64505によって2001：DB8 :: 1に送信されたパケットは、AS64502に到達します。ただし、AS64502のノードのデータプレーンでは、2001：DB8 :: 1の最長プレフィックス一致は2001：DB8 :: / 34であり、AS64502の決済のないピアであるAS64503を介して到達します。 AS64505はAS64502のカスタマーブランチにないため、AS64502の2つの非カスタマーAS間でトラフィックが流れます。
,-----.
,' `.
/ AS64505 \
( )
\ /
,`. ,' \
/ '-----' \
/ ^ ^ \
/32 | | /32 '
,-----.' + + ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' +-> /34 `. ,'
'-----; <-+ / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +--+ / AS64501 \ +--+
( )
\ /
`. ,'
'-----'
Figure 4: Unexpected Traffic Flows Due to Remote-Triggered Filtering
図4：リモートトリガーフィルタリングによる予期しないトラフィックフロー
3. Techniques to Detect Unexpected Traffic Flows Caused by Filtering of More-Specific Prefixes
3. より具体的なプレフィックスのフィルタリングによって引き起こされる予期しないトラフィックフローを検出する手法
To detect if unexpected traffic flows are taking place in its network, an ISP can monitor its traffic data to check if it is providing transit between two of its peers, although its policy is configured to not provide such transit. IPFIX [RFC7011] is an example of a technology that can be used to export information regarding traffic flows across the network. Traffic information must be analyzed under the perspective of the business relationships with neighboring ASes to detect the flows not fitting the policy. Operators can use collection systems that combine traffic statistics with policy information for this end. See the pmacct project [PMACCT] for an open-source application meeting these requirements.
ネットワークで予期しないトラフィックフローが発生しているかどうかを検出するために、ISPはトラフィックデータを監視して、2つのピア間でトランジットを提供しているかどうかを確認できます。 IPFIX [RFC7011]は、ネットワーク全体のトラフィックフローに関する情報をエクスポートするために使用できるテクノロジーの例です。トラフィック情報は、隣接するASとのビジネス関係の観点から分析して、ポリシーに適合しないフローを検出する必要があります。事業者は、この目的のために、トラフィック統計とポリシー情報を組み合わせる収集システムを使用できます。これらの要件を満たすオープンソースアプリケーションについては、pmacctプロジェクト[PMACCT]を参照してください。
Note that the AS detecting the unexpected traffic flow may simply realize that its policy configuration is broken. The first recommended action upon detection of an unexpected traffic flow is to verify the correctness of the BGP configuration.
ASが予期しないトラフィックフローを検出すると、そのポリシー設定が壊れていることに気付く場合があります。予期しないトラフィックフローを検出したときに最初に推奨されるアクションは、BGP構成の正確さを確認することです。
Once the local configuration is confirmed correct, the operator should check if the unexpected flow arose due to filtering of BGP paths for more-specific prefixes by neighboring ASes. This can be performed in two steps. First, the operator should check whether the neighboring AS originating the unexpected flow is forwarding traffic using a less-specific prefix that is announced to it by the affected network. The second step is to try to infer the reason why the neighboring AS does not use the more-specific path for forwarding, i.e., finding why the more-specific prefix was filtered. Due to the distributed nature and restricted visibility of the steering of BGP policies, this second step does not identify the origin of the problem with guaranteed accuracy.
ローカル設定が正しいことが確認されたら、隣接するASによるより具体的なプレフィックスのBGPパスのフィルタリングが原因で予期しないフローが発生したかどうかをオペレータが確認する必要があります。これは2つのステップで実行できます。最初に、オペレーターは、予期しないフローを発信している隣接ASが、影響を受けるネットワークによってアナウンスされる特定性の低いプレフィックスを使用してトラフィックを転送しているかどうかを確認する必要があります。 2番目のステップは、隣接ASが転送に特定のパスを使用しない理由を推測することです。つまり、特定のプレフィックスがフィルタリングされた理由を見つけます。 BGPポリシーのステアリングの分散された性質と制限された可視性のため、この2番目のステップは、保証された精度で問題の原因を特定しません。
For the first step, the operator should check if the destination address of the unexpected traffic flow is locally routed as per a more-specific prefix only received from noncustomer peers. The operator should also check if there are paths to a less-specific prefix received from a customer and hence propagated to peers. If these two situations happen at the same time, the neighboring AS at the entry point of the unexpected flow is routing the traffic based on the less-specific prefix, although the ISP is actually forwarding the traffic via noncustomer links.
最初のステップとして、オペレーターは、予期しないトラフィックフローの宛先アドレスが、非顧客のピアからのみ受信されたより具体的なプレフィックスに従ってローカルにルーティングされているかどうかを確認する必要があります。オペレーターはまた、顧客から受信した、具体的にはピアに伝播される、それほど具体的でないプレフィックスへのパスがあるかどうかを確認する必要があります。これら2つの状況が同時に発生した場合、ISPは実際には非カスタマーリンクを介してトラフィックを転送していますが、予期しないフローのエントリポイントにある隣接ASは、あまり具体的でないプレフィックスに基づいてトラフィックをルーティングしています。
For the second step, one can rely on human interaction or looking glasses to find out whether local filtering, remote filtering, or selective propagation was performed on the more-specific prefix. No openly available tools that can automatically perform this operation have been identified.
2番目のステップでは、人間の操作またはメガネを使用して、ローカルフィルタリング、リモートフィルタリング、または選択的伝播がより具体的なプレフィックスで実行されたかどうかを確認できます。この操作を自動的に実行できる公開されているツールは確認されていません。
3.2. Contribution to the Existence of Unexpected Traffic Flows in Another AS
3.2. 別のASでの予期しないトラフィックフローの存在への寄与
It can be considered problematic to trigger unexpected traffic flows in another AS. It is thus advisable for an AS to assess the risks of filtering more-specific prefixes before implementing them by obtaining as much information as possible about its surrounding routing environment.
別のASで予期しないトラフィックフローをトリガーすることは問題があると考えることができます。したがって、ASは、周囲のルーティング環境に関する可能な限り多くの情報を取得することにより、プレフィックスを実装する前に、より具体的なプレフィックスをフィルタリングするリスクを評価することをお勧めします。
There may be justifiable reasons for one ISP to perform filtering: either to enforce established policies or to provide prefix-advertisement scoping features to its customers. These can vary from troubleshooting purposes to business-relationship implementations. Restricting the use of these features for the sake of avoiding the creation of unexpected traffic flows is not a practical option.
1つのISPがフィルタリングを実行する正当な理由がある可能性があります。確立されたポリシーを適用するためか、プレフィックスアドバタイズメントスコーピング機能を顧客に提供するためです。これらは、トラブルシューティングの目的からビジネス関係の実装までさまざまです。予期しないトラフィックフローの作成を回避するためにこれらの機能の使用を制限することは、現実的な選択肢ではありません。
In order to assess the risk of filtering more-specific prefixes, the AS would need information on the routing policies and the relationships among external ASes to detect if its actions could trigger the appearance of unexpected traffic flows. With this information, the operator could detect other ASes receiving the more-specific prefix from noncustomer ASes while announcing the less-specific prefix to other noncustomer ASes. If the filtering of the more-specific prefix leads other ASes to send traffic for the more-specific prefix to these ASes, an unexpected traffic flow can arise. However, the information required for this operation is difficult to obtain since it is frequently considered confidential.
より具体的なプレフィックスをフィルタリングするリスクを評価するために、ASは、ルーティングポリシーと外部AS間の関係に関する情報を必要とし、そのアクションが予期しないトラフィックフローの出現をトリガーするかどうかを検出します。この情報を使用して、オペレーターは、顧客固有でないASからより具体的なプレフィックスを受信している他のASを検出し、固有性が低い接頭辞を他の非カスタマーASに通知することができます。より具体的なプレフィックスのフィルタリングにより、他のASがより具体的なプレフィックスのトラフィックをこれらのASに送信する場合、予期しないトラフィックフローが発生する可能性があります。ただし、この操作に必要な情報は、機密情報と見なされることが多いため入手が困難です。
Network operators can adopt different approaches with respect to unexpected traffic flows. Note that due to the complexity of inter-domain routing policies, there is not a single solution that can be applied to all situations. This section provides potential solutions that ISPs must evaluate against each particular case. We classify these actions according to whether they are proactive or reactive.
ネットワークオペレーターは、予期しないトラフィックフローに関してさまざまなアプローチを採用できます。ドメイン間のルーティングポリシーは複雑であるため、すべての状況に適用できる単一のソリューションはありません。このセクションでは、ISPが特定の各ケースに対して評価する必要がある潜在的なソリューションを示します。これらのアクションは、プロアクティブであるかリアクティブであるかに従って分類します。
Reactive approaches are those in which the operator tries to detect the situations via monitoring and solve unexpected traffic flows manually on a case-by-case basis.
事後対応型のアプローチとは、オペレーターが監視によって状況を検出し、予期しないトラフィックフローをケースバイケースで手動で解決しようとするものです。
Anticipant or preventive approaches are those in which the routing system will not let the unexpected traffic flows actually take place when the scenario arises.
予測的または予防的アプローチとは、シナリオが発生したときにルーティングシステムが予期しないトラフィックフローを実際に行わないようにするアプローチです。
We use the scenario depicted in Figure 5 to describe these two kinds of approaches. Since proactive approaches can be complex to implement and can lead to undesired effects, the reactive approach is the more reasonable recommendation to deal with unexpected flows.
図5に示すシナリオを使用して、これらの2種類のアプローチを説明します。プロアクティブなアプローチは実装が複雑になり、望ましくない影響が生じる可能性があるため、予期しないフローに対処するには、リアクティブなアプローチがより合理的な推奨事項です。
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| | | |
| | /32 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 5: Traffic Engineering of Unexpected Traffic Flows - Base Example
図5：予期しないトラフィックフローのトラフィックエンジニアリング-基本例
An operator who detects unexpected traffic flows originated by any of the cases described in Section 2 can contact the ASes that are likely to have performed the propagation tweaks, inform them of the situation, and persuade them to change their behavior.
セクション2で説明したいずれかのケースによって発生した予期しないトラフィックフローを検出したオペレーターは、伝播の微調整を行ったと思われるASに連絡して、状況を通知し、動作を変更するように説得できます。
If the situation remains, the operator can implement prefix filtering in order to stop the unexpected flows. The operator can decide to perform this action over the session with the operator announcing the more-specific prefix or over the session with the neighboring AS from which it is receiving the traffic. Each of these options carry a different repercussion for the affected AS. We briefly describe the two alternatives.
この状況が続く場合、オペレーターは、予期しないフローを停止するためにプレフィックスフィルタリングを実装できます。オペレータは、より具体的なプレフィックスをアナウンスするセッションで、またはトラフィックの受信元である隣接ASとのセッションで、このアクションを実行することを決定できます。これらのオプションはそれぞれ、影響を受けるASに対して異なる影響をもたらします。 2つの選択肢について簡単に説明します。
o An operator can decide to stop announcing the less-specific prefix at the peering session with the neighboring AS from which it is receiving traffic to the more-specific prefix. In the example of Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from the eBGP session with AS64504. In this case, traffic heading to the prefix 2001:DB8::/32 from AS64501 would no longer traverse AS64502. AS64502 should evaluate if solving the issues originated by the unexpected traffic flows are worth the loss of this traffic share.
o オペレーターは、より具体的なプレフィックスへのトラフィックを受信している隣接ASとのピアリングセッションで、より具体的でないプレフィックスのアナウンスを停止することを決定できます。図5の例では、AS64502は、AS64504とのeBGPセッションからプレフィックス2001：DB8 :: / 32を除外します。この場合、AS64501からプレフィックス2001：DB8 :: / 32に向かうトラフィックは、AS64502を通過しなくなります。 AS64502は、予期しないトラフィックフローに起因する問題を解決することが、このトラフィックシェアの損失に値するかどうかを評価する必要があります。
o An operator can decide to filter out the more-specific prefix at the peering session over which it was received. In the example of Figure 5, AS64502 would filter out the incoming prefix 2001:DB8::/34 from the eBGP session with AS64505. As a result, the traffic destined to that /32 would be forwarded by AS64502 along its link with AS64501, despite the actions performed by AS64501 to have this traffic coming in through its link with AS64503. However, as AS64502 will no longer know a route to the more-specific prefix, it risks losing the traffic share from customers different from AS64501 to that prefix. Furthermore, this action can generate conflicts between AS64502 and AS64501, since AS64502 does not follow the routing information expressed by AS64501 in its BGP announcements.
o オペレーターは、それを受信したピアリングセッションで、より具体的なプレフィックスをフィルターで除外することを決定できます。図5の例では、AS64502は、AS64505とのeBGPセッションから着信プレフィックス2001：DB8 :: / 34をフィルターで除外します。その結果、AS64503とのリンクを介してこのトラフィックを受信するためにAS64501が実行したアクションにもかかわらず、その/ 32宛てのトラフィックは、AS64501とのリンクに沿ってAS64502によって転送されます。ただし、AS64502はより具体的なプレフィックスへのルートを認識しなくなるため、AS64501とは異なる顧客からそのプレフィックスへのトラフィック共有を失うリスクがあります。さらに、AS64502はBGPアナウンスでAS64501によって表現されたルーティング情報に従わないため、このアクションはAS64502とAS64501の間に競合を生成する可能性があります。
Note that it is possible that the behavior of the neighboring AS causing the unexpected traffic flows violates a contractual agreement between the two networks.
予期しないトラフィックフローを引き起こす隣接ASの動作が2つのネットワーク間の契約上の合意に違反する可能性があることに注意してください。
An operator could install access lists to prevent unexpected traffic flows from happening in the first place. In the example of Figure 5, AS64502 would install an access list denying packets matching 2001:DB8::/34 associated with the interface connecting to AS64504. As a result, traffic destined to that prefix would be dropped despite the existence of a valid route towards 2001:DB8::/32.
オペレータはアクセスリストをインストールして、最初から予期しないトラフィックフローが発生するのを防ぐことができます。図5の例では、AS64502は、AS64504に接続するインターフェイスに関連付けられている2001：DB8 :: / 34に一致するパケットを拒否するアクセスリストをインストールします。その結果、2001：DB8 :: / 32への有効なルートが存在するにもかかわらず、そのプレフィックス宛てのトラフィックはドロップされます。
The operational overhead of such a solution is considered high, as the operator would have to constantly adapt these access lists to accommodate inter-domain routing changes. Moreover, this technique lets packets destined to a valid prefix be dropped while they are sent from a neighboring AS that may not know about the policy conflict and hence had no means to avoid the creation of unexpected traffic flows. For this reason, this technique can be considered harmful.
オペレーターはドメイン間のルーティングの変更に対応するためにこれらのアクセスリストを常に調整する必要があるため、このようなソリューションの運用オーバーヘッドは高いと考えられます。さらに、この手法により、有効なプレフィックス宛てのパケットは、ポリシーの競合を知らない可能性がある隣接ASから送信されている間、ドロップされるため、予期しないトラフィックフローの作成を回避する手段がありませんでした。このため、この手法は有害であると考えることができます。
An operator can technically ensure that traffic destined to a given prefix will be forwarded from an entry point of the network based only on the set of paths that have been advertised over that entry point.
オペレータは、特定のプレフィックス宛てのトラフィックが、そのエントリポイントを介してアドバタイズされた一連のパスのみに基づいて、ネットワークのエントリポイントから転送されることを技術的に保証できます。
As an example, let us analyze the scenario of Figure 5 from the point of view of AS64502. The edge router connecting to the AS64504 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. Likewise, it forwards packets destined to prefix 2001:DB8::/32 towards AS64501. The router, however, only propagates the path of the less-specific prefix (2001:DB8::/32) to AS64504. An operator could implement the necessary techniques to force the edge router to forward packets coming from AS64504 based only on the paths propagated to AS64504. Thus, the edge router would forward packets destined to 2001:DB8::/34 towards AS64501, in which case no unexpected traffic flow would occur.
例として、図5のシナリオをAS64502の観点から分析してみましょう。 AS64504に接続するエッジルーターは、プレフィックス2001：DB8 :: / 34宛てのパケットをAS64505に転送します。同様に、プレフィックス2001：DB8 :: / 32宛てのパケットをAS64501に転送します。ただし、ルーターは、それほど具体的でないプレフィックス（2001：DB8 :: / 32）のパスをAS64504に伝搬するだけです。オペレーターは、AS64504に伝搬されたパスのみに基づいて、エッジルーターにAS64504からのパケットを強制的に転送させるために必要な技術を実装できます。したがって、エッジルーターは2001：DB8 :: / 34宛てのパケットをAS64501に転送します。この場合、予期しないトラフィックフローは発生しません。
Different techniques could provide this functionality; however, their technical implementation can be complex to design and operate. An operator could, for instance, employ VPN Routing and Forwarding (VRF) tables [RFC4364] to store the routes announced to a neighbor and forward traffic exclusively based on those routes. A presentation from 2009 [on_BGP_RS_VPNs] describes the use of such an architecture for Internet routing and provides a description of its limitations.
さまざまな手法でこの機能を提供できます。ただし、技術的な実装は、設計と運用が複雑になる場合があります。たとえば、オペレーターはVPNルーティングおよび転送（VRF）テーブル[RFC4364]を使用して、ネイバーにアナウンスされたルートを格納し、それらのルートに基づいてトラフィックを排他的に転送できます。 2009年のプレゼンテーション[on_BGP_RS_VPNs]では、このようなアーキテクチャをインターネットルーティングに使用する方法について説明し、その制限について説明しています。
In such architecture, packets received from a peer would be forwarded solely based on the paths that fit the path propagation policy for that peer and not based on the global routing table of the router. As a result, a more-specific path that would not be propagated to a peer will not be used to forward a packet from that peer, and the unexpected flow will not take place. Packets will be forwarded based on the policy-compliant, less-specific prefix. However, note that an operator must make sure that all their routers could support the potential performance impact of this approach.
このようなアーキテクチャでは、ピアから受信したパケットは、そのピアのパス伝播ポリシーに適合するパスのみに基づいて転送され、ルーターのグローバルルーティングテーブルには基づいていません。その結果、ピアに伝搬されないより具体的なパスは、そのピアからのパケットの転送には使用されず、予期しないフローは発生しません。パケットは、ポリシーに準拠し、特定性の低いプレフィックスに基づいて転送されます。ただし、オペレーターはすべてのルーターがこのアプローチの潜在的なパフォーマンスへの影響をサポートできることを確認する必要があることに注意してください。
Note that similar to the solution described in Section 4.1, this approach could create conflicts between AS64502 and AS64501, since the traffic forwarding performed by AS64502 goes against the policy of AS64501.
セクション4.1で説明したソリューションと同様に、AS64502によって実行されるトラフィック転送はAS64501のポリシーに反するため、このアプローチではAS64502とAS64501の間に競合が生じる可能性があることに注意してください。
This document describes how filtering and selective propagation of more-specific prefixes can potentially create unexpected traffic flows across some ASes. We provided examples of scenarios where these practices lead to unexpected traffic flows and introduce some techniques for their detection and prevention. Although there are reasonable situations in which ASes could filter more-specific prefixes, network operators are encouraged to implement this type of filter considering the cases described in this document. Operators can implement monitoring systems to detect unexpected traffic flows and react to them according to their own policy.
このドキュメントでは、より具体的なプレフィックスのフィルタリングと選択的な伝播が、一部のASで予期しないトラフィックフローを作成する可能性がある方法について説明します。これらのプラクティスが予期しないトラフィックフローにつながるシナリオの例を提供し、それらを検出および防止するためのいくつかの手法を紹介しました。 ASがより具体的なプレフィックスをフィルタリングできる合理的な状況がありますが、ネットワークオペレータは、このドキュメントで説明されているケースを考慮して、このタイプのフィルタを実装することをお勧めします。オペレーターは、監視システムを実装して、予期しないトラフィックフローを検出し、独自のポリシーに従ってそれらに対応できます。
It is possible for an AS to use any of the methods described in this document to deliberately reroute traffic flowing through another AS. This document described the potential routing security issue and analyzed ways for operators to defend against it.
ASは、このドキュメントで説明されている方法のいずれかを使用して、別のASを流れるトラフィックを意図的に再ルーティングすることができます。このドキュメントでは、潜在的なルーティングセキュリティの問題について説明し、オペレーターがそれを防御する方法を分析しました。
It must be noted that, at the time of this document, there are no existing or proposed tools to automatically protect against such behavior. Operators can use network monitoring and collection tools to detect unexpected flows and deal with them on a case-by-case basis.
このドキュメントの作成時点では、このような動作から自動的に保護するための既存のツールや提案されているツールはないことに注意してください。オペレーターは、ネットワーク監視および収集ツールを使用して、予期しないフローを検出し、ケースバイケースでそれらに対処できます。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.
[RFC1812]ベイカー、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<http://www.rfc-editor.org/info/rfc1812>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, DOI 10.17487/RFC4384, February 2006, <http://www.rfc-editor.org/info/rfc4384>.
[RFC4384] Meyer、D。、「BGP Communities for Data Collection」、BCP 114、RFC 4384、DOI 10.17487 / RFC4384、2006年2月、<http://www.rfc-editor.org/info/rfc4384>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 DOI 10.17487 / RFC7011、2013年9月、<http://www.rfc-editor.org/info/rfc7011>。
[INIT7-RIPE63] Kunzler, F., "How More Specifics increase your transit bill (and ways to avoid it)", Reseaux IP Europeens (RIPE) 63rd Meeting, October 2011, <http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
[INIT7-RIPE63] Kunzler、F。、「詳細情報により交通費が増える（そしてそれを回避する方法）」、Reseaux IP Europeens（RIPE）第63回会議、2011年10月、<http://ripe63.ripe.net/ presentations / 48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>。
[on_BGP_communities] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM Computer Communication Review, Volume 38, Number 2, pp. 55-59, DOI 10.1145/1355734.1355743, April 2008, <http://www.sigcomm.org/sites/default/files/ccr/ papers/2008/April/1355734-1355743.pdf>.
[on_BGP_communities] Donnet、B。およびO. Bonaventure、「On BGP Communities」、ACM SIGCOMM Computer Communication Review、Volume 38、Number 2、pp。55-59、DOI 10.1145 / 1355734.1355743、2008年4月、<http：// www .sigcomm.org / sites / default / files / ccr / papers / 2008 / April / 1355734-1355743.pdf>。
[on_BGP_RS_VPNs] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco Systems, Routing Symposium, October 2009, <http://inl.info.ucl.ac.be/system/files/ Cisco_NAG_2009_ns_bgp.pdf>.
[on_BGP_RS_VPNs] Vanbever、L.、Francois、P.、Bonaventure、O。、およびJ. Rexford、「BGP / MPLS VPNを使用したカスタマイズされたBGPルート選択」、Cisco Systems、ルーティングシンポジウム、2009年10月、<http：// inl .info.ucl.ac.be / system / files / Cisco_NAG_2009_ns_bgp.pdf>。
[PMACCT] "pmacct project: IP accounting iconoclasm", <http://www.pmacct.net>.
[PMACCT] "pmacctプロジェクト：IPアカウンティングアイコンクラス"、<http://www.pmacct.net>。
Acknowledgements
謝辞
The authors would like to thank Wes George, Jon Mitchell, Bruno Decraene, and Job Snijders for their useful suggestions and comments.
著者は、ウェス・ジョージ、ジョン・ミッチェル、ブルーノ・デクレイネ、およびジョブ・スナイダースの有益な提案とコメントに感謝します。
Authors' Addresses
著者のアドレス
Camilo Cardona IMDEA Networks/UC3M Avenida del Mar Mediterraneo, 22 Leganes 28919 Spain
Camilo Cardona IMDEA Networks / UC3M Avenida del Mar Mediterraneo、22 Leganesスペイン
Email: juancamilo.cardona@imdea.org
Pierre Francois Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States
Pierre Francois Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: pifranco@cisco.com
Paolo Lucente Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States
Paolo Lucente Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: plucente@cisco.com