Distributed Denial-of-Service (DDoS) Protection Overview
A denial-of-service (DoS) attack is any attempt to deny valid users access to network or server resources by using up all the resources of the network element or server. Distributed denial-of-service (DDoS) attacks involve an attack from multiple sources, enabling a much greater amount of traffic to attack the network. The attacks typically use network protocol control packets to trigger a large number of exceptions to the device’s control plane. This results in an excessive processing load that disrupts normal network operations.
Junos OS DDoS protection enables the device to continue functioning while under an attack. It identifies and suppresses malicious control packets while enabling legitimate control traffic to be processed. A single point of DDoS protection management enables network administrators to customize profiles for their network control traffic. For routers, protection and monitoring persists across graceful Routing Engine switchover (GRES) and unified in-service-software-upgrade (ISSU) switchovers. Protection is not diminished as the number of subscribers increases.
Host-bound Traffic Policers for DDoS Violations
To protect against DDoS attacks, you can configure policers for host-bound traffic. Host-bound traffic is traffic destined to the Routing Engine, including protocol control packets for routing protocols, such as OSPF and BGP. Traffic destined to router IP addresses is also considered host-bound traffic.
The policers specify rate limits for all control traffic for a given protocol, or, in some cases, for specific control packet types for a protocol. You can monitor policer actions for packet types and protocol groups at the level of the device, Routing Engine, and line cards. You can also control logging of policer events.
Control traffic is dropped when it exceeds any configured policer values or, for unconfigured policers, the default policer values. When a DDoS violation is reached, the device will not stop processing packets; it only limits their rate. Each violation immediately generates a notification to alert operators about a possible attack. The violation is counted, the time that the violation starts is noted, and the time of the last observed violation is noted. When the traffic rate drops below the bandwidth violation threshold, a recovery timer determines when the traffic flow is considered to have returned to normal. If no further violation occurs before the timer expires, the violation state is cleared and a notification is generated.
On PTX routers and QFX Series switches, the timer is set to 300 seconds and cannot be modified.
The first line of protection is the policer on the Packet Forwarding Engine (PFE). On devices with multiple line cards, policer states and statistics from each line card are relayed to the Routing Engine and aggregated. The policer states are maintained during a switchover. Although line card statistics and violation counts are preserved during a switchover, Routing Engine policer statistics are not. Control traffic arriving from all ports of the line card converges on the Packet Forwarding Engine, where it is subject to policing. Thus, excess packets are dropped before they reach the Routing Engine, ensuring that the Routing Engine receives only the amount of traffic it can process.
On QFX Series switches and PTX Series routers, the DDoS policers operate at the PFE and line card level only.
In addition to providing notification of violations through event logging, Junos OS DDoS protection allows you to monitor policers, obtaining information such as policer configuration, number of violations encountered, date and time of violations, packet arrival rates, and number of packets received or dropped.
DDoS protection policers act on the system’s traffic queues. The QFX5100 and QFX5200 lines of switches manage traffic for more protocols than the number of queues, so the system often must map more than one protocol to the same queue. When traffic for one protocol shares a queue with other protocols and violates DDoS protection policer limits, these devices report a violation on that queue for all mapped protocols because the system doesn’t distinguish which protocol’s traffic specifically caused the violation. You can use what you know about the types of traffic flowing through your network to identify which of the reported protocols actually triggered the violation.
In Junos OS Release 14.2 and later releases, DDoS protection is supported on specific platforms. Verify that your installation includes any of the following:
MX Series routers that have only MPCs installed: MX240, MX480, MX960, MX2010, and MX2020.
MX Series routers with a built-in MPC: MX5, MX10, MX40, MX80, and MX104.
For simplicity, where the text refers to line cards or line card policers, for these routers that means the built-in MPC.
Because these routers do not have FPC slots, information displayed in FPC fields by show commands actually refers to TFEB.
PTX Series routers that have only PE-based FPCs installed (PTX3000, PTX5000, PTX1000, and PTX10000) support DDoS protection starting in Junos OS Release 17.4R1.
PTX10002 routers support DDoS protection starting in Junos OS Release 18.2R1.
QFX Series switches, including the QFX5100 line, QFX5200 line, and the QFX10000 line of switches.
QFX10002-60C switches support DDoS protection starting in Junos OS Release 18.1R1.
T4000 routers that have only Type 5 FPCs installed.
For router platforms that have other line cards in addition to MPCs (MX Series), Type 5 FPCs (T4000), or PE-based FPCs (PTX3000, PTX5000, PTX1000, and PTX10000), the CLI accepts the configuration but the other line cards are not protected, so the router is not protected.
DDoS protection support for Enhanced Subscriber Management was added in Junos OS Release 17.3R1 on routing platforms.
To configure DDoS protection for supported protocol groups and packet types, PTX Series routers and QFX Series switches have CLI configuration options that differ significantly from the options available for MX Series and T4000 routers. See protocols (DDoS) (PTX Series and QFX Series) for the available DDoS protection configuration options on PTX routers and QFX Series switches.
Policer Types and Packet Priorities
DDoS protection includes two types of policers:
An aggregate policer is applied to the complete set of packet types that belong to a protocol group. For example, you can configure an aggregate policer that applies to all PPPoE control packet types or to all DHCPv4 control packet types. You can specify bandwidth and burst limits, scale the bandwidth and burst limits, and set a traffic priority for aggregate policers. An aggregate policer is supported by all protocol groups.
An individual policer, also referred to as a packet-type policer, is allocated for each control packet type within a protocol group. For example, you can configure a policer for one or more types of PPPoE control packets, RADIUS control packets, or multicast snooping packets. You can specify bandwidth and burst limits, scale the bandwidth and burst limits, and set a traffic priority for packet-type policers. Individual policers are available for some protocol groups.
Protocol group and packet type support varies across platforms and Junos OS releases, as follows:
For routing devices except PTX Series routers, see protocols (DDoS).
For PTX Series routers and QFX Series switches, see protocols (DDoS) (PTX Series and QFX Series).
A control packet is policed first by its individual policer (if supported) and then by its aggregate policer. A packet dropped by the individual policer never reaches the aggregate policer. A packet that passes the individual policer can subsequently be dropped by the aggregate policer.
Packet types within a protocol group have a default, configurable priority: low, medium, or high. Each control packet competes with other packets for the bandwidth within the limit imposed by its aggregate policer based on the priority configured for each packet type in the protocol group.
The priority mechanism is absolute. High-priority traffic gets bandwidth in preference to medium-priority and low-priority traffic. Medium-priority traffic gets bandwidth in preference to low-priority traffic. Low-priority traffic can use only the bandwidth left by high-priority and medium-priority traffic. If higher priority traffic takes all of the bandwidth, then all the lower priority traffic is dropped.
Example of Policer Priority Behavior
For example, on a device that supports DDoS protection for the PPPoE protocol group, consider how you might configure packet types within this protocol group. Ignoring other PPPoE packet types for this example, suppose you configure individual policers for PADI and PADT packets, as well as a PPPoE aggregate policer for all those packets. You prioritize PADT packets over PADI packets because PADT packets enable the PPPoE application to release resources to accept new connections. Therefore, you assign high priority to the PADT packets and low priority to the PADI packets.
The aggregate policer imposes a total bandwidth limit for the protocol group. PADT packets passed by their individual policer have access to that bandwidth before PADI packets passed by their individual policer, because the PADT packets have a higher priority. If so many PADT packets are passed that they use all the available bandwidth, then all the PADI packets are dropped, because there is no bandwidth remaining at the aggregate policer.
Policer Hierarchy on Routers
DDoS policers are organized to match the hierarchical flow of protocol control traffic. Control traffic arriving from all ports of a line card converges on the Packet Forwarding Engine. Control traffic from all line cards on the router converges on the Routing Engine. Similarly, the DDoS policers are placed hierarchically along the control paths so that excess packets are dropped as early as possible on the path. This design preserves system resources by removing excess, malicious traffic so that the Routing Engine receives only the amount of traffic that it can process. To implement this design, typically five DDoS policers are present: One on the Packet Forwarding Engine (the chipset), two at the line card, and two at the Routing Engine. An aggregate policer is also present on the Packet Forwarding Engine for some protocol groups, for a total of six policers; for simplicity, the text follows the general case. For example, Figure 1 shows the policer process for PPPoE traffic. Figure 2 shows the policer process for DHCPv4 traffic. (The same process applies to DHCPv6 traffic as well.)
The first policer is an individual policer for protocol groups that support individual policers, with two exceptions. For DHCPv4 and DHCPv6 traffic, the first policer is an aggregate policer.
The first policer is an aggregate policer for protocol groups that support only aggregate policers.
Traffic that passes the first policer is monitored by one or both of the line card policers. If the card has more than one Packet Forwarding Engine, traffic from all Packet Forwarding Engines converges on the line card policers.
When the traffic belongs to a protocol group that supports individual policers, it passes through the line card individual policer (2) and then the line card aggregate policer (3). Traffic that passes the individual policer can be dropped by the aggregate policer. Although DHCPv4 and DHCPv6 traffic was monitored by an aggregate policer at the Packet Forwarding Engine, at the line card it is handled like other protocols that support individual policers.
When the traffic belongs to a protocol group that supports only aggregate policers, only the line card aggregate policer monitors the traffic.
Traffic that passes the line card policers is monitored by one or both of the Routing Engine policers. Traffic from all the line cards converges on the Routing Engine policers.
When the traffic belongs to a protocol group that supports individual policers, it passes through the Routing Engine individual policer (4) and then the Routing Engine aggregate policer (5). Traffic that passes the individual policer can be dropped by the aggregate policer. As it was at the line card level, DHCPv4 and DHCPv6 traffic at the Routing Engine is handled like other protocols that support individual policers.
When the traffic belongs to a protocol group that supports only aggregate policers, only the aggregate policer monitors the traffic.
With this design, three policers evaluate the traffic for protocol groups that support only aggregate policers. Among other groups, this includes ANCP, dynamic VLAN, FTP, and IGMP traffic. Traffic for protocol groups that support both aggregate and individual policers is evaluated by all five policers. Among other groups, this includes DHCPv4, MLP, PPP, PPPoE, and virtual chassis traffic.
Figure 1 shows how DDoS protection polices PPPoE control packets:
PADR packets, for example, are evaluated at the first policer on the Packet Forwarding Engine to determine whether they are within the bandwidth limits. PADR packets that exceed the limit are dropped.
All PADR packets that pass the policer on all Packet Forwarding Engines on the line card are next evaluated by the line card individual policer. PADR packets that exceed the limit are dropped.
All PADR packets that pass the line card individual policer proceed to the line card aggregate policer. PADR packets that exceed the limit are dropped.
All PADR packets that are passed by the line card aggregate policers on all line cards on the router proceed to the Routing Engine individual policer. PADR packets that exceed the limit are dropped.
Finally, all PADR packets that are passed by the Routing Engine individual policer proceed to the Routing Engine aggregate policer. PADR packets that exceed the limit are dropped. PADR packets that are not dropped here are passed along as safe, normal traffic.
By default, all three individual policers (Packet Forwarding Engine, line card, and Routing Engine) have the same bandwidth limit for a given packet type. This design enables all the control traffic from a Packet Forwarding Engine and line card to reach the Routing Engine, as long as there is no competing traffic of the same type from other Packet Forwarding Engines or line cards. When competing traffic is present, excess packets are dropped at the convergence points. That is, they are dropped at the line card for all competing Packet Forwarding Engines and at the Routing Engine for all competing line cards.
Example of Policer Bandwidth Limit Behavior
For example, suppose you set the policer bandwidth for PADI packets to 1000 packets per second. This value applies to the individual PADI policers at the Packet Forwarding Engine, the line card, and the Routing Engine. If only the card in slot 5 is receiving PADI packets, then up to 1000 PADI pps can reach the Routing Engine (if the PPPoE aggregate policer is not exceeded). However, suppose the card in slot 9 is also receiving PADI packets at 1000 pps and that its PPPoE aggregate policer is not exceeded. The traffic passes the individual and aggregate policers at both line cards and proceeds to the Routing Engine. At the Routing Engine, the combined bandwidth is 2000 pps. Because the PADI policer at the Routing Engine allows only 1000 PADI pps to pass, it drops the excess 1000 packets. It continues to drop the excess packets for as long as the bandwidth is exceeded.
You can apply a scaling factor for both the bandwidth limit and the burst limit at the line card. This enables you to fine-tune the traffic limits for each slot. For example, suppose the individual policer sets the PADI packet bandwidth to 1000 pps and the burst size to 50,000 packets. You can reduce the traffic limit for PADI packets on any line card by specifying the slot number and scaling factor. A bandwidth scaling factor of 20 for slot 5 reduces the traffic in this example to 20 percent of 1000 pps, or 200 pps for the line card in that slot. Similarly, a burst scaling factor of 50 for that slot reduces the burst size by 50 percent to 25,000 packets. By default, scaling factors are set to 100 so traffic can pass through at 100 percent of the rate limit.
DDoS Protection Compared to Subscriber Login Packet Overload Protection
In addition to the DDoS protection capability, MX Series routers also have a built-in subscriber login overload protection mechanism. The login overload protection mechanism (also called a load-throttling mechanism) monitors the incoming subscriber login packets and admits only what the system is capable of handling in accordance with the prevailing load on the system. Packets in excess of what the system can handle are discarded. By shedding this excess load, the system is able to maintain optimal performance and prevent any degradation of login-completion rate under overload conditions. This mechanism uses minimal resources and is enabled by default; no user configuration is required.
The protection provided by this mechanism is secondary to what DDoS protection provides as a first level of defense against high rates of incoming packets. DDoS protection operates on the Packet Forwarding Engine and protects against all packet types of all protocols. In contrast, the login overload protection mechanism is located on the Routing Engine and specifically operates only on incoming connection-initiation packets such as DHCPv4 DHCPDISCOVER, DHCPv6 SOLICIT, and PPPoE PADI packets.