Network Working Group T. Griffin
Request for Comments: 4264 University of Cambridge
Category: Informational G. Huston
APNIC
November 2005
BGP Wedgies
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies".
一般的に、ボーダーゲートウェイプロトコル（BGP）は決定論的方法で転送パスを作成する方法で到達可能性情報を配信するためのツールであると仮定されています。意図した状態以外の転送状態が均等に安定している場合があり、複数の潜在的な結果であり、そしてそのため、このメモでは、BGP構成のクラスを説明します。また、BGPが収束し安定した状態は、非決定論的方法でBGPによって選択することができます。これらの安定が、意図しない、BGPの状態は、ここで「BGP Wedgies」と呼ばれます。
Table of Contents
目次
1. Introduction ....................................................2
2. Describing BGP Routing Policy ...................................2
3. BGP Wedgies .....................................................3
4. Multi-Party BGP Wedgies .........................................6
5. BGP and Determinism .............................................7
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
It has commonly been assumed that the Border Gateway Protocol (BGP) [RFC1771] is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. This is a 'problem statement' memo that describes a class of BGP configurations for which there is more than one stable forwarding state. In this class of configurations there exist multiple stable forwarding states. One of these stable forwarding states is the intended state, with other stable forwarding states being unintended. The BGP convergence process of selection of a stable forwarding state may operate in a non-deterministic manner in such cases.
一般的にボーダーゲートウェイプロトコル（BGP）[RFC1771]は、決定論的方法で転送パスを作成する方法で到達可能性情報を配信するためのツールであると仮定されています。これは、複数の安定した転送状態が存在するためにBGP構成のクラスを記述する「問題文の」メモです。構成のこのクラスでは、複数の安定した転送状態が存在します。他の安定した転送状態が意図しないされると、これらの安定した転送状態の一つは、意図した状態です。安定した転送状態の選択のBGP収束プロセスは、このような場合には非決定論的な方法で動作することができます。
These stable, but unintended, BGP states are termed here "BGP Wedgies".
これらの安定が、意図しない、BGPの状態は、ここで「BGP Wedgies」と呼ばれます。
BGP routing policies generally reflect each network administrator's objective to optimize their position with respect to their network's cost, performance, and reliability.
BGPルーティングポリシーは、一般的に、ネットワークのコスト、性能、および信頼性に関して、その位置を最適化するために、各ネットワーク管理者の目標を反映しています。
With respect to cost optimization, the local network's default routing policy often reflects a local preference to prefer routes learned from a customer to routes learned from some form of peering exchange. In the same vein, the local network is often configured to prefer routes learned from a peer or a customer over those learned from a directly connected upstream transit provider. These preferences may be expressed via a local preference configuration setting, where the local preference overrides the AS path length metric of the base BGP operation.
最適化の費用に関しては、ローカルネットワークのデフォルトのルーティングポリシーは、多くの場合、ルートが交換をピアリングのいくつかのフォームから学んだに顧客から学習したルートを好むためのローカルプリファレンスを反映しています。同じ静脈では、ローカル・ネットワークは、多くの場合、ピアまたは直接接続された上流のトランジット・プロバイダから学んだものを超える顧客から学習されたルートを好むように構成されています。これらの設定は、ローカルプリファレンスは、ベースBGP動作のASパス長メトリックを上書きローカル優先の構成設定を介して発現させることができます。
In terms of engineering reliability in the inter-domain routing environment it is commonly the case that a service provider may enter into arrangements with two or more upstream transit providers, passing routes to all upstream providers, and receiving traffic from all sources. If the path to one upstream fails, the traffic will switch to other links. Once the path is recovered, the traffic should switch back.
ドメイン間ルーティング環境における工学信頼性の面では、一般的に、サービスプロバイダは、すべての上流のプロバイダへのルートを通過し、すべてのソースからのトラフィックを受信し、二つ以上の上流のトランジットプロバイダと取り決めに入ることができる場合です。 1つのアップストリームへのパスに障害が発生した場合、トラフィックは他のリンクに切り替わります。パスが回復されると、トラフィックはスイッチバックする必要があります。
In such situations of multiple upstream providers it is also common to place a relative preference on the providers, so that one connection is regarded as a preferred, or "primary" connection, and other connections are regarded as less preferred, or "backup" connections. The intent is typically that the backup connections will be used for traffic only for the duration of a failure in the primary connection.
一つの接続を好ましい、又は「一次」接続とみなされ、他の接続はあまり好ましくない、または「バックアップ」接続としてみなされるように、複数の上流プロバイダのような状況では、また、プロバイダに相対的嗜好を配置することが一般的です。その意図は、バックアップ接続は、プライマリ接続に障害が発生した期間にトラフィックに使用されることが一般的です。
It is possible to express this primary / backup policy using local AS path prepending, where the AS path is artificially lengthened towards the backup providers, using additional instances of the local AS. This is not a deterministic selection algorithm, as the selected primary provider may in turn be using AS path prepending to its backup upstream provider, and in certain cases the path through the backup provider may still be selected as the shortest AS path length.
ASパスが人為的にローカルASの追加インスタンスを使用して、バックアッププロバイダに向けて延長される前に付けるパス、ローカルASを使用して、このプライマリ/バックアップポリシーを表現することが可能です。選択された一次プロバイダは順番にそのバックアップ上流プロバイダに前置パスAS使用することができるので、これは、決定論的選択アルゴリズムではなく、ある場合には、バックアップ・プロバイダを通る経路はまだ経路長と最短として選択することができます。
An alternative approach to routing policy specification uses BGP communities [RFC1997]. In this case, the provider publishes a set of community values that allows the client to select the provider's local preference setting. The client can use a community to mark a route as "backup only" towards the backup provider, and "primary preferred' to the primary provider, assuming both providers support community values with such semantics. In this case, the local preference overrides the AS path length metric, so that if the route is marked "backup only", the route will be selected only when there is no other source of the route.
ポリシーの仕様をルーティングするための別のアプローチは、BGPコミュニティ[RFC1997]を使用します。この場合、プロバイダは、クライアントがプロバイダのローカルプリファレンスの設定を選択することを可能にするコミュニティ値のセットを発行しています。クライアントは、このようなセマンティクスで両方のプロバイダサポートコミュニティ値を仮定し、主要プロバイダに「「優先プライマリバックアッププロバイダに向けた「唯一のバックアップ」などのルートをマークするためにコミュニティを使用して、することができます。この場合、ローカルプリファレンスはASを上書きします路長メトリック、ルートは「バックアップのみ」とマークされている場合、ルートの他のソースが存在しないときにのみ、ルートが選択されますように。
The richness of local policy expression through the use of communities, when coupled with the behavior of a distance vector protocol like BGP, leads to the observation that certain configurations have more than one "solution", or more than one stable BGP state. An example of such a situation is indicated in Figure 1.
BGPのような距離ベクトルプロトコルの動作と組み合わせるとコミュニティの使用を介してローカルポリシー表現の豊かさは、特定の構成は、複数の「溶液」、又は複数の安定したBGP状態を有するという観察につながります。このような状況の一例は、図1に示されています。
+----+peer peer+----+
|AS 3|------------------------|AS 4|
+----+ +----+
|provider provider|
| |
| |
|customer |
+----+ |
|AS 2| |
+----+ |
|provider |
| |
| |
|customer customer|
+---------------+ +----------+
backup service| |primary service
+----+
|AS 1|
+----+
Figure 1
図1
In this case, AS1 has marked its advertisement of prefixes to AS2 as "backup only", and its advertisement of prefixes to AS4 as "primary". AS4 will advertise AS1's prefixes to AS3. AS3 will hear AS4's advertisement across the peering link, and select AS1's prefixes with the path "AS4, AS1". AS3 will advertise these prefixes to AS2. AS2 will hear two paths to AS1's prefixes, the first is via the direct connection to AS1, and the second is via the path "AS3, AS4, AS1". AS2 will prefer the longer path, as the directly connected routes are marked "backup only", and AS2's local preference decision will prefer the AS3 advertisement over the AS1 advertisement.
この場合、AS1は、「バックアップのみ」としてAS2へのプレフィックスのその広告をマークした、と「主」としてAS4への接頭辞のその広告。 AS4は、AS3にAS1のプレフィックスを通知します。 AS3は、ピアリングのリンクを介してAS4の広告を聞き、そしてパス「AS4、AS1」とAS1の接頭辞を選択します。 AS3はAS2にこれらのプレフィックスをアドバタイズします。 AS2は、AS1のプレフィックスへの2つのパスを聞くこと、最初は、AS1への直接接続を介してであり、第二の経路を介して、「AS3、AS4、AS1」です。直接接続されたルートは、「バックアップのみ」とマークされているようAS2は、より長い経路を好むだろう、とAS2のローカルプリファレンスの決定は、AS1広告の上にAS3広告を好むでしょう。
This is the intended outcome of AS1's policy settings where, in the 'normal' state, no traffic passes from AS2 to AS1 across the backup link, and AS2 reaches AS1 via a path that transits AS3 and AS4, using the primary link to AS1.
これは、「通常」の状態で、トラフィックはバックアップリンクを渡っAS1にAS2から渡さない、とAS2がAS1へのプライマリリンクを使用して、AS3とAS4を通過する経路を介して、AS1に到達し、AS1のポリシー設定の意図成果です。
This intended outcome is achieved as long as AS1 announces its routes on the primary path to AS4 before announcing its backup routes to AS2.
この意図した結果は限りAS1はAS2にそのバックアップルートを発表する前に、AS4へのプライマリパス上のルートを発表しましたように達成されます。
If the AS1 - AS4 path is broken, causing a BGP session failure between AS1 and AS4, then AS4 will withdraw its advertisement of AS1's routes to AS3, who, in turn, will send a withdrawal to AS2. AS2 will then select the backup path to AS1. AS2 will advertise this path to AS3, and AS3 will advertise this path to AS4. Again, this is part of the intended operation of the primary / backup policy setting, and all traffic to AS1 will use the backup path.
AS1場合 - AS4パスが壊れている、AS1とAS4との間のBGPセッションの失敗を引き起こし、その後、AS4は、順番に、AS2に撤退を送信する、AS3にAS1のルート、その広告を撤回します。 AS2は、AS1へのバックアップパスを選択します。 AS2はAS3にこのパスをアドバタイズします、とAS3はAS4にこのパスをアドバタイズします。繰り返しますが、これはプライマリ/バックアップポリシー設定の意図する動作の一部であり、AS1へのすべてのトラフィックは、バックアップパスを使用します。
When connectivity between AS4 and AS1 is restored the BGP state will not revert to the original state. AS4 will learn the primary path to AS1 and re-advertise this to AS3 using the path "AS4, AS1". AS3, using a default preference of preferring customer-advertised routes over peer routes will continue to prefer the "AS2, AS1" path. AS3 will not pass any updates to AS2. After the restoration of the AS4-to-AS1 circuit, the traffic from AS3 to AS1 and from AS2 to AS1 will be presented to AS1 via the backup path, even through the primary path via AS4 is back in service.
AS4とAS1との間の接続が復元されるときBGP状態を元の状態に戻らないであろう。 AS4はAS1へのプライマリパスを学び、パス「AS4、AS1」を使用してAS3にこれを再アドバタイズします。 AS3は、ピア・ルート上で、顧客アドバタイズされたルートを好むのデフォルト設定を使用すると、「AS2、AS1」パスを優先していきます。 AS3はAS2に更新を渡しません。 AS4ツーAS1回路の復元後、AS3からAS1及びAS2からAS1へのトラフィックは、AS4を介してプライマリパスバックサービスであってもを通して、予備パスを介してAS1に提示されます。
The intended forwarding state can only be restored by AS1 deliberately bringing down its eBGP session with AS2, even though it is carrying traffic. This will cause the BGP state to revert to the intended configuration.
意図転送状態は、それがトラフィックを伝送しているにもかかわらず、故意AS2とののeBGPセッションをダウンさせAS1によって復元することができます。これは、BGPの状態が所望の形状に戻ることになります。
It is often the case that an AS will attempt to balance incoming traffic across multiple providers, again using the primary / backup mechanism. For some prefixes one link is configured as the primary link, and the others as the backup link, while for other prefixes another link is selected as the primary link. An example is shown in
それは多くの場合、ASは、再び主/バックアップ・メカニズムを使用して、複数のプロバイダ間での着信トラフィックを分散しようとする場合です。他のプレフィックスのために別のリンクを一次リンクとして選択されている間、いくつかのプレフィクスの一つのリンクを一次リンクとして構成され、バックアップリンクとして挙げられます。例が示されています
Figure 2.
図2。
+----+peer peer+----+
|AS 3|--------------------------|AS 4|
+----+ +----+
|provider provider|
| |
| customer|
|customer |
+----+ +----+
|AS 2| |AS 5|
+----+ +----+
|provider provider|
| |
| |
|customer customer|
+-----------------+ +----------+
| |
backup (192.0.2.0/25) | |primary service (192.0.2.0/25)
primary (192.0.2.128/25)| |backup service (192.0.2.128/25)
+----+
|AS 1|
+----+
Figure 2
図2
The intended configuration has all incoming traffic for addresses in the range 192.0.2.0/25 via the link from AS5, and all incoming traffic for addresses in the range 192.0.2.128/25 from AS2.
意図した構成はAS5からのリンク、およびAS2の範囲192.0.2.128/25のアドレスのためのすべての着信トラフィックを経由して範囲192.0.2.0/25のアドレスのためのすべての着信トラフィックを持っています。
In this case, if the link between AS3 and AS4 is reset, AS3 will learn both routes from AS2, and AS4 will learn both routes from AS5. As these customer routes are preferred over peer routes, when the link between AS3 and AS4 is restored, neither AS3 nor AS4 will alter their routing behavior with respect to AS1's routes. This situation is now wedged, in that there is no eBGP peering that can be reset that will flip BGP back to the intended state. This is an instance of a BGP Wedgie.
AS3とAS4との間のリンクがリセットされている場合は、この場合には、AS3はAS2から両方のルートを学びます、とAS4はAS5から両方のルートを学びます。これらの顧客のルートがピア・ルートよりも優先されるため、AS3とAS4との間のリンクが回復したときに、どちらAS3もAS4はAS1のルートに関しては、ルーティング動作を変更します。この状況は、今、それが戻って意図した状態にBGPを反転しますリセットすることができます何のeBGPピアリングが存在しないという点で、挟まれています。これは、BGPのパンツを食い込ませるのインスタンスです。
The restoration path here is that AS1 has to withdraw the backup advertisements on both paths and operate for an interval without backup, and then re-advertise the backup prefix advertisements. The length of the interval cannot be readily determined in advance, as it has to be sufficiently long so as to allow AS2 and AS5 to learn of an alternate path to AS1. At this stage the backup routes can be re-advertised.
ここでの復旧パスは、AS1は、バックアッププレフィックス広告を両方のパス上のバックアップ広告を撤回し、バックアップなし間隔で動作し、その後、再広告することがあるということです。それはAS2とAS5は、AS1への代替パスの学習を可能にするように十分に長くなければならないように間隔の長さは、容易に、事前に決定することができません。この段階では、バックアップルートを再アドバタイズできます。
This situation can be more complex when three or more parties provide upstream transit services to an AS. An example is indicated in Figure 3.
三つ以上の当事者がASに上流のトランジットサービスを提供する場合に、この状況はより複雑になることがあります。一例が図3に示されています。
+----+ peer peer +----+
|AS 3|------------------------|AS 4|
+----+ +----+
||provider provider|
|+----------------+ |
| | |
|customer |customer |
+----+peer peer+----+ |
|AS 2|-----------|AS 5| |
+----+ +----+ |
|provider provider| |
| | |
| | |
|customer customer| customer|
+---------------+ |+---------+
backup service| ||primary service
+----+
|AS 1|
+----+
Figure 3
図3
In this example, the intended state is that AS2 and AS5 are both backup providers to AS1, and AS4 is the primary provider. When the link between AS1 and AS4 breaks and is subsequently restored, AS3 will continue to direct traffic to AS1 via AS2 or AS5. In this case, a single reset of the link between AS2 and AS1 will not restore the original intended BGP state, as the BGP-selected best route to AS1 will switch to AS5, and AS2 and AS3 will learn a path to AS1 via AS5.
この例では、意図された状態は、AS2とAS5はAS1にバックアッププロバイダの両方であることであり、AS4は、プライマリプロバイダです。 AS1とAS4ブレイクとの間のリンクがその後復元されると、AS3は、AS2またはAS5を経由してAS1に直接トラフィックに継続されます。 AS1にBGP-選択された最適経路がAS5に切り替わり、AS2及びAS3はAS5介しAS1へのパスを知るであろうように、この場合には、AS2とAS1との間のリンクの単一のリセットは、元の意図BGP状態を復元しないであろう。
What AS1 is observing is incoming traffic on the backup link from AS2. Resetting this connection will not restore traffic back to the primary path, but instead will switch incoming traffic over to AS5. The action required to correct the situation is to simultaneously reset both the link to AS2, and also the link to AS5. This is not necessarily an intuitively obvious solution, as at any point on time only one of these links will be carrying backup traffic, yet both BGP sessions need to be brought down at the same time in order to commence restoration of the intended primary and backup state.
何AS1を観察しているAS2からバックアップリンク上の着信トラフィックです。この接続をリセットすると、プライマリパスに戻って、トラフィックを復元することはありませんが、代わりにAS5の上で着信トラフィックを切り替えます。状況を修正するために必要なアクションが同時にAS5にAS2へのリンク、および、リンクの両方をリセットすることです。これは、これらのリンクの1つがバックアップトラフィックを伝送します時間上の任意の点でのように、必ずしも直感的に明白な解決策ではない、まだ両方のBGPセッションが意図したプライマリおよびバックアップの復元を開始するために、同時にダウンする必要があります状態。
BGP does not behave deterministically in all cases, and, as a consequence, there is intended and unintended non-determinism in BGP. For example, the default final tie break in some implementations of BGP is to prefer the longest-lived route. To achieve determinism in this last step it would be necessary to use a comparison operator that has a predictable outcome, such as a comparison of router identifiers. This class of non-deterministic behavior is termed here "intended" non-determinism, in that the policy interactions are, to some extent, predictable by network administrators.
BGPは、結果として、すべてのケースでは確定的に動作し、しない、そこに意図されており、BGPにおける意図しない非決定論。たとえば、BGPのいくつかの実装では、デフォルトの最終タイブレークは、最長寿命のルートを好むことです。この最後のステップで決定論を達成するためには、ルータ識別子の比較として、予測可能な結果を、持っている比較演算子を使用することが必要であろう。非決定論的行動のこのクラスは、ここに呼ばれている政策の相互作用は、ある程度、ネットワーク管理者によって予測可能であることで、非決定論を「意図」。
BGP is also able to generate outcomes that can be described as "unintended non-determinism" that can result from unexpected policy interactions. These outcomes do not represent misconfiguration in the standard sense, since all policies may look completely rational locally, but their interaction across multiple routing entities can cause unintended outcomes, and BGP may reach a state that includes such unintended outcomes in a non-deterministic manner.
BGPはまた、予期しないポリシーの相互作用から生じ得る「意図しない非決定論」として記述することができる結果を生成することができます。すべてのポリシーがローカルに完全に合理的に見えるかもしれないので、これらの結果は、標準の意味での設定ミスを表すものではありませんが、複数のルーティングエンティティ間の相互作用は、予期せぬ結果を引き起こす可能性があり、およびBGPは、非決定論的に、このような意図しない結果を含んでいる状態に達することがあります。
Unintended non-determinism in BGP would not be as critical an issue if all stable routings were guaranteed to be consistent with the policy writer's intent. However, this is not always the case. The above examples indicate that the operation of BGP allows multiple stable states to exist from a single configuration state, where some of these states are not consistent with the policy writer's intent. These particular examples can be described as a form of "route pinning", where the route is pinned to a non-preferred path.
すべての安定したルーティングがポリシー作家の意図と一致するように保証された場合、BGPにおける意図しない非決定論はそれほど重要な問題ではないであろう。しかし、これは必ずしもそうではありません。上記の例は、BGPの動作は、複数の安定状態は、これらの状態のいくつかは、ポリシーライタの意図と一致していない単一の構成状態から存在することを可能にすることを示しています。これらの特定の例は、ルートが非優先パスに固定された「ルートピニング」の形態として説明することができます。
The challenge for the network administrator is to ensure that an intended state is maintained. Under certain circumstances this can only be achieved by deliberate service disruption, involving the withdrawal of routes being used to forward traffic, and re-advertising routes in a certain sequence in order to induce an intended BGP state. However, the knowledge that is required by any single network operator administrator in order to understand the reason why BGP has stabilized to an unintended state requires BGP policy configuration knowledge of remote networks. In effect, there is insufficient local information for any single network administrator to correctly identify the root cause of the unintended BGP state, nor is there sufficient information to allow any single network administrator to undertake a sequence of steps to rectify the situation back to the intended routing state.
ネットワーク管理者にとっての課題は、意図した状態が維持されることを保証することです。特定の状況下ではこれが唯一の意図BGP状態を誘導するためにトラフィックを転送するために使用される経路、及び特定の配列に再広告経路の撤退を含む、意図的なサービスを中断することによって達成することができます。しかし、BGPが意図しない状態に安定している理由を理解するために、任意の単一のネットワークオペレータの管理者が必要とされる知識は、リモートネットワークのBGPポリシー設定の知識が必要です。実際には、正しく意図しないBGP状態の根本原因を特定するために、任意の単一のネットワーク管理者のための不十分な地域情報があり、また戻っ意図に状況を是正するために一連のステップに着手する任意の単一のネットワーク管理者を可能にするのに十分な情報がありますルーティング状態。
It is reasonable to anticipate that the density of interconnection will continue to increase, and the capability for policy-based preference settings of learned and re-advertised routes will become more expressive. Therefore, it is reasonable to anticipate that the number of unintended but stable BGP states will increase, and the ability to define the necessary sequence of route withdrawals and re-advertisements will become more challenging for network operators to determine in advance.
相互接続の密度が増加し続けると予想するのが妥当である、と学んだと再アドバタイズされたルートのポリシーベースの環境設定のための能力は、より表現になります。したがって、意図しないが、安定したBGP状態の数が増加すると予想するのが妥当であり、ネットワークオペレータは事前に決定するための経路引き出し、再広告の必要なシーケンスを定義する能力はより困難になるであろう。
Whether this could lead to a BGP routing system reaching a point where each network consistently cannot direct traffic in a deterministic manner is, at this stage, a matter of speculation. BGP Wedgies illustrate that a sufficiently complex interconnection topology, coupled with a sufficiently expressive set of policy constructs, can lead to a number of stable BGP states, rather than a single intended state. As the topology complexity increases, it is not possible to deterministically predict which state the BGP routing system may converge to. Paradoxically, the demands of inter-domain traffic engineering appear to require greater levels of expressive capability in policy-based routing directives, operating across denser interconnectivity topologies in a deterministic manner. This may not be a sustainable outcome in BGP-based routing systems.
これは、各ネットワークが一貫決定論的にトラフィックを指示することができない点に到達BGPルーティングシステムにつながる可能性があるかどうかは、この段階では、投機の問題です。 BGPのWedgiesは、ポリシー構築の十分に表現セットに結合され、十分に複雑な相互接続トポロジーは、安定したBGP状態の数ではなく、単一の意図された状態をもたらすことができることを示します。トポロジの複雑さが増加すると、決定論BGPルーティングシステムは、に収束することができる状態を予測することは不可能です。逆説的に、ドメイン間のトラフィックエンジニアリングの需要は、決定論的に密度の高い相互接続トポロジ全体で動作し、ポリシーベースルーティングディレクティブで表現力の高いレベルを必要とするように見えます。これは、BGPベースのルーティングシステムにおける持続可能な結果ではないかもしれません。
BGP is a relaying protocol, where route information is received, processed, and forwarded. BGP contains no specific mechanisms to prevent the unauthorized modification of the information by a forwarding agent, allowing routing information to be modified or deleted, or for false information to be inserted without the knowledge of the originator of the routing information or any of the recipients.
BGPは、経路情報は、受信処理され、転送される中継プロトコルです。 BGPは、ルーティング情報が変更または削除されることを可能にする、転送エージェントが情報の不正改変を防止するために特別な機構を含んでいない、または誤った情報が、ルーティング情報、または受信者の任意の発信者の知識なしに挿入されるため。
This memo proposes no modifications to the BGP protocol, nor does it propose any changes to the manner of deployment of BGP, and therefore introduces no new factors in terms of the security and integrity of inter-domain routing.
このメモは、BGPプロトコルへの変更を提案していない、またそれは、BGPの展開の仕方への変更を提案しないので、ドメイン間ルーティングのセキュリティと整合性の面で新たな要因が導入されていません。
This memo illustrates that, in attempting to create policy-based outcomes relating to path selection for incoming traffic, it is possible to generate BGP configurations where there are multiple stable outcomes, rather than a single outcome. Furthermore, of these instances of multiple outcomes, there are cases where the BGP selection of a particular outcome is not a deterministic selection.
このメモは、着信トラフィックを経路選択に関するポリシーベースの成果を作成しようとして、複数の安定した結果ではなく、単一の結果が存在するBGPの設定を生成することが可能である、ことを示します。また、複数の結果のこれらのインスタンスで、特定の結果のBGP選択が確定的選択ではない場合があります。
This class of behaviour may be exploitable by a hostile third party. A common theme of BGP Wedgies is that starting from an intended or desired forwarding state, the loss and subsequent restoration of an eBGP peering connection can flip the network's forwarding configuration into an unintended and potentially undesired state. Significant administrative effort, based on BGP state and configuration knowledge that may not be locally available, may be required to shift the BGP forwarding configuration back to the intended or desired forwarding state. If a hostile third party can deliberately cause the BGP session to reset, thereby producing the initial conditions that lead to an unintended forwarding state, the network impacts of the resulting unintended or undesired forwarding state may be long-lived, far outliving the temporary interruption of connectivity that triggered the condition. If these impacts, including potential issues of increased cost, reduction of available bandwidth, increases in overall latency or degradation of service reliability, are significant, then disrupting a BGP session could represent an attractive attack vector to a hostile party.
行動のこのクラスは、敵対的な第三者によって悪用可能かもしれません。 BGP Wedgiesの共通のテーマは、意図したまたは所望のフォワーディング状態からのeBGPの喪失およびその後の復元が接続ピアリングは意図しないと潜在的に望ましくない状態にネットワークの転送設定を反転できることです。有意な管理作業は、ローカルに利用可能ではないかもしれないBGP状態および構成の知識に基づいて、バック意図または所望のフォワーディング状態にBGP転送設定をシフトするために必要とされ得ます。敵対的な第三者が故意にそれによって意図しないフォワーディングステートにつながる初期条件を生成する、BGPセッションをリセットさせることができれば、結果として意図しないまたは望ましくないフォワーディングステートのネットワークへの影響は、これまでの一時的な中断をoutliving、長寿命かもしれ条件をトリガ接続。コスト上昇の潜在的な問題、利用可能な帯域幅の削減、サービスの信頼性の全体的な遅延や劣化の増加、など、これらの影響は、重要である場合には、BGPセッションを中断することは敵対関係者に魅力的な攻撃ベクトルを表すことができます。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandrasekeran、R.、Trainaの、P.、およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
Authors' Addresses
著者のアドレス
Tim G. Griffin Computer Laboratory University of Cambridge
ケンブリッジのティム・G.グリフィンコンピュータ研究所大学
EMail: Timothy.Griffin@cl.cam.ac.uk
メールアドレス：Timothy.Griffin@cl.cam.ac.uk
Geoff Huston Asia Pacific Network Information Centre
ジェフ・ヒューストンアジア太平洋ネットワークインフォメーションセンター
EMail: gih@apnic.net
メールアドレス：gih@apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。