STIGViewer Support

The Nokia Border Gateway Protocol (BGP) router must be configured to use the maximum prefixes feature to protect against route table flooding and prefix deaggregation attacks.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-283856NOKI-RT-000380SV-283856r1203817_ruleCCI-002385medium
Description
The effects of prefix deaggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix deaggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements. In 1997, misconfigured routers in the Florida Internet Exchange network (AS7007) deaggregated every prefix in their routing table and started advertising the first /24 block of each of these prefixes as their own. Faced with this additional burden, the internal routers became overloaded and crashed repeatedly. This caused prefixes advertised by these routers to disappear from routing tables and reappear when the routers came back online. As the routers came back after crashing, they were flooded with the routing table information by their neighbors. The flood of information again overwhelmed the routers and caused them to crash. This process of route flapping destabilized not only the surrounding network but also the entire internet. Routers trying to reach those addresses would choose the smaller, more specific /24 blocks first. This caused backbone networks throughout North America and Europe to crash. Maximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the deaggregation risk. BGP maximum prefix must be used on all eBGP routers to limit the number of prefixes that it should receive from a particular neighbor, whether customer or peering autonomous system. Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected.
STIGDate
Nokia Service Router OS 25.x Router Security Technical Implementation Guide2026-06-15

Related Frameworks

1 mapping across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (13) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

MON-01Continuous Monitoring
1.00
MON-01.1Intrusion Detection & Prevention Systems (IDS & IPS)
1.00
MON-01.3Inbound & Outbound Communications Traffic
1.00
MON-01.4System Generated Alerts
1.00
MON-01.8Security Event Monitoring
1.00
NET-01Network Security Controls (NSC)
1.00
NET-02Layered Network Defenses
1.00
SEA-01Secure Engineering Principles
1.00
SEA-02Alignment With Enterprise Architecture
1.00
CAP-01Capacity & Performance Management
0.50

+3 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (36) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-10Concurrent Session Control
1.00
AC-17(9)Disconnect or Disable Access
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-4Information Flow Enforcement
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-12Audit Record Generation
1.00
AU-3Content of Audit Records
1.00
AU-5Response to Audit Logging Process Failures
1.00
CM-11(2)Software Installation with Privileged Status
1.00

+26 more (top 10 by confidence shown)

CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (3) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

12 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-283856r1203817_chk)

Review the router configuration to verify the number of received prefixes from each eBGP neighbor is controlled. Use the command below to verify the prefix limit for IPv4 and IPv6: - show router bgp neighbor 20.20.20.2 detail | match "Prefix Limit" post-lines 6 Prefix Limits Per Address Family Family Limit IdleTimeout TH LogOnly PostImport ExcessInact ------------------------------------------------------------------------------- ipv4 500 forever 90 Disabled Disabled N/A ipv6 500 forever 90 Disabled Disabled N/A If the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix deaggregation attacks, this is a finding.

Fix Text (F-88326r1203816_fix)

Configure all eBGP routers to use the maximum prefixes feature to protect against route table flooding and prefix deaggregation attacks, as shown in the example below: - configure router bgp group "eBGP" prefix-limit 500 ipv4 - configure router bgp group "eBGP" prefix-limit 500 ipv6