[要約] RFC 6192は、ルーターの制御プレーンを保護するためのガイドラインを提供します。その目的は、ネットワークインフラストラクチャのセキュリティを向上させ、攻撃からルーターを保護することです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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攻撃に対してより耐性があります。このメモは、サンプルトラフィックマッチング、フィルタリング、およびレート制限基準のセットを満たすポリシーフィルターを展開する方法の1つの例を示しています。
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.
セクション3で説明し、図1に示す方法は、不要なトラフィックからルーター制御プレーンを保護する方法を示しています。展開シナリオが異なることを認識すると、正確な実装は一般にすべての状況で適用できません。正当なルーター制御プレーントラフィックの分類は、実装の成功において非常に重要です。
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（Cisco IOSソフトウェア）とJuniper（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 サブネット192.0.2.0/24内のルーターからのOSPFトラフィックとIPv6リンクローカルユニキャストアドレスからのOSPFV3トラフィック（FE80 ::/10）を許可します
o Permit internal BGP (iBGP) traffic from routers within subnets 192.0.2.0/24 and 2001:db8:1::/48
o サブネット内のルーターからの内部BGP（IBGP）トラフィックを許可する192.0.2.0/24および2001：DB8：1 ::/48
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
o EBGPピアからの外部BGP（EBGP）トラフィックを許可する198.51.100.25、198.51.100.27、198.51.100.29、および198.51.100.31;およびIPv6 Peers 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
o サブネット内のDNSサーバーからのDNSトラフィックを許可する198.51.100.0/30および2001：DB8：100：1 ::/64
o Permit NTP traffic from NTP servers within subnet 198.51.100.4/30 and 2001:db8:100:2::/64
o サブネット内のNTPサーバーからのNTPトラフィックを許可する198.51.100.4/30および2001：DB8：100：2 ::/64
o Permit Secure SHell (SSH) traffic from network management stations within subnet 198.51.100.128/25 and 2001:db8:100:3::/64
o Subnet 198.51.100.128/25および2001内のネットワーク管理ステーションからのセキュアシェル（SSH）トラフィックを許可します：DB8：100：3 ::/64
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
o Subnet 198.51.100.128/25および2001内のネットワーク管理ステーションからの単純なネットワーク管理プロトコル（SNMP）トラフィックを許可します：DB8：100：3 ::/64
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
o RADIUSサーバーからの半径認証と会計返信を許可する198.51.100.9、198.51.100.10、2001：DB8：100 :: 9、および2001：DB8：100 :: 10はUDPポート1812および1813で聴いています（インターネット数字の権限（IANA）半径ポート）。これは、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
o 非IPトラフィック（Connectionless Network Service（CLNS）、InternetWork Packet Exchange（IPX）、PPP Link Control Protocol（LCP）など）、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.
実際の生産環境では、日々の操作のためにルーターのコントロールプレーンに到達するために必要なトラフィックの完全かつ網羅的なリストを予測することは、ここで説明した例ほど明白ではないかもしれません。このトラフィックセットを測定する推奨方法の1つは、すべてのトラフィックを最初に許可し、明示的なフィルターまたはレート制限を適用する前にルーター制御プレーンに到達するトラフィックを監査することです。このトピックの詳細については、以下のセクション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.
このドキュメントで提供されるフィルター設計は、問題のローカルルーターでのアタッチメントに意図的に制限されています（たとえば、Cisco iOSの「コントロールプレーン」に接続された「サービスポリティ」、または「LO0」インターフェイスに接続されたファイアウォールフィルターに限定されています。ジュノスで）。実質的にすべての生産環境は、エッジ保護またはインターフェイスフィルタリングに大きく依存していますが、これらのルーター保護の方法は、このドキュメントの意図された範囲を超えています。さらに、ルーター制御プレーン（例：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.).
保護方法を設計する際には、2つの独立した部分を考慮する必要があります。トラフィックの分類（つまり、トラフィックはフィルターによって一致するもの）と、分類されたトラフィックで取られたポリシーアクション（つまり、ドロップ、許可、レートリミット、等。）。
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のさまざまなレート制限を定義することができ、外部アドレスからのトラフィックはレート制限されている間、内部トラフィックがルーター制御プレーンへの抑制されないアクセスが付与されます。オペレーターは、Rate-limitポリシーを設計する際に、ICMPV6がIPv6の全体的な動作において存在する新しい機能と役割に特別な注意を払う必要があります。例機能には、Neighbor Discovery（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オプションパケットをドロップすることを選択する場合があります。他の人は、リソース予約プロトコル（RSVP）などのIPオプションパケットを必要とするプロトコルを可能にするために制約を緩める必要がある場合があります。設計のトレードオフは、すべてのIPオプションパケットをドロップすると、不正なオプションを活用する攻撃からルーターを保護し、IPオプションパケットのスローパス処理（つまり、ソフトウェア処理パス）に依存する攻撃が保護されます。プロトコルがIPオプションを使用しないネットワーク展開の場合、フィルターは、すべてのパケットを任意のIPオプションセットでドロップできるという点で設計が簡単です。ただし、IPオプションに依存するプロトコルを利用するネットワークの場合、正当なパケットを識別するフィルターはより複雑です。フィルターが正しく設計されていない場合、それらのプロトコルのトラフィックの不注意な黒hol帯になる可能性があります。このドキュメントには、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 / HOPリミットの有効期限が切れたトラフィックの有効期限が切れたトラフィックは、ICMPエラーを生成するルーター制御プレーンコンポーネントにパケットを送信し、ICMPエラーの送信をラインカードCPUに分配することで、攻撃を緩和する保護メカニズムです。レート制限ルーター制御プレーンコンポーネントに悪影響を与える可能性があります。
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 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.
著者は、初期および継続的なレビュー、提案、および貴重な入力を提供してくれたRon Bonicaに感謝したいと思います。Pekka Savola、Warren Kumari、およびXu Chenは、ドキュメントを改善する非常に徹底的で有用なフィードバックを提供しました。ジョン・クリストフ、クリストファー・モロー、ドナルド・スミスに感謝します。ルーター制御プレーン保護技術の運用および管理性の側面についての実り多い議論に感謝します。著者はまた、ジョエル・ジェグリ、リチャード・グレイブマン、ダニー・マクファーソン、グレッグ・シュデル、エディ・パラ、ソ・ブーン・NG、マナブ・バティア、ドイツ・マルティネス、ウェン・チャン、ロニ・イヴ・イヴーテンに感謝したいと思います。徹底的なレビュー、有用な提案、貴重な入力を提供してくれたスチュワートブライアント。IPv6セクションで技術的な方向性とサンプル構成ガイダンスを提供する際のジムベイリーとラファンハンの支援も非常に高く評価されました。最後に、著者は、著者に代わってIETF 78（2010年7月、オランダのMaastricht）でこの文書を提示する彼のレビュー、コメント、意欲のために、Andrew 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] Baker、F.、ed。、「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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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] Davies、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] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、および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] Le Faucheur、F.、ed。、「IPルーターのアラートの考慮事項と使用法」、2011年3月、進行中。
The configurations provided below are syntactical representations of the semantics described in the document and should be treated as non-normative.
以下に示されている構成は、ドキュメントで説明されているセマンティクスの構文表現であり、非規範的なものとして扱う必要があります。
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.
Cisco iOSソフトウェア機能ガイド（<http://www.cisco.com/>で入手可能）のコントロールプレーンポリシング（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
！開始：ルーター制御プレーンを保護します！！コントロールプレーンポリシング（COPP）構成！！アクセス制御リストの定義！IP Access-List拡張ICMP許可ICMP任意のIPv6アクセスリストICMPV6許可ICMP任意のIPアクセスリスト拡張OSPF許可OSPF 192.0.2.0 0.0.0.255 Any IPv6 Access-List OSOSPFV3 PRIMIMIT 89 FE80 :: ANY IP Access-/10 Any IP Accessリスト拡張IBGP許可TCP 192.0.2.0 0.0.0.255 EQ BGP任意の許可TCP 192.0.2.0 0.0.0.255任意のEQ BGP IPv6アクセスリスト1 ::/48任意のEQ BGP IP Access-List拡張EBGP許可TCPホスト198.51.100.25 EQ BGP任意の許可TCPホスト198.51.100.25任意のEQ BGP許可TCPホスト198.51.100.27 EQ BGP任意のTCPホスト198.100.100.27許可TCPホスト198.51.100.29 EQ BGP ANY PRILMIT TCP HOST 198.51.100.29 ANY EQ BGP許可TCPホスト198.51.100.31 EQ BGP Any Permit TCP HOST 198.51.100.31 Any 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
! !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
！！クラスの定義！class-map match-any icmp matchアクセスグループ名ICMPクラスマップマッチ-nate-any icmpv6マッチアクセス - グループ名ICMPV6クラスマップマッチ-Any OSPF MATCE ACCESS-GROUP NAME OSPF MATCE ACCESS-GROUP NAME OSPFV3 CLASS-MAP MATCE-任意のIBGPマッチアクセスグループ名IBGPマッチアクセスグループ名IBGPV6クラスマットマッチ-Any EBGPマッチアクセスグループ名ebgpアクセスグループ名ebgpv6クラスマットマッチマッチ - アニメーションアクセス - グループ名DNSマッチアクセスグループ名前dnsv6クラスマップマッチ-ntpマッチアクセスグループ名NTPマッチアクセス - グループ名NTPV6クラスマップマッチマッチアクセスアクセス - グループ名SSHマッチアクセス - グループ名SSHV6クラスマットマッチアクセス - アクセス - グループ名SNMPマッチアクセスグループ名SNMPV6クラスマップマッチマッチ - ラディアスマッチアクセス - グループ名ラジウスアクセスグループ名RADIUSV6クラスマップマッチマッチマッチアクセスグループ名フラグメントマッチアクセスグループ名フラグメント66クラスマップマッチ - any altotheripマッチアクセスグループ名alotheripクラスマップマッチ - anytheripv6マッチアクセス-Group名alotheripv6
! !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クラスフラグメントドロップクラスICMP警察SSHクラスSNMPクラス半径クラスAltotherip Police CIR 500000適合アクション送信アクションを超えるドロップ違反アクションドロップ！！コントロールプレーンの構成！コントロールプレーンサービスポリティ入力COPP！！終了：ルーター制御プレーンの保護
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 Software Policy Framework Configuration Guide（<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
Dave Dugal Juniper Networks 10 Technology Park Drive Westford、MA 01886 US
EMail: dave@juniper.net
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: 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