Internet Engineering Task Force (IETF) D. Dugal
Request for Comments: 6192 Juniper Networks
Category: Informational C. Pignataro
ISSN: 2070-1721 R. Dunn
Cisco Systems
March 2011
Protecting the Router Control Plane
Abstract
抽象
This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
このメモは、望ましくないまたは悪意のあるトラフィックからルータのコントロールプレーンを保護するための方法を提供します。このアプローチでは、すべての正当なルータコントロールプレーントラフィックが識別されます。正当なトラフィックが識別されたら、フィルタは、ルータのフォワーディングプレーンに展開されています。そのフィルタは、許容可能なレベルにまで、そのようなトラフィックをルータの制御プレーンに到達する、または速度制限から特異的正当として識別されていないトラフィックを防止します。
Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router.
このメモで説明したフィルタがルータを通過するすべてのトラフィックにのみルータ宛てのトラフィックに適用され、されていないことに注意してください。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6192.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6192で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本書の出版物。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Applicability Statement .........................................4
3. Method ..........................................................4
3.1. Legitimate Traffic .........................................5
3.2. Filter Design ..............................................6
3.3. Design Trade-Offs ..........................................7
3.4. Additional Protection Considerations ......................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................11
6. Informative References .........................................12
Appendix A. Configuration Examples ................................13
A.1. Cisco Configuration .......................................13
A.2. Juniper Configuration .....................................17
Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software. The router control plane supports routing and management functions. It is generally described as the router architecture hardware and software components for handling packets destined to the device itself as well as building and sending packets originated locally on the device. The forwarding plane is typically described as the router architecture hardware and software components responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's IP next hop and determine the best outgoing interface towards the destination, and forwarding the packet out through the appropriate outgoing interface.
現代のルータアーキテクチャの設計は、転送ルータコントロールプレーンのハードウェアおよびソフトウェアの厳格な分離を維持します。ルータ制御プレーンは、ルーティングおよび管理機能をサポートしています。これは、一般的にそれ自体ならびにパケットを構築し、送信デバイス上でローカルに発信装置宛てのパケットを処理するためのルータ・アーキテクチャのハードウェアおよびソフトウェア構成要素として記載されています。転送プレーンは、典型的には、先に向かって最高の発信インタフェースをパケットのIPネクストホップを識別し、決定するためにルックアップを実行、着信インターフェイス上でパケットを受信し、そして介してパケットを転送する責任ルータアーキテクチャのハードウェアおよびソフトウェア構成要素として記載されています適切な発信インターフェイス。
Visually, this architecture can be represented as the router's control plane hardware sitting on top of, and interfacing with, the forwarding plane hardware with interfaces connecting to other network devices. See Figure 1.
視覚的に、このアーキテクチャは、ルータの制御プレーンのハードウェアは、上に座って、他のネットワーク機器に接続するインターフェースと転送プレーンのハードウェアとのインターフェースとして表すことができます。図1を参照してください。
+----------------+
| Router Control |
| Plane |
+------+ +-------+
| |
Router Control
Plane Protection
| |
+------+ +-------+
| Forwarding |
Interface X ==[ Plane ]== Interface Y
+----------------+
Figure 1: Router Control Plane Protection
図1：ルータのコントロールプレーン保護
Typically, forwarding plane functionality is realized in high-performance Application Specific Integrated Circuits (ASICs) that are capable of handling very high packet rates. By contrast, the router control plane is generally realized in software on general-purpose processors. While software instructions run on both planes, the router control plane hardware is usually not optimized for high-speed packet handling. Given their differences in packet-handling capabilities, the router's control plane hardware is more susceptible to being overwhelmed by a Denial-of-Service (DoS) attack than the forwarding plane's ASICs. It is imperative that the router control plane remain stable regardless of traffic load to and from the device because the router control plane is what drives the programming of the forwarding plane.
典型的には、転送プレーン機能は、非常に高いパケットレートを取り扱うことのできる高性能特定用途向け集積回路（ASIC）で実現されます。対照的に、ルータ制御プレーンは、一般に汎用プロセッサ上のソフトウェアで実現されます。ソフトウェア命令は、両方の面上で実行している間、ルータのコントロールプレーンのハードウェアは、通常、高速パケット処理用に最適化されていません。パケット処理機能では、その違いを考えると、ルータのコントロールプレーンのハードウェアは、フォワーディングプレーンのASICに比べてサービス拒否（DoS）攻撃に圧倒されているの影響を受けやすくなります。ルータ制御プレーンは、フォワーディングプレーンのプログラミングを駆動するものであるため、ルータの制御プレーンは、デバイスにしてからにかかわらず、トラフィック負荷の安定を維持することが不可欠です。
The router control plane also processes traffic destined to the router, and because of the wider range of functionality is more susceptible to security vulnerabilities and a more likely target for a DoS attack than the forwarding plane.
ルータ制御プレーンは、ルータ宛てのトラフィックを処理し、ための機能の広い範囲のセキュリティ上の脆弱性とフォワーディングプレーンよりもDoS攻撃のための可能性が高いターゲットの影響を受けやすくなります。
It is advisable to protect the router control plane by implementing mechanisms to filter completely or rate-limit traffic not required at the control plane level (i.e., unwanted traffic). "Router control plane protection" is the concept of filtering or rate-limiting unwanted traffic that would be diverted from the forwarding plane up to the router control plane. The closer the filters and rate limiters are to the forwarding plane and line-rate hardware, the more effective the protection is and the more resistant the system is to DoS attacks. This memo demonstrates one example of how to deploy a policy filter that satisfies a set of sample traffic-matching, filtering, and rate-limiting criteria.
完全にフィルタリングするメカニズムを実装するか、コントロールプレーンレベル（即ち、不要なトラフィック）で必要ではないレート制限トラフィックによってルータ制御プレーンを保護することが望ましいです。 「ルータのコントロールプレーン保護は、」アップルータ制御プレーンへのフォワーディングプレーンから流用されるだろうフィルタリングまたはレート制限不要なトラフィックの概念です。近いフィルタおよびレートリミッタは、転送プレーンとラインレートハードウェアに、より効果的な保護は、より耐性のシステムは、DoS攻撃です。このメモは、サンプルトラフィックマッチングのセット、フィルタリング、およびレート制限基準を満たすポリシー・フィルタを展開する方法の一例を示します。
Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router.
このメモで説明したフィルタがルータを通過するすべてのトラフィックにのみルータ宛てのトラフィックに適用され、されていないことに注意してください。
The method described in Section 3 and depicted in Figure 1 illustrates how to protect the router control plane from unwanted traffic. Recognizing that deployment scenarios will vary, the exact implementation is not generally applicable in all situations. The categorization of legitimate router control plane traffic is critically important in a successful implementation.
図1の第3章に記載され示された方法は、不要なトラフィックからルータ制御プレーンを保護する方法を示しています。展開シナリオが変化することを認識し、正確な実装は、すべての状況で、一般的には適用できません。正当なルータコントロールプレーントラフィックの分類は、実装を成功に決定的に重要です。
The examples given in this memo are simplified and minimalistic, designed to illustrate the concept of protecting the router's control plane. From them, operators can extrapolate specifics based on their unique configuration and environment. This document is about semantics, and Appendix A exemplifies syntax. For additional router vendor implementations, or other converged devices, the syntax should be translated to the respective language in a manner that preserves the semantics.
このメモで与えられる例は、簡略化及びミニマル、ルータのコントロールプレーンを保護する概念を説明するために設計されています。彼らからは、事業者は、独自の構成や環境に基づいて詳細を推定することができます。このドキュメントは、意味論についてです、そして付録Aには、構文を例示しています。追加ルータのベンダー実装、または他の集中型デバイスの場合、構文はセマンティクスを維持する方法で、それぞれの言語に翻訳されなければなりません。
Additionally, the need to provide the router control plane with isolation, stability, and protection against rogue packets has been incorporated into router designs for some time. Consequently, there may be other vendor or implementation specific router control plane protection mechanisms that are active by default or always active. Those approaches may apply in conjunction with, or in addition to, the method described in Section 3 and illustrated in Appendices A.1 and A.2. Those implementations should be considered as part of an overall traffic management plan but are outside the scope of this document.
また、不正なパケットに対して分離、安定性、および保護をルータ制御プレーンを提供する必要性がいくつかの時間のためのルータの設計に組み込まれています。したがって、デフォルトでアクティブまたは常に活性である他のベンダーまたは実装固有のルータ制御プレーン保護メカニズムが存在してもよいです。これらのアプローチは、と組み合わせて適用する、またはセクション3に記載され付録A.1およびA.2に示された方法に加えてもよいです。これらの実装は、全体的なトラフィック管理計画の一環として考えたが、この文書の範囲外であるべきです。
This method is applicable for IPv4 as well as IPv6 address families, and the legitimate traffic example in Section 3.1 provides examples for both.
この方法は、IPv4と同様にIPv6アドレスファミリに適用可能であり、セクション3.1に正当なトラフィックの例は、両方の例を提供します。
In this memo, the authors demonstrate how a filter protecting the router control plane can be deployed. In Section 3.1, a sample router is introduced, and all traffic that its control plane must process is identified. In Section 3.2, filter design concepts are discussed. Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are provided in Appendices A.1 and A.2, respectively.
このメモでは、著者は、ルータのコントロールプレーンを保護するフィルタを展開することができる方法を示しています。 3.1節では、サンプルルータが導入され、すべてのトラフィックを処理しなければならない、そのコントロールプレーンが特定されていること。 3.2節では、フィルタ設計コンセプトが議論されています。シスコ（Cisco IOSソフトウェア）およびジュニパー（JUNOS）の実装は、それぞれ、付録A.1およびA.2に設けられています。
In this example, the router control plane must process traffic (i.e., traffic destined to the router and not through the router) per the following criteria:
この例では、ルータ制御プレーンは、次の条件ごとに（すなわち、トラフィックルータを介してルータ宛ではなく）トラフィックを処理しなければなりません。
o Drop all IP packets that are fragments (see Section 3.3)
O断片である、すべてのIPパケットをドロップします（3.3節を参照してください）
o Permit ICMP and ICMPv6 traffic from any source, rate-limited to 500 kbps for each category
O許可ICMPや任意のソースからのICMPv6トラフィックは、カテゴリごとに500 kbpsに速度が制限され
o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and OSPFv3 traffic from IPv6 Link-Local unicast addresses (fe80::/10)
O IPv6のリンクローカルユニキャストアドレス（FE80 :: / 10）からサブネット192.0.2.0/24とのOSPFv3トラフィック内のルータからOSPFトラフィックを許可
o Permit internal BGP (iBGP) traffic from routers within subnets 192.0.2.0/24 and 2001:db8:1::/48
DB8：1 :: / 48 O 192.0.2.0/24と2001年のサブネット内のルータから内部BGP（iBGPの）トラフィックを許可
o Permit external BGP (eBGP) traffic from eBGP peers 198.51.100.25, 198.51.100.27, 198.51.100.29, and 198.51.100.31; and IPv6 peers 2001:db8:100::25, 2001:db8:100::27, 2001:db8:100::29, and 2001:db8:100::31
eBGPは198.51.100.25、198.51.100.27、198.51.100.29、および198.51.100.31をピアからO、外部BGP（のeBGP）トラフィックを許可します。およびIPv6 2001ピア：DB8：100 :: 25、2001：DB8：100 :: 27、2001：DB8：100 :: 29、および2001：DB8：100 :: 31
o Permit DNS traffic from DNS servers within subnet 198.51.100.0/30 and 2001:db8:100:1::/64
サブネット198.51.100.0/30と2001内のDNSサーバからOを許可DNSトラフィック：1 :: / 64：DB8：100
o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30 and 2001:db8:100:2::/64
DB8：：100：2 :: / 64 Oサブネット内のNTPサーバから198.51.100.4/30と2001年のNTPトラフィックを許可
o Permit Secure SHell (SSH) traffic from network management stations within subnet 198.51.100.128/25 and 2001:db8:100:3::/64
DB8：100：3 :: / 64 Oの許可は、サブネット内のネットワーク管理ステーションから198.51.100.128/25及び2001シェル（SSH）トラフィックをセキュア
o Permit Simple Network Management Protocol (SNMP) traffic from network management stations within subnet 198.51.100.128/25 and 2001:db8:100:3::/64
DB8：：100：3 :: / 64 Oサブネット内198.51.100.128/25と2001年をネットワーク管理ステーションからのSNMP（Simple Network Management Protocol）トラフィックを許可
o Permit RADIUS authentication and accounting replies from RADIUS servers 198.51.100.9, 198.51.100.10, 2001:db8:100::9, and 2001:db8:100::10 that are listening on UDP ports 1812 and 1813 (Internet Assigned Numbers Authority (IANA) RADIUS ports). Note that this does not accommodate a server using the original UDP ports of 1645 and 1646
RADIUSサーバ198.51.100.9からO許可RADIUS認証およびアカウンティング応答、198.51.100.10、2001：DB8：100 :: 9、および2001：DB8：100 :: 10 UDPポート1812と1813（インターネット割り当て番号機関に聞いています（IANA）RADIUSポート）。これは1645年と1646年のオリジナルのUDPポートを使用してサーバーに対応していないことに注意してください
o Permit all other IPv4 and IPv6 traffic that was not explicitly matched in a class above, rate-limited to 500 kbps, and drop above that rate for each category
O 500 kbpsにレート制限され、明示的に上記のクラスに一致しなかった他のすべてのIPv4およびIPv6トラフィックを許可し、各カテゴリのためにそのレート上のドロップ
o Permit non-IP traffic (e.g., Connectionless Network Service (CLNS), Internetwork Packet Exchange (IPX), PPP Link Control Protocol (LCP), etc.), rate-limited to 250 kbps, and drop all remaining traffic above that rate
許可非IPトラフィック（例えば、コネクションレスネットワークサービス（CLNS）、インターネットワークパケット交換（IPX）、PPPリンク制御プロトコル（LCP）など）O、250 kbpsにレート制限、およびその速度の上方に残りのすべてのトラフィックをドロップ
The characteristics of legitimate traffic will vary from network to network. To illustrate this, a router implementing the DHCP relay function can rate-limit inbound DHCP traffic from clients and restrict traffic from servers to a list of known DHCP servers. The list of criteria above is provided for example only.
正当なトラフィックの特性は、ネットワークからネットワークに変化します。これを説明するために、DHCPリレー機能を実装するルータは、クライアントからの着信DHCPトラフィックを制限レートと知られているDHCPサーバのリストに、サーバからのトラフィックを制限することができます。上記の基準のリストは、単に例のために提供されます。
A filter is installed on the forwarding plane. This filter counts and applies the actions to the categories of traffic described in Section 3.1. Because the filter is enforced in the forwarding plane, it prevents traffic from consuming bandwidth on the interface that connects the forwarding plane to the router control plane. The counters serve as an important forensic tool for the analysis of potential attacks, and as an invaluable debugging and troubleshooting aid. By adjusting the granularity and order of the filters, more granular forensics can be performed (i.e., create a filter that matches only traffic allowed from a group of IP addresses for a given protocol followed by a filter that denies all traffic for that protocol). This would allow for counters to be monitored for the allowed protocol filter, as well as any traffic matching the specific protocol that didn't originate from the explicitly allowed hosts.
フィルタは、転送プレーンにインストールされています。このフィルタの数と3.1節で説明したトラフィックの分類にアクションを適用します。フィルタがフォワーディングプレーンに施行されているので、それはルータの制御プレーンにフォワーディングプレーンを接続するインターフェイス上の帯域幅を消費するからトラフィックを防ぎます。カウンタは、潜在的な攻撃の分析のための重要な法医学ツールとして、そして貴重なデバッグとトラブルシューティングの補助としての役割を果たす。フィルタの精度及び順序を調整することにより、より詳細なフォレンジック（すなわち、そのプロトコルのすべてのトラフィックを拒否フィルタが続く特定のプロトコルのためのIPアドレスの群から許容トラフィックのみに一致するフィルタを作成）を行うことができます。これは、許可されたプロトコルフィルタだけでなく、明示的に許可されているホストから発信されなかった特定のプロトコルに一致するすべてのトラフィックを監視するカウンターを可能にするであろう。
In addition to the filters, rate limiters for certain classes of traffic are also installed in the forwarding plane as defined in Section 3.1. These rate limiters help further control the traffic that will reach the router control plane for each filtered class as well as all traffic not matching an explicit class. The actual rates selected for various classes are network deployment specific; analysis of the rates required for stability should be done periodically. It is important to note that the most significant factor to consider regarding the traffic profile going to the router control plane is the packets per second (pps) rate. Therefore, careful consideration must be given to determine the maximum pps rate that could be generated from a given set of packet size and bandwidth usage scenarios.
セクション3.1で定義されるようにフィルタに加えて、特定のトラフィッククラスのレートリミッタはまた、転送プレーンにインストールされています。これらのレートリミッタは、各フィルタクラスのルータ制御プレーンだけでなく、すべてのトラフィックの明示的なクラスを一致していないに到達するトラフィックを制御するのに役立ちます。様々なクラスのために選択された実際のレートは、特定のネットワークを展開しています。安定性のために必要な速度の分析が定期的に行われるべきです。トラフィックプロファイルは、ルータ制御プレーンに行くに関して考慮すべき最も重要な要因は、秒あたりのパケット（PPS）率であることに注意することが重要です。したがって、慎重に検討は、パケットサイズおよび帯域幅の使用シナリオの所定のセットから生成され得る最大PPSレートを決定するために与えられなければなりません。
Syntactically, these filters explicitly define "allowed" traffic (including IP addresses, protocols, and ports), define acceptable actions for these acceptable traffic profiles (e.g., rate-limit or simply permit the traffic), and then discard all traffic destined to the router control plane that is not within the specifications of the policy definition.
構文的には、これらのフィルタは、明示的に、（IPアドレス、プロトコル、およびポートを含む）「許可」トラフィックを定義し、これらの許容可能なトラフィックプロファイルのための許容可能なアクションを定義（例えば、レート制限または単にトラフィックを許可）、そして宛てのすべてのトラフィックを破棄しますポリシー定義の仕様の範囲内ではないルータ制御プレーン。
In an actual production environment, predicting a complete and exhaustive list of traffic necessary to reach the router's control plane for day-to-day operation may not be as obvious as the example described herein. One recommended method to gauge this set of traffic is to allow all traffic initially, and audit the traffic that reaches the router control plane before applying any explicit filters or rate limits. See Section 3.3 below for more discussion of this topic.
実際の運用環境では、日々のオペレーションのためのルータのコントロールプレーンに到達するために必要なトラフィックの完全かつ網羅したリストを予測することは、本明細書に記載された例のように明らかではないかもしれません。トラフィックのこのセットを測るための一つの方法をお勧めは、まず、すべてのトラフィックを許可し、明示的なフィルタやレート制限を適用する前に、ルータのコントロールプレーンに到達したトラフィックを監査することです。このトピックのより多くの議論については、以下のセクション3.3を参照してください。
The filter design provided in this document is intentionally limited to attachment at the local router in question (e.g., a "service-policy" attached to the "control-plane" in Cisco IOS, or a firewall filter attached to the "lo0" interface in JUNOS). While virtually all production environments utilize and rely heavily upon edge protection or interface filtering, these methods of router protection are beyond the intended scope of this document. Additionally, the protocols themselves that are allowed to reach the router control plane (e.g., OSPF, RSVP, TCP, SNMP, DNS, NTP, and inherently, SSH, TLS, ESP, etc.) may have cryptographic security methods applied to them, and the method of router control plane protection provided herein is not a replacement for those cryptographic methods.
このドキュメントに記載されているフィルタ設計は、意図的に問題になっているローカルルータ（で添付ファイルに限られているなど、「lo0で」インターフェイスに接続されたCisco IOSの「コントロールプレーン」に添付の「サービスポリシー」、またはファイアウォールフィルタJUNOSで）。事実上すべての本番環境を活用し、エッジ保護またはインタフェースのフィルタリングに大きく依存していますが、ルータを保護するこれらの方法は、この文書の意図した範囲を超えています。また、ルータ制御プレーン（例えば、OSPF、RSVP、TCP、SNMP、DNS、NTP、および本質的に、SSH、TLS、ESPなど）を到達させているプロトコル自体はそれらに適用される暗号化セキュリティメソッドを有していてもよく、本明細書で提供されるルータ制御プレーン保護の方法は、これらの暗号化方法の代替ではありません。
In designing the protection method, there are two independent parts to consider: the classification of traffic (i.e., which traffic is matched by the filters), and the policy actions taken on the classified traffic (i.e., drop, permit, rate-limit, etc.).
保護方法を設計する際には、二つの独立を検討するための部品があります。（つまり、トラフィックはフィルタにマッチしている）、トラフィックの分類、および分類されたトラフィックに（すなわち、ドロップ、許可証、レート制限を取ら政策行動は、等。）。
There are different levels of granularity utilized for traffic classification. For example, allowing all traffic from specific source IP addresses versus allowing only a specific set of protocols from those specific source IP addresses will each affect a different subset of traffic.
トラフィックの分類に利用する粒度の異なるレベルがあります。例えば、各トラフィックの異なるサブセットに影響するこれらの特定の送信元IPアドレスからのプロトコルの唯一の特定のセットを許可に対する特定の送信元IPアドレスからのすべてのトラフィックを許可します。
Similarly, the policy actions taken on the classified traffic have degrees of impact that may not become immediately obvious. For example, discarding all ICMP traffic will have a negative impact on the operational use of ICMP tools such as ping or traceroute to debug network issues or to test deployment of a new circuit. Expanding on this, in a real production network, an astute operator could define varying rate limits for ICMP such that internal traffic is granted uninhibited access to the router control plane, while traffic from external addresses is rate-limited. Operators should pay special attention to the new functionality and roles that ICMPv6 has in the overall operation of IPv6 when designing the rate-limit policies. Example functions include Neighbor Discovery (ND) and Multicast Listener Discovery version 2 (MLDv2).
同様に、分類されたトラフィックに取ら政策行動はすぐに明らかになっていないことの影響度を持っています。たとえば、すべてのICMPトラフィックを破棄することは、pingやtracerouteのようデバッグネットワークの問題にICMPツールの操作上の使用にマイナスの影響を与えることになるか、新しい回路の展開をテストします。このように拡大、実際の生産ネットワークでは、抜け目のないオペレータが、外部アドレスからのトラフィックは、レート制限されながら、内部トラフィックは、ルータ制御プレーンに阻害されていないアクセスが許可されるようにICMPの変化率制限を定義することができます。オペレータは、レート制限ポリシーを設計する際のICMPv6は、IPv6の全体的な動作であり、新たな機能や役割に特別な注意を払う必要があります。例関数は近隣探索（ND）とマルチキャストリスナ探索バージョン2（MLDv2）が挙げられます。
It is important to note that both classification and policy action decisions are accompanied by respective trade-offs. Two examples of these trade-off decisions are operational complexity at the expense of policy and statistics-gathering detail, and tighter protection at the expense of network supportability and troubleshooting ability.
両方の分類とポリシーアクションの決定は、それぞれのトレードオフを伴っていることに注意することが重要です。これらのトレードオフの意思決定の2つの例は、ネットワークのサポート性とトラブルシューティング能力を犠牲にして政策と統計収集の詳細、および緊密な保護を犠牲にして、操作の複雑さです。
Two types of traffic that need special consideration are IP fragments and IP optioned packets:
特別な配慮を必要とする2種類のトラフィックは、IPフラグメントであり、IPパケットをオプションで用意しました。
o For network deployments where IP fragmentation is necessary, a blanket policy of dropping all fragments destined to the router control plane may not be feasible. However, many deployments allow network configurations such that the router control plane should never see a fragmented datagram. Since many attacks rely on IP fragmentation, the example policy included herein drops all fragments destined to the router control plane.
O IP断片化が必要であるネットワークの展開では、ルータのコントロールプレーン宛てのすべての断片を落とすのブランケット政策は実現可能ではないかもしれません。しかし、多くの配備は、ルータのコントロールプレーンが断片化したデータグラムを見ることはありませんことをネットワーク構成は、このようなことができます。多くの攻撃は、IPフラグメンテーションに依存しているので、ここに含ま例のポリシーでは、ルータのコントロールプレーン宛てのすべての断片を削除します。
o Similarly, some deployments may choose to drop all IP optioned packets. Others may need to loosen the constraint to allow for protocols that require IP optioned packets such as the Resource Reservation Protocol (RSVP). The design trade-off is that dropping all IP optioned packets protects the router from attacks that leverage malformed options, as well as attacks that rely on the slow-path processing (i.e., software processing path) of IP optioned packets. For network deployments where the protocols do not use IP options, the filter is simpler to design in that it can drop all packets with any IP option set. However, for networks utilizing protocols relying on IP options, the filter to identify the legitimate packets is more complex. If the filter is not designed correctly, it could result in the inadvertent blackholing of traffic for those protocols. This document does not include filter configurations for IP optioned packets; additional explanations regarding the filtering of packets based on the IP options they contain can be found in [IP-OPTIONS-FILTER].
O同様に、いくつかの展開では、すべてのIPオプションのあるパケットをドロップすることもできます。その他にはIPは、このようなリソース予約プロトコル（RSVP）などのパケットをオプションで用意必要とするプロトコルを可能にするための制約を緩める必要があるかもしれません。設計上のトレードオフは、すべてのIPパケットをオプションで用意ドロップすると、レバレッジ不正なオプションだけでなく、攻撃IPオプションで用意パケットのスローパス処理（すなわち、ソフトウェア処理経路）に依存していることを攻撃からルータを保護することです。プロトコルはIPオプションを使用しないネットワーク展開のために、フィルタは、それが任意のIPオプションが設定されたすべてのパケットをドロップすることができるという点で設計するのが簡単です。しかし、ネットワークはIPオプションに依存するプロトコルを利用するために、正当なパケットを識別するためのフィルタはより複雑です。フィルタが正しく設計されていない場合は、これらのプロトコルのトラフィックの不注意なブラックホールにつながる可能性があります。この文書では、IPオプションで用意したパケットのフィルタ設定が含まれていません。それらに含まれるIPオプションに基づいてパケットのフィルタリングに関する追加の説明は、[IP-OPTIONS-FILTER]で見つけることができます。
The goal of the method for protecting the router control plane is to minimize the possibility for disruptions by reducing the vulnerable surface, which is inversely proportional to the granularity of the filter design. The finer the granularity of the filter design (e.g., filtering a more targeted subset of traffic from the rest of the policed traffic, or isolating valid source addresses into a different class or classes), the smaller the probability of disruption.
ルータコントロールプレーンを保護するための方法の目的は、フィルタ設計の粒度に反比例する脆弱な表面を減少させることによって混乱の可能性を最小にすることです。フィルタの設計（例えば、ポリシングトラフィックの残りの部分からのトラフィックのよりターゲットを絞ったサブセットをフィルタリングする、または別のクラスまたはクラスに有効な送信元アドレスを単離）のより細かい粒度、より小さな破壊の確率。
In addition to the traffic that matches explicit classes, care should be taken on the policy decision that governs the handling of traffic that would fall through the classification. Typically, that traffic is referred to as traffic that gets matched in a default class. It may also be traffic that matches a blanket protocol specific class where previous classes that have more granular classification did not match all packets for that specific protocol. The ideal policy would have explicit classes to match only the traffic specifically required at the router control plane and would drop all other traffic that does not match a predefined class. As most vendor implementations permit all traffic hitting the default class, an explicit drop action would need to be configured in the policy such that the traffic hitting that default class would be dropped, versus being permitted and delivered to the router control plane. This approach requires rigorous traffic pattern identification such that a default drop policy does not break existing device functionality. The approach defined in this document allows the default traffic and rate-limits it as opposed to dropping it. This approach was chosen as a way to give the operator time to evaluate and characterize traffic in a production scenario prior to dropping all traffic not explicitly matched and permitted. However, it is highly recommended that after monitoring the traffic matching the default class, explicit classes be defined to catch the legitimate traffic. After all legitimate traffic has been identified and explicitly allowed, the default class should be configured to drop any remaining traffic.
明示的なクラスに一致するトラフィックに加えて、ケアは、分類を通じて落ちるトラフィックの取り扱いを管理政策決定に取られるべきです。一般的に、そのトラフィックは、デフォルトのクラスにマッチしますトラフィックと呼ばれています。それはまた、より詳細な分類があり、以前のクラスは、特定のプロトコルのすべてのパケットを一致しませんでした毛布プロトコル特定のクラスに一致するトラフィックかもしれません。理想的な方針は、特にルータ制御プレーンに必要なトラフィックだけを一致させるために、明示的なクラスを持っているでしょうし、事前に定義されたクラスに一致しない他のすべてのトラフィックをドロップします。ほとんどのベンダーの実装は、デフォルトのクラスを打つすべてのトラフィックを許可するよう、明示的なドロップアクションは、トラフィックがデフォルトのクラスは、ルータのコントロールプレーンに許可され、配信される対、ドロップされることを打つようなポリシーで設定する必要があります。このアプローチは、デフォルトのドロップポリシーは、既存のデバイスの機能を壊さないように厳格なトラフィックパターンの識別が必要です。この文書で定義されたアプローチは、それをドロップするとは対照的に、デフォルトのトラフィックおよびレート制限、それを可能にします。このアプローチは、評価し、前に明示的に一致し、許可されていないすべてのトラフィックをドロップし、生産のシナリオでトラフィックを特徴づけるためのオペレータの時間を与えるための方法として選ばれました。しかし、非常にデフォルトのクラスと一致するトラフィックを監視した後に、明示的なクラスが正当なトラフィックをキャッチするように定義することをお勧めします。すべての正当なトラフィックを識別し、明示的に許可された後、デフォルトのクラスは、任意の残りのトラフィックをドロップするように設定する必要があります。
Additionally, the baselining and monitoring of traffic flows to the router's control plane are critical in determining both the rates and granularity of the policies being applied. It is also important to validate the existing policies and rules or update them as the network evolves and its traffic dynamics change. Some possible ways to achieve this include individual policy counters that can be exported or retrieved, for example via SNMP, and logging of filtering actions.
また、トラフィックのベースラインとモニタリングはルータの制御プレーンに流れ率と適用されたポリシーの細かさの両方を決定する上で極めて重要です。既存のポリシーとルールを検証したり、ネットワークが進化し、そのトラフィックのダイナミクスの変化に応じてそれらを更新することも重要です。いくつかの可能な方法は、これは、個々の政策SNMP経由して、たとえば、エクスポートまたは検索することができ、カウンタ、およびフィルタリングアクションのログを含める実現しています。
Finally, the use of flow-based behavioral analysis or command-line interface (CLI) functions to identify what client/server functions a given router's control plane handles would be very useful during initial policy development phases, and certainly for ongoing forensic analysis.
最後に、フローベース行動分析またはコマンドラインインタフェース（CLI）機能を使用すると、特定のルータのコントロールプレーンハンドルが初期ポリシー開発の段階で非常に有用であること、そして確かに継続的な法医学的分析のためになるのか、クライアント/サーバー機能を識別します。
In addition to the design described in this document of defining "allowed" traffic (i.e., identifying traffic that the control plane must process) and limiting (e.g., rate-limiting or blocking) the rest, the router control plane protection method can be applied to thwart specific attacks. In particular, it can be used to protect against TCP SYN flooding attacks and other Denial-of-Service attacks that starve router control plane resources.
トラフィック（すなわち、制御プレーンを処理しなければならないトラフィックを識別）と（例えば、レート制限またはブロック）を制限し、残り「許可」を定義この文書で説明した設計に加えて、ルータの制御プレーンの保護方法を適用することができます特定の攻撃を阻止します。特に、TCP SYNフラッド攻撃やルータの制御プレーン資源を餓死他のサービス拒否攻撃から保護するために使用することができます。
The filters described in this document leave the router susceptible to discovery from any host in the Internet. If network operators find this risk objectionable, they can reduce the exposure to discovery with ICMP by restricting the sub-networks from which ICMP Echo requests and potential traceroute packets (i.e., packets that would trigger an ICMP Time Exceeded reply) are accepted, and therefore to which sub-networks ICMP responses (ICMP Echo Reply and Time Exceeded) are sent. A similar concern exists for ICMPv6 traffic but on a broader level due to the additional functionalities implemented in ICMPv6. Filtering recommendations for ICMPv6 can be found in [RFC4890]. Moreover, different rate-limiting policies may be defined for internally (e.g., from the Network Operations Center (NOC)) versus externally sourced traffic. Note that this document is not targeted at the specifics of ICMP filtering or traffic filtering designed to prevent device discovery.
この文書で説明するフィルタは、インターネット内の任意のホストから発見されやすいルータを残します。ネットワークオペレータは、このリスクが不快に感じる場合は、ICMPエコー要求および潜在的なトレースルートパケット、そこからサブネットワークを制限することにより、ICMPと発見への露出を減らすことができます（すなわち、ICMP時間をトリガーするパケットが返信を超過）受け入れられているので、これにサブネットワークのICMP応答（ICMPエコー応答と時間超過）が送信されます。同様の懸念は、ICMPv6のトラフィックのためではなく、ICMPv6のに実装追加機能のために、より広いレベルで存在します。 ICMPv6のためのフィルタリング勧告は、[RFC4890]で見つけることができます。また、異なるレート制限ポリシーは、内部（例えば、ネットワークオペレーションセンター（NOC）から）外部から供給トラフィック対のために定義されてもよいです。この文書は、ICMPフィルタリングまたはデバイスの検出を防ぐために設計されたトラフィックのフィルタリングの詳細をターゲットにされていないことに注意してください。
The filters described in this document do not block unwanted traffic having spoofed source addresses that match a defined traffic profile as discussed in Section 3.1. Network operators can mitigate this risk by preventing source address spoofing with filters applied at the network edge. Refer to Section 5.3.8 of [RFC1812] for more information regarding source address validation. Other methods also exist for limiting exposure to packet spoofing, such as the Generalized Time to Live (TTL) Security Mechanism (GTSM) [RFC5082] and Ingress Filtering [RFC2827] [RFC3704].
この文書で説明するフィルタは、3.1節で説明したように定義されたトラフィックプロファイルに一致する偽装された送信元アドレスを持つ不要なトラフィックをブロックしません。ネットワークオペレータは、ネットワークエッジで適用されるフィルタと送信元アドレスのスプーフィングを防止することによって、このリスクを軽減することができます。送信元アドレスの検証の詳細については、[RFC1812]のセクション5.3.8を参照してください。他の方法は、（TTL）セキュリティメカニズム（GTSM）[RFC5082]と入力フィルタリング[RFC2827]、[RFC3704]をライブするためにそのような一般化時間として、パケットスプーフィングへの曝露を制限するために存在します。
The ICMP rate limiter specified for the filters described in this document protects the router from floods of ICMP traffic; see Sections 3.1 and 3.3 for details. However, during an ICMP flood, some legitimate ICMP traffic may be dropped. Because of this, when operators discover a flood of ICMP traffic, they are highly motivated to stop it at the source where the traffic is being originated.
この文書で説明フィルタに指定したICMPレートリミッタは、ICMPトラフィックの洪水からルータを保護します。セクションに詳細については、3.1と3.3を参照してください。しかし、ICMPフラッドの間に、いくつかの正当なICMPトラフィックがドロップされる可能性があります。事業者はICMPトラフィックの洪水を発見したときにこのため、彼らは、トラフィックが発信されているソースでそれを止めるために意欲的です。
Additional considerations pertaining to the usage and handling of traffic that utilizes the IP Router Alert Options can be found in [RTR-ALERT-CONS], and additional IP options filtering explanations can be found in [IP-OPTIONS-FILTER].
IPルータアラートオプションを利用して、トラフィックの使用及び取扱いに関するその他の考慮事項[RTR-ALERT-CONS]で見つけることができ、および追加のIPオプションフィルタリングの説明は、[IP-OPTIONS-FILTER]で見つけることができます。
The treatment of exception traffic in the forwarding plane and the generation of specific messages by the router control plane also require protection from a DoS attack. Specifically, the generation of ICMP Unreachable messages by the router control plane needs to be rate-limited, either implicitly within the router's architecture or explicitly through configuration. When possible, different ICMP Destination Unreachable codes (e.g., "fragmentation needed and DF set") or "Packet Too Big" messages can receive a different rate-limiting treatment. Continuous benchmarking of router-generated ICMP traffic should be done before applying rate limits such that sufficient headroom is included to prevent inadvertent Path Maximum Transmission Unit Discovery (PMTUD) blackhole scenarios during normal operation. It is also recommended to deploy explicit rate limiters where possible to improve troubleshooting and monitoring capability. The explicit rate limiters in a class allow for monitoring tools to detect and report when these rate limiters become active (i.e., when traffic is policed). This in turn serves as an indicator that either the normal traffic rates have increased or "out of policy" traffic rates have been detected. More thorough analysis of the traffic flows and rate-limited traffic is needed to identify which of these two cases triggered the rate limiters. For additional information regarding specific ICMP rate-limiting, see Section 4.3.2.8 of [RFC1812].
フォワーディングプレーンで例外トラフィックの処理やルータの制御プレーンにより、特定のメッセージの生成もDoS攻撃からの保護を必要とします。具体的には、ルータの制御プレーンによって、ICMP到達不能メッセージの生成には、暗黙のうちにルータのアーキテクチャ内または明示的な構成のいずれかを介して、レート制限する必要があります。可能な場合、異なったICMP宛先到達不能コード（例えば、「必要に応じて断片化とDFセット」）または「パケット過大」メッセージは、異なる速度制限処理を受けることができます。ルータが生成したICMPトラフィックの連続的なベンチマークは、十分なヘッドルームが通常動作中に不慮のパスの最大転送単位ディスカバリー（PMTUD）ブラックホールのシナリオを防ぐために含まれるような速度制限を適用する前に行われるべきです。また、トラブルシューティングや監視能力を向上させることが可能な場合は、明示的なレートリミッタを展開することをお勧めします。クラスの明示的なレートリミッタを検出し、これらのレートリミッタがアクティブになったときに報告するためのツールを監視するための許可（すなわち、トラフィックがポリシングされた場合）。これは、順番に、通常のトラフィックレートが増加しているか「政策のうち、」トラフィックレートが検出されたいずれかのことを指標として役立ちます。トラフィックフローおよびレート制限トラフィックのより徹底的な分析は、レートリミッタを引き起こし、これらの2例を識別するために必要です。特定のICMPレート制限に関する追加情報については、[RFC1812]のセクション4.3.2.8を参照してください。
Additionally, the handling of TTL / Hop Limit expired traffic needs protection. This traffic is not necessarily addressed to the device, but it can get sent to the router control plane to process the TTL / Hop Limit expiration. For example, rate-limiting the TTL / Hop Limit expired traffic before sending the packets to the router control plane component that will generate the ICMP error, and distributing the sending of ICMP errors to Line Card CPUs, are protection mechanisms that mitigate attacks before they can negatively affect a rate-limited router control plane component.
また、TTL /ホップ制限の取り扱いは、トラフィックが保護を必要と期限切れ。このトラフィックは、必ずしもデバイスに対処されていないが、それはTTL /ホップリミットの有効期限を処理するために、ルータのコントロールプレーンに送信されますすることができます。例えば、速度制限TTL /ホップ制限は、ICMPエラーが発生しますルータ制御プレーンコンポーネントにパケットを送信し、ラインカードのCPUにICMPエラーの送信を配布する前に、トラフィックを満了し、彼らの前に攻撃を軽減する保護メカニズムですマイナスのレート制限ルータの制御プレーンのコンポーネントに影響を与えることができます。
The authors would like to thank Ron Bonica for providing initial and ongoing review, suggestions, and valuable input. Pekka Savola, Warren Kumari, and Xu Chen provided very thorough and useful feedback that improved the document. Many thanks to John Kristoff, Christopher Morrow, and Donald Smith for a fruitful discussion around the operational and manageability aspects of router control plane protection techniques. The authors would also like to thank
著者は、初期および継続的な見直し、提案、貴重な入力を提供するためのロンBonicaに感謝したいと思います。ペッカSavola、ウォーレン・クマリ、及びズ・チェンは、ドキュメントの改善に非常に徹底的かつ有益なフィードバックを提供します。ルータ制御プレーン保護技術の運用と管理面の周りに実りある議論のためのジョンKristoff、クリストファー・モロー、ドナルド・スミスに感謝します。著者らはまた、感謝したいと思います
Joel Jaeggli, Richard Graveman, Danny McPherson, Gregg Schudel, Eddie Parra, Seo Boon Ng, Manav Bhatia, German Martinez, Wen Zhang, Roni Even, Acee Lindem, Glen Zorn, Joe Abley, Ralph Droms, and Stewart Bryant for providing thorough review, useful suggestions, and valuable input. Assistance from Jim Bailey and Raphan Han in providing technical direction and sample configuration guidance on the IPv6 sections was also very much appreciated. Finally, the authors extend kudos to Andrew Yourtchenko for his review, comments, and willingness to present this document at IETF 78 (July 2010, Maastricht, The Netherlands) on behalf of the authors.
ジョエルJaeggli、リチャードGraveman、ダニー・マクファーソン、グレッグSchudel、エディ・パーラ、ソ・ブーンン、Manav Bhatiaは、ドイツ語マルティネス、ウェンチャン、ロニでも、ACEE Lindem、グレン・ソーン、ジョーAbley、ラルフDroms、およびスチュワートブライアント徹底的なレビューを提供するための、有益な提案、貴重な入力。 IPv6の切片上の技術的な方向とサンプル構成ガイダンスを提供するジム・ベイリーとRaphan漢からの援助も非常に高く評価されました。最後に、著者は彼のレビュー、コメント、および著者に代わってIETF 78（2010年7月、マーストリヒト、オランダ）でこの文書を提示する意欲のためにアンドリューYourtchenkoに賛辞を拡張します。
[IP-OPTIONS-FILTER] Gont, F. and S. Fouant, "IP Options Filtering Recommendations", Work in Progress, February 2010.
[IP-OPTIONS-FILTER] Gont、F.およびS. Fouant、 "IPオプションフィルタリング勧告"、進歩、2010年2月での作業。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC2827] 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.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]デイヴィス、E.およびJ. Mohacsi、 "ファイアウォールでのフィルタリングICMPv6メッセージへの提言"、RFC 4890、2007年5月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、エド。、およびC. Pignataro、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 5082、2007年10月。
[RTR-ALERT-CONS] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, March 2011.
[RTR-ALERT-CONS]ルFaucheur、F.、エド。、 "IPルータアラートの考慮事項および使用方法"、進歩、2011年3月に作業。
Appendix A. Configuration Examples
付録A.設定例
The configurations provided below are syntactical representations of the semantics described in the document and should be treated as non-normative.
以下に提供する構成は、文書に記載さセマンティクスの構文表現であり、非標準として扱われるべきです。
A.1. Cisco Configuration
A.1。 Ciscoコンフィギュレーション
Refer to the Control Plane Policing (CoPP) document in the Cisco IOS Software Feature Guides (available at <http://www.cisco.com/>) for more information on the syntax and options available when configuring Control Plane Policing.
コントロールプレーンポリシングを設定するときの構文と使用可能なオプションの詳細については、（<http://www.cisco.com/>で入手可能）のCisco IOSソフトウェア機能ガイドでコントロールプレーンポリシング（CoPPの）文書を参照してください。
!Start: Protecting The Router Control Plane ! !Control Plane Policing (CoPP) Configuration ! !Access Control List Definitions ! ip access-list extended ICMP permit icmp any any ipv6 access-list ICMPv6 permit icmp any any ip access-list extended OSPF permit ospf 192.0.2.0 0.0.0.255 any ipv6 access-list OSPFv3 permit 89 FE80::/10 any ip access-list extended IBGP permit tcp 192.0.2.0 0.0.0.255 eq bgp any permit tcp 192.0.2.0 0.0.0.255 any eq bgp ipv6 access-list IBGPv6 permit tcp 2001:DB8:1::/48 eq bgp any permit tcp 2001:DB8:1::/48 any eq bgp ip access-list extended EBGP permit tcp host 198.51.100.25 eq bgp any permit tcp host 198.51.100.25 any eq bgp permit tcp host 198.51.100.27 eq bgp any permit tcp host 198.51.100.27 any eq bgp permit tcp host 198.51.100.29 eq bgp any permit tcp host 198.51.100.29 any eq bgp permit tcp host 198.51.100.31 eq bgp any permit tcp host 198.51.100.31 any eq bgp
！開始します。Routerコントロールプレーンを保護します！ ！コントロールプレーンポリシング（CoPPの）コンフィギュレーション！ ！アクセス制御リストの定義！ IPアクセスリストは、ICMPの許可が任意の任意のIPv6アクセスリストのICMPv6許可が任意の任意のIPアクセスリストが許可したOSPFv3のOSPF許可のOSPF 192.0.2.0 0.0.0.255任意のIPv6アクセスリストを拡張し、ICMP ICMP延長89 FE80 :: / 10の任意のIP access-リスト拡張IBGP許可のTCP 192.0.2.0いかなる許可のTCP 192.0.2.0 0.0.0.255 BGP 0.0.0.255 EQ任意のEQのBGPのIPv6アクセスリストIBGPv6許可TCP 2001：DB8：1 :: / 48 EQ任意の許可TCP 2001 BGP：DB8： 1 :: / 48の任意のEQ BGP、IPアクセスリストの拡張EBGP許可TCPホスト198.51.100.25任意の許可TCPホスト198.51.100.25 BGP EQ任意のEQのBGP許可TCPホスト198.51.100.27 EQ任意の許可TCPホスト198.51.100.27 BGP任意のEQのBGP任意の許可TCPホスト198.51.100.31 BGP許可TCPホスト198.51.100.29任意の許可TCPホスト198.51.100.29 BGP EQ任意のEQのBGP許可TCPホスト198.51.100.31 EQ任意のEQのBGP
ipv6 access-list EBGPv6 permit tcp host 2001:DB8:100::25 eq bgp any permit tcp host 2001:DB8:100::25 any eq bgp permit tcp host 2001:DB8:100::27 eq bgp any permit tcp host 2001:DB8:100::27 any eq bgp permit tcp host 2001:DB8:100::29 eq bgp any permit tcp host 2001:DB8:100::29 any eq bgp permit tcp host 2001:DB8:100::31 eq bgp any permit tcp host 2001:DB8:100::31 any eq bgp ip access-list extended DNS permit udp 198.51.100.0 0.0.0.252 eq domain any ipv6 access-list DNSv6 permit udp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any ip access-list extended NTP permit udp 198.51.100.4 255.255.255.252 any eq ntp ipv6 access-list NTPv6 permit udp 2001:DB8:100:2::/64 any eq ntp ip access-list extended SSH permit tcp 198.51.100.128 0.0.0.128 any eq 22 ipv6 access-list SSHv6 permit tcp 2001:DB8:100:3::/64 any eq 22 ip access-list extended SNMP permit udp 198.51.100.128 0.0.0.128 any eq snmp ipv6 access-list SNMPv6 permit udp 2001:DB8:100:3::/64 any eq snmp ip access-list extended RADIUS permit udp host 198.51.100.9 eq 1812 any permit udp host 198.51.100.9 eq 1813 any permit udp host 198.51.100.10 eq 1812 any permit udp host 198.51.100.10 eq 1813 any ipv6 access-list RADIUSv6 permit udp host 2001:DB8:100::9 eq 1812 any permit udp host 2001:DB8:100::9 eq 1813 any permit udp host 2001:DB8:100::10 eq 1812 any permit udp host 2001:DB8:100::10 eq 1813 any ip access-list extended FRAGMENTS permit ip any any fragments ipv6 access-list FRAGMENTSv6 permit ipv6 any any fragments ip access-list extended ALLOTHERIP permit ip any any ipv6 access-list ALLOTHERIPv6 permit ipv6 any any
IPv6アクセスリストEBGPv6許可TCPホスト2001：DB8：100 :: 25 EQ任意の許可TCPホスト2001 BGP：DB8：100 :: 25の任意のEQ BGP許可TCPホスト2001：DB8：任意の許可TCPホストBGP 100 :: 27 EQ 2001：DB8：100 :: 27の任意のEQ BGP許可TCPホスト2001：DB8：DB8：：100 :: 29の任意のEQ BGP許可TCPホスト2001：DB8：100 :: 31任意の許可TCPホスト2001 BGP 100 :: 29 EQ BGP EQ任意の許可TCPホスト2001：DB8：100 :: 31任意のEQ BGP、IPアクセスリストの拡張DNS許可UDP 198.51.100.0 0.0.0.252 EQドメインの任意のIPv6アクセスリストでDNSv6許可UDP 2001：DB8：100：1 :: / 64 EQドメイン任意の許可TCP 2001：DB8：100：1 :: / 64 EQドメインの任意のIPアクセスリストは、2001年UDP UDP 198.51.100.4 255.255.255.252任意のEQ NTP IPv6アクセスリストNTPv6許可NTP許可を拡張：DB8：100 ：2 :: / 64の任意のEQ NTPのIPアクセスリストの拡張SSH許可TCP 198.51.100.128 0.0.0.128任意のEQ 22 IPv6アクセスリストSSHv6許可TCP 2001：DB8：100：3 :: / 64の任意のEQ 22のIP access- DB8：：100：3 :: / 64任意のEQのSNMP IPアクセスリストは、198.51.100.128 0.0.0.128 UDPの任意のEQのSNMPのIPv6アクセスリストSNMPv6許可UDP 2001 SNMP許可を延長しました-list拡張RADIUS許可UDPホスト198.51.100.9 EQ 1812任意の許可UDPホスト198.51.100.9 EQ 1813任意の許可UDPホスト198.51.100.10 EQ 1812任意の許可UDPホスト198.51.100.10 EQ 1813任意のIPv6アクセスリストRADIUSv6はUDPホスト2001を許可します： DB8：1812 100 :: 9 EQ任意の許可UDPホスト2001：DB8：1813 100 :: 9 EQ任意の許可UDPホスト2001：DB8：100 :: 10当量1812の任意の許可UDPホスト2001：DB8：100 :: 10当量1813任意のIPアクセスリストの拡張フラグメントは、任意のIPを許可する任意の断片のIPv6アクセスリストFRAGMENTSv6許可証は、いずれかの任意の断片のIPアクセスリストは、任意のALLOTHERIP許可IPを拡張任意のIPv6アクセスリストALLOTHERIPv6許可が任意の任意のIPv6のIPv6の
! !Class Definitions ! class-map match-any ICMP match access-group name ICMP class-map match-any ICMPv6 match access-group name ICMPv6 class-map match-any OSPF match access-group name OSPF match access-group name OSPFv3 class-map match-any IBGP match access-group name IBGP match access-group name IBGPv6 class-map match-any EBGP match access-group name EBGP match access-group name EBGPv6 class-map match-any DNS match access-group name DNS match access-group name DNSv6 class-map match-any NTP match access-group name NTP match access-group name NTPv6 class-map match-any SSH match access-group name SSH match access-group name SSHv6 class-map match-any SNMP match access-group name SNMP match access-group name SNMPv6 class-map match-any RADIUS match access-group name RADIUS match access-group name RADIUSv6 class-map match-any FRAGMENTS match access-group name FRAGMENTS match access-group name FRAGMENTSv6 class-map match-any ALLOTHERIP match access-group name ALLOTHERIP class-map match-any ALLOTHERIPv6 match access-group name ALLOTHERIPv6
！ ！クラス定義！クラスマップは、match-any ICMP一致アクセスグループ名ICMPクラスマップは、match-any ICMPv6の一致アクセスグループ名ICMPv6のクラスマップは、match-any OSPF一致アクセスグループ名OSPF一致アクセスグループ名のOSPFv3クラスマップmatch-すべてのIBGP一致アクセスグループ名のIBGP一致アクセスグループ名IBGPv6クラスマップのmatch-anyのEBGP一致アクセスグループ名のEBGP一致アクセスグループ名EBGPv6クラスマップのmatch-anyのDNS一致アクセスグループ名のDNS一致アクセスグループでDNSv6クラスマップのmatch-anyのNTP一致アクセスグループ名NTP一致アクセスグループ名NTPv6クラスマップのmatch-anyのSSHマッチアクセスグループ名のSSH一致アクセスグループ名SSHv6クラスマップのmatch-anyのSNMPの試合に名前を付けますaccess-グループ名SNMP一致アクセスグループ名SNMPv6クラスマップは、match-any RADIUS一致アクセスグループ名のRADIUS一致アクセスグループ名RADIUSv6クラスマップは、match-any FRAGMENTS一致アクセスグループ名が一致アクセスグループ名のFRAGMENTSv6クラスマップを断片match-anyのALLOTHERIP一致アクセスグループ名ALLOTHERIPクラスマップは、match-any ALLOTHERIPv6マッチアクセス名前ALLOTHERIPv6 -group
! !Policy Definition ! policy-map COPP class FRAGMENTS drop class ICMP police 500000 conform-action transmit exceed-action drop violate-action drop class ICMPv6 police 500000 conform-action transmit exceed-action drop violate-action drop class OSPF class IBGP class EBGP class DNS class NTP class SSH class SNMP class RADIUS class ALLOTHERIP police cir 500000 conform-action transmit exceed-action drop violate-action drop class ALLOTHERIPv6 police cir 500000 conform-action transmit exceed-action drop violate-action drop class class-default police cir 250000 conform-action transmit exceed-action drop violate-action drop ! !Control Plane Configuration ! control-plane service-policy input COPP ! !End: Protecting The Router Control Plane
！ ！ポリシー定義！ポリシーマップCOPPクラスFRAGMENTSは、クラスICMP警察500000送信は、exceed-action dropアクション準拠違反アクションドロップクラスのICMPv6警察をドロップ500000準拠アクション送信は、exceed-action dropが違反アクションドロップクラスOSPFクラスIBGPクラスEBGPクラスDNSクラスNTPクラスをSSHクラスSNMPクラスRADIUSクラスALLOTHERIP警察CIR 500000送信は、exceed-action dropアクション準拠違反アクションドロップクラスALLOTHERIPv6警察は500000は、送信は、exceed-action drop違反アクションアクション準拠CIRドロップclass-defaultクラス警察のCIRに250000準拠アクション送信を超過アクションのドロップをドロップアクション違反！ ！コントロールプレーンコンフィギュレーション！コントロールプレーンサービスポリシー入力COPP！ ！終了：ルータコントロールプレーンの保護
A.2. Juniper Configuration
A.2。ジュニパーの設定
Refer to the Firewall Filter Configuration section of the Junos Software Policy Framework Configuration Guide (available at <http://www.juniper.net/>) for more information on the syntax and options available when configuring Junos firewall filters.
Junosファイアウォールフィルタを設定するときの構文と使用可能なオプションの詳細については、（<http://www.juniper.net/>で入手可能）のJunosソフトウェアポリシーフレームワークコンフィギュレーションガイドのファイアウォールのフィルタ設定のセクションを参照してください。
policy-options {
prefix-list IBGP-NEIGHBORS {
192.0.2.0/24;
}
prefix-list EBGP-NEIGHBORS {
198.51.100.25/32;
198.51.100.27/32;
198.51.100.29/32;
198.51.100.31/32;
}
prefix-list RADIUS-SERVERS {
198.51.100.9/32;
198.51.100.10/32;
}
prefix-list IBGPv6-NEIGHBORS {
2001:DB8:1::/48;
}
prefix-list EBGPv6-NEIGHBORS {
2001:DB8:100::25/128;
2001:DB8:100::27/128;
2001:DB8:100::29/128;
2001:DB8:100::31/128;
}
prefix-list RADIUSv6-SERVERS {
2001:DB8:100::9/128;
2001:DB8:100::10/128;
}
} firewall {
policer 500kbps {
if-exceeding {
bandwidth-limit 500k;
burst-size-limit 1500;
}
then discard;
}
policer 250kbps {
if-exceeding {
bandwidth-limit 250k;
burst-size-limit 1500;
}
then discard;
}
family inet {
filter protect-router-control-plane {
term first-frag {
from {
first-fragment;
}
then {
count frag-discards;
log;
discard;
}
}
term next-frag {
from {
is-fragment;
}
then {
count frag-discards;
log;
discard;
}
}
term icmp {
from {
protocol icmp;
}
then {
policer 500kbps;
accept;
}
} term ospf {
from {
source-address {
192.0.2.0/24;
}
protocol ospf;
}
then accept;
}
term ibgp-connect {
from {
source-prefix-list {
IBGP-NEIGHBORS;
}
protocol tcp;
destination-port bgp;
}
then accept;
}
term ibgp-reply {
from {
source-prefix-list {
IBGP-NEIGHBORS;
}
protocol tcp;
port bgp;
}
then accept;
}
term ebgp-connect {
from {
source-prefix-list {
EBGP-NEIGHBORS;
}
protocol tcp;
destination-port bgp;
}
then accept;
} term ebgp-reply {
from {
source-prefix-list {
EBGP-NEIGHBORS;
}
protocol tcp;
port bgp;
}
then accept;
}
term dns {
from {
source-address {
198.51.100.0/30;
}
protocol udp;
port domain;
}
then accept;
}
term ntp {
from {
source-address {
198.51.100.4/30;
}
protocol udp;
destination-port ntp;
}
then accept;
}
term ssh {
from {
source-address {
198.51.100.128/25;
}
protocol tcp;
destination-port ssh;
}
then accept;
} term snmp {
from {
source-address {
198.51.100.128/25;
}
protocol udp;
destination-port snmp;
}
then accept;
}
term radius {
from {
source-prefix-list {
RADIUS-SERVERS;
}
protocol udp;
port [ 1812 1813 ];
}
then accept;
}
term default-term {
then {
count copp-exceptions;
log;
policer 500kbps;
accept;
}
}
}
}
family inet6 {
filter protect-router-control-plane-v6 {
term fragv6 {
from {
next-header fragment;
}
then {
count frag-v6-discards;
log;
discard;
}
} term icmpv6 {
from {
next-header icmpv6;
}
then {
policer 500kbps;
accept;
}
}
term ospfv3 {
from {
source-address {
FE80::/10;
}
next-header ospf;
}
then accept;
}
term ibgpv6-connect {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
}
term ibgpv6-reply {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
port bgp;
}
then accept;
}
term ebgpv6-connect {
from {
source-prefix-list {
EBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
} term ebgpv6-reply {
from {
source-prefix-list {
EBGPv6-NEIGHBORS;
}
next-header tcp;
port bgp;
}
then accept;
}
term dnsv6 {
from {
source-address {
2001:DB8:100:1::/64;
}
next-header [ udp tcp ];
port domain;
}
then accept;
}
term ntpv6 {
from {
source-address {
2001:DB8:100:2::/64;
}
next-header udp;
destination-port ntp;
}
then accept;
}
term sshv6 {
from {
source-address {
2001:DB8:100:3::/64;
}
next-header tcp;
destination-port ssh;
}
then accept;
} term snmpv6 {
from {
source-address {
2001:DB8:100:3::/64;
}
next-header udp;
destination-port snmp;
}
then accept;
}
term radiusv6 {
from {
source-prefix-list {
RADIUSv6-SERVERS;
}
next-header udp;
port [ 1812 1813 ];
}
then accept;
}
term default-term-v6 {
then {
policer 500kbps;
count copp-exceptions-v6;
log;
accept;
}
}
}
}
family any {
filter protect-router-control-plane-non-ip {
term rate-limit-non-ip {
then {
policer 250kbps;
accept;
}
}
}
}
} interfaces {
lo0 {
unit 0 {
family inet {
filter input protect-router-control-plane;
}
family inet6 {
filter input protect-router-control-plane-v6;
}
family any {
filter input protect-router-control-plane-non-ip;
}
}
}
}
Authors' Addresses
著者のアドレス
Dave Dugal Juniper Networks 10 Technology Park Drive Westford, MA 01886 US
デイブDugalジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886米国
EMail: dave@juniper.net
メールアドレス：dave@juniper.net
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
カルロスPignataroシスコシステムズ7200から12キットクリーク道路リサーチトライアングルパーク、ノースカロライナ州27709米国
EMail: cpignata@cisco.com
メールアドレス：cpignata@cisco.com
Rodney Dunn Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
ロドニーダンシスコシステムズ7200から12キットクリーク道路リサーチトライアングルパーク、ノースカロライナ州27709米国
EMail: rodunn@cisco.com
メールアドレス：rodunn@cisco.com