RFC5123 日本語訳
5123 Considerations in Validating the Path in BGP. R. White, B. Akyol. February 2008. (Format: TXT=39948 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. White
Request for Comments: 5123 B. Akyol
Category: Informational Cisco Systems
February 2008
コメントを求めるワーキンググループのR.の白い要求をネットワークでつないでください: 5123年のB.Akyolカテゴリ: 情報のシスコシステムズ2008年2月
Considerations in Validating the Path in BGP
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は配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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 Autonomous System(AS)経路の中で合法化の概念でホップごとの推進、ルート集合、およびルートフィルタリングの含意を調べます。
1. Background
1. バックグラウンド
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 Pathを有効にする際に問題について説明することです、それが経路合法化を改良しようとする計画の評価で助ける期待で。 最初のセクションは少なくとも同輩からアップデートを受けるBGPスピーカーがルーティングアップデートの中で地方の自律システム(AS)で情報に関して尋ねることができなかったという質問の何人かのタイプを定義します。 以下のセクションはBGPの特定の展開を考慮してこれらの質問の答えを調べます。
White & Akyol Informational [Page 1] RFC 5123 Path Validation Considerations February 2008
[1ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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.
本書では出された例が展開をそれらの最も重要なコンポーネントまで蒸留することを意図します、理解して、例を考えるのをより簡単にして。 多くの状況で、例で取られた特定の経路は関連していないかもしれませんが、それは各例で考えられた原則を無効にしません。 特定保険証券を実際の問題に入れないので、これらの例が「薫製ニシン」であると示唆されました。 これに反して、それらが簡単であるので、これらの例は強力です。 これらの例のtopologiesの1つが「副-トポロジー」であるどんなトポロジーも本書では説明された特性を示すでしょう。 特定のトポロジーに焦点を合わせて、次に、「角のケース」としてその単一のトポロジーを棄却するよりむしろ、このドキュメントはBGPの中にAS Path属性に関して主張の初版を示しています。 そして、これらの一般化された問題をより特定のケースに適用できます。
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.
ネットワークセキュリティへの高められた関心をもって、[RFC4271]で説明されるようにBGPを走らせながらルーティングシステムの中で運ばれた情報のセキュリティは興味津々で見られています。 ルーティングプロトコル情報を交換しながら2台の装置の間の関係を保証するのに利用可能なテクニックがある間、[BGP-MD5]などのようなこれらのテクニックは、ルーティング・プロトコルの中で運ばれた情報の種々相が有効であるか、または認可されているのを確実にしません。
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)
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スピーカーが10.1のために広告を受け取ったと仮定してください。.1 65000、65001のAS PathとAS65001のBGPスピーカーからの.0/24。
1.1. Is the Originating AS Authorized to Advertise Reachability to the
Destination?
1.1. 広告を出すのが認可される由来は目的地への可到達性ですか?
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の中に.0/24に.1を含んだということです。 AS65000がAS65000への.1.0/24由来が確かめることができる10.1へのルートですが、受信しているBGPスピーカー、本当にか否かに関係なく、10.1に.1の広告を出すのが認可されて、このドキュメントの範囲の外に.0/24があります。
White & Akyol Informational [Page 2] RFC 5123 Path Validation Considerations February 2008
[2ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
1.2. Is the Path Contained in the Advertised Routing Information Valid?
1.2. 広告を出している経路情報に含まれた経路は有効ですか?
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に続いて、受信機が容認されたAS Pathに記載された由来している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 Path65000、65001でAS65001のBGPスピーカーから広告を受け取るとき、スピーカーが、AS65001が地方のASに取り付けられて、また、AS65001がAS65000に取り付けられると仮定できると断言します。
1.3. Is the Advertisement Authorized?
1.3. 広告は認可されますか?
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 送信機がルートに含まれた特定のルーティング情報の広告を出すのが認可されます。 これはルートが実際に含む情報にかかわらず単一の、そして、原子力の単位としてルーティング情報を扱います。 Aは.0/24と別のものが10.1に発送する.1を10.1に発送します。これら以来の.0/24は10.1に.1の広告を出す認可への尊敬がなければ、そうです。.0 .0/16がルーティング情報の完全に異なった広告であると考えられる、したがって、ASが10.1に.0.0/の広告を出すのが認可されるかもしれない、16、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 送信機がルートに含まれた特定の届いている目的地の広告を出すのが認可されます。 これは1セットの目的地としてルーティング情報を扱います。 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 送信機はルートの中に含まれた目的地へのトランジット交通に認可されます。 これはルートが使用されることにルートの概念を結びます。 .0/24、それは10.1の中ですべての届いている目的地へのトランジット交通に認可されます。BGPスピーカーであるなら10.1への広告の可到達性が.1である、.1 経路に沿った.0/24は広告を出しました。 これはこのドキュメント中にトランジット認可と呼ばれます。
White & Akyol Informational [Page 3] RFC 5123 Path Validation Considerations February 2008
[3ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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つの定義の間には、かなりの緊張があります。 彼らがそうする認可、およびどのようにに関するこれらの異なったタイプの間の関係について調査するかの周りでこのドキュメントの多くが築き上げられます、様々なインターネットワークにおける仕事。 このドキュメントで達した結論の1つはルート認可、可到達性認可、およびトランジット認可がしばしば互いと不和であるということです。 1つのタイプの認可が本当であることを示すのがいかなる他のタイプの認可も本当であることを示しません、そして、ルーティングシステムにおける、これらの3つのタイプの認可のからみ合っている本質のために、ルート認可には、疑わしい値があります。
1.4. Will Traffic Forwarded to an Advertising Speaker Follow the
Described AS Path?
1.4. Advertising議長に送られたウィルTrafficは説明に経路を続いて起こりますか?
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 Pathで説明したアップデート尾行の広告を出す同輩に送られた交通を望んでくれますか? 本書では、これは推進の一貫性と呼ばれます。
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スピーカーが.0/24がAS Path65000、65001と共にAS65001のBGPスピーカーに送られた交通を望んでいる目的地10.1.1のために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同輩は元々、接頭語(または、接頭語の広告を出すのが認可された)の広告を出していました。 このドキュメントの範囲の外にこの主張はあります。
2. Analysis
2. 分析
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と共に経路ベクトルルーティングシステムの認可の様々なタイプの間で引き受けられるでしょう。
2.1. A Short Analysis of Routing
2.1. ルート設定の短い分析
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
要するに、ルーティング・プロトコルは、ネットワーク(または、インターネットワーク)の中で1セットの無輪の経路をそれぞれの届いている目的地に発見するように設計されています。 特定の目的地に達するように選ばれた無輪の経路は最短パスでないかもしれません、そして、それはいつもあるかもしれないというわけではありません。
White & Akyol Informational [Page 4] RFC 5123 Path Validation Considerations February 2008
[4ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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.
これは経路ベクトルプロトコルのルーティングアップデートに経路を含む目的をいくつか解明します: いかなる他の情報も提供するというよりむしろ経路には輪がないと立証するために、経路はそこにあります。 ダイクストラのSender Policy Framework(SPF)と両方が基礎づけるDiffusing Update Algorithm(DUAL)をゆったり過ごしてください、それら、輪なし、経路の費用における経路計算(BGPなどの経路ベクトルプロトコル)は、経路が広告自体が横断したノードのリストを運ぶのによる無料の輪であると立証します。 BGPがどんな与えられたアップデートのためにも輪のろ水度を立証するのに明確にAS Pathベースのメカニズムを使用するので、競争している測定基準によって引き起こされたルーティングシステムで輪を危険にさらさないで、経路に沿った各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スピーカーによるその方針を設定するか、またはルートのセキュリティー・レベルを測る使用を考えるとき、私たちは、この原則を覚えておく必要があります。
2.2. First Example: Manual Intervention in the Path Choice
2.2. 最初の例: 経路選択における手動の介入
In the small network:
小さいネットワークで:
+---(AS65002)---+
(AS65000)--(AS65001) (AS65004)--10.1.1.0/24
+---(AS65003)---+
+---(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スピーカーは同輩から広告をその10.1に受け取るかもしれません。.1 .0/24は経路65004、65002、65001に沿って届いています。 この情報に基づいて、BGPスピーカーはAS65001の同輩にパケットを送るかもしれません、説明された経路を取ると予想して。 しかしながら、AS65001の中でネットワーク管理者は10.1への次のホップを.1.0/にするスタティックルートを構成したかもしれません。24 AS65003がある縁のルータ。
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
それは、[RFC4271]は以下を述べますが、それに注意するために役に立ちます。 "....「私たちは、BGPスピーカーがそれ自体が使用するそれらのルートの同輩だけに広告を出すと思います」…, 「使用」という用語の定義はすべての広く配備された知られているBGP実現でかなりゆるいです。 意味よりむしろ: 一般に、「BGPスピーカーはスピーカーのBGPの過程が経路指定テーブルにインストールした目的地の広告を出すだけでしょう」と意味します: 「BGPスピーカーは地方がテーブルを発送して、合っているルートをインストールする目的地の広告を出すだけでしょう、ローカルルータの上のどんな過程がルートをインストールしたかとしても。」 ナイーブな反応が単にBGP仕様とすべての既存の実現を変えることであるかもしれないので、BGPスピーカーはaにルートの広告を出すだけでしょう。
White & Akyol Informational [Page 5] RFC 5123 Path Validation Considerations February 2008
[5ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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の過程が実際に地方の経路指定テーブルにルートをインストールしたなら、じっと見てください。 しかしながら、これは内部の、そして、外のゲートウェイプロトコルの間の複雑な相互作用とルート創作の複雑さを無視します。(相互作用は同じ装置でたいてい動きます)。
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 Pathは有効ですか? AS65000の受信BGPスピーカーがAS65001の同輩から受け取るAS Path、65004、65002、65001は、)存在していて、有効です。
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にはルートと可到達性認可の両方があると思うことができますが、この状況でどうトランジット認可を実行できるかを見るのは難しいです。 AS65000のBGPスピーカーが確かめることができても、AS65001は達するトランジットAS65002に認可されます。10.1 .1 .0/24、これはトランジット交通への経路交通による認可に関する何も実際に取らないのを含意します、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 Pathが推進経路と一致している、(推進の一貫性が存在している、)、-- いいえ、広告を出しているAS Pathは65004、65002、65001ですが、実際の経路は65004、65003、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
推論として、私たちは、特定のAS Pathを通してトランジットを認可するのが可能でないことを見ることができます。 aの源です。
White & Akyol Informational [Page 6] RFC 5123 Path Validation Considerations February 2008
[6ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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.
特定の流れは、その流れの中の交通が始めるどんな経路が目的地に達するかを知ることができないで、次に、川下のルータが、ソースが交通を通過するのに利用可能な経路を使用するのを認可できるどんな重要な感覚もありません。
2.3. Second Example: An Unintended Reachable Destination
2.3. 第2例: 故意でない届いている目的地
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のシステム管理者は目的地10.1のようにそうしないでしょう。.1 AS65001を超えたどんな自律システムからも届く.0/24。 24がそうするべきである.1.0/は、言い換えれば、10.1に、AS65001の中で届きますが、自律システムに接続しませんでした。AS65002などのAS65001に。
10.1.1.0/24---(AS65000)---(AS65001)---(AS65002)
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.
AS65000の中のBGPスピーカーが広告を出すことを引き起こすことによって、システム管理者はこの政策を実施できます。10.1 .1 AS65001のBGPスピーカーがこのルーティング情報の可到達性の「再-広告を出」すべきでないという信号があるAS65001の中の同輩への.0/24。 例えば、AS65000のBGPスピーカーが10.1にルートの広告を出すことができた、.1、.0/24、ノー_、広告、共同体は付きました、[RFC4271]で説明されるように。 AS65001のBGPスピーカーが正しくこの共同体(私たちは、彼らがこのドキュメントの目的のためのものであると思う)に応じるために構成されるなら、10.1に可到達性の「再-広告を出」さないのを除いて、それらはこの広告を受け入れるべきです。.1 AS65002への.0/24。
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 Pathと共にデフォルトルートのAS65002に広告を出します。 次に、AS65002の中のホストが由来するならパケットが10.1に.1を運命づけた、.1 何が起こるでしょうか? デフォルトルートに応じて、パケットはAS65002からAS65001に発送されるでしょう。 結局交通をAS65000に送って、AS65001の中のルータは.1.0/24ルートを10.1に沿ったパケットに送るでしょう。
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 Pathは有効ですか? 例には2つの異なった広告が実際にあるので、これは答えにくい質問です。 AS65001の同輩から広告におけるデフォルトルートを受けるAS65002のBGPスピーカーの見解から、デフォルトルートへのAS Pathは有効です。 10.1へのルートが全くありません。.1 AS65002のBGPスピーカーが正当性がないかどうか調べる.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
o AS Pathは推進経路(推進の一貫性がある)と一致していますか? AS65002のBGPスピーカーの見解、10.1の中で目的地に向かったAS65001に送られた交通から、.0/24が実際に行く.1はAS65001の中で終わります、以来
White & Akyol Informational [Page 7] RFC 5123 Path Validation Considerations February 2008
[7ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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".
それはデフォルトルートへの全体のAS Pathです。 しかしながら、この交通は実際にAS65000に向かってAS65001を通過します。 したがって、推進の一貫性はこの例に存在していません:(そこでは、集合、.4セクション9.1[RFC4271]が集められたルーティング情報に関して述べるように私たちがケースに対処しています)。 「そのようなルートに沿った推進は、IPパケットが実際にルートのAS_PATH属性で記載されたASesだけを横断するのを保証しません。」
2.3.1. Advertisement Authorization
2.3.1. 広告認可
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の以下の章がAS65001がAS65002に送るかもしれない異なった広告の問題について議論します。
2.3.1.1. Valid Unauthorized Aggregates
2.3.1.1. 有効な権限のない集合
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方針を保証するための努力のパワーと適用性に限界を置きます。 それはそのような努力における基本的な値を損ないません。
2.3.1.2. Owner Aggregation
2.3.1.2. 所有者集合
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に.0.0/の広告を出すために認可を受けるかもしれない、例えば、16、10.1 .1 .0/24、認可されたスペースの副ブロック。 これは細分割当てと呼ばれます。
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:
.0/16、それは広告を出すことができました。例えば、AS65001が認可されるならこの例では、10.1に.0を溯源してください、10.1 .0 デフォルトルートよりむしろAS65002に向かった.0/16。 AS65002が10.1に.0/16に.0の広告を出すために認可されたAS65001について確かめるために相談できる認可メカニズムの何らかのフォームがあると仮定してください。 この場合AS65002が10.1に.0.0/を溯源するためにAS65001の認可を調べることができた、16、AS65002が10.1に.0の広告を出すのが認可されるならそれを仮定してください、.0/16、また、それがあらゆる可能な副ブロックに向かったトランジット交通に認可される、(あらゆる目的地、中)、10.1 .0 .0/16。 より異なった用語でこれを置くために:
White & Akyol Informational [Page 8] RFC 5123 Path Validation Considerations February 2008
[8ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
o AS65002 verifies route authorization by examining the
authorization of AS65001 to advertise 10.1.0.0/16.
o AS65002は、10.1に.0/16に.0の広告を出すためにAS65001の認可を調べることによって、ルート認可について確かめます。
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/16に.0の広告を出すのが認可されます。
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/16に.0の広告を出すのが認可されます。
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.
しかしながら、出された例から、ルート認可が目的地かトランジット認可と等しくないのは、明白です。 10.1で目的地のための認可を通過してください。AS65001には10.1に.0の広告を出すルート認可がある、.0/16、それに10.1に.1.0/の広告を出す目的地認可がない、24、.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の一部を「副-割り当て」るとき、システムどこAS65001を思い描くかは可能です。.0 また、創始者への.0/16、必須はこの問題を解決するのを試みるために集合として元のあて先ブロックの広告を出し続ける許可を得ます。 しかしながら、これはある他の問題を提起します:
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.
o 創始者が、10.1に.1を含む集合の.0/24、当時のAS65001がそうする広告を出すのがやむを得ず「副-割り当て」られたブロックを含まない広告の何らかの収集の広告を出すのにAS65001に同意しなかったなら。
o If AS65001 actually does obtain permission to advertise the
aggregate, we must find some way to provide AS65002 with
o AS65001が実際に集合の広告を出す許可を得るなら、私たちはAS65002を提供する何らかの方法を見つけなければなりません。
White & Akyol Informational [Page 9] RFC 5123 Path Validation Considerations February 2008
[9ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
information about this authorization for each possible subblock of
10.1.0.0/16.
それぞれのための可能なこの認可の情報は10.1を「副-妨げ」ます。.0 .0/16。
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の各細分割当てのための実際のルートを受けなければならない、AS65001が10.1の各細分割当ての広告を出すのを許容しながら16、またはそれがそうしなければならない.0.0/が何らかの形式の認可を受ける、.0 .0/16。 現在のデザインよりはるかにスケーラブルでないのにルーティングシステムを表すのは集合の目的をくつがえすようにこれを見えさせます。 さらに、これがAS65002が実際にどうなにかを知るだろうかに関する問題を解決しない、すべての細分割当て、10.1 .0 .0/16は実際にそうです。 いくつかの可能な解決策は以下の通りであるかもしれません。
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 「副-アロケータ」はすべての細分割当ての広告を出さなければなりません。 これは、潜在的に、多くの大きい商業プロバイダーが露出したがっていない取引関係とパターンを露出できて、全体で細分割当ての階層的な本質を下がらせます。
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.
o IPアドレス空間を再建しなければならないので、IPアドレス空間を使用している皆は、IPアドレス空間の工事に基づいて何の副ブロックが存在するかを知るでしょう。 例えば、/24に最も長い副ブロックが許された設定できました、そして、認可はアドレス空間におけるあらゆる可能な/24か、創作か、集合の一部として利用可能であるに違いありません。 この種類の解決策はルーティングシステムの上の極端な負担でしょう。
2.3.1.3. Proxy Aggregation
2.3.1.3. プロキシ集合
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.
何らかの未知からの24が出典を明示して、決める.0.0/が10.1に10.1に両方の広告を出すのでAS65001が広告を出していると仮定してください、.0 24と.0/10.1.1.0/、24、10.1 .0 AS65002への.0/23。 AS65001がプロキシ集合のAS65002に広告を出す協定が存在していると、後者は、どんな付属認可にかかわらず広告を出すために広告を受け入れるでしょう。 これは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
問題はそうです、しかしながら、また、これがAS65000の方針に影響を与えます。(方針はAS65001によって集められる2つのルートの由来している1つです)。 この方針に関して知って、それに反応するために、AS65002のための方法は全くありません、そして、AS65002がそれがダイレクトにしないAS65000に引き起こされた軍事的脅威に反応する実際に誘因が全くありません。
White & Akyol Informational [Page 10] RFC 5123 Path Validation Considerations February 2008
[10ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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.
関係 この問題の少しのすぐに利用可能な解決もあるように見えません、プロキシ集合を禁じるのを除いて、2つの協力自律システムの間でさえ。
2.3.2. Implications
2.3.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.
基本的問題がAS65002が、いつAS65001が10.1にまた有効な権限のない集合、より自身の集められたルート、またはプロキシ集合、AS65001を通した.0/24には副ブロック10.1.1の.0/24、およびトランジット認可のための目的地認可がある.1を含む認可されたルートの広告を出すかと仮定するということである、目的地、中、10.1 .1 .0/24。 これらは事実上無効の仮定ですが、それらはルーティングが実際に利く方法に結ばれます。 これは、ルート認可の値が疑わしいのを示します、ルート広告から目的地とトランジット認可を解く何らかの方法がない場合。深く、広告は今日、からみ合います。
2.4. Third Example: Following a Specific Path
2.4. 第3例: 特定の経路に続きます。
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には.0/25に10.1の中の範囲の目的地へのトランジットBへの交通に.1を許容しない互いに同意された方針があると仮定してください。
10.1.1.0/25--A---B---C---D
| | |
E-------F---G
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が広告を出す、10.1 .1 Bへの.0/25、10.1 .1 Eへの.0/24。
o B advertises 10.1.1.0/25 {B,A} to C.
o Bが10.1に.1.0/の広告を出す、25、B、A、Cに。
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/の広告を出す、24、E、A、F、フィルタリング10.1.1.0/、25 E、Aは何らかのローカルの方針を基礎づけました。
o F advertises 10.1.1.0/24 {F,E,A} to C and to G.
o Fが10.1に.1.0/の広告を出す、24、F、E、A、Cと、そして、Gに。
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/の広告を出す、24、C、F、E、A、D、フィルタリング10.1.1.0/、25 B、Aは何らかのローカルの方針を基礎づけました。
o G advertises 10.1.1.0/24 {G,F,E,A} to D.
o Gが10.1に.1.0/の広告を出す、24、G、F、E、A、Dに。
o D chooses 10.1.1.0/24 {C,F,E,A} over 10.1.1.0/24 {G,F,E,A}.
o Dが10.1に.1.0/に24を選ぶ、C、F、E、A、10.1以上、.1.0/、24 G、F、E、A。
White & Akyol Informational [Page 11] RFC 5123 Path Validation Considerations February 2008
[11ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
What path will traffic forwarded to C destined to hosts within 10.1.1.0/25 actually follow?
どんな経路がCに送られた交通を望んでいるかが10.1の中で.0/25が実際に続く.1をホストに運命づけましたか?
o D forwards this traffic to C, since its best path is through
10.1.1.0/24 {C,F,E,A}.
o 10.1を通して最も良い経路以来のCには、.1.0/があります。Dがこの交通を進める、24 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 10.1を通して最も良い経路以来のBには、.1.0/があります。Cがこの交通を進める、25 B、A。
o B forwards this traffic to A, since its best path is through
10.1.1.0/25 {A}.
o 10.1を通して最も良い経路がAあるので、Bはこの交通を進めます。.1 .0/25A。
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 Pathは有効ですか? ともに、G、F、E、AとC、F、E、Aが有効なAS Pathsであるので、この例の両方のAS Pathsは有効です。
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、ルートは認可されています。 しかしながら、Cは、目的地を持って、10.1に認可を通過しません。.1 Bが10.1.1.0/25、およびDへのCからの最も良い経路であり、Aにはトランジットへのこの経路ではなく、明白な方針があって以来の.0/25。 事実上、次に、Cには目的地かトランジット認可が10.1のためにない、.1、.0/24、それは10.1に.0/25に.1を含んでいます。
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 Pathは推進経路(推進の一貫性がある)と一致していますか? 10.1の中で目的地に達してください。Cである、AS Pathの広告を出すのが、C、F、E、Aである、D、.1 .0/24、それは実際にこの広告の中のいくつかの目的地への異なった経路に沿った推進です。 推進の一貫性はこのインターネットワークの中に存在していません。
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の知識かコントロールの外でルーティングシステムから方針でトランジットB.情報およそ10.1.1.0/25まで取り除かれないか、またはD. ルーティングシステムに残っている情報は、Dが10.1の中で正しく.1を目的地に発送するかもしれないのを含意します。この例では、Aが、Dが10.1のために両方の広告を受け取ると仮定する、.1、10.1の.1の.0/25、および意志のための.0/24と広告、でしゃばるのに含まれているAS Pathを使用できてください、それら、Cを通した.0/25; .0/25は10.1の中に含まれています。10.1、.1、.1 .0/24。(Cは法的にその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.
このわずかに複雑な例で明確にルート認可と、目的地認可と、トランジット認可の間の緊張を見ることができます。 ルート認可はルーティングで目的地とトランジット認可を含意しますが、ルート認可はこの例に目的地か接頭語認可を含んでいません。
White & Akyol Informational [Page 12] RFC 5123 Path Validation Considerations February 2008
[12ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
2.5. Fourth Example: Interior and Exterior Paths Mismatch
2.5. 第4例: 内部の、そして、外の経路ミスマッチ
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.
これは私たちが本書ではカバーするつもりである中で最も複雑な例です。 この例で説明された構成がmisconfigurationですが、私たちが簡単さのためのこの例を選んだと主張できます、自律システムの中の内部の、そして、外のゲートウェイプロトコルの間の相互作用の複雑さのイラストとして。 特に階層構造で構成されると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)--+
+-----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はRouter Eを通して経路を使用しています。
o Router B is using the path through Router E.
o ルータBはRouter 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.
しかしながら、より密接にRouter Bに関するケースを調べて、私たちは、Router BがそれがRouter Eから学んだ経路を好んでいる間その経路がRouter E自身の次のホップで広告を出していると発見します。 しかしながら、実際にRouter C.Thusを通して(すなわち、Router E)がこれほど次に跳ぶ内部のルーティング・プロトコルで決定するRouterのビーズの最も良い経路があって、Router Bが経路の広告を出す、2、5、Router Bがそれを受けるとき、Router Aに、交通だけが実際に経路2、3、5に続いて起こります。
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,
AS1のシステム管理者は、攻撃者がAS3にいると決心して、ルータAに関する方針にAS3と共にAS Pathであらゆるルートを避けるように設定しました。 それで、この規則で始まって、それはAS9から学習された経路を捨てます。 それは現在2つの残っている経路を調べます。
White & Akyol Informational [Page 13] RFC 5123 Path Validation Considerations February 2008
[13ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
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}.
AS2(B)を通してAS2(B)とAS6から学んで、最も良い経路が2、5であることを決定します。 しかしながら、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 Pathは有効ですか? AS Path2、3、5は有効なAS Pathです。
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を仮定して、.1.0/は、経路に沿って、由来するのが認可されるか、または10.1に「再-広告を出」しています。24、認可されたルート。 また、10.1以来目的地認可もこの状況で明確です。.1 .0/24は例中の単一の目的地です。 トランジット認可は決定するのがもう少し難しいです、交通が実際にルーティング広告に含まれたAS Pathに沿って流れないので。 AS Pathが2、3、5歳であると主張するのが、ルート創始者か交通創始者のどちらかからの有効な経路であることは不可能です、そのAS Pathが広告に掲載されたAS Pathでないので。 本質的には、Router Eは、10.1へのルート認可からトランジット交通までのトランジット認可が.1であると.0/24に仮定します。その時、AS3が実際に認可されることを決定する方法が全くありません。
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 Pathは推進経路(推進の一貫性がある)と一致していますか? 広告を出しているAS Pathは2、5歳ですが、目的地に送られた交通は実際に2、3、5を通過します。 推進はこの例で一貫していません。
3. Summary
3. 概要
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.
本書では出された例は推進の唯一の広告を出しているAS Pathに矛盾した可能な例ではありません。 また、[ROUTINGLOGIC]はまた、いくつかの例を提供します。 [ASTRACEROUTE]は広告を出しているAS Pathに無節操な推進の実用的な影響で何らかのおもしろいバックグラウンドを提供します、大きいインターネットワークを通してパケットの実際の経路をたどるのを試みることの文脈で、外のゲートウェイプロトコルとして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スピーカーが特定のルートの広告を出すのに権限を与えられるなら、ルーティングは、また、目的地接頭語の中にあらゆる可能な副ブロックの広告を出すのが認可されて、広告主がルートの中のあらゆる目的地へのトランジットパケットに権限を与えられると仮定します。 これらの例について調査することによって、私たちは、事実上、ルート認可が目的地認可かトランジット認可と等しくないのがわかります、ルート認可の値を疑って。
White & Akyol Informational [Page 14] RFC 5123 Path Validation Considerations February 2008
[14ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
There are no easy or obviously scalable solutions to this problem.
この問題のどんな簡単であるか明らかにスケーラブルな解決もありません。
4. Acknowledgements
4. 承認
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.
このドキュメントの彼の貢献とコメントについてスティーブ・ケントに感謝申し上げます。 また、危険域の追加テキストを含んでいて、彼の仕事についてドキュメントの多くのセクションをはっきりさせる際にジョエル・アルペルンに感謝申し上げます。
5. Security Considerations
5. セキュリティ問題
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.
このドキュメントは、プロトコルを提案して、存在することへのどんな新しい拡大や追加も提案しないので、どんなプロトコルのセキュリティにも影響を与えません。
6. Informative References
6. 有益な参照
[ASTRACEROUTE] Feamster, N. and H. Balakrishnan, "Towards an Accurate
ASLevel Traceroute Tool", SIGCOMM ACM SIGCOMM, 2003.
[ASTRACEROUTE] FeamsterとN.とH.Balakrishnan、「正確なASLevelトレースルートツール」、SIGCOMM ACM SIGCOMM、2003
[BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[BGP-MD5] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、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)について議定書の中で述べます」、RFC4271、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.Balakrishnan、「広い領域ルート設定のための論理」、ネットワークアーキテクチャの今後の指示のSIGCOMM ACM SIGCOMM Worshop、ドイツ(2003年8月)。
[SOBGP] White, R., "Architecture and Deployment Considerations
for Secure Origin BGP (soBGP)", Work in Progress.
[SOBGP]ホワイト、「安全な起源BGP(soBGP)のための構造と展開問題」というR.は進行中で働いています。
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
White & Akyol Informational [Page 15] RFC 5123 Path Validation Considerations February 2008
[15ページ]RFC5123経路合法化問題2008年2月の情報のホワイトとAkyol
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
White & Akyol Informational [Page 16]
白くて、Akyol情報です。[16ページ]
一覧
スポンサーリンク
