I recently had to build some filters for implementations and will be sharing them. The goal here is to provide an up-to-date example of a strong protection filtering for both IPv4 and IPV6 and to the address topic of why filters are required.
The topic of router security is fairly complex. So much so that the IETF has an informational RFC 6192 produced to outline best practices. The RFC includes examples for both IOS- and Junos based products.
Modern routers have the forwarding plane separated from the control plane and can forward millions+ of packets per second with ease. However that does not mean the control plane can handle those volumes. If the control plane is over-loaded, it will not able to send or receive routing protocol messages and other important control plane packets in a timely manner such as keep-alives. As a consequence loss of routing protocol adjacency can disrupt traffic flow though the forwarding plane.
Juniper carrier routers packet forwarding happens completely in hardware on the forwarding plane. The router consists of: a routing engine where all the protocols run and forwarding plane (PFE) which receives updates from the RE and programs forwarding functionality.
Since the Routing Engine does not handle packet forwarding its processing cannot be overwhelmed by packets that are supposed to be forwarded.
Firewall filters and policers in JunOS can be used to mitigate certain types of bad traffic that are destined to the router.
A form of denial of service attack on the control plane of routing equipment can lead to the scenario describe above.
There are many ways to protect your router and one of them not included in this post is filtering and policing on broadcast, multicast and unknown traffic. This known as a BUM filter that I may share in another post for Layer2 related networking.
Lastly in addition the Trio-based MX routers have additional DDoS detection features, which is for another post. However the filters provided is the required to be used in combination with other mechanisms to secure your infrastructure.
ARP request packets are sent to the broadcast MAC addresses while ARP replies are sent to the requested source mac. Improper configuration in the network causing broadcast storms could result in flooding of ARP packets to the routing engine. This could also be possible that a port receives lots of ARP requests and reply packets as part of DOS attack. Without protection these packets will all be sent to the routing engine.
By default Juniper routers have a policer for ARP packets that is shared by all interfaces on a line-card and the rate limits the aggregate ARP traffic to a value of 150Kbit/s.
The above default policer applied to ARP packets can be modified using hidden cli commands
Below is more aggressive configuration that can be applied on a per port basis. Its better in since one port being flooded does not impact the aggregate ports on the same line card.
Note it could be applied either under physical for all logical interfaces or just under a specific logical interface using apply-groups PROTECT-ARP
Example of applying the above ARP policing to specific interface
The protection filter both for both IPV4 and IPV6 is combined within a simple apply-group to guard against resource depletion denial of service attacks and securing the access to specific protocols using filters. Using apply-groups the filters automatically are updated based on the configuration. For example if you add another BGP neighbor you do not have to add it to any specific prefix list.
However its required to specify core interfaces and mpls loopbacks and prefixes that do have access to the system via SSH or TELNET.
MPLS Loopbacks is used by unicast tcp LDP sessions for example.
Example of applying SECURE-RE Filter