Network Working Group R. White
Request for Comments: 5123 B. Akyol
Category: Informational Cisco Systems
February 2008
Considerations in Validating the Path in BGP
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESG注意
After consultation with the RPSEC WG, the IESG thinks that this work is related to IETF work done in WG RPSEC, but this does not prevent publishing.
RPSEC WGとの協議の後、IESGは、この作品はWG RPSECで行わIETF仕事に関連していると思うが、これは公開を防ぐことはできません。
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
Abstract
抽象
This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path.
この文書は、BGP自律システム（AS）パス内の検証の概念上のホップバイホップ転送、ルート集約、および経路フィルタリングの影響を調べます。
A good deal of thought has gone into, and is currently being given to, validating the path to a destination advertised by BGP. The purpose of this work is to explain the issues in validating a BGP AS Path, in the expectation that it will help in the evaluation of schemes seeking to improve path validation. The first section defines at least some of the types of questions a BGP speaker receiving an update from a peer not in the local autonomous system (AS) could ask about the information within the routing update. The following sections examine the answers to these questions in consideration of specific deployments of BGP.
思考の良い取引がに入った、そして現在はBGPによってアドバタイズの宛先へのパスを有効に与えられています。この作業の目的は、パス検証を改善しようとしているスキームの評価に役立つことを期待して、BGP ASパスを有効に問題を説明することです。最初のセクションは、ルーティングアップデート内の情報について求めることができる質問の種類ではないローカル自律システム（AS）内のピアからの更新を受信するBGPスピーカの少なくとも一部を画定します。次のセクションでは、BGPの具体的な展開を考慮してこれらの質問に対する答えを調べます。
The examples given in this document are intended to distill deployments down to their most critical components, making the examples easier to understand and consider. In many situations, the specific path taken in the example may not be relevant, but that does not nullify the principles considered in each example. It has been suggested that these examples are "red herrings", because they do not illustrate actual problems with specific policies. On the contrary, these examples are powerful because they are simple. Any topology in which one of these example topologies is a subtopology will exhibit the characteristics explained in this document. Rather than focusing on a specific topology, then dismissing that single topology as a "corner case", this document shows the basic issues with assertions about the AS Path attribute within BGP. These generalized issues can then be applied to more specific cases.
この文書で与えられた例が理解し、検討する例が容易になり、彼らの最も重要なコンポーネントへの展開をダウン蒸留することを意図しています。多くの状況では、例えば取り込ま特定のパスは、関連ではないかもしれないが、それは、各実施例において考慮原理を無効にしません。彼らは特定のポリシーと実際の問題を示していないので、これらの例は、「赤いニシン」であることが示唆されています。彼らはシンプルであるため、逆に、これらの例は強力です。任意のトポロジとは、これらの例トポロジの一つは、特性を示すであろうsubtopologyは、この文書で説明しています。むしろ「コーナーケース」として、その単一のトポロジを却下、その後、特定のトポロジに焦点を当てよりも、この文書では、BGP内のASパス属性に関するアサーションとの基本的な問題を示しています。これらの一般化の問題は、より具体的な例にも適用することができます。
With the heightened interest in network security, the security of the information carried within routing systems running BGP, as described in [RFC4271], is being looked at with great interest. While there are techniques available for securing the relationship between two devices exchanging routing protocol information, such as [BGP-MD5], these techniques do not ensure various aspects of the information carried within routing protocols are valid or authorized.
ネットワークセキュリティに関心が高まっと、BGPを実行しているルーティングシステム内で搬送される情報のセキュリティは、[RFC4271]に記載されているように、大きな関心とを見ています。このような[BGP-MD5]などのルーティングプロトコル情報を交換する2つのデバイス間の関係を固定するために利用可能な技術があるが、これらの技術は有効または許可されているルーティングプロトコル内で搬送される情報の様々な側面を保証しません。
The following small internetwork is used to examine the concepts of validity and authorization within this document, providing definitions used through the remainder of the document.
以下の小規模なインターネットワークでは、文書の残りの部分によって使用される定義を提供し、この文書内の妥当性と承認の概念を調べるために使用されます。
10.1.1.0/24--(AS65000)---(AS65001)--(AS65002)
Assume a BGP speaker in AS65002 has received an advertisement for 10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000, 65001}.
AS65002内のBGPスピーカは{65000、65001}のASパスと、AS65001内のBGPスピーカから10.1.1.0/24の広告を受信したと仮定する。
1.1. Is the Originating AS Authorized to Advertise Reachability to the Destination?
1.1. 発信先への到達可能性を宣伝するためにAS許可されていますか？
The most obvious question the receiving BGP speaker can ask about this advertisement is whether or not the originating AS, in this case AS65000, is authorized to advertise the prefix contained within the advertisement, in this case 10.1.1.0/24. Whether or not a BGP speaker receiving a route to 10.1.1.0/24 originating in AS65000 can verify that AS65000 is, indeed, authorized to advertise 10.1.1.0/24 is outside the scope of this document.
受信BGPスピーカはこの広告について尋ねることができる最も明白な質問は、発信元がAS、この場合のAS65000には、この場合10.1.1.0/24には、広告内に含まれるプレフィックスを通知することが許可されているかどうかです。そのAS65000を確認することができますAS65000に10.1.1.0/24発信元へのルートを受け取るBGPスピーカーがあるかどうかは、実際に、10.1.1.0/24はこの文書の範囲外で宣伝することが許可。
If a BGP speaker receives an advertisement from a peer outside the local autonomous system (AS), the peer sending the update has a path to the destination prefix in the update. Specifically, are the autonomous systems within the internetwork connected in such a way that the receiver, following the AS Path listed in the BGP update itself, can reach the originating AS listed in the received AS Path? Within this document, this is called path validation.
BGPスピーカは、ローカル自律システム（AS）外部ピアから広告を受信した場合、更新を送信するピアは更新の宛先プレフィックスへの経路を有します。パスとして受信に記載されている具体的に、BGPに記載されているASパス以下の受信機は、それ自体を更新するように接続されたインターネットワーク内の自律システムでは、発信に到達することができますか？この文書の中で、これはパス検証と呼ばれています。
Path validation, in the context of this small internetwork, asserts that when a BGP speaker in AS65002 receives an advertisement from a BGP speaker in AS65001 with the AS Path {65000, 65001}, the speaker can assume that AS65001 is attached to the local AS, and that AS65001 is also attached to AS65000.
パスの検証は、この小さなインターネットの文脈において、AS65002内のBGPスピーカは、ASパス{65000、65001}とAS65001内のBGPスピーカから広告を受信した場合、スピーカがそのAS65001ローカルASに取り付けられていると仮定することができると主張します、そしてそのAS65001もAS65000に取り付けられています。
There are at least three senses in which the readvertisement of a received advertisement can be authorized in BGP:
受信した広告の広告がBGPに認可することができる少なくとも3つの感覚があります。
o The transmitter is authorized to advertise the specific routing information contained in the route. This treats the routing information as a single, atomic unit, regardless of the information the route actually contains. A route to 10.1.1.0/24 and another route to 10.1.0.0/16 are considered completely different advertisements of routing information, so an AS may be authorized to advertise 10.1.0.0/16 without regard to its authorization to advertise 10.1.1.0/24, since these are two separate routes. This is called route authorization throughout this document.
O送信機は、経路に含まれる特定のルーティング情報を公示することを許可されています。これは、経路が実際に含まれている情報に関係なく、単一のアトミック単位としてルーティング情報を扱います。 10.1.1.0/24へのルートと10.1.0.0/16に別のルートは、ルーティング情報の完全に異なる広告を考えられているので、ASは、宣伝するその権限に関係なく10.1.0.0/16をアドバタイズすることを許可されてもよい10.1.1.0/ 24、これら2つの別々の経路であるからです。これは、この文書全体でルート認証と呼ばれています。
o The transmitter is authorized to advertise the specific reachable destination(s) contained in the route. This treats the routing information as a set of destinations. 10.1.1.0/24 is contained within 10.1.0.0/16, and authorization to advertise the latter implies authorization to advertise the former. This is called reachability authorization throughout this document.
O送信機は、経路に含まれる特定の到達先（複数可）を宣伝することを許可されています。これは、目的地のセットとしてルーティング情報を扱います。 10.1.1.0/24は10.1.0.0/16内に含まれ、後者をアドバタイズする権限は、前者をアドバタイズする権限を意味しています。これは、この文書全体に到達可能性の承認と呼ばれています。
o The transmitter is authorized to transit traffic to the destinations contained within the route. This ties the concepts of the route to what the route is used for. If a BGP speaker is advertising reachability to 10.1.1.0/24, it is authorized to transit traffic to all reachable destinations within 10.1.1.0/24 along the path advertised. This is called transit authorization throughout this document.
O送信機は、経路内に含まれる宛先への通過トラフィックを許可されています。これは、ルートがために使用されるものへのルートの概念を結びつけます。 BGPスピーカーが10.1.1.0/24への到達可能性をアドバタイズしている場合は、アドバタイズされるパスに沿って10.1.1.0/24内のすべての到達可能な宛先にトランジットトラフィックを許可されています。これは、この文書全体でのトランジットの許可と呼ばれています。
There is considerable tension between these three definitions of authorization; much of this document is built around exploring the relationships between these different types of authorization, and how they may, or may not, work in various internetworks. One of the conclusions reached by this document is that route authorization, reachability authorization, and transit authorization are often at odds with each other. Showing one type of authorization to be true does not show any other types of authorization to be true, and route authorization is of questionable value because of the intertwined nature of these three types of authorization in a routing system.
承認のこれらの3つの定義の間にかなりの緊張があります。このドキュメントの多くは、認可、およびそれらがどのようにしたり、ないかもしれないが、様々なインターネットワークでの仕事のこれらの異なるタイプ間の関係を模索して構築されています。この文書で到達した結論の一つは、ルート認証、到達可能性の承認、およびトランジット承認が互いに対立してあることが多いということです。真であると承認のいずれかのタイプを表示することは真であると承認の任意の他のタイプを示し、ルート権限があるため、ルーティングシステムの承認のこれら3種類の絡み合った性質の疑問価値があるものではありません。
1.4. Will Traffic Forwarded to an Advertising Speaker Follow the Described AS Path?
1.4. 広告スピーカーに転送されるトラフィックは、パスのように説明に従ってくださいだろうか？
If a BGP speaker receives an advertisement from a peer not in the local AS, will traffic forwarded to the peer advertising the update follow the path described in the AS Path? In this document, this is called forwarding consistency.
BGPスピーカは、ローカルAS内にない相手からの広告を受信した場合、更新を広告するピアにトラフィックを転送しますASパスに記述パスをたどりますか？この文書では、これは、転送の一貫性と呼ばれています。
In terms of the small example internetwork, if a BGP speaker in AS65002 receives an advertisement from a peer in AS65001 for the destination 10.1.1.0/24, with an AS Path {65000, 65001}, will traffic forwarded to the BGP speaker in AS65001 actually be forwarded through routers within AS65001, then AS65000, to reach its destination?
小例えばインターネットワークの観点から、AS65002内のBGPスピーカは、AS65001内のBGPスピーカへのトラフィック転送し、ASパス{65000、65001}で、宛先10.1.1.0/24ためAS65001内のピアから広告を受信した場合実際AS65001内のルータを介して転送され、その後、AS65000は、その宛先に到達するには？
1.5. Is a Withdrawing Speaker Authorized to Withdraw the Routing Information?
1.5. 撤退スピーカーは、ルーティング情報を撤回することを許可されていますか？
If an advertisement is withdrawn, the withdrawing BGP peer was originally advertising the prefix (or was authorized to advertise the prefix). This assertion is out of the scope of this document.
広告が撤回された場合、撤退BGPピアは、もともとプレフィックスを広告した（またはプレフィックスを通知する権限を与えられました）。この主張は、このドキュメントの範囲外です。
To begin, we review some of the concepts of routing, since we need to keep these concepts fixed firmly in place while we examine these questions. After this, four examples will be undertaken with BGP to show the tension between the various types of authorization in a path vector routing system.
我々はこれらの問題を検討しながら、所定の位置にしっかりと固定し、これらの概念を維持する必要があるため開始するために、我々は、ルーティングの概念のいくつかを確認します。この後、4つの例は、パスベクトルルーティングシステムにおける権限の様々なタイプの間で張力を示すためにBGPで行われるであろう。
Routing protocols are designed, in short, to discover a set of loop-free paths to each reachable destination within a network (or internetwork). The loop-free path chosen to reach a specific destination may not be the shortest path, and it may not always be the "best" path (depending on the definition of "best"), but it should always be a loop-free path, otherwise the routing protocol has failed.
ルーティングプロトコルは、ネットワーク（またはインターネット）内の各到達可能な目的地までのループのないパスのセットを発見するために、短期に、設計されています。特定の宛先に到達するために選ばれたループフリーパスを最短経路ではないかもしれないが、それは常に（「最高」の定義に応じて）「最善」のパスではないかもしれないが、それは常にループフリーパスでなければなりません、そうでなければ、ルーティングプロトコルが失敗しました。
This sheds some light on the purpose of the path included in a path vector protocol's routing update: the path is there to prove the path is loop free, rather than to provide any other information. While Dijkstra's Sender Policy Framework (SPF) and the Diffusing Update Algorithm (DUAL) both base their loop-free path calculations on the cost of a path, path vector protocols, such as BGP, prove a path is loop free by carrying a list of nodes the advertisement itself has traversed. BGP specifically uses an AS Path-based mechanism to prove loop freeness for any given update so each AS along the path may implement local policy without risking a loop in the routing system caused by competing metrics.
これは、パスベクトルプロトコルのルーティングアップデートに含まれるパスの目的でいくつかの光を当て：パスは、パスが証明する任意の他の情報を提供するのではなく、ループフリーです。ダイクストラのSPF（Sender Policy Framework）をし、拡散性更新アルゴリズム（DUAL）の両方が、パスのコストに自分のループフリーパスの計算を基礎としながら、BGPなどのパスベクトルプロトコルは、パスを証明するのリストを運ぶことにより、ループの自由です広告自体が横断したノード。 BGPは、具体的には、パスに沿ってASそれぞれが競合メトリックによって引き起こされるルーティングシステムでループを危険にさらすことなく、ローカルポリシーを実装することができるように、任意の所与の更新のためのループ濾水度を証明するためにASパスベースのメカニズムを使用します。
We need to keep this principle in mind when considering the use of the path carried in a path-vector protocol, and its use by a receiving BGP speaker for setting policy or gauging the route's security level.
私たちは、パスベクトルプロトコルで運ばパス、およびポリシーの設定や経路のセキュリティレベルを評価するための受信BGPスピーカによる使用の使用を検討する際に念頭に置いて、この原則を維持する必要があります。
In the small network:
小規模なネットワークでは：
+---(AS65002)---+
(AS65000)--(AS65001) (AS65004)--10.1.1.0/24
+---(AS65003)---+
A BGP speaker in AS65000 may receive an advertisement from a peer that 10.1.1.0/24 is reachable along the path {65004, 65002, 65001}. Based on this information, the BGP speaker may forward packets to its peer in AS65001, expecting them to take the path described. However, within AS65001, the network administrator may have configured a static route making the next hop to 10.1.1.0/24 the edge router with AS65003.
AS65000内のBGPスピーカは{65001、65004、65002} 10.1.1.0/24は、経路に沿って到達可能なピアから広告を受信することができます。この情報に基づいて、BGPスピーカは説明のパスを取るためにそれらを期待し、AS65001にそのピアにパケットを転送することができます。しかし、AS65001内に、ネットワーク管理者はAS65003とエッジルータを10.1.1.0/24する次のホップを行う静的ルートを設定してもよいです。
It's useful to note that while [RFC4271] states: "....we assume that a BGP speaker advertises to its peers only those routes that it itself uses...", the definition of the term "use" is rather loose in all known widely deployed BGP implementations. Rather than meaning: "A BGP speaker will only advertise destinations the BGP process on the speaker has installed in the routing table", it generally means: "A BGP speaker will only advertise destinations that the local routing table has a matching route installed for, no matter what process on the local router installed the route". A naive reaction may be to simply change the BGP specifications and all existing implementations so a BGP speaker will only advertise a route to a peer if the BGP process on the router actually installed the route in the local routing table. This, however, ignores the complex interactions between interior and exterior gateway protocols, which most often run on the same device, and the complexities of route origination.
「...私たちはBGPスピーカは、そのピアに、それ自体が使用するだけでそれらのルートをアドバタイズすることを前提とし....」は、用語 『使用』の定義はでかなり緩んでいる：それは、[RFC4271]ながらすると述べていることに注意することは便利ですすべては広く展開されているBGPの実装を知られています。むしろ意味より：「BGPスピーカーはスピーカーのみのBGPプロセスがルーティングテーブルにインストールされている宛先をアドバタイズします」、それは一般的意味：「BGPスピーカーは、ローカルルーティングテーブルがために設置一致するルートを持って目的地をのみアドバタイズします、関係なく、ローカルルータ上のどのようなプロセスはルート」をインストールしていません。ナイーブな反応は、ルータ上のBGPプロセスが実際にローカルルーティングテーブル内のルートをインストールした場合、BGPスピーカのみピアにルートをアドバタイズしますので、単にBGP仕様およびすべての既存の実装を変更することができます。これは、しかし、ほとんどの場合、同じデバイス上で実行する内部と外部ゲートウェイプロトコルとの間の複雑な相互作用、およびルート元の複雑さを無視します。
Although this is an "extreme" example, since we can hardly claim the information within the routing protocol is actually insufficient, we still find this example instructive in light of the questions outlined in Section 1:
これは、「極端な」例であるが、我々はほとんどのルーティングプロトコル内の情報を請求することができないので、実際には不十分である、我々はまだ項1に概説質問に照らして有益この例を見つけます。
o Is the AS Path valid? The AS Path the receiving BGP speaker in AS65000 receives from its peer in AS65001, {65004, 65002, 65001), does exist, and is valid.
O ASパスは有効ですか？ AS65000内のASパス受信BGPスピーカは{65004、65002、65001）、AS65001内のピアから受信し、存在し、かつ有効です。
o Is the advertisement authorized? Since we have no knowledge of any autonomous system level policy within this network, we have no way of answering this question. We can assume that AS65001 has both route and reachability authorization, but it is difficult to see how transit authorization can be accomplished in this situation. Even if the BGP speaker in AS65000 could verify AS65001 is authorized to transit AS65002 to reach 10.1.1.0/24, this implies nothing about the authorization to transit traffic through the path traffic will actually take, which is through AS65003.
oは広告が許可されていますか？私たちはこのネットワーク内の任意の自律システムレベルの政策の知識がないので、私たちはこの質問に答えるの方法がありません。私たちは、AS65001は、両方のルートと到達可能性の権限を持っていると仮定することができますが、このような状況で行うことができる方法のトランジットの許可を参照することは困難です。 AS65001を確認することができAS65000内のBGPスピーカーが10.1.1.0/24に到達するためにトランジットAS65002に認可されている場合でも、これはAS65003ている実際に取るパストラフィックを通る通過交通への許可、については何も意味しません。
o Is the AS Path consistent with the forwarding path (does forwarding consistency exist)? No, the advertised AS Path is {65004, 65002, 65001}, while the actual path is {65004, 65003, 65001}.
oは転送パスと一致ASパス（存在する一貫性を転送しない）されていますか？実際の経路は{65004、65003、65001}である間は、パスとしてアドバタイズは、{65004、65002、65001}です。
From this example, we can see forwarding consistency is not possible to validate in a deployed network; just because a BGP speaker advertises a specific path to reach a given destination, there is no reason to assume traffic forwarded to the speaker will actually follow the path advertised. In fact, we can reason this from the nature of packet-forwarding networks; each router along a path makes a completely separate decision about where to forward received traffic. Any router along the path could actually change the path due to network conditions without notifying, in any way, upstream routers. Therefore, at any given time, an upstream router may be forwarding traffic along a path that no longer exists, or is no longer optimal, and downstream routers could be correcting the forwarding decision by placing the traffic on another available path unknown to the upstream router.
この例から、我々は転送一貫性が展開ネットワークに検証することはできません見ることができます。 BGPスピーカは、所定の宛先に到達するために特定のパスをアドバタイズという理由だけで、スピーカーに転送されたトラフィックが実際に広告を出し道をたどるだろうと想定する理由はありません。実際には、我々は、パケット転送ネットワークの性質からこれを推論することができます。パスに沿った各ルータは、受信トラフィックを転送する場所について完全に独立した決定を下します。パスのルーターは、実際にどのような方法、上流のルータでは、通知することなく、ネットワークの状況へのパスを変更することができます。したがって、任意の時点で、上流のルータは、もはや存在しない、またはもはや最適である経路に沿ってトラフィックを転送することができ、下流のルータはアップストリームルータへの未知の他の利用可能なパス上のトラフィックを置くことによって転送決定を補正することができます。
As a corollary, we can see that authorizing transit through a specific AS Path is not possible, either. If the source of a specific flow cannot know what path the traffic within that flow will take to reach the destination, then there is no meaningful sense in which downstream routers can authorize the source to use available paths for transiting traffic.
当然の結果として、我々はパスAS特定通る通過を許可すると、いずれか、不可能であることがわかります。具体的な流れの源は、そのフロー内のトラフィックが宛先に到達するのにかかるどのようなパスを知ることができない場合は、ダウンストリームルータがトラフィックを通過するために利用可能なパスを使用するソースを許可することが可能な意味のある意味ではありません。
In this internetwork, we assume a single policy: the system administrator of AS65000 would not like the destination 10.1.1.0/24 to be reachable from any autonomous system beyond AS65001. In other words, 10.1.1.0/24 should be reachable within AS65001, but not to autonomous systems connected to AS65001, such as AS65002.
このインターネットワークでは、我々は、単一のポリシーを前提としていますAS65000のシステム管理者は、AS65001を越えた自律システムから到達可能にする先10.1.1.0/24を好きではないだろう。換言すれば、10.1.1.0/24はAS65001内ではなく、例えばAS65002としてAS65001に接続された自律システムに到達可能でなければなりません。
10.1.1.0/24---(AS65000)---(AS65001)---(AS65002)
The system administrator can implement this policy by causing BGP speakers within AS65000 to advertise 10.1.1.0/24 to peers within AS65001 with a signal that the BGP speakers in AS65001 should not readvertise the reachability of this routing information. For example, BGP speakers in AS65000 could advertise the route to 10.1.1.0/24 with the NO_ADVERTISE community attached, as described in [RFC4271]. If the BGP speakers in AS65001 are configured to respond to this community (and we assume they are for the purposes of this document) correctly, they should accept this advertisement, but not readvertise reachability to 10.1.1.0/24 into AS65002.
システム管理者は、AS65001内のBGPスピーカはこのルーティング情報の到達可能性をreadvertiseないことを信号でAS65001内のピアに10.1.1.0/24をアドバタイズするAS65000内のBGPスピーカを引き起こすことによって、このポリシーを実装することができます。 [RFC4271]に記載されているように、例えば、AS65000内のBGPスピーカは、添付のNO_ADVERTISEコミュニティと10.1.1.0/24へのルートをアドバタイズすることができました。 AS65001内のBGPスピーカーが正しくこのコミュニティに応答するように構成（と私たちは、彼らがこの文書の目的であると仮定）している場合、彼らはこの広告を受け入れるが、AS65002に10.1.1.0/24に到達可能性をreadvertiseべきではありません。
However, unknown to the system administrator of AS65000, AS65001 is actually advertising a default route to AS65002 with an AS Path of {65001}, and not a full routing table. If some host within AS65002, then, originates a packet destined to 10.1.1.1, what will happen? The packet will be routed according to the default route from AS65002 into AS65001. Routers within AS65001 will forward the packet along the 10.1.1.0/24 route, eventually forwarding the traffic into AS65000.
しかし、AS65000のシステム管理者に知られていないが、AS65001は実際には{65001}のASパスではなく、完全なルーティングテーブルをAS65002へのデフォルトルートを広告しています。 AS65002内のいくつかのホストは、その後、10.1.1.1宛てのパケットを発信した場合、何が起こるのだろうか？パケットは、AS65001にAS65002からデフォルトルートに従ってルーティングされます。 AS65001内のルータは、最終的にAS65000にトラフィックを転送し、10.1.1.0/24ルートに沿ってパケットを転送します。
o Is the AS Path valid? This is a difficult question to answer, since there are actually two different advertisements in the example. From the perspective of the BGP speaker in AS65002 receiving a default route in an advertisement from a peer in AS65001, the AS Path to the default route is valid. However, there is no route to 10.1.1.0/24 for the BGP speaker in AS65002 to examine for validity, so the question appears to be out of scope for this example.
O ASパスは有効ですか？実際に例の2つの異なる広告があるので、これは、答えるのが難しい質問です。 AS65001内のピアからの広告にデフォルトルートを受信AS65002内のBGPスピーカーの観点からは、デフォルトルートのASパスは有効です。しかし、そこに妥当性検査するAS65002内のBGPスピーカーのため10.1.1.0/24へのルートがないので、問題は、この例の範囲外であるように思われます。
o Is the AS Path consistent with the forwarding path (is there forwarding consistency)? From the perspective of a BGP speaker in AS65002, traffic forwarded to AS65001 towards a destination within 10.1.1.0/24 is going to actually terminate within AS65001, since that is the entire AS Path for the default route. However, this traffic actually transits AS65001 towards AS65000. Therefore, forwarding consistency does not exist in this example, in which we are dealing with a case of aggregation, and as Section 9.1.4 of [RFC4271], in reference to aggregated routing information, states: "Forwarding along such a route does not guarantee that IP packets will actually traverse only ASes listed in the AS_PATH attribute of the route".
oは（一貫性が転送される）の転送パスと一致ASパスますか？ AS65002内のBGPスピーカーの観点から、10.1.1.0/24内の宛先に向けてAS65001に転送されたトラフィックは、デフォルトルートのパスAS全体であるため、実際に、AS65001内に終了する予定です。しかし、このトラフィックは、実際にAS65000に向けAS65001を通過します。したがって、一貫性を転送することは、我々は、凝集の場合を扱った、この例では存在せず、[RFC4271]のセクション9.1.4のように、集約ルーティング情報を参照して、状態：「そのようなルートに沿って転送がありませんIPパケットは、実際に「ルートのAS_PATH属性に記載されているだけのASを通過することを保証。
Is the advertisement authorized? This example higlights the tension between the three different types of authorization. The three following sections discuss issues with different advertisements AS65001 may send to AS65002.
広告は許可されていますか？この例では、承認の3つの異なる種類の間の緊張をhiglights。 3次のセクションでは、AS65002に送信することが異なる広告のAS65001の問題を議論します。
The first issue that comes up in this example is the case where there is no expectation of authorization for aggregation. The most common example of this is the advertising and accepting of the default route (0/0). This is a common practice typically done by agreement between the two parties. Obviously, there is not an authorization process for such an advertisement. This advertisement may extend reachability beyond the originator's intention (along the lines of the previous example). It may cause packets to take paths not known by the sender (since the path on 0/0 is simply the advertising AS). It may violate other security constraints. This places limits on the power and applicability of efforts to secure the AS path and AS policies. It does not vitiate the underlying value in such efforts.
この例では、最大来る最初の問題は、集計用の許可のない期待が存在しない場合です。この最も一般的な例は、広告やデフォルトルート（0/0）で受け入れています。これは典型的には、2つの当事者間の合意によって行わ一般的です。もちろん、そのような広告の承認プロセスがありません。この広告は、（前の例の線に沿って）発信者の意図を超えて到達可能性を拡張することができます。それは（0/0上のパスは、単に広告ASであるため）、パケットが送信者には知られていないパスを取る可能性があります。これは、他のセキュリティ制約に違反することがあります。これは、パワーとASパスとASの方針を確保するための努力の適用に制限を配置します。このような努力で根本的な価値を損なわれません。
In the current instantiation of IP address allocation, an AS may receive authorization to advertise 10.1.0.0/16, for instance, and may authorize some other party to use (or own) 10.1.1.0/24, a subblock of the space authorized. This is called a suballocation.
IPアドレスの割り当ての現在のインスタンスでは、ASは10.1.1.0/24、認可スペースのサブブロックを、たとえば、10.1.0.0/16を宣伝するための許可を受けることができる、および使用するためにいくつかの他の当事者を許可することができる（または自分）。これは、細分割り当てと呼ばれています。
For instance, in this example, if AS65001 were authorized to originate 10.1.0.0/16, it could advertise 10.1.0.0/16 towards AS65002, rather than a default route. Assume there is some form of authorization mechanism AS65002 can consult to verify AS65001 is authorized to advertise 10.1.0.0/16. In this case, AS65002 could examine the authorization of AS65001 to originate 10.1.0.0/16, and assume that if AS65002 is authorized to advertise 10.1.0.0/16, it is also authorized to transit traffic towards every possible subblock of (every destination within) 10.1.0.0/16. To put this in more distinct terms: o AS65002 verifies route authorization by examining the authorization of AS65001 to advertise 10.1.0.0/16.
AS65001が10.1.0.0/16を発信することを許可している場合たとえば、この例では、それはむしろ、デフォルトルートよりも、AS65002に向けて10.1.0.0/16を宣伝できます。 AS65001が10.1.0.0/16を宣伝することが許可されていることを確認するために相談することができ、認証機構AS65002のいくつかのフォームがあると仮定します。この場合、AS65002は10.1.0.0/16を発信するAS65001の許可を調べ、AS65002は10.1.0.0/16を宣伝することが許可されている場合、それはまた、（すべての目的地のすべての可能なサブブロック内に向けて通過トラフィックを許可されていることを前提と可能性）10.1.0.0/16。より明確な用語でこれを置くために：AS65002は10.1.0.0/16をアドバタイズするAS65001の許可を調べることによって、ルート認証を検証oを。
o AS65002 assumes destination authorization, that AS65001 has the authorization to advertise every possible subblock of 10.1.0.0/16, because AS65001 is authorized to advertise 10.1.0.0/16.
O AS65002はAS65001が10.1.0.0/16を宣伝することが許可されているのでAS65001は、10.1.0.0/16のあらゆる可能なサブブロックを宣伝する権限を持っていることを、先の認可を前提としています。
o AS65002 assumes transit authorization, that AS65001 has the authorization to transit traffic to every possible subblock of 10.1.0.0/16, because AS65001 is authorized to advertise 10.1.0.0/16.
O AS65002はAS65001が10.1.0.0/16を宣伝することが許可されているのでAS65001は、10.1.0.0/16のすべての可能なサブブロックへの通過トラフィックの許可を持っていること、トランジットの認可を前提としています。
From the example given, however, it is obvious route authorization does not equal destination or transit authorization. While AS65001 does have route authorization to advertise 10.1.0.0/16, it does not have destination authorization to advertise 10.1.1.0/24, nor transit authorization for destinations with 10.1.1.0/24.
与えられた例から、しかし、ルート認証は、同じ宛先または通過許可しない明らかです。 AS65001は10.1.0.0/16をアドバタイズするルートの権限を持っているが、それは10.1.1.0/24と宛先の10.1.1.0/24をアドバタイズする先の認可、またトランジットの許可を持っていません。
The naive reply to this would be to simply state that destination and transit authorization should not be assumed from route authorization. However, the problem is not that simple to resolve. The assumption of destination authorization and transit authorization are not decisions AS65002 actually makes; they are embedded in the way the routing system works. The route itself, within the design of routing, carries these implications.
これに対してナイーブ応答は単に目的地及び通過の許可がルート認証から推定されるべきではないと述べることであろう。しかし、問題は解決することは簡単ではありません。先の承認及び輸送の許可の前提は、AS65002が実際に作るの意思決定ではありません。彼らは、ルーティングシステムが機能する方法に埋設されています。ルート自体は、ルーティングの設計内で、これらの影響を運びます。
Why does routing intertwine these three types of authorization? Most simply, because AS65002 does not have any information about subblocks that are part of 10.1.0.0/16. There is no way for AS65002 to check for destination and transit authorization because this information is removed from the system altogether. In order to show destination and transit authorization, this information must be reinjected into the routing system in some way.
なぜルーティングは、認可のこれらの3種類が絡み合っていますか？最も単純には、AS65002は10.1.0.0/16の一部であるサブブロックについての情報を持っていないので。この情報は完全にシステムから削除されているため、AS65002が先及び通過の許可をチェックする方法はありません。目的地及び通過の許可を示すために、この情報は、何らかの方法で、ルーティングシステムに再注入する必要があります。
For instance, considering destination authorization alone, it is possible to envision a system where AS65001, when suballocating part of 10.1.0.0/16 to the originator, must also obtain permission to continue advertising the original address block as an aggregate, to attempt to resolve this problem. However, this raises some other issues:
例えば、一人で先の承認を考慮すると、解決しようとするために、発信元に10.1.0.0/16の一部をsuballocatingときAS65001は、また、骨材として元のアドレスブロックの広告を継続して許可を得なければならないシステムを想定することが可能ですこの問題。しかし、これは他のいくつかの問題を提起します：
o If the originator did not agree to AS65001 advertising an aggregate containing 10.1.1.0/24, then AS65001 would be forced to advertise some collection of advertisements not containing the suballocated block.
発信者が10.1.1.0/24を含む集計を宣伝AS65001に同意しなかった場合は、O、その後、AS65001はsuballocatedブロックを含まない広告のいくつかのコレクションを宣伝することを余儀なくされるだろう。
o If AS65001 actually does obtain permission to advertise the aggregate, we must find some way to provide AS65002 with information about this authorization for each possible subblock of 10.1.0.0/16.
AS65001が実際に集計を宣伝するための許可を取得した場合は、O、我々は10.1.0.0/16の可能な各サブブロックのために、この許可の詳細をAS65002を提供するためにいくつかの方法を見つける必要があります。
In other words, either AS65002 must receive the actual routes for each suballocation of 10.1.0.0/16, or it must receive some form of authorization allowing AS65001 to advertise each suballocation of 10.1.0.0/16. This appears to defeat the purpose of aggregation, rendering routing systems much less scalable than current design allows. Further, this does not resolve the issue of how AS65002 would actually know what all the suballocations of 10.1.0.0/16 actually are. Some possible solutions could be:
換言すれば、いずれかAS65002は10.1.0.0/16の各サブ割り当てのための実際のルートを受信しなければならないか、AS65001が10.1.0.0/16の各サブ割り当てをアドバタイズすることを可能にする許可のいくつかのフォームを受信しなければなりません。これは、はるかに少ないスケーラブル現在の設計が可能によりルーティングシステムをレンダリングする、凝集の目的を無効にするように見えます。さらに、これはAS65002が実際に10.1.0.0/16のすべてsuballocationsが実際にあるか知っているだろうかの問題が解決しません。いくつかの可能な解決策は次のようになります。
o The suballocator must advertise all suballocations. This could potentially expose business relationships and patterns that many large commercial providers do not want to expose, and degrades the hierarchical nature of suballocation altogether.
O suballocatorはすべてsuballocationsを宣伝しなければなりません。これは潜在的に多くの大規模な商業プロバイダが公開したくないビジネス関係やパターンを露出させ、そして完全に細分割り当ての階層的な性質を劣化させることができます。
o The IP address space must be reconstructed so everyone using IP address space will know, based on the construction of the IP address space, what subblocks exist. For instance, the longest allowed subblock could be set at a /24, and authorization must be available for every possible /24 in the address space, either for origination, or as part of an aggregate. This sort of solution would be an extreme burden on the routing system.
IPアドレス空間を使用して、誰もがサブブロックが存在するものを、IPアドレス空間の構築に基づいて、知っているので、oをIPアドレス空間を再構築する必要があります。例えば、最長の許可サブブロックには、/ 24に設定することができ、および承認は発信のため、または集合体の一部として、アドレス空間内のすべての可能な/ 24のために利用可能でなければなりません。ソリューションのこの種は、ルーティングシステム上の極端な負担になります。
It is also possible for AS65001 to have some form of agreement with AS65002 to aggregate blocks of address space it does not own towards AS65002. This might be done to reduce the burden on BGP speakers within AS65002. This is called proxy aggregation. While proxy aggregation is rare, it is useful to examine the result of agreed upon proxy aggregation in this situation.
AS65001はそれがAS65002の方に所有していないアドレス空間の集約ブロックにAS65002との契約のいくつかのフォームを持ってすることも可能です。これは、AS65002内のBGPスピーカーの負担を軽減するために行われるかもしれません。これは、プロキシの集約と呼ばれています。プロキシ凝集はまれですが、このような状況で合意したプロキシ集計の結果を検討するのに便利です。
Assume AS65001 has an advertisement for 10.1.0.0/24 from some unknown source, and decides to advertise both 10.1.0.0/24 and 10.1.1.0/24 as 10.1.0.0/23 to AS65002. If there exists an agreement for AS65001 to advertise proxy aggregates to AS65002, the latter will accept the advertisement regardless of any attached authorization to advertise. This may represent a security risk for AS65002, but it might be seen as an acceptable risk considering the trade-offs, from AS65002's perspective.
想定AS65001は、いくつかの未知のソースから10.1.0.0/24の広告があり、AS65002に10.1.0.0/23など10.1.0.0/24と10.1.1.0/24の両方を宣伝することを決定。 AS65002にプロキシ凝集体を宣伝するAS65001ための合意が存在する場合、後者は関係なく、宣伝するために取り付けられているすべての承認の広告を受け入れます。これは、AS65002のセキュリティリスクを表すことができるが、それはAS65002の視点からのトレードオフを考慮許容できるリスクとして見られるかもしれません。
The problem is, however, this also impacts the policies of AS65000, which is originating one of the two routes being aggregated by AS65001. There is no way for AS65002 to know about this policy, nor to react to it, and there is actually no incentive for AS65002 to react to a security threat posed to AS65000, which it has no direct relationship with. There doesn't appear to be any immediately available solution to this problem, other than to disallow proxy aggregation, even between two cooperating autonomous systems.
問題は、しかし、これも影響AS65001によって集約されている2つの経路の1つを発信さAS65000のポリシーです。 AS65002このポリシーを知って、またそれに反応するための方法はありません、とAS65002は、セキュリティ上の脅威に対処するためにインセンティブが、それはとは直接関係はありませんAS65000に提起しない実際にそこにあります。でも、2つのつの協働の自律システム間で、プロキシ集約を禁止する以外に、この問題へのすぐに利用できるソリューション、があるように表示されません。
The basic problem is that AS65002 assumes when AS65001 advertises an authorized route containing 10.1.1.0/24, either through a valid unauthorized aggregate, an owner aggregated route, or a proxy aggregation, AS65001 also has destination authorization for the subblock 10.1.1.0/24, and transit authorization for destinations within 10.1.1.0/24. These are, in fact, invalid assumptions, but they are tied to the way routing actually works. This shows the value of route authorization is questionable, unless there is some way to untie destination and transit authorization from route advertisements, which are deeply intertwined today.
基本的な問題は、AS65001は10.1.1.0/24を含む認可ルートをアドバタイズするときAS65002を前提とすることである、いずれかの有効な不正凝集、所有者集約経路、またはプロキシ凝集を通じて、AS65001はまた、サブブロック10.1.1.0/24の宛先権限を有します10.1.1.0/24以内の目的地のため、およびトランジット承認。これらは、実際には、無効な仮定ですが、彼らは、ルーティングが実際に動作する方法に関連付けられています。これは深く、今日絡み合っているルート通知から目的地及び通過の許可をほどくためにいくつかの方法がない限り、ルート認証の値は、疑問であることを示しています。
This example is slightly more complex than the last two. Given the following small network, assume that A and D have a mutually agreed upon policy of not allowing traffic to transit B to reach destinations within 10.1.1.0/25.
この例は少し複雑最後の2以上です。以下の小規模なネットワークを考えると、AとDは、相互にトランジットBへのトラフィックが10.1.1.0/25以内の目的地に到達することを可能にするのではない政策に合意していることを前提としています。
10.1.1.0/25--A---B---C---D
| | |
E-------F---G
Assume the following:
次のことを想定します。
o A advertises 10.1.1.0/25 to B, and 10.1.1.0/24 to E.
O AはBに10.1.1.0/25をアドバタイズし、そしてE.へ10.1.1.0/24
o B advertises 10.1.1.0/25 {B,A} to C.
O BはCに10.1.1.0/25 {B、A}をアドバタイズ
o E advertises 10.1.1.0/24 {E,A} to F, filtering 10.1.1.0/25 {E,A} based on some local policy.
O Eは、いくつかのローカルポリシーに基づいて10.1.1.0/25 {E、A}をフィルタリングし、Fに10.1.1.0/24 {E、A}をアドバタイズ。
o F advertises 10.1.1.0/24 {F,E,A} to C and to G.
O Fは、CおよびGに10.1.1.0/24 {F、E、A}をアドバタイズ
o C advertises 10.1.1.0/24 {C,F,E,A} to D, filtering 10.1.1.0/25 {B,A} based on some local policy.
O Cは、いくつかのローカルポリシーに基づいて10.1.1.0/25 {B、A}をフィルタリングし、Dに10.1.1.0/24 {C、F、E、A}をアドバタイズ。
o G advertises 10.1.1.0/24 {G,F,E,A} to D.
O GはDに10.1.1.0/24 {G、F、E、A}をアドバタイズ
o D chooses 10.1.1.0/24 {C,F,E,A} over 10.1.1.0/24 {G,F,E,A}.
O Dは{G、F、E、A} 10.1.1.0/24上10.1.1.0/24 {C、F、E、A}を選択します。
What path will traffic forwarded to C destined to hosts within 10.1.1.0/25 actually follow?
どのようなパスCに転送されるトラフィックは、実際に従う10.1.1.0/25内のホスト宛のでしょうか？
o D forwards this traffic to C, since its best path is through 10.1.1.0/24 {C,F,E,A}.
O Dの最良の経路が10.1.1.0/24を介しているので、Cへ転送し、このトラフィックを、{C、F、E、A}。
o C forwards this traffic to B, since its best path is through 10.1.1.0/25 {B,A}.
O C最善経路は10.1.1.0/25を介しているので、Bに転送し、このトラフィックを、{B、A}。
o B forwards this traffic to A, since its best path is through 10.1.1.0/25 {A}.
O B Aに転送し、このトラフィックを、その最良の経路が10.1.1.0/25 {A}を介するものであるからです。
Considering this result:
この結果を考慮すると：
o Is the AS Path valid? Both {G, F, E, A} and {C, F, E, A} are valid AS Paths, so both AS Paths in this example are valid.
O ASパスは有効ですか？ {G、F、E、A}及び{C、F、E、A}は経路として有効であるので、この例のように両方のパスの両方が有効です。
o Is the advertisement authorized? Assuming A is authorized to advertise 10.1.1.0/24, and all the autonomous systems in the example are authorized to readvertise 10.1.1.0/24, the route is authorized. However, C does not have destination nor transit authorization to 10.1.1.0/25, since B is the best path from C to 10.1.1.0/25, and D and A have explicit policies not to transit this path. In effect, then C does not have destination or transit authorization for 10.1.1.0/24, because it contains 10.1.1.0/25.
oは広告が許可されていますか？仮定すると、Aが10.1.1.0/24を宣伝することが許可され、そして例では、すべての自律システムが10.1.1.0/24をreadvertiseする権限を与えられ、ルートが許可されています。 BがCから10.1.1.0/25への最適なパスがあり、そしてDおよびAがないトランジットへの明示的なポリシーこのパスを持っているので、Cは、10.1.1.0/25に先や輸送許可を持っていません。それは10.1.1.0/25が含まれているため、実際には、その後、Cは、10.1.1.0/24の送信先または通過の許可を持っていません。
o Is the AS Path consistent with the forwarding path (is there forwarding consistency)? While C is advertising the AS Path {C, F, E, A} to D to reach destinations within 10.1.1.0/24, it is actually forwarding along a different path to some destinations within this advertisement. Forwarding consistency does not exist within this internetwork.
oは（一貫性が転送される）の転送パスと一致ASパスますか？ Cは10.1.1.0/24内の目的地に到達するためにDにASパス{C、F、E、A}を広告しているが、それは実際にこの広告内のいくつかの目的地への別のパスに沿って転送されます。一貫性を転送すると、このインターネットワーク内に存在しません。
In this example, A assumes that D will receive both the advertisement for 10.1.1.0/24 and the advertisement for 10.1.1.0/25, and will be able to use the included AS Path to impose their mutually agreed on policy not to transit B. Information about 10.1.1.0/25, however, is removed from the routing system by policies outside the knowledge or control of A or D. The information remaining in the routing system implies D may correctly route to destinations within 10.1.1.0/25 through C, since 10.1.1.0/25 is contained within 10.1.1.0/24, which C is legally advertising.
この例では、Aは、Dは10.1.1.0/25ため10.1.1.0/24の広告及び広告の両方を受信することになる、としないトランジットBへの相互ポリシーに合意を課すパスとして含まを使用することができるであろうことを前提としてい約10.1.1.0/25、ただし、AまたはDの知識又は制御外部ポリシーによってルーティングシステムから除去される。情報は、ルーティングシステムに残りの情報は10.1.1.0/25内の宛先へDよい正しく経路を通ることを意味しますCは、10.1.1.0/25以来、Cが合法的に宣伝され、10.1.1.0/24内に含まれています。
The tension between route authorization, destination authorization, and transit authorization can be seen clearly in this slightly more complex example. Route authorization implies destination and transit authorization in routing, but route authorization does not include destination or prefix authorization in this example.
ルート認証、先の承認、及び中継許可間の張力は、このもう少し複雑な例でははっきりと見ることができます。ルート認証は、ルーティングの宛先と中継許可を意味するが、ルート認証は、この例では、宛先またはプレフィックス認可を含んでいません。
This is the most complex example we will cover in this document. It can be argued that the configuration described in this example is a misconfiguration, but we have chosen this example for its simplicity, as an illustration of the complexity of the interaction between interior and exterior gateway protocols within an autonomous system. BGP route reflectors, particularly when configured in a hierarchy, provide many examples of forwarding inconsistency, but they are much more complex than this small example.
これは、私たちがこのドキュメントでカバーする最も複雑な例です。なお、この例で説明した構成は、設定ミスであると主張することができるが、我々は、自律システム内の内部と外部ゲートウェイプロトコルとの間の相互作用の複雑さの実例として、その単純さのためにこの例を選択しました。階層で構成された場合、BGPルートリフレクタは、特に矛盾を転送するの多くの例を提供するが、それらははるかに複雑この小さな例よりいます。
+-----F(9)---------------G(3)--------+
| | |
| +------+ |
| | |
| +---C(2)--+ |
| | | |
A(1)-----B(2) +----------------E(5)--10.1.1.0/24
| | | |
| +---D(2)--+ |
| |
+------------------H(6)--J(7)--K(8)--+
In this diagram, each router is labeled, with the AS in which it is contained, in parenthesis following the router label. As its best path to 10.1.1.0/24:
この図では、各ルータは、ルータのラベル、次の括弧内に、それが含まれているASで、標識されています。 10.1.1.0/24への最良のパスとして：
o Router E is using its local (intra-AS) path.
OルータEは、ローカル（イントラAS）パスを使用しています。
o Router C is using the path through AS3.
OルータCは、AS3を通る経路を使用しています。
o Router D is using the path through Router E.
OルータDはルータE.通る経路を使用しています
o Router B is using the path through Router E.
OルータBは、ルータE.通る経路を使用しています
Examining the case of Router B more closely, however, we discover that while Router B prefers the path it has learned from Router E, that path has been advertised with a next hop of Router E itself. However, Router B's best path to this next hop (i.e., Router E), as determined by the interior routing protocol, is actually through Router C. Thus, Router B advertises the path {2, 5} to Router A, but traffic actually follows the path {2, 3, 5} when Router B receives it.
より密接にルータBの場合を調べると、しかし、私たちは、ルータBは、それがルータEから学習したパスを好む一方で、そのパスがルータE自体のネクストホップと宣伝されていることを発見します。内部ルーティングプロトコルによって決定されるが、ルータこのネクストホップ（すなわち、ルータE）にBの最良の経路は、ルータCを介して実際にこのように、ルータBは、実際には、ルータAのパス{2,5}が、トラフィックをアドバタイズパス{2、3、5}ルータBがそれを受信する以下。
The system administrator of AS1 has determined there is an attacker in AS3, and has set the policy on router A to avoid any route with AS3 in the AS Path. So, beginning with this rule, it discards the path learned from AS9. It now examines the two remaining paths, learned from AS2 (B) and AS6, and determines the best path is {2, 5}, through AS2 (B). However, unknown to A, AS2 (B) is also connected to AS3, and is transiting traffic to AS5 via the path {2, 3, 5}.
AS1のシステム管理者は、AS3で、攻撃者がある決定した、とASパスにAS3との任意の経路を回避するために、ルータAにポリシーを設定しています。だから、このルールから始まる、それはAS9から学んだパスを破棄します。今AS2（B）およびAS6から学習し、残りの2つの経路を調べ、最適なパスは、{2,5}、AS2を介して（B）であるかを判断します。しかし、Aにとって未知、AS2（B）もAS3に接続され、パス{2、3、5}を介しAS5にトラフィックを通過されます。
Returning to our questions:
私たちの質問に戻ります：
o Is the AS Path valid? The AS Path {2, 3, 5} is a valid AS Path.
O ASパスは有効ですか？ ASパス{2,3,5}はパスとして有効です。
o Is the route authorized? Assuming each AS along the path is authorized to originate, or readvertise, 10.1.1.0/24, the route is authorized. Destination authorization is also clear in this situation, since 10.1.1.0/24 is the single destination throughout the example. Transit authorization is a little more difficult to determine, since the traffic doesn't actually flow along the AS Path contained in the routing advertisement. It's impossible to claim the AS Path {2,3,5} is a valid path from either the route originator or the traffic originator, since that AS Path is not the AS Path advertised. Essentially, Router E assumes transit authorization from route authorization, when there is no way to determine that AS3 is actually authorized to transit traffic to 10.1.1.0/24.
oはルートが許可されていますか？経路に沿った各ASを仮定すると、ルートが許可され、発信、またはreadvertise、10.1.1.0/24を許可されています。 10.1.1.0/24を例を通して単一の宛先であるので、先の承認は、このような状況でも明らかです。トラフィックが実際にルーティング広告に含まれるASパスに沿って流れないので、トランジットの許可は、少し難しく決定することです。パスとしてそれをアドバタイズASパスではないので、それは、ASパスは、{2,3,5}はルート発信またはトラフィック発信元のいずれかから有効なパスであると主張することは不可能です。 AS3が実際に10.1.1.0/24への通過トラフィックを許可されていることを判断する方法がないとき基本的には、ルータEは、ルート認証からトランジットの認可を前提としています。
o Is the AS Path consistent with the forwarding path (is there forwarding consistency)? The advertised AS Path is {2, 5}, while the traffic forwarded to the destination actually transits {2, 3, 5}. Forwarding is not consistent in this example.
oは（一貫性が転送される）の転送パスと一致ASパスますか？パスとしてアドバタイズは{2,5}であり、宛先に転送されたトラフィックが実際に遷移しながら、{2,3,5}。転送は、この例では一貫していません。
The examples given in this document are not the only possible examples of forwarding that is inconsistent with the advertised AS Path; [ROUTINGLOGIC] also provides some examples, as well. [ASTRACEROUTE] provides some interesting background on the practical impact of forwarding that is inconsistent with the advertised AS Path, in the context of attempting to trace the actual path of packets through a large internetwork, running BGP as an exterior gateway protocol.
この文書で与えられた例はパスとしてアドバタイズと矛盾しているフォワーディングの唯一の可能な例ではありません。 【ROUTINGLOGIC】また同様に、いくつかの例を提供します。 【ASTRACEROUTE】外部ゲートウェイプロトコルとしてBGPを実行して、大規模なインターネットワークを介してパケットの実際のパスをトレースしようとする状況において、パスとしてアドバタイズと矛盾する転送の実用的な影響に関するいくつかの興味深い背景を提供します。
Routing strongly intertwines the concepts of route authorization, destination authorization, and transit authorization. If a BGP speaker is authorized to advertise a specific route, routing assumes that it is also authorized to advertise every possible subblock within the destination prefix, and the advertiser is authorized to transit packets to every destination within the route. By surveying these examples, we see that route authorization does not, in fact, equal destination authorization or transit authorization, calling into question the value of route authorization.
ルーティングが強く、ルート認証、先の承認、および輸送の許可の概念を絡み合います。 BGPスピーカは、特定のルートをアドバタイズするために許可されている場合は、ルーティングは、また、宛先プレフィクス内のすべての可能なサブブロックを宣伝することが許可されていることを前提とし、広告主は、ルート内のすべての宛先へのトランジットパケットを許可されています。これらの例を調査することによって、我々は質問に、ルート認証の値を呼び出して、ルートの許可がないことを、実際には、同じ目的地の許可または通過の許可を参照してください。
There are no easy or obviously scalable solutions to this problem.
この問題に対する簡単かは明らかにスケーラブルなソリューションではありません。
We would like to thank Steve Kent for his contributions and comments on this document. We would also like to thank Joel Halpern for his work in clarifying many sections of the document, including additional text in critical sections.
私たちは、この文書の彼の貢献とコメントをスティーブ・ケントに感謝したいと思います。また、クリティカルセクションでは、追加のテキストを含む文書の多くのセクションを、明確に彼の仕事のためにジョエル・ハルパーンに感謝したいと思います。
This document does not propose any new extensions or additions to existing or proposed protocols, and so does not impact the security of any protocol.
この文書では、既存または提案されたプロトコルに新たな拡張や追加を提案していない、ので、任意のプロトコルのセキュリティに影響を与えません。
[ASTRACEROUTE] Feamster, N. and H. Balakrishnan, "Towards an Accurate ASLevel Traceroute Tool", SIGCOMM ACM SIGCOMM, 2003.
"正確なASLevel tracerouteのツールに向けて" [ASTRACEROUTE] Feamster、N.およびH.バラクリシュナン、SIGCOMM ACM SIGCOMM、2003。
[BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[BGP-MD5] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[ROUTINGLOGIC] Feamster, N. and H. Balakrishnan, "Towards a Logic for Wide Area Routing", SIGCOMM ACM SIGCOMM Worshop on Future Directions in Network Architecture, Germany, August 2003.
[ROUTINGLOGIC] Feamster、N.およびH.バラクリシュナン、ネットワークアーキテクチャ、ドイツ、2003年8月今後の方向について、SIGCOMM ACM SIGCOMM Worshop「広域ルーティングのロジックに向けて」。
[SOBGP] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Work in Progress.
[SOBGP]ホワイト、R.、 "セキュア起源BGP（soBGP）のためのアーキテクチャと実装の考慮事項" が進行中で働いています。
Authors' Addresses
著者のアドレス
Russ White Cisco Systems
ラスホワイトシスコシステムズ
EMail: riw@cisco.com
メールアドレス：riw@cisco.com
Bora Akyol Cisco Systems
ボラAkyolシスコシステムズ
EMail: bora@cisco.com
メールアドレス：bora@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。