Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that access control lists (ACLs) and filters are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. These filters should be applied inbound or outbound on the appropriate external and internal interfaces. If the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure ACLs and filters to allow or deny traffic for specific source and destination addresses as well as ports and protocols. Apply the filters inbound or outbound on the appropriate external and internal interfaces. Policy-based routing can also be implemented if needed.
Review the router configuration to verify that it will reject routes of any Bogon prefixes. The prefix filter must be referenced inbound on the appropriate BGP neighbor statements. If the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.
Ensure all eBGP routers are configured to reject inbound route advertisements for any Bogon prefixes.
Review the router configuration to verify that it will reject routes belonging to the local AS. The prefix filter must be referenced inbound on the appropriate BGP neighbor statements. If the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.
Ensure all eBGP routers are configured to reject inbound route advertisements for any prefixes belonging to the local AS.
Review the router configuration to verify that there are filters defined to only accept routes for prefixes that belong to specific customers. The prefix filter must be referenced inbound on the appropriate BGP neighbor statement. If the router is not configured to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer, this is a finding. Note: Routes to PE-CE links within a VPN are needed for troubleshooting end-to-end connectivity across the MPLS/IP backbone. Hence, these prefixes are an exception to this requirement.
Configure all eBGP routers to reject inbound route advertisements from a CE router for prefixes that are not allocated to that customer.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that there is a filter defined to only advertise routes for prefixes that belong to any customers or the local AS. The prefix filter must be referenced outbound on the appropriate BGP neighbor statements. If the router is not configured to reject outbound route advertisements that belong to any customers or the local AS, this is a finding.
Configure all eBGP routers to filter outbound route advertisements for prefixes that are not allocated to or belong to any customer or the local AS.
Review the router configuration to verify the router is configured to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. If the router is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding.
Configure all ASBRs to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute.
Review the router configuration to determine if there is an import policy to block source-active multicast advertisements for any undesirable multicast groups, as well as any (S, G) states with undesirable source addresses. Step 1: Verify that an inbound source-active filter is bound to each MSDP peer. Step 2: Review the access lists referenced by the source-active filter to verify that undesirable multicast groups, auto-RP, single source multicast (SSM) groups, and advertisements from undesirable sources are blocked. If the router is not configured with an import policy to block undesirable SA multicast advertisements, this is a finding.
Configure the MSDP router to implement an import policy to block multicast advertisements for undesirable multicast groups and sources.
Review the router configuration to determine if there is export policy to block local source-active multicast advertisements. Verify that an outbound source-active filter is bound to each MSDP peer. Review the access lists referenced by the source-active filters and verify that MSDP source-active messages being sent to MSDP peers do not leak advertisements that are local. If the router is not configured with an export policy to block local source-active multicast advertisements, this is a finding.
Ensure an export policy is implemented on all MSDP routers to avoid global visibility of local multicast (S, G) states.
Review the router configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis. If the router is not configured to limit the source-active messages it accepts, this is a finding.
Configure the MSDP router to limit the amount of source-active messages it accepts from each peer.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify the router is configured to deny updates received from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: Review router configuration and verify that there is an as-path access-list statement defined to only accept routes from a CE router whose AS did not originate the route. Step 2: Verify that the as-path access list is referenced by the filter-list inbound for the appropriate BGP neighbors. If the router is not configured to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.
Configure the router to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.
Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it. If the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.
Disable the auxiliary port. If used for out-of-band administrative access, the port must be connected to a secured modem providing encryption and authentication.
Verify each router enforces approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy. If the router does not enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy, this is a finding.
Configure the router to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.
If IPv4 or IPv6 multicast routing is enabled, verify all interfaces enabled for PIM are documented in the network's multicast topology diagram. Review the router configuration to determine if multicast routing is enabled and which interfaces are enabled for PIM. If an interface is not required to support multicast routing and it is enabled, this is a finding.
Document all enabled interfaces for PIM in the network's multicast topology diagram. Disable support for PIM on interfaces that are not required to support it.
This requirement is not applicable for the DoDIN Backbone. Review the multicast topology diagram and determine if router interfaces are enabled for IPv4 or IPv6 multicast routing. If the router is enabled for multicast routing, verify all interfaces enabled for PIM have a neighbor filter bound to the interface. The neighbor filter must only accept PIM control plane traffic from the documented PIM neighbors. If PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM enabled interfaces.
Review the router configuration and verify that admin-scope multicast traffic is blocked at the external edge. If the router is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.
Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses. Step 2: Apply the multicast boundary at the appropriate interfaces.
Review the router configuration. If an interface is not being used but is configured or enabled, this is a finding.
Delete inactive sub-interfaces and disable and delete the configuration of any inactive ports on the router.
This requirement is not applicable for the DoDIN Backbone. Review the configuration of each router interface connecting to an alternate gateway. Verify each permit statement of the ingress filter only permits packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider. If the ingress filter permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the ingress filter of the perimeter router connected to an alternate gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider.
This requirement is not applicable for the DoDIN Backbone. Review the configuration of the router connecting to the alternate gateway. Verify there are no BGP neighbors configured to the remote AS that belongs to the alternate gateway service provider. If there are BGP neighbors connecting the remote AS of the alternate gateway service provider, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure a static route on the perimeter router to reach the AS of a router connecting to an alternate gateway.
This requirement is not applicable for the DoDIN Backbone. Review the configuration of the router connecting to the alternate gateway and verify that redistribution of static routes to the alternate gateway is not occurring. If the static routes to the alternate gateway are being redistributed into BGP or any IGP peering with a NIPRNet gateway or another autonomous system, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router so that static routes are not redistributed to an alternate gateway into either an Exterior Gateway Protocol or Interior Gateway Protocol to the NIPRNet or to other autonomous systems.
This requirement is not applicable for the DoDIN Backbone. Verify that the OOBM interface is an adjacency in the Interior Gateway Protocol routing domain for the management network. If the router does not enforce that Interior Gateway Protocol instances configured on the OOBM gateway router peer only with their own routing domain, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router to enforce that Interior Gateway Protocol instances configured on the OOBM gateway router peer only with their own routing domain.
This requirement is not applicable for the DoDIN Backbone. Verify the Interior Gateway Protocol instance used for the managed network does not redistribute routes into the Interior Gateway Protocol instance used for the management network, and vice versa. If the Interior Gateway Protocol instance used for the managed network redistributes routes into the Interior Gateway Protocol instance used for the management network, or vice versa, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the Interior Gateway Protocol instance used for the managed network to prohibit redistribution of routes into the Interior Gateway Protocol instance used for the management network, and vice versa.
Verify that the RP router is configured to filter PIM register messages. If the RP router peering with PIM-SM routers is not configured with a PIM import policy to block registration messages for any undesirable multicast groups and sources, this is a finding.
Configure the RP router to filter PIM register messages received from a multicast DR for any undesirable multicast groups or sources.
Verify that the RP router is configured to filter PIM register messages. Note: Alternative is to configure all designated routers to filter IGMP Membership Report (a.k.a join) messages received from hosts. If the RP router peering with PIM-SM routers is not configured with a PIM import policy to block registration messages for any undesirable multicast groups and Bogon sources, this is a finding.
RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block join messages for reserved and any undesirable multicast groups.
The router must log all packets that have been dropped via the access control list (ACL). If the router fails to log all packets that have been dropped via the ACL, this is a finding. Log output must contain an interface name as to where the packet was filtered. If the logged output does not contain an interface name as to where the packet was filtered, this is a finding.
Configure the router to record the interface in the log record for packets being dropped.
The router must log all packets that have been dropped via the access control list. If the router fails to log all packets that have been dropped via the control list, this is a finding. Log output must contain the source IP address and port of the filtered packets. If the logged output does not contain source IP address and port of the filtered packets, this is a finding.
Configure the router to record the source address in the log record for packets being dropped.
Review the router interface access control lists (ACLs) to verify all deny statements are logged. If packets being dropped are not logged, this is a finding.
Configure interface ACLs to log all deny statements.
Review the router configuration to determine if services or functions not required for operation, or not related to router functionality (e.g., DNS, email client or server, FTP server, or web server) are enabled. If unnecessary services and functions are enabled on the router, this is a finding.
Remove unneeded services and functions from the router. Removal is recommended because the service or function may be inadvertently enabled otherwise. However, if removal is not possible, disable the service or function.
Review the router configuration. For every protocol that affects the routing or forwarding tables (where information is exchanged between neighbors), verify that neighbor router authentication is encrypting the authentication key. If authentication is not encrypting the authentication key, this is a finding.
Configure routing protocol authentication to encrypt the authentication key.
Review the router configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages. If a NIST-validated FIPS 198-1 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.
Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm.
Review the PE router configuration to determine if a MAC address limit has been set for each bridge domain. If a limit has not been configured, this is a finding.
Configure a MAC address learning limit for each VPLS bridge domain.
Review the router configuration to verify that the router has been configured to prevent a burst of RSVP traffic engineering signaling messages from overflowing the input queue of any neighbor core router. If the router with RSVP-TE enabled does not have message pacing configured based on the link speed and input queue size of adjacent core routers, this is a finding.
Ensure all routers with RSVP-TE enabled have message pacing configured that will adjust maximum burst and maximum number of RSVP messages to an output queue based on the link speed and input queue size of adjacent core routers.
Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS. If storm control is not enabled for broadcast traffic, this is a finding. Note: The threshold level can be from 0 to 100 percent of the link's bandwidth, where "0" suppresses all traffic. Most FastEthernet switching modules do not support multicast and unicast traffic storm control.
Configure storm control for each VPLS bridge domain. Base the suppression threshold on expected traffic rates plus some additional capacity.
Review the router configuration and interview the System Administrator to verify that a mechanism for traffic prioritization and bandwidth reservation exists. This arrangement must ensure that sufficient capacity is available for mission-critical traffic and enforce the traffic priorities specified by the Combatant Commands/Services/Agencies. If no such scheme exists or it is not configured, this is a finding.
Implement a mechanism for traffic prioritization and bandwidth reservation. This mechanism must enforce the traffic priorities specified by the Combatant Commands/Services/Agencies.
Review the router configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile. Verify that the class-maps are configured to match on DSCP, protocols, or access control lists (ACLs) that identify traffic types based on ports. Verify that the policy-map is configured to set DSCP values for the defined class-maps in accordance with the QoS GIG Technical Profile. Verify that an output service policy is bound to all interfaces. Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the router is not configured to implement a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Configure a QoS policy on each router in accordance with the QoS GIG Technical Profile.
Review the router configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS GIG Technical Profile. Verify that the class-maps are configured to match on DSCP, protocols, or access control lists (ACLs) that identify traffic types based on ports. Verify that the policy-map is configured to set DSCP values for the defined class-maps in accordance with the QoS GIG Technical Profile. Verify that an input service policy is bound to all interfaces. Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the router is not configured to implement a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.
Configure a QoS policy on each router in accordance with the QoS GIG Technical Profile.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the access control list (ACL) or filter is configured to allow specific ports and protocols and deny all other traffic. The filter must be configured inbound on all external interfaces. If the ACL or filter is not configured to allow specific ports and protocols and deny all other traffic, this is a finding. If the filter is not configured inbound on all external interfaces, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the perimeter router to deny network traffic by default and allow network traffic by exception.
Review the access control list (ACL) or filter for the router receive path and verify that it will only process specific management plane and control plane traffic from specific sources. If the router is not configured with a receive-path filter to restrict traffic destined to itself, this is a finding. Note: If the platform does not support the receive path filter, verify that all Layer 3 interfaces have an ingress ACL to control what packets are allowed to be destined to the router for processing.
Configure all routers with receive path filters to restrict traffic destined to the router.
Review the access control list (ACL) or filter for the router receive path. Verify that it will drop all fragmented ICMP packets destined to itself. If the router is not configured with a receive-path filter to drop all fragmented ICMP packets, this is a finding. Note: If the platform does not support the receive path filter, verify that all Layer 3 interfaces have an ingress ACL to control what packets are allowed to be destined to the router for processing.
Ensure all routers have their receive path filter configured to drop all fragmented ICMP packets.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the ingress filter is in accordance with DoD 8551. If the router does not filter traffic in accordance with the guidelines contained in DoD 8551, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router to use ingress ACLs to restrict traffic in accordance with the guidelines contained in DOD Instruction 8551.1 for all services and protocols required for operational commitments.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the ingress ACL is bound to the external interface in an inbound direction. If the router is not configured to filter traffic entering the network at the external interface in an inbound direction, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Bind the ingress ACL to the external interface (inbound).
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. If the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure an egress ACL bound to the internal interface in an inbound direction to filter traffic leaving the network.
Review the router configuration to verify that there is a filter defined to block route advertisements for prefixes that belong to the IP core. The prefix filter must be referenced outbound on the appropriate BGP neighbor statements. If the router is not configured to reject outbound route advertisements that belong to the IP core, this is a finding.
Configure all eBGP routers to filter outbound route advertisements belonging to the IP core.
Review the router configuration to verify that an ingress ACL is applied to all CE-facing interfaces. Verify that the ingress ACL rejects and logs packets destined to the IP core address block. If the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding. Note: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent peers.
Configure protection for the IP core to be implemented at the edges by blocking any traffic with a destination address assigned to the IP core infrastructure.
Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces. If uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.
Enable uRPF loose mode on all CE-facing interfaces.
This requirement is not applicable for the DoDIN Backbone. Review the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path and interface that the management traffic traverses. If management traffic is not transported between the managed network and the NOC via dedicated circuit, MPLS/VPN service, or IPsec tunnel, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Ensure that a dedicated circuit, MPLS/VPN service, or IPsec tunnel is deployed to transport management traffic between the managed network and the NOC.
This requirement is not applicable for the DoDIN Backbone. Review the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path that the management traffic traverses. Verify that only management traffic is forwarded through the OOBM interface or IPsec tunnel. If traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure filters based on port, source IP address, and destination IP address to permit only authorized management traffic into IPsec tunnels or the OOBM interface used for forwarding management data.
This requirement is not applicable for the DoDIN Backbone. Review the access control list (ACL) or filter for the router receive path. Verify that only traffic sourced from the OOBM network or the NOC is allowed to access the router. If the router does not block any traffic destined to itself that is not sourced from the OOBM network or the NOC, this is a finding. Note: If the platform does not support the receive path filter, verify that all non-OOBM interfaces have an ingress ACL to restrict access to that interface address or any of the router’s loopback addresses to only traffic sourced from the management network. An exception would be to allow packets destined to these interfaces used for troubleshooting, such as ping and traceroute.
This requirement is not applicable for the DoDIN Backbone. Ensure that traffic from the managed network is not able to access the OOBM gateway router using either receive path or interface ingress ACLs.
Step 1: Verify that the managed interface has an inbound and outbound ACL configured. Step 2: Verify that the ingress filter only allows management, IGP, and ICMP traffic. Caveat: If the management interface is a true OOBM interface, this requirement is not applicable. If the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.
If the management interface is a routed interface, it must be configured with both an ingress and egress ACL.
This requirement is not applicable for the DoDIN Backbone. Verify that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel. If the management traffic is not secured via IPsec tunnel, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Ensure that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel.
Verify the router stops forwarding traffic or maintains the configured security policies upon the failure of the following actions: system initialization, shutdown, or system abort. If the router does not stop forwarding traffic or maintain the configured security policies upon the failure of system initialization, shutdown, or system abort, this is a finding.
This is a capability that would be intrinsic to the router as a result of its development and may not be configurable. If it is a configurable option, configure the router to stop forwarding traffic or maintain the configured security policies upon the failure of the following actions: system initialization, shutdown, or system abort.
Review the router configuration to determine if LDP messages are being authenticated for the targeted LDP sessions. If authentication is not being used for the LDP sessions using a FIPS-approved message authentication code algorithm, this is a finding.
Implement authentication for all targeted LDP sessions using a FIPS-approved message authentication code algorithm.
Review the router configuration to determine if received MSDP packets are authenticated. If the router does not require MSDP authentication, this is a finding.
Ensure all MSDP packets received by an MSDP router are authenticated.
Review the device configuration to determine if a configuration auto-loading or zero-touch deployment feature is enabled. If a configuration auto-loading feature or zero-touch deployment feature is enabled, this is a finding. Note: Auto-configuration or zero-touch deployment features can be enabled when the router is offline for the purpose of image loading or building out the configuration. In addition, this would not be applicable to the provisioning of virtual routers via a software-defined network (SDN) orchestration system.
Disable all configuration auto-loading or zero-touch deployment features.
Determine whether control plane protection has been implemented on the device by verifying traffic types have been classified based on importance levels and a policy has been configured to filter and rate limit the traffic according to each class. If the router does not have control plane protection implemented, this is a finding.
Implement control plane protection by classifying traffic types based on importance and configure filters to restrict and rate limit the traffic directed to and processed by the RP according to each class.
Review the configuration to determine if gratuitous ARP is disabled on all external interfaces. If gratuitous ARP is enabled on any external interface, this is a finding.
Disable gratuitous ARP on all external interfaces.
Review the router configuration to determine if IP directed broadcast is enabled. If IP directed broadcast is enabled on Layer 3 interfaces, this is a finding.
Disable IP directed broadcasts on all Layer 3 interfaces.
Review the device configuration to determine if controls have been defined to ensure the router does not send ICMP unreachable notifications out to any external interfaces. If ICMP unreachable notifications are enabled on any external interfaces, this is a finding.
Disable ICMP unreachable notifications on all external interfaces.
Review the device configuration to determine if controls have been defined to ensure the router does not send ICMP Mask Reply messages out to any external interfaces. If ICMP Mask Reply messages are enabled on any external interfaces, this is a finding.
Disable ICMP mask replies on all external interfaces.
Review the device configuration to determine if controls have been defined to ensure the router does not send ICMP Redirect messages out to any external interfaces. If ICMP Redirect messages are enabled on any external interfaces, this is a finding.
Disable ICMP redirects on all external interfaces.
Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled. If the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.
Configure all eBGP routers to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify that there is a filter to reject inbound route advertisements that are greater than /24 or the least significant prefixes issued to the customer, whichever is larger. If the router is not configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer, this is a finding.
Ensure all eBGP routers are configured to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer.
Review the router configuration to verify that IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain (VFI instance). If the router is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.
Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain.
Review the router configuration to determine if forwarding cache thresholds are defined. If the RP router is not configured to limit the multicast forwarding cache to ensure that its resources are not saturated, this is a finding.
Configure MSDP-enabled RP routers to limit the multicast forwarding cache for source-active entries.
Review the configuration of the RP to verify that it is rate limiting the number of multicast register messages. If the RP is not limiting multicast register messages, this is a finding.
Configure the RP to rate limit the number of multicast register messages.
Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. If the DR is not limiting multicast join requests via IGMP or MLD, this is a finding. Note: If both global and per-interface state limiters are configured, the limits configured for per-interface state limiters are still enforced but are constrained by the global limit.
Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.
Review the multicast last-hop router configuration to verify that the SPT switchover threshold is increased (default is "0") or set to infinity (never switch over). If any multicast router is not configured to increase the SPT threshold or set to infinity to minimalize (S, G) state, this is a finding.
Configure the multicast router to increase the SPT threshold or set it to infinity to minimalize (S, G) state within the multicast topology where ASM is deployed.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to determine if the router allows only incoming communications from authorized sources to be routed to authorized destinations. If the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router to allow only incoming communications from authorized sources to be routed to authorized destinations.
This requirement is not applicable for the DODIN Backbone. Verify that the ingress filter is blocking packets with Bogon source addresses. Review the router configuration to verify that it is configured to block IP packets with a Bogon source address. IPv4 Bogon Prefixes 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 192.88.99.0/24 192.168.0.0/16 198.18.0.0/15 | 198.51.100.0/24 203.0.113.0/24 224.0.0.0/4 240.0.0.0/4 IPv6 Bogon Prefixes ::/128 ::1/128 0::/96 ::ffff:0:0/96 3ffe::/16 64:ff9b::/96 100::/64 2001:10::/28 2001:db8::/32 2001:2::/48 2001::/32 2001::/23 2002::/16 fc00::/7 fec0::/10 ff00::/8 If the router is not configured to block inbound IP packets containing a Bogon source address, this is a finding. Note: At a minimum, IP packets containing a source address from the special purpose address space as defined in RFC 6890 must be blocked. The 6Bone prefix (3ffe::/16) is also be considered a Bogon address. Perimeter routers connected to commercial ISPs for Internet or other non-DoD network sources will need to be reviewed for a full Bogon list. The IPv4 full Bogon list contains prefixes that have been allocated to RIRs but not assigned by those RIRs. Reference the following link: http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt The IPv6 full Bogon list contains prefixes that have not been allocated to RIRs, or those that have been allocated to RIRs but have not been assigned by those RIRs. Reference the following link: https://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt
This requirement is not applicable for the DODIN Backbone. Configure the router to block inbound packets with Bogon source addresses.
This requirement is not applicable for the DoDIN Backbone. Review all router configurations to ensure LLDPs are not included in the global configuration or LLDPs are not included for each active external interface. Examples of LLDPs are Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP), and Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED). If LLDPs are configured globally or on any external interface, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Disable LLDPs on all external interfaces.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to determine if IP Proxy ARP is disabled on all external interfaces. If IP Proxy ARP is enabled on any external interface, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Disable IP Proxy ARP on all external interfaces.
This requirement is not applicable for the DoDIN Backbone. The perimeter router of the managed network must be configured with an access control list (ACL) or filter on the egress interface to block all management traffic. If management traffic is not blocked at the perimeter, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the perimeter router of the managed network with an ACL or filter on the egress interface to block all outbound management traffic.
Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to join only those groups that have been approved. Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation. This requirement is not applicable to Any Source Multicast (ASM) since the filtering is being performed by the Rendezvous Point router. If the DR is not filtering IGMP or MLD report messages, this is a finding.
Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups that have been approved.
Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to only join multicast groups from sources that have been approved. Note: This requirement is only applicable to Source Specific Multicast (SSM) implementation If the DR is not filtering IGMP or MLD report messages, this is a finding.
Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups from sources that have been approved.
Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers. If the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.
Ensure the receive path or interface filter for all MSDP routers only accepts MSDP packets from known MSDP peers.
Review the documentation of the router or interview the System Administrator. Verify that the router fails securely in the event of an operational failure. If it cannot fail securely, this is a finding.
This is a capability that would be intrinsic to the router as a result of its development and may not be configurable. If it is a configurable option, configure the device to fail securely in the event of an operational failure.
Review the router configuration to verify that a loopback address has been configured. Verify that a loopback interface is used as the source address for all iBGP sessions. If the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.
Ensure that the router’s loopback address is used as the source address when originating traffic.
Review the router configuration to determine if it uses its loopback address as the source address for LDP peering sessions. Verify that a loopback address has been configured as shown in the following example: An MPLS router will use the LDP router ID as the source address for LDP hellos and when establishing TCP sessions with LDP peers; hence, it is necessary to verify that the LDP router ID is the same as the loopback address. By default, routers will assign the LDP router ID using the highest IP address on the router, with preference given to loopback addresses. If the router-id command is specified that overrides this default behavior, verify that it is the IP address of the designated loopback interface. If the router is not configured do use its loopback address for LDP peering, this is a finding.
Configure MPLS routers to use their loopback address as the source address for LDP peering sessions.
Review the router OSPF or IS-IS configuration. Verify that LDP will synchronize with the link-state routing protocol. If the router is not configured to synchronize IGP and LDP, this is a finding.
Configure the MPLS router to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.
Review the router configuration to verify that TTL propagation is disabled. If the router is not configured to disable TTL propagation, this is a finding.
Configure LERs to disable TTL propagation.
Review the design plan for deploying L3VPN and VRF-lite. Review all CE-facing interfaces and verify that the proper VRF is defined. If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.
Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.
Verify that the correct RT is configured for each VRF. Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF. Review the route-target import, route-target, or route-target export statements under each configured VRF and verify that the correct RTs have been defined for each VRF. Note: Import and export route-maps are normally used when finer granularity is required. If there are VRFs configured with the wrong RT, this is a finding.
Configure all J-PE routers to have the correct VRF defined with the appropriate RT.
Review the RDs that have been assigned for each VRF according to the plan provided by the ISSM. Review all VRFs configured on CE-facing interfaces and verify that the proper RD has been configured for each. If the wrong RD has been configured for any VRF, this is a finding.
Configure the correct RD for each VRF.
Review the ingress and egress PE router configuration for each virtual circuit that has been provisioned. Verify that the correct and unique VCID has been configured for the appropriate attachment circuit. If the correct VC ID has not been configured on both routers, this is a finding. Note: Ethernet over MPLS in VLAN mode transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network. The VC ID must be unique and the same on each end as it is used to connect the endpoints of the VC.
Assign globally unique VC IDs for each virtual circuit and configure the attachment circuits with the appropriate VC ID. Configure the same VC ID on both ends of the VC.
Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment. Review the PE router configuration to verify that customer attachment circuits (i.e., VLANs) are associated to the appropriate VFI. If the attachment circuits have not been bound to VFI configured with the assigned VPN ID for each VLAN, this is a finding.
Assign globally unique VPN IDs for each customer VLAN using VPLS for carrier Ethernet services between multiple sites, and configure the attachment circuits to the appropriate VFI.
Review the PE router configuration to verify that split horizon is enabled. If it is disabled, this is a finding. Note: In a ring VPLS, split horizon is disabled so that a PE router can forward a packet received from one pseudowire to another pseudowire. To prevent the consequential loop, at least one span in the ring would not have a pseudowire for any given VPLS instance.
Enable split horizon on all PE routers deploying VPLS in a full-mesh configuration.
Review the router configuration to verify that a loopback address has been configured. Verify that a loopback interface is used as the source address for all MSDP packets generated by the router. If the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.
Ensure that the router’s loopback address is used as the source address when originating traffic.
Determine if the router is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not configured in accordance with the designated security configuration settings, this is a finding.
Configure the router to be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.
Verify the call home service is disabled on the device. If a call home service is enabled, this is a finding.
Configure the network device to disable the call home service or feature.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify uRPF or an egress filter has been configured on all internal interfaces to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field. If uRPF or an egress filter to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router to ensure that an egress filter or uRPF is configured to restrict the router from accepting any outbound IP packet that contains an external IP address in the source field.
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to determine if it will block all packets with IP options. If the router is not configured to drop all packets with IP options, this is a finding.
This requirement is not applicable for the DoDIN Backbone. Configure the router to drop all packets with IP options.
Review the router configuration to determine if it will block all packets with IP options. If the router is not configured to drop all packets with IP options, this is a finding.
Configure the router to drop all packets with IP options.
Review the router configuration. For every protocol that affects the routing or forwarding tables (where information is exchanged between neighbors), verify that neighbor router authentication is enabled. If authentication is not enabled, this is a finding.
Configure authentication to be enabled for every protocol that affects the routing or forwarding tables.
Interview the ISSM and router administrator to determine if unique keys are being used. If unique keys are not being used, this is a finding.
Configure all eBGP routers with unique keys for each eBGP neighbor that it peers with.
This requirement is not applicable for the DoDIN Backbone. For each authenticated routing protocol session, review the configured key expiration dates. If any key has a lifetime of more than 180 days, this is a finding.
This requirement is not applicable for the DoDIN Backbone. For each authenticated routing protocol session, configure each key to have a lifetime of no more than 180 days.
Review the router configuration. If the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.
Configure all Exterior Border Gateway Protocol peering sessions to use GTSM.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if the hop limit has been configured for Router Advertisement messages. If it has been configured and has not been set to at least 32, it is a finding.
Configure the router to advertise a hop limit of at least 32 in Router Advertisement messages.
Review the router configuration to ensure FEC0::/10 IP addresses are not defined. If IPv6 Site Local Unicast addresses are defined, this is a finding.
Configure the router using authorized IPv6 addresses.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify Router Advertisements are suppressed on all external IPv6-enabled interfaces. If the router is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.
Configure the router to suppress Router Advertisements on all external IPv6-enabled interfaces.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if it is configured to drop IPv6 undetermined transport packets. If the router is not configured to drop IPv6 undetermined transport packets, this is a finding.
Configure the router to drop IPv6 undetermined transport packets.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3–255. If the router is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3–255, this is a finding.
Configure the router to drop IPv6 packets with Routing Header of type 0, 1, or 3–255.
This requirement is not applicable for the DODIN Backbone. Review the router configuration to determine if filters are bound to the applicable interfaces to drop IPv6 packets containing a Hop-by-Hop header with option type values of 0x04 (Tunnel Encapsulation Limit), 0xC9 (Home Address Destination), or 0xC3 (NSAP Address). Note: Because hop-by-hop and destination options have the same exact header format, they are combined under the dest-option-type keyword. Since Hop-by-Hop and Destination Option headers have non-overlapping types, the dest-option-type to match either can be used. The Hop-by-Hop and Destination Option headers can be filtered via protocol 0 and 60 respectively. If the router is not configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values, this is a finding.
Configure the router to drop IPv6 packets containing a Hop-by-Hop header with option type values of 0x04 (Tunnel Encapsulation Limit), 0xC9 (Home Address Destination), or 0xC3 (NSAP Address).
This requirement is not applicable for the DODIN Backbone. Review the router configuration and determine if filters are bound to the external interfaces to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload). Note: Because Hop-by-Hop and destination options have the same exact header format, they are combined under the dest-option-type keyword. According to Cisco, since Hop-by-Hop and Destination Option headers have non-overlapping types, dest-option-type to match either can be used. The Hop-by-Hop and Destination Option headers can be filtered via protocol 0 and 60 respectively. If the router is not configured to drop IPv6 packets containing a Destination Option header with invalid option type values, this is a finding.
Configure the router to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload).
This requirement is not applicable for the DODIN Backbone. Review the router switch configuration and determine if filters are bound to the applicable interfaces to drop IPv6 packets containing an option type values of 0x8A (Endpoint Identification) regardless of whether it appears in a Hop-by-Hop or Destination Option header. Note: Because hop-by-hop and destination options have the same exact header format, they are combined under the dest-option-type keyword. According to Cisco, since Hop-by-Hop and Destination Option headers have non-overlapping types, dest-option-type to match either can be used. The Hop-by-Hop and Destination Option headers can be filtered via protocol 0 and 60 respectively. If the router is not configured to drop IPv6 packets containing an extension header with the Endpoint Identification option, this is a finding.
Configure the router to drop IPv6 packets containing an option type values of 0x8A (Endpoint Identification) regardless of whether it appears in a Hop-by-Hop or Destination Option header.
This requirement is not applicable for the DODIN Backbone. Review the router configuration and determine if filters are bound to the applicable interfaces to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address). Note: Because Hop-by-Hop and destination options have the same header format, they are combined under the dest-option-type keyword. According to Cisco, since Hop-by-Hop and Destination Option headers have non-overlapping types, dest-option-type to match either can be used. The Hop-by-Hop and Destination Option headers can be filtered via protocol 0 and 60 respectively. If the router is not configured to drop IPv6 packets containing the NSAP address option within Destination Option header, this is a finding.
Configure the router to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address).
This requirement is not applicable for the DODIN Backbone. Review the router configuration and determine if filters are bound to the applicable interfaces to drop all inbound IPv6 packets containing an undefined option type value regardless of whether they appear in a Hop-by-Hop or Destination Option header. Undefined values are 0x02, 0x03, 0x06, 0x9 – 0xE, 0x10 – 0x22, 0x24, 0x25, 0x27 – 0x2F, and 0x31 – 0xFF. If the router is not configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type, this is a finding.
Configure the router to drop all inbound IPv6 packets containing an undefined option type value regardless of whether or not they appear in a Hop-by-Hop or Destination Option header.
Verify the router is configured to employ organization-defined controls by type of DoS to achieve the DoS objective. If the router is not configured to employ organization-defined controls by type of DoS to achieve the DoS objective, this is a finding.
Configure the router to employ organization-defined controls by type of DoS to achieve the DoS objective.
Verify the router is configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. If the router is not configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions, this is a finding.
Configure the router to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.
Verify the router is configured to establish organization-defined alternate communications paths for system operations organizational command and control. If the router is not configured to establish organization-defined alternate communications paths for system operations organizational command and control, this is a finding.
Configure the router to establish organization-defined alternate communications paths for system operations organizational command and control.