Neighbor Discovery Cache Protection
SUMMARY NDP Cache Protection enables you to protect the routing engine from certain types of denial-of-service (DoS) attacks in IPv6 deployment scenarios.
Neighbor Discovery Cache Protection Overview
Routing Engines can be susceptible to certain denial-of-service
(DoS) attacks in IPv6 deployment scenarios. IPv6 subnets in general
tend be very large—for example, a /64 subnet might
have a high number of unassigned addresses. The control plane of the
Routing Engine performs the address resolution for unknown addresses.
An attacker can quickly overwhelm the control plane of the Routing
Engine by generating resolution requests for this unassigned address
space, resulting in a cache overflow. The attacker relies on both
the number of requests generated and the rate at which requests are
queued up. Such scenarios can tie up router resources and prevent
the Routing Engine from answering valid neighbor solicitations and
maintaining existing neighbor cache entries, effectively resulting
in a DoS attack for legitimate users.
The strategies for mitigating such DoS attacks are as follows:
Filter unused address space.
Minimize the size of subnets.
Configure discard routes for subnets.
Enforce limits to the size and rate of resolution for entries in the neighbor discovery cache.
Neighbor discovery cache impact can be minimized by restricting
the number of IPv6 neighbors and new unresolved next-hop addresses
that can be added to the cache. You can set limits per interface by
using the nd6-max-cache and the nd6-new-hold-limit configuration statements or system-wide by using the nd-system-cache-limit configuration statement.
For small sized platforms such as ACX, EX22XX, EX3200, EX33XX, and SRX, default is 20,000.
For medium sized platforms such as EX4200, EX45XX, EX4300, EX62XX, QFX, and MX, default is 75,000.
For rest of the platforms, default is 100,000.
Configuring Neighbor Discovery Cache Protection
Routing Engines can be susceptible to certain types of
denial-of-service (DoS) attacks in IPv6 deployment scenarios. IPv6
subnets in general tend be very large; for example, a /64 subnet might have a high number of unassigned addresses. The control
plane of the Routing Engine performs the address resolution for unknown
addresses. An attacker can quickly overwhelm the control plane of
the Routing Engine by generating resolution requests for this unassigned
address space, resulting in a cache overflow. An attacker relies on
both the number of requests generated and the rate at which requests
are queued up.
The neighbor discovery process is that part of the control plane that implements the Neighbor Discovery Protocol. It is responsible for performing address resolution and maintaining the entries in the neighbor cache. One way to mitigate the DoS attacks is by enforcing limits to the size of the neighbor discovery cache and the rate of resolution of new next-hop entries, and by prioritizing certain categories of neighbor discovery traffic. You can configure limits to the neighbor discovery cache per interface and systemwide.
Before you begin, ensure that you are running Junos OS Release 15.1 or later.
Local limits apply to individual interfaces and are defined for resolved and unresolved entries in the neighbor discovery queue, while global limits apply systemwide.
To configure neighbor discovery cache protection on an interface:
To verify the configuration, execute the show interfaces interface-name operational command.
To configure neighbor discovery cache protection systemwide:
Configure the systemwide limit for the neighbor discovery cache.
[edit] user@host# set system nd-system-cache-limit limit
To verify the configured system-wide limits, execute the show system statistics icmp6 operational command.
For small sized platforms such as ACX, EX22XX, EX3200, EX33XX, and SRX, default is 20,000.
For medium sized platforms such as EX4200, EX45XX, EX4300, EX62XX, QFX, and MX, default is 75,000.
For rest of the platforms, default is 100,000.
Example: Configuring Neighbor Discovery Cache Protection to Prevent Denial-of-Service Attacks
This example shows how to configure a limit to the number of IPv6 neighbor entries that can be added to the neighbor discovery. Enforcing limits to the number of entries in the cache mitigates denial-of-service (DoS) attacks. The neighbor discovery cache feature supports two types of limits:
Local—Local limits are configured per interface and are defined for resolved and unresolved entries in the neighbor discovery cache.
Global—Global limits apply systemwide. A global limit is further defined separately for the public interfaces and management interfaces, for example, fxp0. The management interface has a single global limit and no local limit. The global limit enforces a systemwide cap on entries for the neighbor discovery cache, including for the loopback interface for the internal routing instance, as well as management interfaces and the public interfaces.
Requirements
This example requires MX Series routers running Junos OS Release 15.1 or later.
Overview
Routing Engines can be susceptible to certain types of DoS attacks
in IPv6 deployment scenarios. IPv6 subnets in general tend be very
large—for example, a /64 subnet might have a high
number of unassigned addresses, which can be used to perform DoS attacks.
The control plane of the Routing Engine performs the address resolution
for unknown addresses. An attacker can quickly overwhelm the control
plane of the Routing Engine by generating resolution requests for
this unassigned address space and overflow the queue. The attacker
relies on both the number of requests generated and the rate at which
requests are queued up.
The neighbor discovery process is that part of the control plane that implements the Neighbor Discovery Protocol. It is responsible for performing address resolution and maintaining the neighbor cache. One way to mitigate DoS attacks is by enforcing limits ot the neighbor discovery queue limits, which can be done by restricting queue size and the rate of resolution, and by prioritizing certain categories of neighbor discovery traffic.
Configuration
To configure neighbor discovery cache protection, perform these tasks:
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
and copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration
mode.
set interfaces ge-0/3/0 unit 5 family inet6 nd6-max-cache 100 set interfaces ge-0/3/0 unit 5 family inet6 nd6-new-hold-limit 100
You can also configure a systemwide limit to the number of IPv6 neighbor entries in the neighbor discovery cache. This limit also includes the loopback interface, management interfaces, and the public interfaces.
set system nd-system-cache-limit 100
The limit distribution from the nd-system-cache-limit statement for different interface types is performed according to
certain fixed percentages. When nd-system-cache-limit is
defined as X and the internal routing interface
neighbor discovery cache limit is Y (default
is 200), then:
Public maximum cache limit, Z = 80% of (X- Y)
Management interface maximum cache limit (for example, fxp0), M = 20% of (X-Y)
Configuring Neighbor Discovery Cache Protection
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure neighbor discovery cache protection per interface:
Configure the
nd6-max-cacheandnd6-new-hold-limit.[edit] user@host# set interfaces ge-0/3/0 unit 5 family inet6 nd6-max-cache 100 user@host# set interfaces ge-0/3/0 unit 5 family inet6 nd6-new-hold-limit 100
Results
To confirm neighbor discovery cache protection locally,
enter show interfaces ge-0/3/0 from configuration mode.
If the output does not display the intended configuration, repeat
the instructions in this example to correct the configuration.
[edit]
user@host# show interfaces ge-0/3/0
unit 5{
family inet6 {
nd6-max-cache 100;
nd6-new-hold-limit 100;
}
}
Verification
Confirm that the configuration is working properly.
- Verifying Neighbor Discovery Cache Protection Globally
- Verifying Neighbor Discovery Cache Protection Locally
Verifying Neighbor Discovery Cache Protection Globally
Purpose
Verify that the output reflects the systemwide limit for the neighbor discovery cache.
Action
From operational mode, run the show system statistics
icmp6 command.
user@host> show system statistics icmp6
icmp6:
79 Calls to icmp_error
0 Errors not generated because old message was icmp error
0 Errors not generated because rate limitation
Output histogram:
79 unreach
30 echo
163 multicast listener query
6 multicast listener report
940 neighbor solicitation
694184 neighbor advertisement
0 Messages with bad code fields
0 Messages < minimum length
0 Bad checksums
0 Messages with bad length
Input histogram:
10 echo reply
6 multicast listener report
693975 neighbor solicitation
Histogram of error messages to be generated:
0 No route
0 Administratively prohibited
0 Beyond scope
79 Address unreachable
0 Port unreachable
0 Time exceed transit
0 Time exceed reassembly
0 Erroneous header field
0 Unrecognized next header
0 Unrecognized option
0 Unknown
0 Message responses generated
0 Messages with too many ND options
100000 Max System ND nh cache limit
79840 Max Public ND nh cache limit
200 Max IRI ND nh cache limit
19960 Max Management intf ND nh cache limit
79840 Current Public ND nexthops present
4 Current IRI ND nexthops present
0 Current Management ND nexthops present
909266 Total ND nexthops creation failed as limit reached
909266 Public ND nexthops creation failed as public limit reached
0 IRI ND nexthops creation failed as iri limit reached
0 Management ND nexthops creation failed as mgt limit reached
Meaning
The systemwide cap enforced on the neighbor discovery cache entries is 100000.
Management ND nexthops creation failed as mgt limit reached indicates the drop count for the management interface when the systemwide limit is reached. Total ND nexthops creation failed as limit reached indicates failure for management, public, or Internal routing instance interfaces, and Public ND nexthops creation failed as public limit reached indicates the drop count for public interfaces when the systemwide limit to the number of entries is reached.
Verifying Neighbor Discovery Cache Protection Locally
Purpose
Verify that the output reflects the configured interface limits.
Action
From operational mode, run the show interfaces
ge-0/3/0 command.
user@host> show interfaces ge-0/3/0
Logical interface ge-0/2/0.8 (Index 348) (SNMP ifIndex 690)
Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.8 ] Encapsulation: ENET2
Input packets : 181628
Output packets: 79872
Protocol inet6, MTU: 1500
Max nh cache: 100000, New hold nh limit: 100000, Curr nh cnt: 79840, Curr new hold cnt: 0, NH drop cnt: 0
Flags: Is-Primary
Addresses, Flags: Is-Preferred Is-Primary
Destination: 8001:1::/64, Local: 8001:1::1:1
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::56e0:3200:8c6:e0a4
Protocol multiservice, MTU: UnlimitedMeaning
The maximum number of total entries and the maximum number of entries for new unresolved next-hop addresses that can be attached to interface ge-0/3/0 is 100000.
NH drop cnt refers to the number of neighbor discovery requests not serviced because the interface maximum queue size limits have been reached.