RFC 6192
Protecting the Router Control Plane
RFC 6192: Protecting the Router Control Plane 🎀
Okay bestie, the title block first 🦋 This one is RFC 6192, Protecting the Router Control Plane, published in March 2011. The authors are D. Dugal (Juniper Networks), C. Pignataro (Cisco Systems), and R. Dunn (Cisco Systems). It's an Informational document, not a standards-track spec, with ISSN 2070-1721 🌸 The header doesn't say it obsoletes or updates anything.
Abstract ✨
This memo shows how to protect a router's control plane from unwanted or malicious traffic 🛡️ The idea is: first you figure out ALL the traffic the control plane legitimately needs, then you deploy a filter in the forwarding plane. That filter keeps anything not specifically identified as legitimate away from the control plane, or rate-limits it down to an acceptable level 💅
Also, the filters in this memo only apply to traffic destined for the router itself, not to everything passing through it 👀
Status of This Memo 💜
This document is not an Internet Standards Track specification. It's published for informational purposes 📚
It's a product of the Internet Engineering Task Force (IETF), it reflects IETF community consensus, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🤓
For the current status, any errata, and how to give feedback, go to 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 ©️
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🧾
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 .....................................171. Introduction ✨
Okay so modern routers are built with a strict split between the forwarding plane and the control plane, both hardware and software 🧚 The control plane handles routing and management. It covers the hardware and software that deal with packets addressed to the device itself, plus building and sending packets that originate on the device 💖
The forwarding plane is the part that receives a packet on an incoming interface, does a lookup to find the packet's IP next hop and the best outgoing interface toward the destination, and then sends the packet out that interface 🚀
Picture it like this: the control plane hardware sits on top of the forwarding plane hardware and talks to it, while the interfaces connect out to other network devices. See Figure 1 🎀
+----------------+
| Router Control |
| Plane |
+------+ +-------+
| |
Router Control
Plane Protection
| |
+------+ +-------+
| Forwarding |
Interface X ==[ Plane ]== Interface Y
+----------------+
Figure 1: Router Control Plane ProtectionThe forwarding plane usually runs on high-performance Application Specific Integrated Circuits (ASICs) that can handle insanely high packet rates 🔥 The control plane is usually software running on general-purpose processors. Software runs on both planes, but the control plane hardware usually isn't built for high-speed packet handling 💀 Because of that, the control plane is more likely to get overwhelmed by a Denial-of-Service (DoS) attack than the ASICs are. It's a big deal that the control plane stays stable no matter how much traffic is going to and from the device, because the control plane is the thing that programs the forwarding plane 😭
The control plane also handles traffic addressed to the router. It does a lot more kinds of work than the forwarding plane, so it's more open to security vulnerabilities and a more likely DoS target 🙈
It's a good idea to protect the control plane by adding mechanisms that filter out, or rate-limit, traffic the control plane doesn't need (the unwanted traffic). "Router control plane protection" is the concept of filtering or rate-limiting that unwanted traffic before it gets diverted from the forwarding plane up to the control plane 🦋 The closer those filters and rate limiters sit to the forwarding plane and line-rate hardware, the better the protection, and the more resistant the system is to DoS attacks 👑 This memo gives one example of a policy filter that meets a set of sample traffic-matching, filtering, and rate-limiting criteria ✨
Once again, the filters described in this memo are applied only to traffic destined for the router, and not to all traffic passing through the router 💅
2. Applicability Statement 🌸
The method in Section 3, shown in Figure 1, shows how to protect the router control plane from unwanted traffic. Deployments vary a lot, though, so the exact implementation isn't generally applicable everywhere 🙃 Correctly categorizing legitimate router control plane traffic is critically important to pulling this off successfully 🫶
The examples in this memo are simplified and minimal on purpose. They're there to illustrate the concept, and operators can build out specifics for their own configuration and environment 🧠 This document is about semantics, and Appendix A shows the syntax. If you're working with other router vendors' implementations, or other converged devices, translate the syntax into the right language while keeping the semantics intact 🍓
Also, routers have needed isolation, stability, and protection against rogue packets for a while now, so there may be other vendor or implementation-specific protection mechanisms that are active by default or always on 💜 Those can work alongside the method in Section 3 (illustrated in Appendices A.1 and A.2), or on top of it. They should be treated as part of an overall traffic management plan, but they're outside the scope of this document 🎀
This method works for both IPv4 and IPv6, and the legitimate traffic example in Section 3.1 covers both 🌈
3. Method 🔥
In this memo, the authors show how a filter that protects the router control plane can be deployed. Section 3.1 introduces a sample router and identifies all the traffic its control plane has to process. Section 3.2 covers filter design concepts. The Cisco (Cisco IOS software) and Juniper (JUNOS) implementations are in Appendices A.1 and A.2, respectively 🦋
3.1. Legitimate Traffic 🧚
Here the router control plane has to process traffic (i.e., traffic destined to the router and not through the router) that matches these criteria:
- Drop all IP packets that are fragments (see Section 3.3) 🚫
- Permit ICMP and ICMPv6 traffic from any source, rate-limited to 500 kbps for each category 🏓
- Permit OSPF traffic from routers within subnet
192.0.2.0/24and OSPFv3 traffic from IPv6 Link-Local unicast addresses (fe80::/10) 🛣️ - Permit internal BGP (iBGP) traffic from routers within subnets
192.0.2.0/24and2001:db8:1::/48🤝 - Permit external BGP (eBGP) traffic from eBGP peers
198.51.100.25,198.51.100.27,198.51.100.29, and198.51.100.31; and IPv6 peers2001:db8:100::25,2001:db8:100::27,2001:db8:100::29, and2001:db8:100::31🌐 - Permit DNS traffic from DNS servers within subnet
198.51.100.0/30and2001:db8:100:1::/64📖 - Permit NTP traffic from NTP servers within subnet
198.51.100.4/30and2001:db8:100:2::/64⏰ - Permit Secure SHell (SSH) traffic from network management stations within subnet
198.51.100.128/25and2001:db8:100:3::/64🔐 - Permit Simple Network Management Protocol (SNMP) traffic from network management stations within subnet
198.51.100.128/25and2001:db8:100:3::/64📊 - Permit RADIUS authentication and accounting replies from RADIUS servers
198.51.100.9,198.51.100.10,2001:db8:100::9, and2001:db8:100::10that are listening on UDP ports1812and1813(Internet Assigned Numbers Authority (IANA) RADIUS ports). Note that this does not accommodate a server using the original UDP ports of1645and1646🎟️ - Permit all other IPv4 and IPv6 traffic that wasn't explicitly matched in a class above, rate-limited to 500 kbps, and drop anything above that rate for each category 🫧
- 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 🧃
Real talk, the legitimate traffic will look different from network to network 🌸 For example, a router doing 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 only an example, so don't just copy-paste it 💖
3.2. Filter Design ✨
Okay so a filter gets installed on the forwarding plane 🦋. It counts and applies actions to the categories of traffic from Section 3.1 💅. Because the filter is enforced in the forwarding plane, it stops traffic from eating up bandwidth on the interface that connects the forwarding plane to the router control plane 🫶. The counters are literally an important forensic tool for analyzing potential attacks, and an invaluable debugging and troubleshooting aid too 🔍. If you adjust the granularity and order of the filters, you get more granular forensics 🕵️♀️ (i.e., make 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). That way you can monitor the counters for the allowed protocol filter, plus any traffic matching that specific protocol that didn't come from the explicitly allowed hosts. Main character analytics 👑.
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 reaches the router control plane for each filtered class, plus all traffic that doesn't match an explicit class. The actual rates you pick for each class are specific to the network deployment, so analysis of the rates required for stability should be done periodically 📊. Here's the big thing: the most significant factor for the traffic profile going to the router control plane is the packets per second (pps) rate 💀. So you have to carefully figure out the maximum pps rate that could be generated from a given set of packet size and bandwidth usage scenarios 🧠.
Syntactically, these filters explicitly define "allowed" traffic (including IP addresses, protocols, and ports) 🎀. They also define acceptable actions for those acceptable traffic profiles (e.g., rate-limit or simply permit the traffic). Then they discard all traffic destined to the router control plane that isn't within the specifications of the policy definition 🚫.
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 here 😭. 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 🦋.
The filter design in this document is intentionally limited to attachment at the local router in question. For example, that's a "service-policy" attached to the "control-plane" in Cisco IOS, or a firewall filter attached to the lo0 interface in JUNOS 🧚. Virtually all production environments use and rely heavily on edge protection or interface filtering, but these methods of router protection are beyond the intended scope of this document 🙈. Also, 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. The method of router control plane protection provided here is not a replacement for those cryptographic methods 🔐.
3.3. Design Trade-Offs 🍓
Okay, when you're designing the protection method, there are two independent parts to consider 💜. The first is the classification of traffic (i.e., which traffic is matched by the filters). The second is the policy actions taken on the classified traffic (i.e., drop, permit, rate-limit, etc.).
There are different levels of granularity used for traffic classification 🌈. For example, allowing all traffic from specific source IP addresses is different from allowing only a specific set of protocols from those same source IP addresses. Each one affects a different subset of traffic.
The policy actions taken on the classified traffic also have degrees of impact that may not be obvious right away 👀. For example, discarding all ICMP traffic will hurt the operational use of ICMP tools like ping or traceroute, which you need to debug network issues or test the deployment of a new circuit 😩. Expanding on this, in a real production network, an astute operator could define varying rate limits for ICMP. That way internal traffic gets uninhibited access to the router control plane, while traffic from external addresses gets rate-limited 🧠. When you design the rate-limit policies, operators should pay special attention to the new functionality and roles that ICMPv6 has in the overall operation of IPv6. Example functions include Neighbor Discovery (ND) and Multicast Listener Discovery version 2 (MLDv2) 🛰️.
Both classification and policy action decisions come with 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 ⚖️.
Two types of traffic need special consideration: IP fragments and IP optioned packets 🫧.
- 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 so that the router control plane should never see a fragmented datagram. Since many attacks rely on IP fragmentation, the example policy included here drops all fragments destined to the router control plane 🚧.
- 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 don't use IP options, the filter is simpler to design, since it can drop all packets with any IP option set. However, for networks using protocols that rely on IP options, the filter to identify legitimate packets is more complex. If the filter isn't 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 about filtering packets based on the IP options they contain can be found in [IP-OPTIONS-FILTER] 📚.
The goal of the method for protecting the router control plane is to minimize the possibility of disruptions by reducing the vulnerable surface. That surface is inversely proportional to the granularity of the filter design 💖. The finer the granularity (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 ✨.
Beyond the traffic that matches explicit classes, care should be taken with the policy decision that governs traffic that falls through the classification 🕸️. That traffic is typically called traffic that gets matched in a default class. It may also be traffic that matches a blanket protocol-specific class, where earlier, more granular classes didn't match all packets for that protocol. The ideal policy would have explicit classes that match only the traffic specifically required at the router control plane, and would drop all other traffic that doesn't match a predefined class. But most vendor implementations permit all traffic hitting the default class. So an explicit drop action would need to be configured in the policy, so that traffic hitting the default class gets dropped instead of being permitted and delivered to the router control plane 🙅♀️. This approach requires rigorous traffic pattern identification, so that a default drop policy doesn't break existing device functionality 😤. The approach defined in this document allows the default traffic and rate-limits it, rather than dropping it. This approach was chosen to give the operator time to evaluate and characterize traffic in a production scenario before dropping all traffic that isn't 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 🎯.
Also, baselining and monitoring the traffic flows to the router's control plane are critical for determining both the rates and the granularity of the policies being applied 📈. It's 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 do this include individual policy counters that can be exported or retrieved, for example via SNMP, and logging of filtering actions 🗂️.
Finally, using 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, and certainly for ongoing forensic analysis 🔬.
3.4. Additional Protection Considerations 🛡️
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 the rest (e.g., rate-limiting or blocking), 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 🚨💜
4. Security Considerations ✨
okay bestie, this section is SERIOUS but also kind of iconic 💀 the filters in this doc leave the router open to being discovered by literally any host on the Internet 😭 if operators think that's a red flag, they can cut down on discovery through ICMP by limiting which sub-networks get to send ICMP Echo requests and potential traceroute packets (the ones that would trigger an ICMP Time Exceeded reply) 🦋 which also limits which sub-networks get ICMP responses (Echo Reply and Time Exceeded) sent back to them. ICMPv6 has a similar worry but it's way bigger because ICMPv6 does more stuff 💅 for ICMPv6 filtering, check out [RFC4890]. operators can also set up different rate-limiting policies for internal traffic (like from the Network Operations Center (NOC)) versus external traffic 🌸 and fyi this doc is NOT about the nitty gritty of ICMP filtering or traffic filtering meant to stop device discovery, so don't come for it for that 🙈
the filters here also don't block unwanted traffic with spoofed source addresses that match a defined traffic profile (see Section 3.1) 😬 operators can deal with this by stopping source address spoofing with filters at the network edge. see Section 5.3.8 of [RFC1812] for source address validation details 🎀 other options for limiting spoofing exposure include the Generalized Time to Live (TTL) Security Mechanism (GTSM) [RFC5082] and Ingress Filtering [RFC2827] [RFC3704] 🧚
the ICMP rate limiter in these filters protects the router from ICMP floods (see Sections 3.1 and 3.3) 🔥 but ngl, during an ICMP flood some legit ICMP traffic might get dropped too 😭 so when operators spot an ICMP flood, they are HIGHLY motivated to stop it at the source where it's coming from 💜
more considerations about traffic using the IP Router Alert Options are in [RTR-ALERT-CONS], and more on IP options filtering is in [IP-OPTIONS-FILTER] 🫶
exception traffic in the forwarding plane and messages generated by the router control plane ALSO need protection from DoS attacks 💀 specifically, ICMP Unreachable messages generated by the router control plane need to be rate-limited, either implicitly through the router's architecture or explicitly through configuration 🌈 where possible, different ICMP Destination Unreachable codes (like "fragmentation needed and DF set") or "Packet Too Big" messages can get different rate-limiting treatment ✨ continuous benchmarking of router-generated ICMP traffic SHOULD be done before applying rate limits, so there's enough headroom to prevent accidental 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 👑 the explicit rate limiters in a class let monitoring tools detect and report when they become active (i.e., when traffic is policed) 🍓 that's an indicator that either normal traffic rates went up or "out of policy" traffic rates were detected 🙈 more thorough analysis of the traffic flows and the rate-limited traffic is needed to figure out which of those two cases triggered the limiters 🦋 for more on specific ICMP rate-limiting, see Section 4.3.2.8 of [RFC1812] 💖
also, handling of TTL / Hop Limit expired traffic needs protection 🫶 this traffic isn't necessarily addressed to the device, but it can still get sent to the router control plane to process the TTL / Hop Limit expiration 😭 for example, rate-limiting TTL / Hop Limit expired traffic before it goes to the router control plane component that generates the ICMP error, and distributing ICMP error sending to Line Card CPUs, are protection mechanisms that stop attacks before they can hurt a rate-limited router control plane component 💅🔥
5. Acknowledgements 🎀
the authors wanna thank Ron Bonica for initial and ongoing review, suggestions, and valuable input 🫶 Pekka Savola, Warren Kumari, and Xu Chen gave super thorough and useful feedback that made the doc better 🌸 huge thanks to John Kristoff, Christopher Morrow, and Donald Smith for a fruitful discussion about the operational and manageability sides of router control plane protection 🧚 also big shoutout to 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 thorough review, useful suggestions, and valuable input 👑 Jim Bailey and Raphan Han helped with technical direction and sample configuration guidance on the IPv6 sections, and the authors really appreciated it 💜 finally, the authors give kudos to Andrew Yourtchenko for his review, comments, and willingness to present this doc at IETF 78 (July 2010, Maastricht, The Netherlands) on behalf of the authors 🌈✨
6. Informative References 📚
[IP-OPTIONS-FILTER]: Gont, F. and S. Fouant, "IP Options Filtering Recommendations", Work in Progress, February 2010. 🦋[RFC1812]: Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 🎀[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. 💖[RFC3704]: Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 🧚[RFC4890]: Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 🌸[RFC5082]: Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. 👑[RTR-ALERT-CONS]: Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, March 2011. 💜
Appendix A. Configuration Examples 🍓
the configurations below are syntactical representations of the semantics described in the document, and they should be treated as non-normative 🫶
A.1. Cisco Configuration 💅
Okay bestie, first up is the Cisco stuff 🎀. Go check the Control Plane Policing (CoPP) document in the Cisco IOS Software Feature Guides (<http://www.cisco.com/>) for the syntax and options. It's the source of truth for CoPP config, and you'll want it open next to this 🧚
Here's the whole router config, exactly as the RFC has it:
!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
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
!
!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 PlaneA.2. Juniper Configuration 🧚
Okay bestie, here's the Juniper version 💅 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 📖✨
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
- EMail: dave@juniper.net
- 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
- EMail: rodunn@cisco.com
That's the whole doc, bestie 🎀🦋 the three authors are all wrapped up 🫶
📦 where this page comes from
- ietf: rfc6192 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms