[要約] RFC 5123は、BGPのパスの検証に関する考慮事項をまとめたものであり、BGPのセキュリティ強化を目的としている。
Network Working Group R. White
Request for Comments: 5123 B. Akyol
Category: Informational Cisco Systems
February 2008
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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をパスとして検証する際の問題を説明することです。これは、パス検証の改善を求めているスキームの評価に役立つと期待しています。最初のセクションでは、BGPスピーカーがローカルの自律システムではなくピアから更新を受けた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.
このドキュメントに記載されている例は、展開を最も重要なコンポーネントまで蒸留することを目的としており、例を理解し、検討しやすくします。多くの状況では、この例で取られた特定のパスは関連しない場合がありますが、それは各例で考慮された原則を無効にしません。特定のポリシーに関する実際の問題を説明していないため、これらの例は「赤いニシン」であることが示唆されています。それどころか、これらの例は単純であるため強力です。これらの例のトポロジーのいずれかが亜熱帯学であるトポロジは、このドキュメントで説明されている特性を示します。特定のトポロジに焦点を当てるのではなく、その単一トポロジーを「コーナーケース」として却下するのではなく、このドキュメントは、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.
ネットワークセキュリティへの関心が高まっているため、[RFC4271]で説明されているように、BGPを実行しているルーティングシステム内で運ばれる情報のセキュリティは、非常に興味深いものになっています。[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スピーカーが、AS65001のBGPスピーカーから10.1.1.0/24の広告を受け取っていると仮定し、{65000、65001}の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スピーカーがこの広告について尋ねることができる最も明白な質問は、この場合、AS65000の起源が広告に含まれるプレフィックス、この場合は10.1.1.0/24を広告することを許可されているかどうかです。AS65000を発信する10.1.1.0/24へのルートを受け取ったBGPスピーカーが、AS65000が実際に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検証と呼ばれます。
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スピーカーがAS65001のBGPスピーカーからAS PATH {65000、65001}を使用して広告を受信すると、AS65001がAS65001がローカルに付属していると仮定できると主張しています。、そしてその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への別のルートは、ルーティング情報の完全に異なる広告と見なされるため、10.1.1.0/を宣伝する権限に関係なく10.1.0.0/16を宣伝することが許可される場合があります。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以内に含まれており、後者を宣伝する許可は、前者を宣伝する許可を意味します。これは、このドキュメント全体でReachability Authorizationと呼ばれます。
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つの認可定義の間にはかなりの緊張があります。このドキュメントの多くは、これらのさまざまなタイプの承認と、さまざまなインターネットワークで機能する可能性がある、または機能しない可能性がある、またはどのように機能しないかの関係を調査することを中心に構築されています。この文書で到達した結論の1つは、ルートの承認、到達可能性の承認、および輸送承認が互いに対立することが多いということです。1つのタイプの許可を真であることを示すことは、他のタイプの承認を真であることを示すものではなく、ルーティングシステムでこれら3種類の承認の性質が絡み合っているため、ルート認証は疑わしい価値があります。
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のピアから宛先10.1.1.0/24のピアから広告を受け取った場合、AS Path {65000、65001}で、AS65001のBGPスピーカーにトラフィックを転送します。実際にAS65001内のルーターから転送され、その後AS65000を介して目的地に到達しますか？
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.
まず、これらの質問を調べている間、これらの概念をしっかりと固定する必要があるため、ルーティングの概念のいくつかを確認します。この後、BGPで4つの例が実施され、Path Vectorルーティングシステムでのさまざまなタイプの承認の間の緊張を示します。
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.
これは、パスベクトルプロトコルのルーティングアップデートに含まれるパスの目的に光を当てます。パスは、他の情報を提供するのではなく、パスがループフリーであることを証明します。Dijkstraの送信者ポリシーフレームワーク（SPF）とDiffusing Update Algorithm（dual）はどちらもパスのコストに基づいてループを含まないパス計算を行いますが、BGPなどのパスベクトルプロトコルは、パスがループフリーであることを証明します。ノード広告自体が横断しています。BGPは、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スピーカーは、10.1.1.0/24がパス{65004、65002、65001}}に沿って到達可能であるというピアから広告を受け取る場合があります。この情報に基づいて、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.
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の受信BGPスピーカーは、AS65001（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パスは転送パスと一致していますか（転送の一貫性は存在しますか）？いいえ、パスとして宣伝されているのは{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 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のシステム管理者は、宛先10.1.1.0/24がAS65001を超えた自律システムから到達可能になることを望んでいません。言い換えれば、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.
システム管理者は、AS65000内のBGPスピーカーにAS65001内のAS65001内のピアに10.1.1.0/24を宣伝することにより、AS65001のBGPスピーカーがこのルーティング情報の到達可能性を読み返すべきではないという信号を実装することにより、このポリシーを実装できます。たとえば、AS65000のBGPスピーカーは、[RFC4271]で説明されているように、NO_Advertiseコミュニティが添付されている状態で10.1.1.0/24にルートを宣伝できます。AS65001のBGPスピーカーがこのコミュニティに応答するように構成されている場合（およびこのドキュメントの目的のためであると仮定します）、この広告を受け入れる必要がありますが、10.1.1.0/24にAS65002にリーチ可能性を読み取りします。
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に向けられたパケットを発信する場合、何が起こりますか？パケットは、AS65002からAS65001へのデフォルトルートに従ってルーティングされます。AS65001内のルーターは、10.1.1.0/24ルートに沿ってパケットを転送し、最終的にトラフィックをAS65000に転送します。
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つの異なる広告があるため、これは答えるのが難しい質問です。AS65002のBGPスピーカーの観点から、AS65001のピアから広告でデフォルトのルートを受け取ると、デフォルトルートへのパスが有効です。ただし、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に転送されたトラフィックは、実際にAS65001内で終了します。ただし、このトラフィックは実際にAS65001をAS65000に向かって通過します。したがって、この例では、集約のケースを扱っているこの例には、[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つの異なるタイプの承認の間の緊張をヒグにしています。次の3つのセクションでは、AS65001がAS65002に送信できるさまざまな広告に関する問題について説明します。
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パスを確保するための努力の力と適用性に制限があります。そのような取り組みにおいて、根本的な価値を損なうものではありません。
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アドレスの割り当ての現在のインスタンス化では、たとえば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: o AS65002 verifies route authorization by examining the authorization of AS65001 to advertise 10.1.0.0/16.
たとえば、この例では、AS65001が10.1.0.0/16を発信することを許可されている場合、デフォルトのルートではなく10.1.0.0/16をAS65002に向けて宣伝できます。AS65001が10.1.0.0/16を宣伝することが許可されていることを確認するために、AS65002が相談できるように何らかの形の認可メカニズムがあると仮定します。この場合、AS65002はAS65001の許可を調べて10.1.0.0/16を発信し、AS65002が10.1.0.0/16を宣伝することが許可されている場合、可能なすべてのサブブロックに向けてトラフィックを通過することも許可されていると仮定します（）10.1.0.0/16。これをより明確な用語にするには：o AS65002は、10.1.0.0/16を宣伝する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 AS65001は10.1.0.0/16のすべての可能なサブブロックを宣伝する許可をAS65001が宣伝するための目的地の承認を想定しています。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 AS65001は、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:
たとえば、目的地の承認だけを考慮すると、AS65001がオリジネーターに10.1.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 OriginatorがAS65001の広告に同意しなかった場合、10.1.1.0/24を含む集計を広告すると、AS65001は、隔離されたブロックを含まない広告のコレクションを宣伝することを余儀なくされます。
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.
o AS65001が実際に集計を宣伝する許可を取得している場合、AS65002に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.0.0/16の各潜水金の実際のルートを受け取る必要があります。または、AS65001が10.1.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アドレススペースの構築に基づいて、サブブロックが存在するものを知る必要があります。たとえば、最長の許可されたサブブロックはA /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の広告があり、10.1.0.0/24と10.1.1.0/24の両方を10.1.0.0/23からAS65002として宣伝することを決定します。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 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.
ただし、問題は、AS65000のポリシーにも影響を与えます。これは、AS65001によって集約されている2つのルートの1つを発信しています。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.
基本的な問題は、AS65002がAS65001が10.1.1.0/24を含む認定ルートを宣伝する場合、有効な不正な集計、所有者の集計ルート、またはプロキシ集約を介して、サブブロック10.1.1.0/24/24.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には、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は10.1.1.0/25をBに、10.1.1.0/24にEを広告します。
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、a}、フィルタリング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を超える10.1.1.0/24 {c、f、e、a}を選択します{g、f、e、a}。
What path will traffic forwarded to C destined to hosts within 10.1.1.0/25 actually follow?
10.1.1.0/25以内のホストに運命づけられたCにどのパスが転送されますか？
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、f、e、a}を通るため、このトラフィックをcに転送します。
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、a}を通るため、このトラフィックをBに転送します。
o B forwards this traffic to A, since its best path is through 10.1.1.0/25 {A}.
o bこのトラフィックは、10.1.1.0/25 {a}を通るため、このトラフィックを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の読み取りを許可されているため、ルートは許可されています。ただし、Cには10.1.1.0/25への宛先や輸送許可はありません。これは、cから10.1.1.0/25までの最適なパスであり、DおよびAにはこのパスを通過しないという明示的なポリシーがあります。実際には、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以内に宛先に到達するためにAs Path {C、F、E、A}をDoに宣伝していますが、実際には、この広告内のいくつかの目的地への別のパスに沿って転送しています。このインターネットワーク内には、転送の一貫性は存在しません。
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/24の広告と10.1.1.0/25の広告の両方を受け取ることを前提としており、Bがbを輸送しないというポリシーに相互に合意したパスとして含まれることを使用することができます。ただし、10.1.1.0/25に関する情報は、AまたはDの知識または制御以外のポリシーによってルーティングシステムから削除されます。ルーティングシステムに残っている情報は、10.1.1.0/25から10.1.0/25以内の目的地に正しくルーティングできることを意味します。C、10.1.1.0/25は10.1.1.0/24以内に含まれているため、Cは法的に広告です。
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が受信すると、パス{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, 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つのパスを調べ、AS2（b）を介して最適なパスが{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パスは有効ですか？As Path {2、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 ルートは許可されていますか？パスに沿ってそれぞれが、10.1.1.0/24の発生またはReadvertiseが認可されることを想定すると、ルートは許可されています。10.1.1.0/24は例全体の単一の目的地であるため、この状況では目的地の承認も明確です。トラフィックは、ルーティング広告に含まれるASパスに沿って実際に流れないため、判断するのは少し難しいです。As Path {2,3,5}は、パスが宣伝されているASパスではないため、ルートオリジネーターまたはトラフィックオリジネーターのいずれかからの有効なパスであると主張することは不可能です。基本的に、ルーターEは、AS3が実際にトラフィックを10.1.1.0/24に輸送することを許可されていると判断する方法がない場合、ルート認証から輸送許可を想定しています。
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.
この文書に関する彼の貢献とコメントについて、Steve Kentに感謝します。また、重要なセクションの追加テキストを含め、ドキュメントの多くのセクションを明確にした彼の仕事について、Joel Halpernに感謝します。
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.
[Astraceroute] Feamster、N。およびH. Balakrishnan、「正確なAslevel Tracerouteツールに向けて」、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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 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. Balakrishnan、「広い領域のルーティングの論理に向けて」、Sigcomm ACM Sigcomm Worshop 2003年8月、ドイツのネットワークアーキテクチャの将来の方向について。
[SOBGP] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", Work in Progress.
[SOBGP] White、R。、「安全な起源BGP（SOBGP）の建築と展開の考慮事項」、進行中の作業。
Authors' Addresses
著者のアドレス
Russ White Cisco Systems
ラスホワイトシスコシステム
EMail: riw@cisco.com
Bora Akyol Cisco Systems
Bora Akyol Cisco Systems
EMail: bora@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://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への情報をお問い合わせください。