RFC3704 日本語訳
3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker Request for Comments: 3704 Cisco Systems Updates: 2827 P. Savola BCP: 84 CSC/FUNET Category: Best Current Practice March 2004
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 3704のシスコシステムズアップデート: 2827P.Savola BCP: 84CSC/FUNETカテゴリ: 2004年の最も良い現在の練習行進
Ingress Filtering for Multihomed Networks
Multihomedのためにネットワークをフィルターにかけるイングレス
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827.
BCP38(RFC2827)は、だまされるのがある交通がネットワークへのアクセスを記述することを否定することによって分散DoS攻撃の影響を制限して、交通が正しいソースネットワークに起因しているのを確実にするのを助けるように設計されています。 また、そのような攻撃に対してインターネットを保護する副作用として、ソリューションを実現するネットワークはこれと他の攻撃から我が身をかばいます、ネットワーク設備へのだまされた管理アクセスなどのように。 これが例えば、マルチホーミングに関する問題を生じさせるとき、ケースがあります。 このドキュメントは、操作上のメカニズムをフィルターにかける現在のイングレスについて説明して、イングレスフィルタリングに関連する一般的な問題を調べて、特にマルチホーミングへの効果を調べます。 このメモはRFC2827をアップデートします。
Baker & Savola Best Current Practice [Page 1] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[1ページ]RFC3704イングレス
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different Ways to Implement Ingress Filtering . . . . . . . . 4
2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . 4
2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . 5
2.3 Feasible Path Reverse Path Forwarding . . . . . . . . . . 6
2.4 Loose Reverse Path Forwarding . . . . . . . . . . . . . . 6
2.5 Loose Reverse Path Forwarding Ignoring Default Routes . . 7
3. Clarifying the Applicability of Ingress Filtering . . . . . . 8
3.1 Ingress Filtering at Multiple Levels . . . . . . . . . . . 8
3.2 Ingress Filtering to Protect Your Own Infrastructure . . . 8
3.3 Ingress Filtering on Peering Links . . . . . . . . . . . . 9
4. Solutions to Ingress Filtering with Multihoming . . . . . . . 9
4.1 Use Loose RPF When Appropriate . . . . . . . . . . . . . . 10
4.2 Ensure That Each ISP's Ingress Filter Is Complete . . . . 11
4.3 Send Traffic Using a Provider Prefix Only to That Provider 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Conclusions and Future Work . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 デフォルトルート. . 7 3を無視して、イングレスフィルタリング. . . . . . . . 4 2.1イングレスアクセスリスト. . . . . . . . . . . . . . . . . . . 4 2.2厳しい逆の経路推進. . . . . . . . . . . . . . 5 2.3実行可能経路逆経路推進. . . . . . . . . . 6 2.4を実行する異なった方法は逆の経路推進. . . . . . . . . . . . . . 6 2.5のゆるい逆の経路推進を発射します。 倍数でイングレスフィルタリング. . . . . . 8 3.1イングレスフィルタリングの適用性をはっきりさせると、.83.2イングレスフィルタリングは、じっと見るときリンク. . . . . . . . . . . . 9 4をフィルターにかけるあなた自身のインフラストラクチャ. . . 8 3.3イングレスを保護するために平らにされます。 そのプロバイダーだけにプロバイダー接頭語を使用して、適切な.104.2が、各ISPのイングレスフィルタが完全な.114.3であることを確実にするときマルチホーミング. . . . . . . 9 4.1使用でゆるいRPFをフィルターにかけるイングレスのソリューションが交通を送る、11、5 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 6。 結論と今後の活動. . . . . . . . . . . . . . . . . 13 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1。 引用規格. . . . . . . . . . . . . . . . . . 14 8.2。 有益な参照. . . . . . . . . . . . . . . . . 14 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 15 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 16
Baker & Savola Best Current Practice [Page 2] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[2ページ]RFC3704イングレス
1. Introduction
1. 序論
BCP 38, RFC 2827 [1], is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering and delves into the effects on multihoming in particular.
BCP38(RFC2827[1])は、だまされるのがある交通がネットワークへのアクセスを記述することを否定することによって分散DoS攻撃の影響を制限して、交通が正しいソースネットワークに起因しているのを確実にするのを助けるように設計されています。 また、そのような攻撃に対してインターネットを保護する副作用として、ソリューションを実現するネットワークはこれと他の攻撃から我が身をかばいます、ネットワーク設備へのだまされた管理アクセスなどのように。 これが例えば、マルチホーミングに関する問題を生じさせるとき、ケースがあります。 このドキュメントは、操作上のメカニズムをフィルターにかける現在のイングレスについて説明して、イングレスフィルタリングに関連する一般的な問題を調べて、特にマルチホーミングへの効果を調べます。
RFC 2827 recommends that ISPs police their customers' traffic by dropping traffic entering their networks that is coming from a source address not legitimately in use by the customer network. The filtering includes but is in no way limited to the traffic whose source address is a so-called "Martian Address" - an address that is reserved [3], including any address within 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, or 240.0.0.0/4.
RFC2827は、ISPが顧客ネットワークで合法的に使用中でないソースアドレスから来るそれらのネットワークに入る交通を落とすのによる彼らの顧客の交通を取り締まることを勧めます。 ソースアドレスがいわゆる「火星のアドレス」である交通に含んでいますが、フィルタリングは決して有限ではありません--予約された[3]であるアドレス、含んでいるいずれも0.0.0 8、.0/10.0.0 8、.0/127.0.0 8、.0/172.16.0 12、.0/192.168.0 16、.0/224.0.0 4、または.0/240.0.0の中に.0/4を記述します。
The reasoning behind the ingress filtering procedure is that Distributed Denial of Service Attacks frequently spoof other systems' source addresses, placing a random number in the field. In some attacks, this random number is deterministically within the target network, simultaneously attacking one or more machines and causing those machines to attack others with ICMP messages or other traffic; in this case, the attacked sites can protect themselves by proper filtering, by verifying that their prefixes are not used in the source addresses in packets received from the Internet. In other attacks, the source address is literally a random 32 bit number, resulting in the source of the attack being difficult to trace. If the traffic leaving an edge network and entering an ISP can be limited to traffic it is legitimately sending, attacks can be somewhat mitigated: traffic with random or improper source addresses can be suppressed before it does significant damage, and attacks can be readily traced back to at least their source networks.
イングレスフィルタリング手順の後ろの推理は分散型サービス妨害Attacksが頻繁に他のシステムのソースアドレスをだますということです、その分野に乱数を置いて。 いくつかの攻撃では、この乱数は目標ネットワークの中では、決定論的に、同時に、1台以上のマシンを攻撃して、それらのマシンが何らかのICMPメッセージで他のものを攻撃することを引き起こすのが取引するということです。 この場合、攻撃されたサイトは適切なフィルタリングで我が身をかばうことができます、それらの接頭語がインターネットから受け取られたパケットのソースアドレスで使用されないことを確かめることによって。 他の攻撃では、ソースアドレスは文字通り32ビットの無作為の数です、たどるのが難しい攻撃の源をもたらして。 縁のネットワークを出て、ISPに入る交通をそれが合法的に送る交通に制限できるなら、攻撃をいくらか緩和できます: 重要な損害を与える前に無作為の、または、不適当なソースアドレスによる交通を抑圧できます、そして、容易に少なくともそれらのソースネットワークに攻撃をたどって戻すことができます。
This document is aimed at ISP and edge network operators who 1) would like to learn more of ingress filtering methods in general, or 2) are already using ingress filtering to some degree but who would like to expand its use and want to avoid the pitfalls of ingress filtering in the multihomed/asymmetric scenarios.
このドキュメントが一般に、方法をフィルターにかけるイングレスのISPと1が)もう少し学びたがっている縁のネットワーク・オペレータを対象にするか、2が)既にイングレスフィルタリングをある程度使用していますが、だれが、使用を広げて、「マルチ-家へ帰」ったか非対称のシナリオのイングレスフィルタリングの落とし穴を避けたがっていますか?
Baker & Savola Best Current Practice [Page 3] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[3ページ]RFC3704イングレス
In section 2, several different ways to implement ingress filtering are described and examined in the generic context. In section 3, some clarifications on the applicability of ingress filtering methods are made. In section 4, ingress filtering is analyzed in detail from the multihoming perspective. In section 5, conclusions and potential future work items are identified.
セクション2で、イングレスフィルタリングを実行するいくつかの異なった方法が、一般的な文脈で述べられて、調べられます。 セクション3では、方法をフィルターにかけるイングレスの適用性におけるいくつかの明確化をします。 セクション4では、イングレスフィルタリングはマルチホーミング見解から詳細に分析されます。 セクション5で、結論と潜在的今後の活動項目は特定されます。
2. Different Ways to Implement Ingress Filtering
2. イングレスフィルタリングを実行する異なった方法
This section serves as an introduction to different operational techniques used to implement ingress filtering as of writing this memo. The mechanisms are described and analyzed in general terms, and multihoming-specific issues are described in Section 4.
異なった操作上のテクニックへの序論が以前はよく書くこと現在このメモをフィルターにかけるイングレスを実行していたとき、このセクションは役立ちます。 メカニズムは、あいまいな言葉で説明されて、分析されます、そして、マルチホーミング特有の問題はセクション4で説明されます。
There are at least five ways one can implement RFC 2827, with varying impacts. These include (the names are in relatively common usage):
1つが異なった衝撃でRFC2827を実行できる少なくとも5つの方法があります。 これらは以下を含んでいます(名前が比較的一般的な用法であります)。
o Ingress Access Lists
o イングレスアクセスリスト
o Strict Reverse Path Forwarding
o 厳しい逆の経路推進
o Feasible Path Reverse Path Forwarding
o 実行可能経路逆経路推進
o Loose Reverse Path Forwarding
o ゆるい逆の経路推進
o Loose Reverse Path Forwarding ignoring default routes
o デフォルトルートを無視するゆるいReverse Path Forwarding
Other mechanisms are also possible, and indeed, there are a number of techniques that might profit from further study, specification, implementation, and/or deployment; see Section 6. However, these are out of scope.
また、他のメカニズムも可能です、そして、本当に、さらなる研究、仕様、実現、そして/または、展開から利益を得るかもしれない多くのテクニックがあります。 セクション6を見てください。 しかしながら、範囲の外にこれらはあります。
2.1. Ingress Access Lists
2.1. イングレスアクセスリスト
An Ingress Access List is a filter that checks the source address of every message received on a network interface against a list of acceptable prefixes, dropping any packet that does not match the filter. While this is by no means the only way to implement an ingress filter, it is the one proposed by RFC 2827 [1], and in some sense the most deterministic one.
Ingress Access Listはネットワーク・インターフェースに許容できる接頭語のリストに対して受け取られたあらゆるメッセージのソースアドレスをチェックするフィルタです、フィルタに合っていないどんなパケットも落として。 これは決してイングレスフィルタを実行する唯一の方法ではありませんが、ものがRFC2827[1]、および何らかの意味で最も決定論的な1つを提案したということです。
However, Ingress Access Lists are typically maintained manually; for example, forgetting to have the list updated at the ISPs if the set of prefixes changes (e.g., as a result of multihoming) might lead to discarding the packets if they do not pass the ingress filter.
しかしながら、Ingress Access Listsは手動で通常維持されます。 例えば、接頭語のセットが変化するなら(例えば、マルチホーミングの結果、)ISPでリストをアップデートさせるのを忘れるのがイングレスフィルタを渡さないならパケットを捨てるのに通じるかもしれません。
Baker & Savola Best Current Practice [Page 4] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[4ページ]RFC3704イングレス
Naturally, this problem is not limited to Ingress Access Lists -- it is inherent to Ingress Filtering when the ingress filter is not complete. However, usually Ingress Access Lists are more difficult to maintain than the other mechanisms, and having an outdated list can prevent legitimate access.
当然、この問題はIngress Access Listsに制限されません--イングレスフィルタが完全でないときに、それはIngress Filteringに固有です。 しかしながら、通常、Ingress Access Listsは維持するのが他のメカニズムより難しいです、そして、時代遅れのリストを持っていると、正統のアクセサリーを防ぐことができます。
2.2. Strict Reverse Path Forwarding
2.2. 厳しい逆の経路推進
Strict Reverse Path Forwarding (Strict RPF) is a simple way to implement an ingress filter. It is conceptually identical to using access lists for ingress filtering, with the exception that the access list is dynamic. This may also be used to avoid duplicate configuration (e.g., maintaining both static routes or BGP prefix- list filters and interface access-lists). The procedure is that the source address is looked up in the Forwarding Information Base (FIB) - and if the packet is received on the interface which would be used to forward the traffic to the source of the packet, it passes the check.
厳しいReverse Path Forwarding(厳しいRPF)はイングレスフィルタを実行する簡単な方法です。 それが概念的にイングレスフィルタリングにアクセスリストを使用するのと同じである、例外で、アクセスが記載するのは、ダイナミックです。 また、これは、写し構成(例えば、スタティックルートかBGP接頭語の両方がフィルタとインタフェースアクセスリストをリストアップすると主張する)を避けるのに使用されるかもしれません。 手順はソースアドレスがForwarding Information基地(FIB)で調べられるということです、そして、パケットの源に交通を送るのに使用されるインタフェースにパケットを受け取るなら、それはチェックを通過します。
Strict Reverse Path Forwarding is a very reasonable approach in front of any kind of edge network; in particular, it is far superior to Ingress Access Lists when the network edge is advertising multiple prefixes using BGP. It makes for a simple, cheap, fast, and dynamic filter.
厳しいReverse Path Forwardingはどんな種類の縁のネットワークでの非常に合理的なアプローチです。 ネットワーク縁がBGPを使用することで複数の接頭語の広告を出しているとき、特に、それはIngress Access Listsよりはるかに優れています。 それは簡単で、安くて、速くて、ダイナミックなフィルタになります。
But Strict Reverse Path Forwarding has some problems of its own. First, the test is only applicable in places where routing is symmetrical - where IP datagrams in one direction and responses from the other deterministically follow the same path. While this is common at edge network interfaces to their ISP, it is in no sense common between ISPs, which normally use asymmetrical "hot potato" routing. Also, if BGP is carrying prefixes and some legitimate prefixes are not being advertised or not being accepted by the ISP under its policy, the effect is the same as ingress filtering using an incomplete access list: some legitimate traffic is filtered for lack of a route in the filtering router's Forwarding Information Base.
しかし、Strict Reverse Path Forwardingには、それ自身のいくつかの問題があります。 まず最初に、テストは単に一方向へのIPデータグラムともう片方からの応答が決定論的に同じ経路を以下であるところでルーティングが対称である場所で適切です。 これは縁のネットワーク・インターフェースでそれらのISPに共通ですが、通常、非対称的な「困難な立場」ルーティングを使用するISPの間で一般的などんな意味でもそれがありません。 また、BGPが接頭語を運んで、いくつかの正統の接頭語が広告を出さないか、またはISPによって方針の下で受け入れられないなら、効果も不完全なアクセスリストを使用するのにおいてイングレスフィルタリングと同じです: 何らかの正統の交通がフィルタリングルータのForwarding Information基地における、ルートの不足によってフィルターにかけられます。
There are operational techniques, especially with BGP but somewhat applicable to other routing protocols as well, to make strict RPF work better in the case of asymmetric or multihomed traffic. The ISP assigns a better metric which is not propagated outside of the router, either a vendor-specific "weight" or a protocol distance to prefer the directly received routes. With BGP and sufficient machinery in place, setting the preferences could even be automated, using BGP Communities [2]. That way, the route will always be the best one in the FIB, even in the scenarios where only the primary connectivity would be used and typically no packets would pass
厳しいRPFを非対称の、または、「マルチ-家へ帰」っている交通の場合でうまくいかせるように、特にBGPにもかかわらず、また、他のルーティング・プロトコルにいくらか適切であるのがある操作上のテクニックがあります。 ISPは、よりよくメートル法でaを割り当てます(直接容認されたルートを好むためにルータ(業者特有の「重さ」かプロトコル距離のどちらか)の外に伝播されません)。 BGPと十分な機械が適所にある場合、BGP Communities[2]を使用して、好みを設定するのは自動化さえされるかもしれません。 そのように、いつもルートはFIBで最も良い方でしょう、第一の接続性だけが使用されて、パケットが通常全く通らないシナリオでさえ
Baker & Savola Best Current Practice [Page 5] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[5ページ]RFC3704イングレス
through the interface. This method assumes that there is no strict RPF filtering between the primary and secondary edge routers; in particular, when applied to multihoming to different ISPs, this assumption may fail.
インタフェースを通して。 この方法は、第一の、そして、二次の縁の間でルータをフィルターにかけるどんな厳しいRPFもないと仮定します。 異なったISPへのマルチホーミングに適用されると、特に、この仮定は失敗するかもしれません。
2.3. Feasible Path Reverse Path Forwarding
2.3. 実行可能経路逆経路推進
Feasible Path Reverse Path Forwarding (Feasible RPF) is an extension of Strict RPF. The source address is still looked up in the FIB (or an equivalent, RPF-specific table) but instead of just inserting one best route there, the alternative paths (if any) have been added as well, and are valid for consideration. The list is populated using routing-protocol specific methods, for example by including all or N (where N is less than all) feasible BGP paths in the Routing Information Base (RIB). Sometimes this method has been implemented as part of a Strict RPF implementation.
可能なPath Reverse Path Forwarding(可能なRPF)はStrict RPFの拡大です。 ソースアドレスがFIB(または、同等で、RPF特有のテーブル)でまだ調べられていますが、ただ1つの最も良いルートをそこに挿入することの代わりに、迂回経路(もしあれば)は、また、加えられて、考慮に、有効です。 ルーティング・プロトコルの特定の方法を使用することでリストは居住されます、例えば、経路情報基地(RIB)のすべてかN(Nがすべて以下であるところ)可能なBGP経路を含んでいることによって。 時々、この方法はStrict RPF実現の一部として実行されました。
In the case of asymmetric routing and/or multihoming at the edge of the network, this approach provides a way to relatively easily address the biggest problems of Strict RPF.
ネットワークの縁の非対称のルーティング、そして/または、マルチホーミングの場合では、このアプローチは比較的容易に訴える中でStrict RPFのその問題を最も大きい方法を提供します。
It is critical to understand the context in which Feasible RPF operates. The mechanism relies on consistent route advertisements (i.e., the same prefix(es), through all the paths) propagating to all the routers performing Feasible RPF checking. For example, this may not hold e.g., in the case where a secondary ISP does not propagate the BGP advertisement to the primary ISP e.g., due to route-maps or other routing policies not being up-to-date. The failure modes are typically similar to "operationally enhanced Strict RPF", as described above.
Feasible RPFが作動する文脈を理解しているのは重要です。 メカニズムは、Feasible RPFの照合を実行するすべてのルータに伝播しながら、一貫したルート広告(すなわち、すべての経路を通した同じ接頭語(es))に依存します。 例えば、これは例えば二次ISPが例えば、路線図のためBGP広告を第一のISPに伝播しないケースか他の最新でないルーティング方針を抑制しないかもしれません。 故障モードは上で説明されるように「操作上高められたStrict RPF」と通常同様です。
As a general guideline, if an advertisement is filtered, the packets will be filtered as well.
一般的ガイドラインとして、広告がフィルターにかけられると、また、パケットはフィルターにかけられるでしょう。
In consequence, properly defined, Feasible RPF is a very powerful tool in certain kinds of asymmetric routing scenarios, but it is important to understand its operational role and applicability better.
その結果、適切に、定義されています、Feasible RPFはある種類の非対称のルーティングシナリオの非常に強力なツールですが、その操作上の役割と適用性をより理解しているのは重要です。
2.4. Loose Reverse Path Forwarding
2.4. ゆるい逆の経路推進
Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar
to strict RPF, but differs in that it checks only for the existence
of a route (even a default route, if applicable), not where the route
points to. Practically, this could be considered as a "route
presence check" ("loose RPF is a misnomer in a sense because there is
no "reverse path" check in the first place).
ゆるいReverse Path Forwarding(ゆるいRPF)はルートが示されるどんなところでも厳しいRPFと同様のalgorithmicallyですが、ルートの存在だけがないかどうかチェックするという点において異なりません(デフォルトルートさえの、そして、適切な)。 実際に、「ルート存在チェック」であるとこれをみなすことができた、(「第一に、「逆の経路」チェックが全くないのでゆるいRPFがある意味で誤称である、)、」
Baker & Savola Best Current Practice [Page 6] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[6ページ]RFC3704イングレス
The questionable benefit of Loose RPF is found in asymmetric routing situations: a packet is dropped if there is no route at all, such as to "Martian addresses" or addresses that are not currently routed, but is not dropped if a route exists.
Loose RPFの疑わしい利益は非対称のルーティング状況で見つけられます: パケットは、ルートが「火星のアドレス」や現在発送されないアドレスなどに全く似ていなければ落とされますが、ルートが存在しているなら、落とされません。
Loose Reverse Path Forwarding has problems, however. Since it sacrifices directionality, it loses the ability to limit an edge network's traffic to traffic legitimately sourced from that network, in most cases, rendering the mechanism useless as an ingress filtering mechanism.
しかしながら、ゆるいReverse Path Forwardingには、問題があります。方向性を犠牲にするので、それは縁のネットワークの交通を多くの場合、イングレスフィルタリングメカニズムとして役に立たなくメカニズムを表しながらそのネットワークから合法的に出典を明示された交通に制限する能力を失います。
Also, many ISPs use default routes for various purposes such as collecting illegitimate traffic at so-called "Honey Pot" systems or discarding any traffic they do not have a "real" route to, and smaller ISPs may well purchase transit capabilities and use a default route from a larger provider. At least some implementations of Loose RPF check where the default route points to. If the route points to the interface where Loose RPF is enabled, any packet is allowed from that interface; if it points nowhere or to some other interface, the packets with bogus source addresses will be discarded at the Loose RPF interface even in the presence of a default route. If such fine-grained checking is not implemented, presence of a default route nullifies the effect of Loose RPF completely.
また、多くのISPが違法な交通をいわゆる「ハニーポット」システムに集めるか、またはそれらが「本当」のルートを持っていないどんな交通も捨てなどなどの様々な目的にデフォルトルートを使用して、より小さいISPは、より大きいプロバイダーからトランジット能力を購入して、たぶんデフォルトルートを使用するでしょう。 Loose RPFの少なくともいくつかの実現が、デフォルトルートがどこに示されるかをチェックします。 ルートがLoose RPFが有効にされるところにインタフェースを示すなら、どんなパケットもそのインタフェースから許容されています。 どこにもある他のインタフェースに指すと、にせのソースアドレスがあるパケットはデフォルトルートがあるときさえLoose RPFインタフェースで捨てられるでしょう。 そのようなきめ細かに粒状の照合が実行されないなら、デフォルトルートの存在はLoose RPFの効果を完全に無効にします。
One case where Loose RPF might fit well could be an ISP filtering packets from its upstream providers, to get rid of packets with "Martian" or other non-routed addresses.
Loose RPFがよく合うかもしれない1つのケースが「火星」の、または、他の非発送されたアドレスでパケットを取り除くために上流のプロバイダーからパケットをフィルターにかけるISPであるかもしれません。
If other approaches are unsuitable, loose RPF could be used as a form of contract verification: the other network is presumably certifying that it has provided appropriate ingress filtering rules, so the network doing the filtering need only verify the fact and react if any packets which would show a breach in the contract are detected. Of course, this mechanism would only show if the source addresses used are "martian" or other unrouted addresses -- not if they are from someone else's address space.
他のアプローチが不適当であるなら、ゆるいRPFは契約検証のフォームとして使用されるかもしれません: もう片方のネットワークが、規則をフィルターにかける適切なイングレスを提供したのをおそらく公認しているので、何か契約に基づく不履行を示しているパケットが検出されるなら、フィルタリングをするネットワークは、事実について確かめるだけであり、反応しなければなりません。 もちろん、このメカニズムは他の誰かのアドレス空間から来ていないなら使用されるソースアドレスが「火星」の、または、他の非発送されたアドレスであるかどうかを示すだけでしょう。
2.5. Loose Reverse Path Forwarding Ignoring Default Routes
2.5. デフォルトルートを無視して、逆の経路推進を発射してください。
The fifth implementation technique may be characterized as Loose RPF ignoring default routes, i.e., an "explicit route presence check". In this approach, the router looks up the source address in the route table, and preserves the packet if a route is found. However, in the lookup, default routes are excluded. Therefore, the technique is mostly usable in scenarios where default routes are used only to catch traffic with bogus source addresses, with an extensive (or even full) list of explicit routes to cover legitimate traffic.
5番目の実現のテクニックはすなわち、デフォルトルート、「明白なルート存在チェック」を無視するLoose RPFとして特徴付けられるかもしれません。 このアプローチでは、ルータは、ルートテーブルのソースアドレスを調べて、ルートが見つけられるなら、パケットを保存します。 しかしながら、ルックアップでは、デフォルトルートは除かれます。 したがって、テクニックはデフォルトルートが正統の交通をカバーするのに使用されるにせのソースアドレス、明白なルートの大規模で(完全さえ)のリストで交通を捕らえるシナリオでほとんど使用可能です。
Baker & Savola Best Current Practice [Page 7] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[7ページ]RFC3704イングレス
Like Loose RPF, this is useful in places where asymmetric routing is found, such as on inter-ISP links. However, like Loose RPF, since it sacrifices directionality, it loses the ability to limit an edge network's traffic to traffic legitimately sourced from that network.
Loose RPFのように、これは非対称のルーティングが相互ISPリンクなどのように見つけられる場所で役に立ちます。 しかしながら、Loose RPFのように、方向性を犠牲にするので、それは縁のネットワークの交通をそのネットワークから合法的に出典を明示された交通に制限する能力を失います。
3. Clarifying the Applicability of Ingress Filtering
3. イングレスフィルタリングの適用性をはっきりさせます。
What may not be readily apparent is that ingress filtering is not applied only at the "last-mile" interface between the ISP and the end user. It's perfectly fine, and recommended, to also perform ingress filtering at the edges of ISPs where appropriate, at the routers connecting LANs to an enterprise network, etc. -- this increases the defense in depth.
容易に明らかでないかもしれないことはイングレスフィルタリングがISPとエンドユーザとの「最後のマイル」インタフェースだけで適用されないということです。 それは、また、適切であるところでISPの縁でイングレスフィルタリングを実行するために完全にすばらしくて、お勧めです、LANを企業網などに関連づけるルータで -- これは縦深防御を増加させます。
3.1. Ingress Filtering at Multiple Levels
3.1. 複数のレベルにおけるイングレスフィルタリング
Because of wider deployment of ingress filtering, the issue is recursive. Ingress filtering has to work everywhere where it's used, not just between the first two parties. That is, if a user negotiates a special ingress filtering arrangement with his ISP, he should also ensure (or make sure the ISP ensures) that the same arrangements also apply to the ISP's upstream and peering links, if ingress filtering is being used there -- or will get used, at some point in the future; similarly with the upstream ISPs and peers.
イングレスフィルタリングの、より広い展開のために、問題は再帰的です。 イングレスフィルタリングはまさしくではなくそれが使用されている最初の2回のパーティーの間のいたる所で働かなければなりません。 また、すなわち、ユーザがアレンジメントをフィルターにかける特別なイングレスを彼のISPと交渉するなら、彼は、また、同じアレンジメントがISPの上流に適用されて、じっと見ることがリンクされるのを保証するべきです(ISPが確実にするのを確実にしてください)、イングレスフィルタリングがそこで使用されているなら--または、使用させるでしょう、未来の何らかのポイントで。 同様である、上流のISPと同輩と共に。
In consequence, manual models which do not automatically propagate the information to every party where the packets would go and where ingress filtering might be applied have only limited generic usefulness.
その結果、自動的にパケットが行って、イングレスフィルタリングが適用されるかもしれないすべてのパーティーに情報を伝播しない手動のモデルは一般的な有用性を制限するだけでした。
3.2. Ingress Filtering to Protect Your Own Infrastructure
3.2. あなた自身のインフラストラクチャを保護するイングレスフィルタリング
Another feature stemming from wider deployment of ingress filtering may not be readily apparent. The routers and other ISP infrastructure are vulnerable to several kinds of attacks. The threat is typically mitigated by restricting who can access these systems.
イングレスフィルタリングの、より広い展開による別の特徴は容易に明らかでないかもしれません。 ルータと他のISPインフラストラクチャは数種類の攻撃に傷つきやすいです。 脅威はだれを制限するかによって通常緩和されて、これらのシステムにアクセスできるということです。
However, unless ingress filtering (or at least, a limited subset of it) has been deployed at every border (towards the customers, peers and upstreams) -- blocking the use of your own addresses as source addresses -- the attackers may be able to circumvent the protections of the infrastructure gear.
--ソースアドレスとしてあなた自身のアドレスの使用を妨げて、イングレスフィルタリング(または、少なくともそれの限られた部分集合)があらゆる境界(顧客、同輩、および上流に向かった)で配備されるというわけではなかったならしかしながら、攻撃者はインフラストラクチャギヤの保護を回避できるかもしれません。
Therefore, by deploying ingress filtering, one does not just help the Internet as a whole, but protects against several classes of threats to your own infrastructure as well.
したがって、イングレスフィルタリングを配備することによって、1つは、ただ全体でインターネットを助けませんが、また、あなた自身のインフラストラクチャへの数人のクラスの脅威から守ります。
Baker & Savola Best Current Practice [Page 8] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[8ページ]RFC3704イングレス
3.3. Ingress Filtering on Peering Links
3.3. じっと見るときリンクをフィルターにかけるイングレス
Ingress filtering on peering links, whether by ISPs or by end-sites, is not really that much different from the more typical "downstream" or "upstream" ingress filtering.
じっと見るときISPか端サイトにかかわらずリンクをフィルターにかけるイングレスは本当により典型的な「川下」の、または、「上流」のイングレスフィルタリングと異なったそれだけではありません。
However, it's important to note that with mixed upstream/downstream and peering links, the different links may have different properties (e.g., relating to contracts, trust, viability of the ingress filtering mechanisms, etc.). In the most typical case, just using an ingress filtering mechanism towards a peer (e.g., Strict RPF) works just fine as long as the routing between the peers is kept reasonably symmetric. It might even be considered useful to be able to filter out source addresses coming from an upstream link which should have come over a peering link (implying something like Strict RPF is used towards the upstream) -- but this is a more complex topic and considered out of scope; see Section 6.
しかしながら、混ぜられた上流/川下とじっと見るリンクがあるので、異なったリンクには異なった特性(例えば、契約法、信用、メカニズムをフィルターにかけるイングレスの生存力などに関連する)があるかもしれないことに注意するのは重要です。 最も典型的な場合では、同輩の間のルーティングが合理的に左右対称に保たれる限り、ただ同輩(例えば、Strict RPF)に向かってイングレスフィルタリングメカニズムを使用するのは問題なく働いています。 どれがじっと見るリンクを襲うべきであったかが上流のリンクから来るソースアドレスは無視できるように役に立つと考えられさえするかもしれませんが(Strict RPFが上流に向かって使用されるように何かを含意して)、これは、より複雑な話題であって範囲から考えられます。 セクション6を見てください。
4. Solutions to Ingress Filtering with Multihoming
4. マルチホーミングがあるイングレスフィルタリングのソリューション
First, one must ask why a site multihomes; for example, the edge network might:
まず最初に、サイトの「マルチ-家」をなぜに尋ねなければならないか。 例えば、縁のネットワークはそうするかもしれません:
o use two ISPs for backing up the Internet connectivity to ensure
robustness,
o 丈夫さを確実にするためにインターネットの接続性を支援するのに2つのISPを使用してください。
o use whichever ISP is offering the fastest TCP service at the
moment,
o 現在最も速いTCPサービスを提供しているどのISPを使用してくださいか。
o need several points of access to the Internet in places where no
one ISP offers service, or
o またはいいえ1、ISPがサービスを提供する場所のインターネットへの必要性数ポイントのアクセス。
o be changing ISPs (and therefore multihoming only temporarily).
o ISPを変えてください、(したがって、マルチホーミングだけ、一時)
One can imagine a number of approaches to working around the limitations of ingress filters for multihomed networks. Options include:
人は「マルチ-家へ帰」っているネットワークでイングレスフィルタの限界の周りで働いていることへの多くのアプローチを想像できます。 オプションは:
1. Do not multihome.
1. どんな「マルチ-家」もしないでください。
2. Do not use ingress filters.
2. イングレスフィルタを使用しないでください。
3. Accept that service will be incomplete.
3. サービスが不完全になると受け入れてください。
4. On some interfaces, weaken ingress filtering by using an
appropriate form of loose RPF check, as described in Section 4.1.
4. いくつかのインタフェースでは、セクション4.1で説明されるように適切な形式のゆるいRPFチェックを使用することによって、イングレスフィルタリングを弱めてください。
Baker & Savola Best Current Practice [Page 9] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[9ページ]RFC3704イングレス
5. Ensure, by BGP or by contract, that each ISP's ingress filter is
complete, as described in Section 4.2.
5. セクション4.2で説明されるようにBGPか契約で各ISPのイングレスフィルタが確実に完全になるようにしてください。
6. Ensure that edge networks only deliver traffic to their ISPs that
will in fact pass the ingress filter, as described in Section
4.3.
6. 縁のネットワークが事実上、イングレスフィルタを渡すそれらのISPに交通を提供するだけであるのを確実にしてください、セクション4.3で説明されるように。
The first three of these are obviously mentioned for completeness; they are not and cannot be viable positions; the final three are considered below.
これら最初の3つは完全性のために明らかに言及されます。 それらは、なくて、実行可能な位置であるはずがありません。 最終的な3は以下で考えられます。
The fourth and the fifth must be ensured in the upstream ISPs as well, as described in Section 3.1.
セクション3.1で説明されるように良い上流の同じくらいISPで4番目と5番目を確実にしなければなりません。
Next, we now look at the viable ways for dealing with the side- effects of ingress filters.
次に、私たちは、今、イングレスフィルタのサイド効果に対処するのを実行可能な道を見ます。
4.1. Use Loose RPF When Appropriate
4.1. 適切であるときにはゆるいRPFを使用してください。
Where asymmetric routing is preferred or is unavoidable, ingress filtering may be difficult to deploy using a mechanism such as strict RPF which requires the paths to be symmetrical. In many cases, using operational methods or feasible RPF may ensure the ingress filter is complete, like described below. Failing that, the only real options are to not perform ingress filtering, use a manual access-list (possibly in addition to some other mechanisms), or to using some form of Loose RPF check.
非対称のルーティングが好まれるか、または避けられないところでは、イングレスフィルタリングは経路が対称であることを必要とする厳しいRPFなどのメカニズムを使用することで展開するのが難しいかもしれません。 多くの場合、操作上の方法か可能なRPFを使用するのは以下で説明されるようにイングレスフィルタが確実に完全になるようにするかもしれません。 それに失敗して、唯一のリアルオプションは、イングレスフィルタリングを実行しないで、また手動のアクセスリスト(ことによるとある他のメカニズムに加えた)を使用しないで、またLoose RPFの何らかのフォームを使用するのにチェックしないことです。
Failing to provide any ingress filter at all essentially trusts the downstream network to behave itself, which is not the wisest course of action. However, especially in the case of very large networks of even hundreds or thousands of prefixes, maintaining manual access- lists may be too much to ask.
受託における本質的にはどんなイングレスフィルタにも行儀よくする川下のネットワークを供給しません。(それは、最も賢明な行動ではありません)。 しかしながら、特に数百さえの非常に大きいネットワークの場合か何千もの接頭語で手動のアクセスリストを維持するのは尋ねることができないくらい多いかもしれません。
The use of Loose RPF does not seem like a good choice between the edge network and the ISP, since it loses the directionality of the test. This argues in favor of either using a complete filter in the upstream network or ensuring in the downstream network that packets the upstream network will reject will never reach it.
Loose RPFの使用は縁のネットワークとISPの良い選択のように見えません、テストの方向性を失うので。 上流のネットワークに完全なフィルタを使用するか、または川下のネットワークで上流のネットワークが拒絶するパケットがそれに決して達しないのを確実にすることを支持してこれは論争します。
Therefore, the use of Loose RPF cannot be recommended, except as a way to measure whether "martian" or other unrouted addresses are being used.
したがって、Loose RPFの使用を推薦できません、「火星」の、または、他の非発送されたアドレスが使用されているかどうかを測定する方法を除いて。
Baker & Savola Best Current Practice [Page 10] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[10ページ]RFC3704イングレス
4.2. Ensure That Each ISP's Ingress Filter Is Complete
4.2. 各ISPのイングレスフィルタが確実に完全になるようにしてください。
For the edge network, if multihoming is being used for robustness or to change routing from time to time depending on measured ISP behavior, the simplest approach will be to ensure that its ISPs in fact carry its addresses in routing. This will often require the edge network to use provider-independent prefixes and exchange routes with its ISPs with BGP, to ensure that its prefix is carried upstream to the major transit ISPs. Of necessity, this implies that the edge network will be of a size and technical competence to qualify for a separate address assignment and an autonomous system number from its RIR.
縁のネットワークのために、最も簡単なアプローチはマルチホーミングが丈夫さか時々測定ISPの振舞いによるルーティングを変えるのに使用されているなら、事実上、ISPがルーティングでアドレスを運ぶのを保証することでしょう。 これは、しばしば縁のネットワークがプロバイダーから独立している接頭語を使用するのが必要であり、接頭語が上流へ主要なトランジットISPまで運ばれるのを保証するためにBGPと共にISPとルートを交換するでしょう。 必要です、これは縁のネットワークがRIRから別々のアドレス課題と自律システム番号の資格を与えるサイズと技術的能力のものになるのを含意します。
There are a number of techniques which make it easier to ensure the ISP's ingress filter is complete. Feasible RPF and Strict RPF with operational techniques both work quite well for multihomed or asymmetric scenarios between the ISP and an edge network.
ISPのイングレスフィルタが確実に完全になるようにするのをより簡単にする多くのテクニックがあります。 操作上のテクニックがある可能なRPFとStrict RPFはISPと縁のネットワークの間の「マルチ-家へ帰」ったか非対称のシナリオにともにかなりうまくいきます。
When a routing protocol is not being used, but rather the customer information is generated from databases such as Radius, TACACS, or Diameter, the ingress filtering can be the most easily ensured and kept up-to-date with Strict RPF or Ingress Access Lists generated automatically from such databases.
ルーティング・プロトコルが使用されていませんが、むしろ顧客情報がRadius、TACACS、またはDiameterなどのデータベースから生成されるとき、Strict RPFかIngress Access Listsがそのようなデータベースから自動的に生成されている状態で最新の状態でイングレスフィルタリングを最も容易に確実にして、保つことができます。
4.3. Send Traffic Using a Provider Prefix Only to That Provider
4.3. そのプロバイダーだけにプロバイダー接頭語を使用して、トラフィックを送ってください。
For smaller edge networks that use provider-based addressing and whose ISPs implement ingress filters (which they should do), the third option is to route traffic being sourced from a given provider's address space to that provider.
プロバイダーベースのアドレシングを使用して、ISPがイングレスがフィルタ(それらがするべきである)であると実装するより小さい縁のネットワークのために、3番目のオプションは与えられたプロバイダーのアドレス空間からそのプロバイダーまで出典を明示されるトラフィックを発送することです。
This is not a complicated procedure, but requires careful planning and configuration. For robustness, the edge network may choose to connect to each of its ISPs through two or more different Points of Presence (POPs), so that if one POP or line experiences an outage, another link to the same ISP can be used. Alternatively, a set of tunnels could be configured instead of multiple connections to the same ISP [4][5]. This way the edge routers are configured to first inspect the source address of a packet destined to an ISP and shunt it into the appropriate tunnel or interface toward the ISP.
これは、複雑な手順ではありませんが、綿密な計画と構成を必要とします。 丈夫さのために、縁のネットワークは、Presence(POP)の2異なったPointsを通してそれぞれのISPに接続するのを選ぶかもしれません、1つのPOPか系列が供給停止になるなら、同じISPへの別のリンクを使用できるように。 あるいはまた、同じISP[4][5]との複数の接続の代わりに1セットのトンネルを構成できました。 このように、縁のルータは、最初に、ISPに運命づけられたパケットのソースアドレスを点検して、ISPに向かった適切なトンネルかインタフェースにそれを入れるために構成されます。
If such a scenario is applied exhaustively, so that an exit router is chosen in the edge network for every prefix the network uses, traffic originating from any other prefix can be summarily discarded instead of sending it to an ISP.
そのようなシナリオが出口ルータがネットワークが使用するあらゆる接頭語のための縁のネットワークで選ばれているように徹底的に適用されるなら、それをISPに送ることの代わりに要約していかなる他の接頭語からも発するトラフィックは捨てることができます。
Baker & Savola Best Current Practice [Page 11] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[11ページ]RFC3704イングレス
5. Security Considerations
5. セキュリティ問題
Ingress filtering is typically performed to ensure that traffic arriving on one network interface legitimately comes from a computer residing on a network reachable through that interface.
イングレスフィルタリングは、1つのネットワーク・インターフェースで到着するトラフィックがそのインタフェースを通して届いているネットワークに住んでいるコンピュータから合法的に来るのを保証するために通常実行されます。
The closer to the actual source ingress filtering is performed, the more effective it is. One could wish that the first hop router would ensure that traffic being sourced from its neighboring end system was correctly addressed; a router further away can only ensure that it is possible that there is such a system within the indicated prefix. Therefore, ingress filtering should be done at multiple levels, with different level of granularity.
イングレスフィルタリングが実際のソースについて、より近く実行されれば実行するほど、それは、より効果的です。 人は、最初のホップルータが、隣接しているエンドシステムから出典を明示されるトラフィックが正しく扱われたのを確実にすることを願うことができました。 さらに遠さのルータは、示された接頭語の中にそのようなシステムがあるのが、可能であることを確実にすることができるだけです。 したがって、異なったレベルの粒状で複数のレベルでイングレスフィルタリングをするべきです。
It bears to keep in mind that while one goal of ingress filtering is to make attacks traceable, it is impossible to know whether the particular attacker "somewhere in the Internet" is being ingress filtered or not. Therefore, one can only guess whether the source addresses have been spoofed or not: in any case, getting a possible lead -- e.g., to contact a potential source to ask whether they're observing an attack or not -- is still valuable, and more so when the ingress filtering gets more and more widely deployed.
それは、イングレスフィルタリングの1つの目標が攻撃を起因するようにすることですが、「インターネットのどこかの」特定の攻撃者がイングレスがフィルターにかけた存在であるかどうかを知るのが不可能であることを覚えておくのに堪えます。 したがって、人は、ソースアドレスが偽造されたかどうか推測できるだけです: どのような場合でも、例えば可能なリードを可能なソースに連絡する得るのは、彼らが攻撃を観測しているかどうか尋ねます--イングレスフィルタリングがますます広く配布されると、まだ貴重であって、よりそうです。
In consequence, every administrative domain should try to ensure a sufficient level of ingress filtering on its borders.
その結果、あらゆる管理ドメインが境界で十分なレベルのイングレスフィルタリングを確実にしようとするべきです。
Security properties and applicability of different ingress filtering types differ a lot.
タイプをフィルターにかける異なったイングレスのセキュリティの特性と適用性は大いに異なります。
o Ingress Access Lists require typically manual maintenance, but are
the most bulletproof when done properly; typically, ingress access
lists are best fit between the edge and the ISP when the
configuration is not too dynamic if strict RPF is not an option,
between ISPs if the number of used prefixes is low, or as an
additional layer of protection.
o イングレスAccess Listsは通常手動のメインテナンスを必要としますが、適切にすると、最も防弾です。 構成が厳しいRPFがISPの間のオプションでないならそれほどダイナミックでないときに、中古の接頭語の数が下であるか追加層の保護としてあるなら、イングレスアクセスリストは通常、縁とISPの間の最良適合です。
o Strict RPF check is a very easy and sure way to implement ingress
filtering. It is typically fit between the edge network and the
ISP. In many cases, a simple strict RPF can be augmented by
operational procedures in the case of asymmetric traffic patterns,
or the feasible RPF technique to also account for other
alternative paths.
o 厳しいRPFチェックはイングレスがフィルタリングであると実装する非常に簡単で確かな方法です。 それは縁のネットワークとISPの間で通常適任です。 多くの場合、簡単な厳しいRPFは、また、他の迂回経路を説明するために非対称のトラフィック・パターンに関するケース、または可能なRPFのテクニックによる操作手順で増大できます。
o Feasible Path RPF check is an extension of Strict RPF. It is
suitable in all the scenarios where Strict RPF is, but multihomed
or asymmetric scenarios in particular. However, one must remember
that Feasible RPF assumes the consistent origination and
o 可能なPath RPFチェックはStrict RPFの拡大です。 それはStrict RPFがありますが、「マルチ-家へ帰」るシナリオか特に非対称のシナリオで適当です。 そしてしかしながら、Feasible RPFが一貫した創作を仮定するのを覚えていなければならない。
Baker & Savola Best Current Practice [Page 12] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[12ページ]RFC3704イングレス
propagation of routing information to work; the implications of
this must be understood especially if a prefix advertisement
passes through third parties.
扱うルーティング情報の伝播。 特に接頭語広告が第三者を通り抜けるなら、この含意を理解しなければなりません。
o Loose RPF primarily filters out unrouted prefixes such as Martian
addresses. It can be applied in the upstream interfaces to reduce
the size of DoS attacks with unrouted source addresses. In the
downstream interfaces it can only be used as a contract
verification, that the other network has performed at least some
ingress filtering.
o ゆるいRPFは主として火星のアドレスなどの非発送された接頭語を無視します。 非発送されたソースアドレスでDoS攻撃のサイズを減少させるために上流のインタフェースでそれを適用できます。 川下のインタフェースでは、契約検証としてそれを使用できるだけであって、もう片方のネットワークは少なくとも何らかのイングレスフィルタリングを実行しました。
When weighing the tradeoffs of different ingress filtering mechanisms, the security properties of a more relaxed approach should be carefully considered before applying it. Especially when applied by an ISP towards an edge network, there don't seem to be many reasons why a stricter form of ingress filtering would not be appropriate.
メカニズムをフィルターにかける異なったイングレスの見返りを熟慮するとき、それを適用する前に、より伸びやかなアプローチのセキュリティの特性は慎重に考えられるべきです。 特にISPによって縁のネットワークに向かって適用される場合、より厳しいフォームのイングレスフィルタリングが適切でない多くの理由はあるように思えません。
6. Conclusions and Future Work
6. 結論と今後の活動
This memo describes ingress filtering techniques in general and the options for multihomed networks in particular.
このメモは特に「マルチ-家へ帰」っているネットワークのために一般に、イングレスフィルター技術とオプションについて説明します。
It is important for ISPs to implement ingress filtering to prevent spoofed addresses being used, both to curtail DoS attacks and to make them more traceable, and to protect their own infrastructure. This memo describes mechanisms that could be used to achieve that effect, and the tradeoffs of those mechanisms.
ISPにおいて、防ぐフィルタリングがともにDoS攻撃を縮小して、それらをより起因するようにして、それら自身のインフラストラクチャを保護するのに使用されるアドレスを偽造したのは、道具イングレスに重要です。 このメモはその効果を達成するのに使用できたメカニズム、およびそれらのメカニズムの見返りを説明します。
To summarize:
まとめるために:
o Ingress filtering should always be done between the ISP and a
single-homed edge network.
o いつもイングレスフィルタリングはして、ISPとaの間では、縁のネットワークがシングル家へ帰っていたということであるべきです。
o Ingress filtering with Feasible RPF or similar Strict RPF
techniques could almost always be applied between the ISP and
multi-homed edge networks as well.
o そして、ISPの間でほとんどいつもFeasible RPFか同様のStrict RPFと共にテクニックをフィルターにかけるイングレスは適用できた、マルチ、家へ帰り、また、ネットワークを斜めに進ませてください。
o Both the ISPs and edge networks should verify that their own
addresses are not being used in source addresses in the packets
coming from outside their network.
o ISPと縁のネットワークの両方が、それら自身のアドレスがそれらのネットワークの外から来ながらパケットのソースアドレスで使用されていないことを確かめるべきです。
o Some form of ingress filtering is also reasonable between ISPs,
especially if the number of prefixes is low.
o また、特に接頭語の数が下位であるなら、何らかのフォームのイングレスフィルタリングもISPの間で妥当です。
Baker & Savola Best Current Practice [Page 13] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[13ページ]RFC3704イングレス
This memo will lower the bar for the adoption of ingress filtering especially in the scenarios like asymmetric/multihomed networks where the general belief has been that ingress filtering is difficult to implement.
このメモは一般的な信念がイングレスフィルタリングは実装するのが難しいということである非対称の、または、「マルチ-家へ帰」っているネットワークのように特にシナリオにおける、イングレスフィルタリングの採用のためのバーを下ろすでしょう。
One can identify multiple areas where additional work would be useful:
1つは追加仕事が役に立つ複数の領域を特定できます:
o Specify the mechanisms in more detail: there is some variance
between implementations e.g., on whether traffic to multicast
destination addresses will always pass the Strict RPF filter or
not. By formally specifying the mechanisms the implementations
might get harmonized.
o さらに詳細にメカニズムを指定してください: 例えば、マルチキャスト送付先アドレスへのトラフィックがいつもStrict RPFフィルタを渡すかどうかの実装の間には、何らかの変化があります。 正式にメカニズムを指定することによって、実装は調和するかもしれません。
o Study and specify Routing Information Base (RIB) -based RPF
mechanisms, e.g., Feasible Path RPF, in more detail. In
particular, consider under which assumptions these mechanisms work
as intended and where they don't.
o さらに詳細に研究してください、そして、経路情報の基地の(RIB)ベースのRPFメカニズム、例えばFeasible Path RPFを指定してください。 特に、これらのメカニズムが意図して、働かないところでどの仮定で働くか考えてください。
o Write a more generic note on the ingress filtering mechanisms than
this memo, after the taxonomy and the details or the mechanisms
(points above) have been fleshed out.
o 書く、 より多くのジェネリック注意、分類学と詳細かメカニズム(上を指す)がこのメモ太った後にメカニズムをフィルターにかけるイングレスで。
o Consider the more complex case where a network has connectivity
with different properties (e.g., peers and upstreams), and wants
to ensure that traffic sourced with a peer's address should not be
accepted from the upstream.
o ネットワークが、異なった特性(例えば、同輩と上流)がある接続性を持って、同輩のアドレスで出典を明示されたトラフィックが上流から受け入れられるべきでないのを保証したがっているより複雑なケースを考えてください。
7. Acknowledgements
7. 承認
Rob Austein, Barry Greene, Christoph Reichert, Daniel Senie, Pedro Roque, and Iljitsch van Beijnum reviewed this document and helped in improving it. Thomas Narten, Ted Hardie, and Russ Housley provided good feedback which boosted the document in its final stages.
ロブAustein、バリー・グリーン、クリストフ・ライヘルト、ダニエルSenie、ペドロ・ロッキ、およびIljitschバンBeijnumは、このドキュメントを再検討して、それを改良するのを手伝いました。 トーマスNarten、テッド・ハーディー、およびラスHousleyは最終段階でドキュメントを上げた良いフィードバックを提供しました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
[1] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
8.2. Informative References
8.2. 有益な参照
[2] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[2]ChandrasekeranとR.とTrainaとP.とT.李、「BGP共同体属性」、RFC1997、1996年8月。
Baker & Savola Best Current Practice [Page 14] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[14ページ]RFC3704イングレス
[3] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[3]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[4] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed
Multi-provider Connectivity", RFC 2260, January 1998.
[4] ベイツ、T.、およびY.Rekhter、「スケーラブルなサポート、マルチ、家へ帰り、マルチプロバイダーの接続性、」、RFC2260、1月1998日
[5] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit
Routers", RFC 3178, October 2001.
[5]HaginoとJ.とH.スナイダー、「サイト出口ルータにおけるIPv6マルチホーミングサポート」、RFC3178、2001年10月。
9. Authors' Addresses
9. 作者のアドレス
Fred Baker Cisco Systems Santa Barbara, CA 93117 US
フレッド・ベイカー・シスコシステムズのカリフォルニア93117サンタバーバラ(米国)
EMail: fred@cisco.com
メール: fred@cisco.com
Pekka Savola CSC/FUNET Espoo Finland
ペッカ・Savola CSC/FUNETエスポーフィンランド
EMail: psavola@funet.fi
メール: psavola@funet.fi
Baker & Savola Best Current Practice [Page 15] RFC 3704 Ingress Filtering for Multihomed Networks March 2004
2004年3月にMultihomedのためにネットワークをフィルターにかけるベイカーとSavolaの最も良い現在の習慣[15ページ]RFC3704イングレス
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baker & Savola Best Current Practice [Page 16]
ベイカーとSavolaの最も良い現在の習慣[16ページ]
一覧
スポンサーリンク
