[要約] RFC 4264は、BGP Wedgies（BGPの問題）に関する技術的な説明と解決策を提供するものであり、BGPプロトコルの安定性と信頼性を向上させることを目的としています。
Network Working Group T. Griffin
Request for Comments: 4264 University of Cambridge
Category: Informational G. Huston
APNIC
November 2005
BGP Wedgies
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).
Copyright（c）The Internet Society（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".
一般的に、Border Gateway Protocol（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.
一般的に、Border Gateway Protocol（BGP）[RFC1771]は、到達可能性情報を決定論的な方法で転送パスを作成する方法で分散するためのツールであると想定されています。これは、複数の安定した転送状態があるBGP構成のクラスを説明する「問題ステートメント」メモです。このクラスの構成には、複数の安定した転送状態が存在します。これらの安定した転送状態の1つは、意図された状態であり、他の安定した転送状態は意図的ではありません。安定した転送状態の選択の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.
ドメイン間のルーティング環境でのエンジニアリングの信頼性に関しては、サービスプロバイダーが2つ以上の上流のトランジットプロバイダーとの取り決めを締結し、すべての上流プロバイダーにルートを渡し、すべてのソースからトラフィックを受け取ることができる場合があります。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.
複数の上流プロバイダーのこのような状況では、プロバイダーに相対的な優先権を置くことも一般的であるため、1つの接続が優先または「プライマリ」接続と見なされ、他の接続はより少ない優先、または「バックアップ」接続と見なされます。意図は、通常、バックアップ接続がプライマリ接続の障害の期間のみトラフィックに使用されることです。
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のPATH PRETENDINGを使用して、このプライマリ /バックアップポリシーを表現することができます。ここでは、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はAS1のプレフィックスをAS3に宣伝します。AS3は、ピアリングリンク全体でAS4の広告を聞き、パス「AS4、AS1」でAS1のプレフィックスを選択します。AS3はこれらのプレフィックスをAS2に宣伝します。AS2はAS1のプレフィックスへの2つのパスを聴き、1つ目はAS1への直接接続を介して、2つ目はパス「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からAS1にトラフィックが通過し、AS2がAS3とAS4を通過するパスを介してAS1に到達し、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はAS1のルートの広告をAS3に引き出します。AS3は、AS2に引き出しを送信します。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.
意図した転送状態は、AS1がトラフィックを運んでいても、AS2でEBGPセッションを意図的に削減することによってのみ回復できます。これにより、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 Figure 2.
多くの場合、ASは、プライマリ /バックアップメカニズムを使用して、複数のプロバイダー間の着信トラフィックのバランスをとろうとする場合があります。一部のプレフィックスでは、1つのリンクがプライマリリンクとして、その他はバックアップリンクとして構成され、他のプレフィックスでは別のリンクがプライマリリンクとして選択されます。例を図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からのリンクを介して192.0.2.0/25の範囲のアドレスのすべての着信トラフィックがあり、AS2からの範囲192.0.2.128/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 Wedgieのインスタンスです。
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.
この状況は、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にトラフィックを向け続けます。この場合、AS2とAS1の間のリンクの単一のリセットは、AS1へのBGPが選択した最適なルートがAS5に切り替え、AS2とAS3がAS5を介して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に切り替えます。状況を修正するために必要なアクションは、AS2へのリンクとAS5へのリンクの両方を同時にリセットすることです。これは必ずしも直感的に明らかなソリューションではありません。これらのリンクの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セッションを意図的にリセットし、それによって意図しない転送状態につながる初期条件を生成できる場合、結果として生じる意図しないまたは望ましくない転送状態のネットワークへの影響は長期にわたり、条件をトリガーした接続性の一時的な中断をはるかに上回る可能性があります。コストの増加、利用可能な帯域幅の削減、全体的な遅延の増加、またはサービス信頼性の劣化の潜在的な問題を含むこれらの影響が重要である場合、BGPセッションを混乱させると、敵対的な政党に対する魅力的な攻撃ベクトルを表す可能性があります。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 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. Li、「BGP Communities属性」、RFC 1997、1996年8月。
Authors' Addresses
著者のアドレス
Tim G. Griffin Computer Laboratory University of Cambridge
ケンブリッジのティムG.グリフィンコンピューター研究所
EMail: Timothy.Griffin@cl.cam.ac.uk
Geoff Huston Asia Pacific Network Information Centre
Geoff Huston Asia Pacific Network Information Center
EMail: gih@apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。