{"stig":{"title":"Router Security Requirements Guide","version":"5","release":"2"},"checks":[{"vulnId":"V-207097","ruleId":"SV-207097r1137893_rule","severity":"medium","ruleTitle":"The router must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.","description":"Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems.\n\nEnforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet filtering capability based on header information, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview 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.\n\nThese filters should be applied inbound or outbound on the appropriate external and internal interfaces.\n\nIf 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.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure ACLs and filters to allow or deny traffic for specific source and destination addresses as well as ports and protocols.\n\nApply the filters inbound or outbound on the appropriate external and internal interfaces.\n\nPolicy-based routing can also be implemented if needed.","ccis":["CCI-001368"]},{"vulnId":"V-207098","ruleId":"SV-207098r1137894_rule","severity":"medium","ruleTitle":"The BGP router must be configured to reject inbound route advertisements for any Bogon prefixes.","description":"Accepting route advertisements for Bogon prefixes can result in the local autonomous system (AS) becoming a transit for malicious traffic as it will in turn advertise these prefixes to neighbor autonomous systems.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration to verify that it will reject routes of any Bogon prefixes.\n\nThe prefix filter must be referenced inbound on the appropriate BGP neighbor statements.\n\nIf the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.","fixText":"Ensure all eBGP routers are configured to reject inbound route advertisements for any Bogon prefixes.","ccis":["CCI-001368"]},{"vulnId":"V-207099","ruleId":"SV-207099r1137895_rule","severity":"medium","ruleTitle":"The BGP router must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).","description":"Accepting route advertisements belonging to the local AS can result in traffic looping or being black holed, or at a minimum using a non-optimized path.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration to verify that it will reject routes belonging to the local AS.\n\nThe prefix filter must be referenced inbound on the appropriate BGP neighbor statements.\n\nIf the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.","fixText":"Ensure all eBGP routers are configured to reject inbound route advertisements for any prefixes belonging to the local AS.","ccis":["CCI-001368"]},{"vulnId":"V-207100","ruleId":"SV-207100r1137896_rule","severity":"medium","ruleTitle":"The BGP router must be configured to reject inbound route advertisements from a customer edge (CE) router for prefixes that are not allocated to that customer.","description":"As a best practice, a service provider should only accept customer prefixes that have been assigned to that customer and any peering autonomous systems. A multi-homed customer with BGP speaking routers connected to the Internet or other external networks could be breached and used to launch a prefix de-aggregation attack. Without ingress route filtering of customers, the effectiveness of such an attack could impact the entire IP core and its customers.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration to verify that there are filters defined to only accept routes for prefixes that belong to specific customers. \n\nThe prefix filter must be referenced inbound on the appropriate BGP neighbor statement.\n\nIf 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.\n\nNote: 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.","fixText":"Configure all eBGP routers to reject inbound route advertisements from a CE router for prefixes that are not allocated to that customer.","ccis":["CCI-001368"]},{"vulnId":"V-207101","ruleId":"SV-207101r1137897_rule","severity":"medium","ruleTitle":"The BGP router must be configured to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS).","description":"Advertisement of routes by an autonomous system for networks that do not belong to any of its customers pulls traffic away from the authorized network. This causes a denial of service (DoS) on the network that allocated the block of addresses and may cause a DoS on the network that is inadvertently advertising it as the originator. It is also possible that a misconfigured or compromised router within the GIG IP core could redistribute IGP routes into BGP, thereby leaking internal routes.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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.\n\nThe prefix filter must be referenced outbound on the appropriate BGP neighbor statements.\n\nIf the router is not configured to reject outbound route advertisements that belong to any customers or the local AS, this is a finding.","fixText":"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.","ccis":["CCI-001368"]},{"vulnId":"V-207102","ruleId":"SV-207102r1137898_rule","severity":"low","ruleTitle":"The BGP router must be configured to reject route advertisements from BGP peers that do not list their autonomous system (AS) number as the first AS in the AS_PATH attribute.","description":"Verifying the path a route has traversed will ensure the IP core is not used as a transit network for unauthorized or possibly even Internet traffic. All autonomous system boundary routers (ASBRs) must ensure updates received from eBGP peers list their AS number as the first AS in the AS_PATH attribute.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"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.\n\nIf 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.","fixText":"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.","ccis":["CCI-001368"]},{"vulnId":"V-207103","ruleId":"SV-207103r1137900_rule","severity":"low","ruleTitle":"The Multicast Source Discovery Protocol (MSDP) router must be configured to filter received source-active multicast advertisements for any undesirable multicast groups and sources.","description":"The interoperability of BGP extensions for interdomain multicast routing and MSDP enables seamless connectivity of multicast domains between autonomous systems. MP-BGP advertises the unicast prefixes of the multicast sources used by Protocol Independent Multicast (PIM) routers to perform RPF checks and build multicast distribution trees. MSDP is a mechanism used to connect multiple PIM sparse-mode domains, allowing RPs from different domains to share information about active sources. When RPs in peering multicast domains hear about active sources, they can pass on that information to their local receivers, thereby allowing multicast data to be forwarded between the domains. Configuring an import policy to block multicast advertisements for reserved, martian, single-source multicast, and any other undesirable multicast groups, as well as any source-group (S, G) states with Bogon source addresses, would assist in avoiding unwanted multicast traffic from traversing the core.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"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. \n\nStep 1: Verify an inbound source-active filter is bound to each MSDP peer.\n\nStep 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.\n\nIf the router is not configured with an import policy to block undesirable SA multicast advertisements, this is a finding.","fixText":"Configure the MSDP router to implement an import policy to block multicast advertisements for undesirable multicast groups and sources.","ccis":["CCI-001368"]},{"vulnId":"V-207104","ruleId":"SV-207104r1137902_rule","severity":"low","ruleTitle":"The Multicast Source Discovery Protocol (MSDP) router must be configured to filter source-active multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.","description":"To avoid global visibility of local information, there are a number of source-group (S, G) states in a PIM-SM domain that must not be leaked to another domain, such as multicast sources with private address, administratively scoped multicast addresses, and the auto-RP groups (224.0.1.39 and 224.0.1.40).\n\nAllowing a multicast distribution tree, local to the core, to extend beyond its boundary could enable local multicast traffic to leak into other autonomous systems and customer networks.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration to determine if there is export policy to block local source-active multicast advertisements.\n\nVerify an outbound source-active filter is bound to each MSDP peer.\n\nReview 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.\n\nIf the router is not configured with an export policy to block local source-active multicast advertisements, this is a finding.","fixText":"Ensure an export policy is implemented on all MSDP routers to avoid global visibility of local multicast (S, G) states.","ccis":["CCI-001368"]},{"vulnId":"V-207105","ruleId":"SV-207105r1137903_rule","severity":"low","ruleTitle":"The MSDP router must be configured to limit the amount of source-active messages it accepts on per-peer basis.","description":"To reduce any risk of a denial-of-service (DoS) attack from a rogue or misconfigured MSDP router, the router must be configured to limit the number of source-active messages it accepts from each peer.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"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.\n\nIf the router is not configured to limit the source-active messages it accepts, this is a finding.","fixText":"Configure the MSDP router to limit the amount of source-active messages it accepts from each peer.","ccis":["CCI-001368"]},{"vulnId":"V-207106","ruleId":"SV-207106r1137905_rule","severity":"low","ruleTitle":"The BGP router must be configured to reject route advertisements from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.","description":"Verifying the path a route has traversed will ensure that the local AS is not used as a transit network for unauthorized traffic. To ensure that the local AS does not carry any prefixes that do not belong to any customers, all PE routers must be configured to reject routes with an originating AS other than that belonging to the customer.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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.\n\nStep 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. \n\nStep 2: Verify the as-path access list is referenced by the filter-list inbound for the appropriate BGP neighbors.\n\nIf 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.","fixText":"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.","ccis":["CCI-001368"]},{"vulnId":"V-207107","ruleId":"SV-207107r1137906_rule","severity":"low","ruleTitle":"The router must be configured to disable the auxiliary port unless it is connected to a secured modem providing encryption and authentication.","description":"The use of POTS lines to modems connecting to network devices provides clear text of authentication traffic over commercial circuits that could be captured and used to compromise the network. Additional war dial attacks on the device could degrade the device and the production network.\n\nSecured modem devices must be able to authenticate users and must negotiate a key exchange before full encryption takes place. The modem will provide full encryption capability (Triple DES) or stronger. The technician who manages these devices will be authenticated using a key fob and granted access to the appropriate maintenance port; thus, the technician will gain access to the managed device (router, switch, etc.). The token provides a method of strong (two-factor) user authentication. The token works in conjunction with a server to generate one-time user passwords that will change values at second intervals. The user must know a personal identification number (PIN) and possess the token to be allowed access to the device.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it.\n\nIf the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.","fixText":"Disable the auxiliary port.\n\nIf used for out-of-band administrative access, the port must be connected to a secured modem providing encryption and authentication.","ccis":["CCI-001414"]},{"vulnId":"V-207108","ruleId":"SV-207108r1137907_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.","description":"Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most routers, internal information flow control is a product of system design.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify each router enforces approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.\n\nIf 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.","fixText":"Configure the router to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.","ccis":["CCI-001414"]},{"vulnId":"V-207109","ruleId":"SV-207109r1137908_rule","severity":"medium","ruleTitle":"The multicast router must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.","description":"If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security. \n\nA scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be \"convex from a routing perspective\"; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. \n\nAs stated in the DOD IPv6 IA Guidance for MO3, \"One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces.\" Therefore, it is imperative that the network engineers have documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"If IPv4 or IPv6 multicast routing is enabled, verify all interfaces enabled for PIM are documented in the network's multicast topology diagram.\n\nReview the router configuration to determine if multicast routing is enabled and which interfaces are enabled for PIM.\n\nIf an interface is not required to support multicast routing and it is enabled, this is a finding.","fixText":"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.","ccis":["CCI-001414"]},{"vulnId":"V-207110","ruleId":"SV-207110r1137911_rule","severity":"medium","ruleTitle":"The multicast router must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.","description":"PIM is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. PIM traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled. If a PIM neighbor filter is not applied to those interfaces that have PIM enabled, unauthorized routers can join the PIM domain, discover and use the rendezvous points, and also advertise their rendezvous points into the domain. This can result in a denial of service by traffic flooding or result in the unauthorized transfer of data.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the multicast topology diagram and determine if router interfaces are enabled for IPv4 or IPv6 multicast routing.\n\nIf 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.\n\nIf PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM enabled interfaces.","ccis":["CCI-001414"]},{"vulnId":"V-207111","ruleId":"SV-207111r1137912_rule","severity":"low","ruleTitle":"The multicast edge router must be configured to establish boundaries for administratively scoped multicast traffic.","description":"If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel.\n\nAdministrative scoped multicast addresses are locally assigned and are to be used exclusively by the enterprise network or enclave. Administrative scoped multicast traffic must not cross the enclave perimeter in either direction. Restricting multicast traffic makes it more difficult for a malicious user to access sensitive traffic.\n\nAdmin-Local scope is encouraged for any multicast traffic within a network intended for network management, as well as for control plane traffic that must reach beyond link-local destinations.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration and verify that admin-scope multicast traffic is blocked at the external edge.\n\nIf the router is not configured to establish boundaries for administratively scoped multicast traffic, this is a finding.","fixText":"Step 1: Configure the ACL to deny packets with multicast administratively scoped destination addresses.\n\nStep 2: Apply the multicast boundary at the appropriate interfaces.","ccis":["CCI-001414"]},{"vulnId":"V-207112","ruleId":"SV-207112r1137913_rule","severity":"low","ruleTitle":"The router must be configured to have all inactive interfaces disabled.","description":"An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use.\n\nIf an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the router configuration.\n\nIf an interface is not being used but is configured or enabled, this is a finding.","fixText":"Delete inactive sub-interfaces and disable and delete the configuration of any inactive ports on the router.","ccis":["CCI-001414"]},{"vulnId":"V-207113","ruleId":"SV-207113r1137916_rule","severity":"high","ruleTitle":"The perimeter router must be configured to protect an enclave connected to an alternate gateway by using an inbound filter that only permits packets with destination addresses within the site's address space.","description":"Enclaves with alternate gateway connections must take additional steps to ensure there is no compromise on the enclave network or NIPRNet. Without verifying the destination address of traffic coming from the site's alternate gateway, the perimeter router could be routing transit data from the Internet into the NIPRNet. This could also make the perimeter router vulnerable to a denial-of-service (DoS) attack as well as provide a back door into the NIPRNet. The DOD enclave must ensure the ingress filter applied to external interfaces on a perimeter router connecting to an Approved Gateway is secure through filters permitting packets with a destination address belonging to the DOD enclave's address block.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the configuration of each router interface connecting to an alternate gateway.\n\nVerify 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.\n\nIf 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.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure 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.","ccis":["CCI-001414"]},{"vulnId":"V-207114","ruleId":"SV-207114r1137919_rule","severity":"high","ruleTitle":"The perimeter router must be configured to not be a Border Gateway Protocol (BGP) peer to an alternate gateway service provider.","description":"ISPs use BGP to share route information with other autonomous systems (i.e., other ISPs and corporate networks). If the perimeter router was configured to BGP peer with an ISP, NIPRnet routes could be advertised to the ISP; thereby creating a backdoor connection from the internet to the NIPRnet.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the configuration of the router connecting to the alternate gateway.\n\nVerify there are no BGP neighbors configured to the remote AS that belongs to the alternate gateway service provider.\n\nIf there are BGP neighbors connecting the remote AS of the alternate gateway service provider, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure a static route on the perimeter router to reach the AS of a router connecting to an alternate gateway.","ccis":["CCI-001414"]},{"vulnId":"V-207115","ruleId":"SV-207115r1137922_rule","severity":"low","ruleTitle":"The perimeter router must be configured to not redistribute static routes to an alternate gateway service provider into Border Gateway Protocol (BGP) or an Interior Gateway Protocol (IGP) peering with the NIPRNet or to other autonomous systems.","description":"If the static routes to the alternate gateway are being redistributed into an Exterior Gateway Protocol or IGP to a NIPRNet gateway, this could make traffic on NIPRNet flow to that particular router and not to the Internet Access Point routers. This could not only wreak havoc with traffic flows on NIPRNet, but it could overwhelm the connection from the router to the NIPRNet gateway(s) and also cause traffic destined for outside of NIPRNet to bypass the defenses of the Internet Access Points.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the configuration of the router connecting to the alternate gateway and verify that redistribution of static routes to the alternate gateway is not occurring. \n\nIf 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.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router so that static routes are not redistributed to an alternate gateway into either an Exterior Gateway Protocol or IGP to the NIPRNet or to other autonomous systems.","ccis":["CCI-001414"]},{"vulnId":"V-207116","ruleId":"SV-207116r1137925_rule","severity":"medium","ruleTitle":"The out-of-band management (OOBM) gateway router must be configured to have separate Interior Gateway Protocol (IGP) instances for the managed network and management network.","description":"If the gateway router is not a dedicated device for the OOBM network, implementation of several safeguards for containment of management and production traffic boundaries must occur. Since the managed and management network are separate routing domains, configuration of separate IGP routing instances is critical on the router to segregate traffic from each network.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nVerify the OOBM interface is an adjacency in the IGP routing domain for the management network.\n\nIf the router does not enforce that IGP instances configured on the OOBM gateway router peer only with their own routing domain, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the router to enforce that IGP instances configured on the OOBM gateway router peer only with their own routing domain.","ccis":["CCI-001414"]},{"vulnId":"V-207117","ruleId":"SV-207117r1137928_rule","severity":"medium","ruleTitle":"The out-of-band management (OOBM) gateway router must be configured to not redistribute routes between the management network routing domain and the managed network routing domain.","description":"If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries; otherwise, it is possible that management traffic will not be separated from production traffic.\n\nSince the managed network and the management network are separate routing domains, separate Interior Gateway Protocol (IGP) routing instances must be configured on the router, one for the managed network and one for the OOBM network. In addition, the routes from the two domains must not be redistributed to each other.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nVerify the IGP instance used for the managed network does not redistribute routes into the IGP instance used for the management network, and vice versa.\n\nIf the IGP instance used for the managed network redistributes routes into the IGP instance used for the management network, or vice versa, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the IGP instance used for the managed network to prohibit redistribution of routes into the IGP instance used for the management network, and vice versa.","ccis":["CCI-001414"]},{"vulnId":"V-207118","ruleId":"SV-207118r1137930_rule","severity":"low","ruleTitle":"The multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Register messages received from the Designated Router (DR) for any undesirable multicast groups and sources.","description":"Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that register messages are accepted only for authorized multicast groups and sources.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the RP router is configured to filter PIM register messages. \n\nIf 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.","fixText":"Configure the RP router to filter PIM register messages received from a multicast DR for any undesirable multicast groups or sources.","ccis":["CCI-001414"]},{"vulnId":"V-207119","ruleId":"SV-207119r1137932_rule","severity":"low","ruleTitle":"The multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the Designated Router (DR) for any undesirable multicast groups.","description":"Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that join messages are only accepted for authorized multicast groups.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the RP router is configured to filter PIM register messages.\n\nNote: Alternative is to configure all designated routers to filter IGMP Membership Report (join) messages received from hosts.\n\nIf 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.","fixText":"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.","ccis":["CCI-001414"]},{"vulnId":"V-207120","ruleId":"SV-207120r604135_rule","severity":"medium","ruleTitle":"The router must be configured to produce audit records containing information to establish where the events occurred.","description":"Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as router components, modules, device identifiers, node names, and functionality.\n\nAssociating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured router.","checkContent":"The router must log all packets that have been dropped via the access control list (ACL). \n\nIf the router fails to log all packets that have been dropped via the ACL, this is a finding.\n\nLog output must contain an interface name as to where the packet was filtered.\n\nIf the logged output does not contain an interface name as to where the packet was filtered, this is a finding.","fixText":"Configure the router to record the interface in the log record for packets being dropped.","ccis":["CCI-000132"]},{"vulnId":"V-207121","ruleId":"SV-207121r604135_rule","severity":"medium","ruleTitle":"The router must be configured to produce audit records containing information to establish the source of the events.","description":"Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event.\n\nIn addition to logging where events occur within the network, the audit records must also identify sources of events such as IP addresses, processes, and node or device names.","checkContent":"The router must log all packets that have been dropped via the access control list.\n\nIf the router fails to log all packets that have been dropped via the control list, this is a finding.\n\nLog output must contain the source IP address and port of the filtered packets.\n\nIf the logged output does not contain source IP address and port of the filtered packets, this is a finding.","fixText":"Configure the router to record the source address in the log record for packets being dropped.","ccis":["CCI-000133"]},{"vulnId":"V-207122","ruleId":"SV-207122r604135_rule","severity":"low","ruleTitle":"The router must be configured to log all packets that have been dropped.","description":"Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being done or attempted to be done, and by whom, to compile an accurate risk assessment. Auditing the actions on network devices provides a means to recreate an attack or identify a configuration mistake on the device.","checkContent":"Review the router interface access control lists (ACLs) to verify all deny statements are logged.\n\nIf packets being dropped are not logged, this is a finding.","fixText":"Configure interface ACLs to log all deny statements.","ccis":["CCI-000134"]},{"vulnId":"V-207123","ruleId":"SV-207123r604135_rule","severity":"low","ruleTitle":"The router must be configured to have all non-essential capabilities disabled.","description":"A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation.","checkContent":"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.\n\nIf unnecessary services and functions are enabled on the router, this is a finding.","fixText":"Remove unneeded services and functions from the router.\n\nRemoval is recommended because the service or function may be inadvertently enabled otherwise.\n\nHowever, if removal is not possible, disable the service or function.","ccis":["CCI-000381"]},{"vulnId":"V-207124","ruleId":"SV-207124r604135_rule","severity":"medium","ruleTitle":"The router must be configured to use encryption for routing protocol authentication.","description":"A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a \"traffic attraction attack\" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack.\n\nThis requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.","checkContent":"Review the router configuration.\n\nFor 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.\n\nIf authentication is not encrypting the authentication key, this is a finding.","fixText":"Configure routing protocol authentication to encrypt the authentication key.","ccis":["CCI-000803"]},{"vulnId":"V-207125","ruleId":"SV-207125r604135_rule","severity":"medium","ruleTitle":"The router must be configured to authenticate all routing protocol messages using NIST-validated FIPS 198-1 message authentication code algorithm.","description":"A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a \"traffic attraction attack\" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack.\n\nSince MD5 is vulnerable to \"birthday\" attacks and may be compromised, routing protocol authentication must use FIPS 198-1 validated algorithms and modules to encrypt the authentication key. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and multicast-related protocols.","checkContent":"Review the router configuration to verify it is using a NIST-validated FIPS 198-1 message authentication code algorithm to authenticate routing protocol messages.\n\nIf a NIST-validated FIPS 198-1 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.","fixText":"Configure routing protocol authentication to use a NIST-validated FIPS 198-1 message authentication code algorithm.","ccis":["CCI-000803"]},{"vulnId":"V-207126","ruleId":"SV-207126r604135_rule","severity":"medium","ruleTitle":"The PE router must be configured to limit the number of MAC addresses it can learn for each Virtual Private LAN Services (VPLS) bridge domain.","description":"VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE routers). A pseudowire contains two unidirectional label-switched paths (LSP). Each MAC forwarding table instance is interconnected using domain-specific LSPs, thereby maintaining privacy and logical separation between each VPLS domain.\n\nWhen a frame arrives on a bridge port (pseudowire or attachment circuit) and the source MAC address is unknown to the receiving PE router, the source MAC address is associated with the pseudowire or attachment circuit and the forwarding table is updated accordingly. Frames are forwarded to the appropriate pseudowire or attachment circuit according to the forwarding table entry for the destination MAC address. Ethernet frames sent to broadcast and unknown destination addresses must be flooded out to all interfaces for the bridge domain; hence, a PE router must replicate packets across both attachment circuits and pseudowires.\n\nA malicious attacker residing in a customer network could launch a source MAC address spoofing attack by flooding packets to a valid unicast destination, each with a different MAC source address. The PE router receiving this traffic would try to learn every new MAC address and would quickly run out of space for the VFI forwarding table. Older, valid MAC addresses would be removed from the table, and traffic sent to them would have to be flooded until the storm threshold limit is reached. Hence, it is essential that a limit is established to control the number of MAC addresses that will be learned and recorded into the forwarding table for each bridge domain.","checkContent":"Review the PE router configuration to determine if a MAC address limit has been set for each bridge domain.\n\nIf a limit has not been configured, this is a finding.","fixText":"Configure a MAC address learning limit for each VPLS bridge domain.","ccis":["CCI-001094"]},{"vulnId":"V-207127","ruleId":"SV-207127r604135_rule","severity":"low","ruleTitle":"The MPLS router with RSVP-TE enabled must be configured with message pacing or refresh reduction to adjust maximum number of RSVP messages to an output queue based on the link speed and input queue size of adjacent core routers.","description":"RSVP-TE can be used to perform constraint-based routing when building LSP tunnels within the network core that will support QoS and traffic engineering requirements. RSVP-TE is also used to enable MPLS Fast Reroute, a network restoration mechanism that will reroute traffic onto a backup LSP in case of a node or link failure along the primary path. When there is a disruption in the MPLS core, such as a link flap or router reboot, the result is a significant amount of RSVP signaling, such as \"PathErr\" and \"ResvErr\" messages that need to be sent for every LSP using that link.\n\nWhen RSVP messages are sent out, they are sent either hop by hop or with the router alert bit set in the IP header. This means that every router along the path must examine the packet to determine if additional processing is required for these RSVP messages. If there is enough signaling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold, resulting in dropped RSVP messages and hence slower RSVP convergence. Increasing the size of the interface input queue can help prevent dropping packets; however, there is still the risk of having a burst of signaling traffic that can fill the queue. Solutions to mitigate this risk are RSVP message pacing or refresh reduction to control the rate at which RSVP messages are sent. RSVP refresh reduction includes the following features: RSVP message bundling, RSVP Message ID to reduce message processing overhead, Reliable delivery of RSVP messages using Message ID,  and summary refresh to reduce the amount of information transmitted every refresh interval.","checkContent":"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.\n\nIf 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.","fixText":"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.","ccis":["CCI-001095"]},{"vulnId":"V-207128","ruleId":"SV-207128r604135_rule","severity":"medium","ruleTitle":"The PE router providing Virtual Private LAN Services (VPLS) must be configured to have traffic storm control thresholds on CE-facing interfaces.","description":"A traffic storm occurs when packets flood a VPLS bridge, creating excessive traffic and degrading network performance. Traffic storm control prevents VPLS bridge disruption by suppressing traffic when the number of packets reaches configured threshold levels. Traffic storm control monitors incoming traffic levels on a port and drops traffic when the number of packets reaches the configured threshold level during any one-second interval.","checkContent":"Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS.\n\nIf storm control is not enabled for broadcast traffic, this is a finding.\n\nNote: 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.","fixText":"Configure storm control for each VPLS bridge domain. Base the suppression threshold on expected traffic rates plus some additional capacity.","ccis":["CCI-001095"]},{"vulnId":"V-207129","ruleId":"SV-207129r604135_rule","severity":"medium","ruleTitle":"The PE router must be configured to enforce a Quality-of-Service (QoS) policy to limit the effects of packet flooding denial-of-service (DoS) attacks.","description":"DoS is a condition when a resource is not available for legitimate users. Packet flooding distributed denial-of-service (DDoS) attacks are referred to as volumetric attacks and have the objective of overloading a network or circuit to deny or seriously degrade performance, which denies access to the services that normally traverse the network or circuit. Volumetric attacks have become relatively easy to launch using readily available tools such as Low Orbit Ion Cannon or botnets. \n\nMeasures to mitigate the effects of a successful volumetric attack must be taken to ensure that sufficient capacity is available for mission-critical traffic. Managing capacity may include, for example, establishing selected network usage priorities or quotas and enforcing them using rate limiting, Quality of Service (QoS), or other resource reservation control methods. These measures may also mitigate the effects of sudden decreases in network capacity that are the result of accidental or intentional physical damage to telecommunications facilities (such as cable cuts or weather-related outages).","checkContent":"Review the router configuration and interview the System Administrator to verify that a mechanism for traffic prioritization and bandwidth reservation exists.\n\nThis arrangement must ensure that sufficient capacity is available for mission-critical traffic and enforce the traffic priorities specified by the Combatant Commands/Services/Agencies.\n\nIf no such scheme exists or it is not configured, this is a finding.","fixText":"Implement a mechanism for traffic prioritization and bandwidth reservation. This mechanism must enforce the traffic priorities specified by the Combatant Commands/Services/Agencies.","ccis":["CCI-001095"]},{"vulnId":"V-207130","ruleId":"SV-207130r604135_rule","severity":"low","ruleTitle":"The PE router must be configured to enforce a Quality-of-Service (QoS) policy in accordance with the QoS DoDIN Technical Profile.","description":"Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy.\n\nPacket markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.","checkContent":"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. \n\nVerify that the class-maps are configured to match on DSCP, protocols, or access control lists (ACLs) that identify traffic types based on ports. \n\nVerify that the policy-map is configured to set DSCP values for the defined class-maps in accordance with the QoS GIG Technical Profile. \n\nVerify that an output service policy is bound to all interfaces. \n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link:\nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\nIf the router is not configured to implement a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.","fixText":"Configure a QoS policy on each router in accordance with the QoS GIG Technical Profile.","ccis":["CCI-001095"]},{"vulnId":"V-207131","ruleId":"SV-207131r604135_rule","severity":"low","ruleTitle":"The P router must be configured to enforce a Quality-of-Service (QoS) policy in accordance with the QoS GIG Technical Profile.","description":"Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy.\n\nPacket markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.","checkContent":"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. \n\nVerify that the class-maps are configured to match on DSCP, protocols, or access control lists (ACLs) that identify traffic types based on ports. \n\nVerify that the policy-map is configured to set DSCP values for the defined class-maps in accordance with the QoS GIG Technical Profile. \n\nVerify that an input service policy is bound to all interfaces. \n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link:\nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\n\nIf the router is not configured to implement a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.","fixText":"Configure a QoS policy on each router in accordance with the QoS GIG Technical Profile.","ccis":["CCI-001095"]},{"vulnId":"V-207132","ruleId":"SV-207132r1137935_rule","severity":"high","ruleTitle":"The perimeter router must be configured to deny network traffic by default and allow network traffic by exception.","description":"A deny-all, permit-by-exception network communications traffic policy ensures only connections that are essential and approved are allowed.\n\nThis requirement applies to both inbound and outbound network communications traffic. All inbound and outbound traffic must be denied by default. Firewalls and perimeter routers should only allow traffic through that is explicitly permitted. The initial defense for the internal network is to block any traffic at the perimeter attempting to make a connection to a host residing on the internal network. In addition, allowing unknown or undesirable outbound traffic by the firewall or router will establish a state that will permit the return of this undesirable traffic inbound.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview 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.\n\nThe filter must be configured inbound on all external interfaces.\n\nIf the ACL or filter is not configured to allow specific ports and protocols and deny all other traffic, this is a finding.\n\nIf the filter is not configured inbound on all external interfaces, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\nConfigure the perimeter router to deny network traffic by default and allow network traffic by exception.","ccis":["CCI-001109"]},{"vulnId":"V-207133","ruleId":"SV-207133r604135_rule","severity":"high","ruleTitle":"The router must be configured to restrict traffic destined to itself.","description":"The route processor handles traffic destined to the router—the key component used to build forwarding paths and is also instrumental with all network management functions. Hence, any disruption or DoS attack to the route processor can result in mission critical network outages.","checkContent":"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.\n\nIf the router is not configured with a receive-path filter to restrict traffic destined to itself, this is a finding.\n\nNote: 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.","fixText":"Configure all routers with receive path filters to restrict traffic destined to the router.","ccis":["CCI-001097"]},{"vulnId":"V-207134","ruleId":"SV-207134r604135_rule","severity":"medium","ruleTitle":"The router must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.","description":"Fragmented ICMP packets can be generated by hackers for DoS attacks such as Ping O' Death and Teardrop. It is imperative that all fragmented ICMP packets are dropped.","checkContent":"Review the access control list (ACL) or filter for the router receive path.\n\nVerify that it will drop all fragmented ICMP packets destined to itself.\n\nIf the router is not configured with a receive-path filter to drop all fragmented ICMP packets, this is a finding.\n\nNote: 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.","fixText":"Ensure all routers have their receive path filter configured to drop all fragmented ICMP packets.","ccis":["CCI-001097"]},{"vulnId":"V-207135","ruleId":"SV-207135r604135_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoD Instruction 8551.1.","description":"Vulnerability assessments must be reviewed by the System Administrator, and protocols must be approved by the Information Assurance (IA) staff before entering the enclave.\n\nAccess control lists (ACLs) are the first line of defense in a layered security approach. They permit authorized packets and deny unauthorized packets based on port or service type. They enhance the posture of the network by not allowing packets to reach a potential target within the security domain. The lists provided are highly susceptible ports and services that should be blocked or limited as much as possible without adversely affecting customer requirements. Auditing packets attempting to penetrate the network but that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation.\n\nIf the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with DoD Instruction 8551.1, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to PPS being blocked would be satisfied.","checkContent":"This requirement is not applicable for the DoDIN Backbone. \n\nReview the router configuration to verify that the ingress filter is in accordance with DoD 8551. \n\nIf the router does not filter traffic in accordance with the guidelines contained in DoD 8551, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure 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.","ccis":["CCI-001097"]},{"vulnId":"V-207136","ruleId":"SV-207136r604135_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to filter ingress traffic at the external interface on an inbound direction.","description":"Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that the ingress ACL is bound to the external interface in an inbound direction.\n\nIf the router is not configured to filter traffic entering the network at the external interface in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nBind the ingress ACL to the external interface (inbound).","ccis":["CCI-001097"]},{"vulnId":"V-207137","ruleId":"SV-207137r604135_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to filter egress traffic at the internal interface on an inbound direction.","description":"Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DoDIN Backbone. \n\nReview the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. \n\nIf the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure an egress ACL bound to the internal interface in an inbound direction to filter traffic leaving the network.","ccis":["CCI-001097"]},{"vulnId":"V-207138","ruleId":"SV-207138r604135_rule","severity":"medium","ruleTitle":"The BGP router must be configured to reject outbound route advertisements for any prefixes belonging to the IP core.","description":"Outbound route advertisements belonging to the core can result in traffic either looping or being black holed, or at a minimum, using a non-optimized path.","checkContent":"Review the router configuration to verify that there is a filter defined to block route advertisements for prefixes that belong to the IP core. \n\nThe prefix filter must be referenced outbound on the appropriate BGP neighbor statements.\n\nIf the router is not configured to reject outbound route advertisements that belong to the IP core, this is a finding.","fixText":"Configure all eBGP routers to filter outbound route advertisements belonging to the IP core.","ccis":["CCI-001097"]},{"vulnId":"V-207139","ruleId":"SV-207139r604135_rule","severity":"high","ruleTitle":"The PE router must be configured to block any traffic that is destined to IP core infrastructure.","description":"IP/MPLS networks providing VPN and transit services must provide, at the least, the same level of protection against denial-of-service (DoS) attacks and intrusions as Layer 2 networks. Although the IP core network elements are hidden, security should never rely entirely on obscurity.\n\nIP addresses can be guessed. Core network elements must not be accessible from any external host. Protecting the core from any attack is vital for the integrity and privacy of customer traffic as well as the availability of transit services. A compromise of the IP core can result in an outage or, at a minimum, non-optimized forwarding of customer traffic. Protecting the core from an outside attack also prevents attackers from using the core to attack any customer. Hence, it is imperative that all routers at the edge deny traffic destined to any address belonging to the IP core infrastructure.","checkContent":"Review the router configuration to verify that an ingress ACL is applied to all CE-facing interfaces. \n\nVerify that the ingress ACL rejects and logs packets destined to the IP core address block. \n\nIf the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding.\n\nNote: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent peers.","fixText":"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.","ccis":["CCI-001097"]},{"vulnId":"V-207140","ruleId":"SV-207140r604135_rule","severity":"medium","ruleTitle":"The PE router must be configured with Unicast Reverse Path Forwarding (uRPF) loose mode enabled on all CE-facing interfaces..","description":"The uRPF feature is a defense against spoofing and denial-of-service (DoS) attacks by verifying if the source address of any ingress packet is reachable. To mitigate attacks that rely on forged source addresses, all provider edge routers must enable uRPF loose mode to guarantee that all packets received from a CE router contain source addresses that are in the route table.","checkContent":"Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces.\n\nIf uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.","fixText":"Enable uRPF loose mode on all CE-facing interfaces.","ccis":["CCI-001097"]},{"vulnId":"V-207141","ruleId":"SV-207141r604135_rule","severity":"medium","ruleTitle":"The out-of-band management (OOBM) gateway must be configured to transport management traffic to the Network Operations Center (NOC) via dedicated circuit, MPLS/VPN service, or IPsec tunnel.","description":"Using dedicated paths, the OOBM backbone connects the OOBM gateway routers located at the edge of the managed network and at the NOC. Dedicated links can be deployed using provisioned circuits or MPLS Layer 2 and Layer 3 VPN services or implementing a secured path with gateway-to-gateway IPsec tunnels. The tunnel mode ensures that the management traffic will be logically separated from any other traffic traversing the same path.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC.\n\nReview the OOBM gateway router configuration to validate the path and interface that the management traffic traverses.\n\nIf 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.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nEnsure that a dedicated circuit, MPLS/VPN service, or IPsec tunnel is deployed to transport management traffic between the managed network and the NOC.","ccis":["CCI-001097"]},{"vulnId":"V-207142","ruleId":"SV-207142r604135_rule","severity":"medium","ruleTitle":"The out-of-band management (OOBM) gateway router must be configured to forward only authorized management traffic to the Network Operations Center (NOC).","description":"The OOBM network is an IP network used exclusively for the transport of OAM&P data from the network being managed to the OSS components located at the NOC. Its design provides connectivity to each managed network device, enabling network management traffic to flow between the managed network elements and the NOC. This allows the use of paths separate from those used by the managed network.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC.\n\nReview the OOBM gateway router configuration to validate the path that the management traffic traverses.\n\nVerify that only management traffic is forwarded through the OOBM interface or IPsec tunnel.\n\nIf traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure 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.","ccis":["CCI-001097"]},{"vulnId":"V-207143","ruleId":"SV-207143r604135_rule","severity":"medium","ruleTitle":"The out-of-band management (OOBM) gateway router must be configured to block any traffic destined to itself that is not sourced from the OOBM network or the NOC.","description":"If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. It is imperative that hosts from the managed network are not able to access the OOBM gateway router.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the access control list (ACL) or filter for the router receive path.\n\nVerify that only traffic sourced from the OOBM network or the NOC is allowed to access the router.\n\nIf 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.\n\nNote: 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.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nEnsure that traffic from the managed network is not able to access the OOBM gateway router using either receive path or interface ingress ACLs.","ccis":["CCI-001097"]},{"vulnId":"V-207144","ruleId":"SV-207144r604135_rule","severity":"medium","ruleTitle":"The router must be configured to only permit management traffic that ingresses and egresses the OOBM interface.","description":"The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network.\n\nAn OOBM interface does not forward transit traffic, thereby providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.","checkContent":"Step 1: Verify that the managed interface has an inbound and outbound ACL configured.  \n\nStep 2: Verify that the ingress filter only allows management, IGP, and ICMP traffic.\n\nCaveat: If the management interface is a true OOBM interface, this requirement is not applicable.\n\nIf the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.","fixText":"If the management interface is a routed interface, it must be configured with both an ingress and egress ACL.","ccis":["CCI-001097"]},{"vulnId":"V-207145","ruleId":"SV-207145r604135_rule","severity":"medium","ruleTitle":"The router providing connectivity to the NOC must be configured to forward all in-band management traffic via an IPsec tunnel.","description":"When the production network is managed in-band, the management network could be housed at a NOC that is located remotely at single or multiple interconnected sites. NOC interconnectivity, as well as connectivity between the NOC and the managed network, must be enabled using IPsec tunnels to provide the separation and integrity of the managed traffic.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nVerify that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel.\n\nIf the management traffic is not secured via IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nEnsure that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel.","ccis":["CCI-001097"]},{"vulnId":"V-207146","ruleId":"SV-207146r604135_rule","severity":"medium","ruleTitle":"The router must be configured to stop forwarding traffic upon the failure of the following actions: system initialization, shutdown, or system abort.","description":"Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Routers that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes.\n\nIf the router fails in an unsecure manner (open), unauthorized traffic originating externally to the enclave may enter, or the device may permit unauthorized information release. Fail secure is a condition achieved by employing information system mechanisms to ensure, in the event of a device initialization failure, a device shutdown failure, or an abort failure of the router, that it does not enter into an unsecure state where intended security properties no longer hold.\n\nIf the device fails, it must not fail in a manner that will allow unauthorized access. If the router fails for any reason, it must stop forwarding traffic altogether or maintain the configured security policies. If the device stops forwarding traffic, maintaining network availability would be achieved through device redundancy.\n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the router component. Compliance can be verified by acceptance/validation processes or vendor attestation.","checkContent":"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.\n\nIf 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.","fixText":"This is a capability that would be intrinsic to the router as a result of its development and may not be configurable.\n\nIf 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.","ccis":["CCI-001190"]},{"vulnId":"V-207147","ruleId":"SV-207147r856631_rule","severity":"medium","ruleTitle":"The PE router providing MPLS Layer 2 Virtual Private Network (L2VPN) services must be configured to authenticate targeted Label Distribution Protocol (LDP) sessions used to exchange virtual circuit (VC) information using a FIPS-approved message authentication code algorithm.","description":"LDP provides the signaling required for setting up and tearing down pseudowires (virtual circuits used to transport Layer 2 frames) across an MPLS IP core network. Using a targeted LDP session, each PE router advertises a virtual circuit label mapping that is used as part of the label stack imposed on the frames by the ingress PE router during packet forwarding. Authentication provides protection against spoofed TCP segments that can be introduced into the LDP sessions.","checkContent":"Review the router configuration to determine if LDP messages are being authenticated for the targeted LDP sessions.\n\nIf authentication is not being used for the LDP sessions using a FIPS-approved message authentication code algorithm, this is a finding.","fixText":"Implement authentication for all targeted LDP sessions using a FIPS-approved message authentication code algorithm.","ccis":["CCI-001958"]},{"vulnId":"V-207148","ruleId":"SV-207148r856632_rule","severity":"medium","ruleTitle":"The Multicast Source Discovery Protocol (MSDP) router must be configured to authenticate all received MSDP packets.","description":"MSDP peering with customer network routers presents additional risks to the core, whether from a rogue or misconfigured MSDP-enabled router. MSDP password authentication is used to validate each segment sent on the TCP connection between MSDP peers, protecting the MSDP session against the threat of spoofed packets being injected into the TCP connection stream.","checkContent":"Review the router configuration to determine if received MSDP packets are authenticated.\n\nIf the router does not require MSDP authentication, this is a finding.","fixText":"Ensure all MSDP packets received by an MSDP router are authenticated.","ccis":["CCI-001958"]},{"vulnId":"V-207149","ruleId":"SV-207149r856633_rule","severity":"medium","ruleTitle":"The router must not be configured to have any zero-touch deployment feature enabled when connected to an operational network.","description":"Network devices that are configured via a zero-touch deployment or auto-loading feature can have their startup configuration or image pushed to the device for installation via TFTP or Remote Copy (rcp). Loading an image or configuration file from the network is taking a security risk because the file could be intercepted by an attacker who could corrupt the file, resulting in a denial of service.","checkContent":"Review the device configuration to determine if a configuration auto-loading or zero-touch deployment feature is enabled.\n\nIf a configuration auto-loading feature or zero-touch deployment feature is enabled, this is a finding.\n\nNote: 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.","fixText":"Disable all configuration auto-loading or zero-touch deployment features.","ccis":["CCI-002385"]},{"vulnId":"V-207150","ruleId":"SV-207150r856634_rule","severity":"medium","ruleTitle":"The router must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection.","description":"The Route Processor (RP) is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Any disruption to the RP or the control and management planes can result in mission-critical network outages.\n\nA DoS attack targeting the RP can result in excessive CPU and memory utilization. To maintain network stability and RP security, the router must be able to handle specific control plane and management plane traffic that is destined to the RP. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grows. Control plane policing increases the security of routers and multilayer switches by protecting the RP from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.","checkContent":"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.\n\nIf the router does not have control plane protection implemented, this is a finding.","fixText":"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.","ccis":["CCI-002385"]},{"vulnId":"V-207151","ruleId":"SV-207151r856635_rule","severity":"medium","ruleTitle":"The router must be configured to have Gratuitous ARP disabled on all external interfaces.","description":"A gratuitous ARP is an ARP broadcast in which the source and destination MAC addresses are the same. It is used to inform the network about a host IP address. A spoofed gratuitous ARP message can cause network mapping information to be stored incorrectly, causing network malfunction.","checkContent":"Review the configuration to determine if gratuitous ARP is disabled on all external interfaces.\n\nIf gratuitous ARP is enabled on any external interface, this is a finding.","fixText":"Disable gratuitous ARP on all external interfaces.","ccis":["CCI-002385"]},{"vulnId":"V-207152","ruleId":"SV-207152r856636_rule","severity":"low","ruleTitle":"The router must be configured to have IP directed broadcast disabled on all interfaces.","description":"An IP directed broadcast is a datagram sent to the broadcast address of a subnet that is not directly attached to the sending machine. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, which is connected directly to the target subnet, can conclusively identify a directed broadcast.\n\nIP directed broadcasts are used in the extremely common and popular smurf, or denial-of-service (DoS), attacks. In a smurf attack, the attacker sends Internet Control Message Protocol (ICMP) echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified. This service should be disabled on all interfaces when not needed to prevent smurf and DoS attacks.\n\nDirected broadcast can be enabled on internal facing interfaces to support services such as Wake-On-LAN. Case scenario may also include support for legacy applications where the content server and the clients do not support multicast. The content servers send streaming data using UDP broadcast. Used in conjunction with the IP multicast helper-map feature, broadcast data can be sent across a multicast topology. The broadcast streams are converted to multicast and vice versa at the first-hop routers and last-hop routers before entering and leaving the multicast transit area respectively. The last-hop router must convert the multicast to broadcast. Hence, this interface must be configured to forward a broadcast packet (i.e., a directed broadcast address is converted to the all nodes broadcast address).","checkContent":"Review the router configuration to determine if IP directed broadcast is enabled.\n\nIf IP directed broadcast is enabled on Layer 3 interfaces, this is a finding.","fixText":"Disable IP directed broadcasts on all Layer 3 interfaces.","ccis":["CCI-002385"]},{"vulnId":"V-207153","ruleId":"SV-207153r856637_rule","severity":"medium","ruleTitle":"The router must be configured to have Internet Control Message Protocol (ICMP) unreachable notifications disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"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.\n\nIf ICMP unreachable notifications are enabled on any external interfaces, this is a finding.","fixText":"Disable ICMP unreachable notifications on all external interfaces.","ccis":["CCI-002385"]},{"vulnId":"V-207154","ruleId":"SV-207154r856638_rule","severity":"medium","ruleTitle":"The router must be configured to have Internet Control Message Protocol (ICMP) mask replies disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"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.\n\nIf ICMP Mask Reply messages are enabled on any external interfaces, this is a finding.","fixText":"Disable ICMP mask replies on all external interfaces.","ccis":["CCI-002385"]},{"vulnId":"V-207155","ruleId":"SV-207155r856639_rule","severity":"medium","ruleTitle":"The router must be configured to have Internet Control Message Protocol (ICMP) redirects disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"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.\n\nIf ICMP Redirect messages are enabled on any external interfaces, this is a finding.","fixText":"Disable ICMP redirects on all external interfaces.","ccis":["CCI-002385"]},{"vulnId":"V-207156","ruleId":"SV-207156r856640_rule","severity":"medium","ruleTitle":"The BGP router must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.","description":"The effects of prefix de-aggregation 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 de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.\n\nIn 1997, misconfigured routers in the Florida Internet Exchange network (AS7007) de-aggregated 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 would again overwhelm the routers and cause them to crash. This process of route flapping served to destabilize 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.\n\nMaximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation 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 AS. Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected.","checkContent":"Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled.\n\nIf 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.","fixText":"Configure all eBGP routers to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.","ccis":["CCI-002385"]},{"vulnId":"V-207157","ruleId":"SV-207157r856641_rule","severity":"low","ruleTitle":"The BGP router must be configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer.","description":"The effects of prefix de-aggregation 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 de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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.\n\nIf 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.","fixText":"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.","ccis":["CCI-002385"]},{"vulnId":"V-207158","ruleId":"SV-207158r856642_rule","severity":"low","ruleTitle":"The PE router must be configured to implement Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) snooping for each Virtual Private LAN Services (VPLS) bridge domain.","description":"IGMP snooping provides a way to constrain multicast traffic at Layer 2. By monitoring the IGMP membership reports sent by hosts within the bridge domain, the snooping application can set up Layer 2 multicast forwarding tables to deliver traffic only to ports with at least one interested member within the VPLS bridge, thereby significantly reducing the volume of multicast traffic that would otherwise flood an entire VPLS bridge domain. The IGMP snooping operation applies to both access circuits and pseudowires within a VPLS bridge domain.","checkContent":"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).\n\nIf the router is not configured to implement IGMP or MLD snooping for each VPLS bridge domain, this is a finding.","fixText":"Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VPLS bridge domain.","ccis":["CCI-002385"]},{"vulnId":"V-207159","ruleId":"SV-207159r856643_rule","severity":"low","ruleTitle":"The multicast Rendezvous Point (RP) router must be configured to limit the multicast forwarding cache so that its resources are not saturated by managing an overwhelming number of Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) source-active entries.","description":"MSDP peering between networks enables sharing of multicast source information. Enclaves with an existing multicast topology using PIM-SM can configure their RP routers to peer with MSDP routers. As a first step of defense against a denial-of-service (DoS) attack, all RP routers must limit the multicast forwarding cache to ensure that router resources are not saturated managing an overwhelming number of PIM and MSDP source-active entries.","checkContent":"Review the router configuration to determine if forwarding cache thresholds are defined.\n\nIf the RP router is not configured to limit the multicast forwarding cache to ensure that its resources are not saturated, this is a finding.","fixText":"Configure MSDP-enabled RP routers to limit the multicast forwarding cache for source-active entries.","ccis":["CCI-002385"]},{"vulnId":"V-207160","ruleId":"SV-207160r856644_rule","severity":"medium","ruleTitle":"The multicast Rendezvous Point (RP) must be configured to rate limit the number of Protocol Independent Multicast (PIM) Register messages.","description":"When a new source starts transmitting in a PIM Sparse Mode network, the DR will encapsulate the multicast packets into register messages and forward them to the RP using unicast. This process can be taxing on the CPU for both the DR and the RP if the source is running at a high data rate and there are many new sources starting at the same time. This scenario can potentially occur immediately after a network failover. The rate limit for the number of register messages should be set to a relatively low value based on the known number of multicast sources within the multicast domain.","checkContent":"Review the configuration of the RP to verify that it is rate limiting the number of multicast register messages.\n\nIf the RP is not limiting multicast register messages, this is a finding.","fixText":"Configure the RP to rate limit the number of multicast register messages.","ccis":["CCI-002385"]},{"vulnId":"V-207161","ruleId":"SV-207161r856645_rule","severity":"medium","ruleTitle":"The multicast Designated Router (DR) must be configured to limit the number of mroute states resulting from Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Host Membership Reports.","description":"The current multicast paradigm can let any host join any multicast group at any time by sending an IGMP or MLD membership report to the DR. In a Protocol Independent Multicast (PIM) Sparse Mode network, the DR will send a PIM Join message for the group to the RP. Without any form of admission control, this can pose a security risk to the entire multicast domain - specifically the multicast routers along the shared tree from the DR to the RP that must maintain the mroute state information for each group join request. Hence, it is imperative that the DR is configured to limit the number of mroute state information that must be maintained to mitigate the risk of IGMP or MLD flooding.","checkContent":"Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD.\n\nIf the DR is not limiting multicast join requests via IGMP or MLD, this is a finding.\n\nNote: 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.","fixText":"Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.","ccis":["CCI-002385"]},{"vulnId":"V-207162","ruleId":"SV-207162r945856_rule","severity":"medium","ruleTitle":"The multicast Designated Router (DR) must be configured to increase the shortest-path tree (SPT) threshold or set it to infinity to minimalize source-group (S, G) state within the multicast topology where Any Source Multicast (ASM) is deployed.","description":"ASM can have many sources for the same groups (many-to-many). For many receivers, the path via the RP may not be ideal compared with the shortest path from the source to the receiver. By default, the last-hop router will initiate a switch from the shared tree to a source-specific SPT to obtain lower latencies. This is accomplished by the last-hop router sending an (S, G) Protocol Independent Multicast (PIM) Join toward S (the source).\n\nWhen the last-hop router begins to receive traffic for the group from the source via the SPT, it will send a PIM Prune message to the RP for the (S, G). The RP will then send a Prune message toward the source. The SPT switchover becomes a scaling issue for large multicast topologies that have many receivers and many sources for many groups because (S, G) entries require more memory than (*, G). Hence, it is imperative to minimize the amount of (S, G) state to be maintained by increasing the threshold that determines when the SPT switchover occurs.","checkContent":"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). \n\nIf any multicast router is not configured to increase the SPT threshold or set to infinity to minimalize (S, G) state, this is a finding.","fixText":"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.","ccis":["CCI-002385"]},{"vulnId":"V-207163","ruleId":"SV-207163r856646_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to only allow incoming communications from authorized sources to be routed to authorized destinations.","description":"Unrestricted traffic may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.\n\nTraffic can be restricted directly by an access control list (ACL), which is a firewall function, or by Policy Routing. Policy Routing is a technique used to make routing decisions based on a number of different criteria other than just the destination network, including source or destination network, source or destination address, source or destination port, protocol, packet size, and packet classification. This overrides the router's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table.\n\nThis requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to determine if the router allows only incoming communications from authorized sources to be routed to authorized destinations.\n\nIf the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to allow only incoming communications from authorized sources to be routed to authorized destinations.","ccis":["CCI-002403"]},{"vulnId":"V-207164","ruleId":"SV-207164r856649_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to block inbound packets with source Bogon IP address prefixes.","description":"Bogons include IP packets on the public Internet that contain addresses that are not in any range allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated regional Internet registry (RIR) and allowed for public Internet use. Bogons also include multicast, IETF reserved, and special purpose address space as defined in RFC 6890.\nSecurity of the Internet's routing system relies on the ability to authenticate an assertion of unique control of an address block. Measures to authenticate such assertions rely on the validation the address block forms as part of an existing allocated address block, and must be a trustable and unique reference in the IANA address registries. The intended use of a Bogon address would only be for the purpose of address spoofing in denial-of-service attacks. Hence, it is imperative that IP packets with a source Bogon address are blocked at the network’s perimeter.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nVerify that the ingress filter is blocking packets with Bogon source addresses. \n\nReview the router configuration to verify that it is configured to block IP packets with a Bogon source address.\n\nIPv4 Bogon Prefixes\n\n0.0.0.0/8\n10.0.0.0/8\n100.64.0.0/10\n127.0.0.0/8\n169.254.0.0/16\n172.16.0.0/12\n192.0.0.0/24\n192.0.2.0/24  \n192.88.99.0/24\n192.168.0.0/16\n198.18.0.0/15 |\n198.51.100.0/24\n203.0.113.0/24 \n224.0.0.0/4 \n240.0.0.0/4\n\n\nIPv6 Bogon Prefixes\n\n::/128\n::1/128\n0::/96\n::ffff:0:0/96 \n3ffe::/16 \n64:ff9b::/96  \n100::/64   \n2001:10::/28   \n2001:db8::/32   \n2001:2::/48  \n2001::/32  \n2001::/23 \n2002::/16   \nfc00::/7 \nfec0::/10  \nff00::/8\n \n    \nIf the router is not configured to block inbound IP packets containing a Bogon source address, this is a finding.\n\nNote: 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. \n\nThe 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\n\nThe 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","fixText":"This requirement is not applicable for the DODIN Backbone. \n\nConfigure the router to block inbound packets with Bogon source addresses.","ccis":["CCI-002403"]},{"vulnId":"V-207165","ruleId":"SV-207165r856650_rule","severity":"low","ruleTitle":"The perimeter router must be configured to have Link Layer Discovery Protocols (LLDPs) disabled on all external interfaces.","description":"LLDPs are primarily used to obtain protocol addresses of neighboring devices and discover platform capabilities of those devices. Use of SNMP with the LLDP Management Information Base (MIB) allows network management applications to learn the device type and the SNMP agent address of neighboring devices, thereby enabling the application to send SNMP queries to those devices. LLDPs are also media- and protocol-independent as they run over the data link layer; therefore, two systems that support different network-layer protocols can still learn about each other. Allowing LLDP messages to reach external network nodes is dangerous as it provides an attacker a method to obtain information of the network infrastructure that can be useful to plan an attack.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview 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).\n\nIf LLDPs are configured globally or on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nDisable LLDPs on all external interfaces.","ccis":["CCI-002403"]},{"vulnId":"V-207166","ruleId":"SV-207166r856651_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to have Proxy ARP disabled on all external interfaces.","description":"When Proxy ARP is enabled on a Cisco router, it allows that router to extend the network (at Layer 2) across multiple interfaces (LAN segments). Because proxy ARP allows hosts from different LAN segments to look like they are on the same segment, proxy ARP is only safe when used between trusted LAN segments. Attackers can leverage the trusting nature of proxy ARP by spoofing a trusted host and then intercepting packets. Proxy ARP should always be disabled on router interfaces that do not require it, unless the router is being used as a LAN bridge.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to determine if IP Proxy ARP is disabled on all external interfaces.\n\nIf IP Proxy ARP is enabled on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nDisable IP Proxy ARP on all external interfaces.","ccis":["CCI-002403"]},{"vulnId":"V-207167","ruleId":"SV-207167r945857_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to block all outbound management traffic.","description":"For in-band management, the management network must have its own subnet in order to enforce control and access boundaries provided by Layer 3 network nodes, such as routers and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. Safeguards must be implemented to ensure that the management traffic does not leak past the perimeter of the managed network.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nThe 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.\n\nIf management traffic is not blocked at the perimeter, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the perimeter router of the managed network with an ACL or filter on the egress interface to block all outbound management traffic.","ccis":["CCI-002403"]},{"vulnId":"V-207168","ruleId":"SV-207168r856652_rule","severity":"low","ruleTitle":"The multicast Designated Router (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join only multicast groups that have been approved by the organization.","description":"Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.","checkContent":"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.\n\nNote: 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.\n\nIf the DR is not filtering IGMP or MLD report messages, this is a finding.","fixText":"Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups that have been approved.","ccis":["CCI-002403"]},{"vulnId":"V-207169","ruleId":"SV-207169r856653_rule","severity":"medium","ruleTitle":"The multicast Designated Router (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join a multicast group only from sources that have been approved by the organization.","description":"Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.","checkContent":"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.\n\nNote: This requirement is only applicable to Source Specific Multicast (SSM) implementation\n\nIf the DR is not filtering IGMP or MLD report messages, this is a finding.","fixText":"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.","ccis":["CCI-002403"]},{"vulnId":"V-207170","ruleId":"SV-207170r856654_rule","severity":"medium","ruleTitle":"The Multicast Source Discovery Protocol (MSDP) router must be configured to only accept MSDP packets from known MSDP peers.","description":"MSDP peering with customer network routers presents additional risks to the DISN Core, whether from a rogue or misconfigured MSDP-enabled router. To guard against an attack from malicious MSDP traffic, the receive path or interface filter for all MSDP-enabled RP routers must be configured to only accept MSDP packets from known MSDP peers.","checkContent":"Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers.\n\nIf the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.","fixText":"Ensure the receive path or interface filter for all MSDP routers only accepts MSDP packets from known MSDP peers.","ccis":["CCI-002403"]},{"vulnId":"V-207171","ruleId":"SV-207171r1137965_rule","severity":"medium","ruleTitle":"The router must be configured to fail securely in the event of an operational failure.","description":"If the router fails in an unsecure manner (open), unauthorized traffic originating externally to the enclave may enter or the device may permit unauthorized information release. Fail secure is a condition achieved by employing information system mechanisms to ensure, in the event of an operational failure of the router, that it does not enter into an unsecure state where intended security properties no longer hold.\n\nIf the device fails, it must not fail in a manner that will allow unauthorized access. If the router fails for any reason, it must stop forwarding traffic altogether or maintain the configured security policies. If the device stops forwarding traffic, maintaining network availability would be achieved through device redundancy.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Review the documentation of the router or interview the system administrator.\n\nVerify the router fails securely in the event of an operational failure.\n\nIf it cannot fail securely, this is a finding.","fixText":"This is a capability that would be intrinsic to the router as a result of its development and may not be configurable.\n\nIf it is a configurable option, configure the device to fail securely in the event of an operational failure.","ccis":["CCI-001126"]},{"vulnId":"V-207172","ruleId":"SV-207172r604135_rule","severity":"low","ruleTitle":"The BGP router must be configured to use its loopback address as the source address for iBGP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router’s loopback address instead of the numerous physical interface addresses.\n\nWhen the loopback address is used as the source for eBGP peering, the BGP session will be harder to hijack since the source address to be used is not known globally—making it more difficult for a hacker to spoof an eBGP neighbor. By using traceroute, a hacker can easily determine the addresses for an eBGP speaker when the IP address of an external interface is used as the source address. The routers within the iBGP domain should also use loopback addresses as the source address when establishing BGP sessions.","checkContent":"Review the router configuration to verify that a loopback address has been configured.\n\nVerify that a loopback interface is used as the source address for all iBGP sessions.\n\nIf the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.","fixText":"Ensure that the router’s loopback address is used as the source address when originating traffic.","ccis":["CCI-000366"]},{"vulnId":"V-207173","ruleId":"SV-207173r604135_rule","severity":"low","ruleTitle":"The MPLS router must be configured to use its loopback address as the source address for LDP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of backbone routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of from a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses.","checkContent":"Review the router configuration to determine if it uses its loopback address as the source address for LDP peering sessions.\n\nVerify that a loopback address has been configured as shown in the following example:\n\nAn 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.\n\nIf the router is not configured do use its loopback address for LDP peering, this is a finding.","fixText":"Configure MPLS routers to use their loopback address as the source address for LDP peering sessions.","ccis":["CCI-000366"]},{"vulnId":"V-207174","ruleId":"SV-207174r604135_rule","severity":"low","ruleTitle":"The MPLS router must be configured to synchronize IGP and LDP to minimize packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.","description":"Packet loss can occur when an IGP adjacency is established and the router begins forwarding packets using the new adjacency before the LDP label exchange completes between the peers on that link. Packet loss can also occur if an LDP session closes and the router continues to forward traffic using the link associated with the LDP peer rather than an alternate pathway with a fully synchronized LDP session. The MPLS LDP-IGP Synchronization feature provides a means to synchronize LDP with OSPF or IS-IS to minimize MPLS packet loss. When an IGP adjacency is established on a link but LDP-IGP synchronization is not yet achieved or is lost, the IGP will advertise the max-metric on that link.","checkContent":"Review the router OSPF or IS-IS configuration.\n\nVerify that LDP will synchronize with the link-state routing protocol.\n\nIf the router is not configured to synchronize IGP and LDP, this is a finding.","fixText":"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.","ccis":["CCI-000366"]},{"vulnId":"V-207175","ruleId":"SV-207175r604135_rule","severity":"medium","ruleTitle":"The MPLS router must be configured to have TTL Propagation disabled.","description":"The head end of the label-switched path (LSP), the label edge router (LER) will decrement the IP packet's time-to-live (TTL) value by one and then copy the value to the MPLS TTL field. At each label-switched router (LSR) hop, the MPLS TTL value is decremented by one. The MPLS router that pops the label (either the penultimate LSR or the egress LER) will copy the packet's MPLS TTL value to the IP TTL field and decrement it by one.\n\nThis TTL propagation is the default behavior. Because the MPLS TTL is propagated from the IP TTL, a traceroute will list every hop in the path, be it routed or label switched, thereby exposing core nodes. With TTL propagation disabled, LER decrements the IP packet's TTL value by one and then places a value of 255 in the packet's MPLS TTL field, which is then decremented by one as the packet passes through each LSR in the MPLS core. Because the MPLS TTL never drops to zero, none of the LSP hops triggers an ICMP TTL exceeded message and consequently, these hops are not recorded in a traceroute. Hence, nodes within the MPLS core cannot be discovered by an attacker.","checkContent":"Review the router configuration to verify that TTL propagation is disabled.\n\nIf the router is not configured to disable TTL propagation, this is a finding.","fixText":"Configure LERs to disable TTL propagation.","ccis":["CCI-000366"]},{"vulnId":"V-207176","ruleId":"SV-207176r604135_rule","severity":"high","ruleTitle":"The PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.","description":"The primary security model for an MPLS L3VPN infrastructure is traffic separation. The service provider must guarantee the customer that traffic from one VPN does not leak into another VPN or into the core, and that core traffic must not leak into any VPN. Hence, it is imperative that each CE-facing interface can only be associated to one VRF—that alone is the fundamental framework for traffic separation.","checkContent":"Review the design plan for deploying L3VPN and VRF-lite. \n\nReview all CE-facing interfaces and verify that the proper VRF is defined.\n\nIf any VRFs are not bound to the appropriate physical or logical interface, this is a finding.","fixText":"Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.","ccis":["CCI-000366"]},{"vulnId":"V-207177","ruleId":"SV-207177r604135_rule","severity":"high","ruleTitle":"The PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance with the appropriate Route Target (RT).","description":"The primary security model for an MPLS L3VPN as well as a VRF-lite infrastructure is traffic separation. Each interface can only be associated to one VRF, which is the fundamental framework for traffic separation. Forwarding decisions are made based on the routing table belonging to the VRF. Control of what routes are imported into or exported from a VRF is based on the RT. It is critical that traffic does not leak from one COI tenant or L3VPN to another; hence, it is imperative that the correct RT is configured for each VRF.","checkContent":"Verify that the correct RT is configured for each VRF.\n\nReview the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF.\n\nReview 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. \n\nNote: Import and export route-maps are normally used when finer granularity is required.\n\nIf there are VRFs configured with the wrong RT, this is a finding.","fixText":"Configure all J-PE routers to have the correct VRF defined with the appropriate RT.","ccis":["CCI-000366"]},{"vulnId":"V-207178","ruleId":"SV-207178r604135_rule","severity":"medium","ruleTitle":"The PE router must be configured to have each VRF with the appropriate Route Distinguisher (RD).","description":"An RD provides uniqueness to the customer address spaces within the MPLS L3VPN infrastructure. The concept of the VPN-IPv4 and VPN-IPv6 address families consists of the RD prepended before the IP address. Hence, if the same IP prefix is used in several different L3VPNs, it is possible for BGP to carry several completely different routes for that prefix, one for each VPN.\n\nSince VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses. The purpose of the RD is to create distinct routes for common IPv4 address prefixes. On any given PE router, a single RD can define a VRF in which the entire address space may be used independently, regardless of the makeup of other VPN address spaces. Hence, it is imperative that a unique RD is assigned to each L3VPN and that the proper RD is configured for each VRF.","checkContent":"Review the RDs that have been assigned for each VRF according to the plan provided by the ISSM.\n\nReview all VRFs configured on CE-facing interfaces and verify that the proper RD has been configured for each.\n\nIf the wrong RD has been configured for any VRF, this is a finding.","fixText":"Configure the correct RD for each VRF.","ccis":["CCI-000366"]},{"vulnId":"V-207179","ruleId":"SV-207179r604135_rule","severity":"high","ruleTitle":"The PE router providing MPLS Virtual Private Wire Service (VPWS) must be configured to have the appropriate virtual circuit identification (VC ID) for each attachment circuit.","description":"VPWS is an L2VPN technology that provides a virtual circuit between two PE routers to forward Layer 2 frames between two customer-edge routers or switches through an MPLS-enabled IP core. The ingress PE router (virtual circuit head-end) encapsulates Ethernet frames inside MPLS packets using label stacking and forwards them across the MPLS network to the egress PE router (virtual circuit tail-end). During a virtual circuit setup, the PE routers exchange VC label bindings for the specified VC ID. The VC ID specifies a pseudowire associated with an ingress and egress PE router and the customer-facing attachment circuits.\n\nTo guarantee that all frames are forwarded onto the correct pseudowire and to the correct customer and attachment circuits, it is imperative that the correct VC ID is configured for each attachment circuit.","checkContent":"Review the ingress and egress PE router configuration for each virtual circuit that has been provisioned.\n\nVerify that the correct and unique VCID has been configured for the appropriate attachment circuit.\n\nIf the correct VC ID has not been configured on both routers, this is a finding.\n\nNote: 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.","fixText":"Assign globally unique VC IDs for each virtual circuit and configure the attachment circuits with the appropriate VC ID.\n\nConfigure the same VC ID on both ends of the VC.","ccis":["CCI-000366"]},{"vulnId":"V-207180","ruleId":"SV-207180r604135_rule","severity":"high","ruleTitle":"The PE router providing Virtual Private LAN Services (VPLS) must be configured to have all attachment circuits defined to the virtual forwarding instance (VFI) with the globally unique VPN ID assigned for each customer VLAN.","description":"VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE routers). A pseudowire contains two unidirectional label-switched paths (LSP) between two PE routers. Each MAC virtual forwarding table instance (VFI) is interconnected using pseudowires provisioned for the bridge domain, thereby maintaining privacy and logical separation between each VPLS bridge domain.\n\nThe VFI specifies the pseudowires associated with connecting PE routers and the customer-facing attachment circuits belonging to a given VLAN. Resembling a Layer 2 switch, the VFI is responsible for learning MAC addresses and providing loop-free forwarding of customer traffic to the appropriate end nodes. Each VPLS domain is identified by a globally unique VPN ID; hence, VFIs of the same VPLS domain must be configured with the same VPN ID on all participating PE routers. To guarantee traffic separation for all customer VLANs and that all packets are forwarded to the correct destination, it is imperative that the correct attachment circuits are associated with the appropriate VFI and that each VFI is associated to the unique VPN ID assigned to the customer VLAN.","checkContent":"Review the implementation plan and the VPN IDs assigned to customer VLANs for the VPLS deployment.\n\nReview the PE router configuration to verify that customer attachment circuits (i.e., VLANs) are associated to the appropriate VFI.\n\nIf the attachment circuits have not been bound to VFI configured with the assigned VPN ID for each VLAN, this is a finding.","fixText":"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.","ccis":["CCI-000366"]},{"vulnId":"V-207181","ruleId":"SV-207181r604135_rule","severity":"low","ruleTitle":"The PE router must be configured to enforce the split-horizon rule for all pseudowires within a Virtual Private LAN Services (VPLS) bridge domain.","description":"A virtual forwarding instance (VFI) must be created on each participating PE router for each customer VLAN using VPLS for carrier Ethernet services. The VFI specifies the VPN ID of a VPLS domain, the addresses of other PE routers in the domain, and the type of tunnel signaling and encapsulation mechanism for each peer PE router. The set of VFIs formed by the interconnection of the emulated VCs is called a VPLS instance, which forms the logic bridge over the MPLS core network.\n\nThe PE routers use the VFI with a unique VPN ID to establish a full mesh of emulated virtual circuits or pseudowires to all the other PE routers in the VPLS instance. The full-mesh configuration allows the PE router to maintain a single broadcast domain. With a full-mesh configuration, signaling and packet replication requirements for each provisioned virtual circuit on a PE can be high. To avoid the problem of a packet looping in the provider core, thereby adding more overhead, the PE devices must enforce a split-horizon principle for the emulated virtual circuits; that is, if a packet is received on an emulated virtual circuit, it is not forwarded on any other virtual circuit.","checkContent":"Review the PE router configuration to verify that split horizon is enabled.\n\nIf it is disabled, this is a finding.\n\nNote: 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.","fixText":"Enable split horizon on all PE routers deploying VPLS in a full-mesh configuration.","ccis":["CCI-000366"]},{"vulnId":"V-207182","ruleId":"SV-207182r604135_rule","severity":"low","ruleTitle":"The Multicast Source Discovery Protocol (MSDP) router must be configured to use its loopback address as the source address when originating MSDP traffic.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of MSDP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router’s loopback address instead of the numerous physical interface addresses.","checkContent":"Review the router configuration to verify that a loopback address has been configured.\n\nVerify that a loopback interface is used as the source address for all MSDP packets generated by the router.\n\nIf the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.","fixText":"Ensure that the router’s loopback address is used as the source address when originating traffic.","ccis":["CCI-000366"]},{"vulnId":"V-216506","ruleId":"SV-216506r604135_rule","severity":"medium","ruleTitle":"The router must 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.","description":"Configuring the network device to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.\n\nConfiguration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network device. Security-related parameters are those parameters impacting the security state of the network device, including the parameters required to satisfy other security control requirements.","checkContent":"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.\n\nIf it is not configured in accordance with the designated security configuration settings, this is a finding.","fixText":"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.","ccis":["CCI-000366"]},{"vulnId":"V-216978","ruleId":"SV-216978r856655_rule","severity":"medium","ruleTitle":"The router must not be configured to have any feature enabled that calls home to the vendor.","description":"Call home services will routinely send data such as configuration and diagnostic information to the vendor for routine or emergency analysis and troubleshooting. There is a risk that transmission of sensitive data sent to unauthorized persons could result in data loss or downtime due to an attack.","checkContent":"Verify the call home service is disabled on the device.\n\nIf a call home service is enabled, this is a finding.","fixText":"Configure the network device to disable the call home service or feature.","ccis":["CCI-002403"]},{"vulnId":"V-216979","ruleId":"SV-216979r945858_rule","severity":"high","ruleTitle":"The perimeter router must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).","description":"A compromised host in an enclave can be used by a malicious platform to launch cyber attacks on third parties. This is a common practice in \"botnets\", which are a collection of compromised computers using malware to attack other computers or networks. DDoS attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet; thereby mitigating IP source address spoofing.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview 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.\n\nIf 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.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure 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.","ccis":["CCI-001097"]},{"vulnId":"V-216980","ruleId":"SV-216980r945859_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to block all packets with any IP options.","description":"Packets with IP options are not fast switched and henceforth must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to determine if it will block all packets with IP options.\n\nIf the router is not configured to drop all packets with IP options, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to drop all packets with IP options.","ccis":["CCI-001097"]},{"vulnId":"V-216981","ruleId":"SV-216981r945860_rule","severity":"medium","ruleTitle":"The PE router must be configured to ignore or block all packets with any IP options.","description":"Packets with IP options are not fast switched and therefore must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"Review the router configuration to determine if it will block all packets with IP options.\n\nIf the router is not configured to drop all packets with IP options, this is a finding.","fixText":"Configure the router to drop all packets with IP options.","ccis":["CCI-001097"]},{"vulnId":"V-216982","ruleId":"SV-216982r945861_rule","severity":"medium","ruleTitle":"The router must be configured to implement message authentication for all control plane protocols.","description":"A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a \"traffic attraction attack\" and is prevented by configuring neighbor router authentication for routing updates.\n\nThis requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information. This includes BGP, RIP, OSPF, EIGRP, IS-IS and LDP.","checkContent":"Review the router configuration.\n\nFor every protocol that affects the routing or forwarding tables (where information is exchanged between neighbors), verify that neighbor router authentication is enabled.\n\nIf authentication is not enabled, this is a finding.","fixText":"Configure authentication to be enabled for every protocol that affects the routing or forwarding tables.","ccis":["CCI-001184"]},{"vulnId":"V-216983","ruleId":"SV-216983r945862_rule","severity":"medium","ruleTitle":"The BGP router must be configured to use a unique key for each autonomous system (AS) that it peers with.","description":"If the same keys are used between eBGP neighbors, the chance of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors.","checkContent":"Interview the ISSM and router administrator to determine if unique keys are being used. \n\nIf unique keys are not being used, this is a finding.","fixText":"Configure all eBGP routers with unique keys for each eBGP neighbor that it peers with.","ccis":["CCI-001184"]},{"vulnId":"V-216984","ruleId":"SV-216984r945863_rule","severity":"medium","ruleTitle":"The router must be configured to use keys with a duration not exceeding 180 days for authenticating routing protocol messages.","description":"If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Some routing protocols allow the use of key chains for authentication. A key chain is a set of keys that is used in succession, with each having a lifetime of no more than 180 days. Changing the keys frequently reduces the risk of them eventually being guessed.\n\nKeys cannot be used during time periods for which they are not activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Therefore, ensure that for a given key chain, key activation times overlap to avoid any period of time during which no key is activated.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nFor each authenticated routing protocol session, review the configured key expiration dates.\n\nIf any key has a lifetime of more than 180 days, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nFor each authenticated routing protocol session, configure each key to have a lifetime of no more than 180 days.","ccis":["CCI-001184"]},{"vulnId":"V-216985","ruleId":"SV-216985r856661_rule","severity":"low","ruleTitle":"The BGP router must be configured to enable the Generalized TTL Security Mechanism (GTSM).","description":"GTSM is designed to protect a router's IP-based control plane from DoS attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol speaking routers. \n\nGTSM is based on the fact that the vast majority of control plane peering is established between adjacent routers; that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.","checkContent":"Review the router configuration.\n\nIf the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.","fixText":"Configure all Exterior Border Gateway Protocol peering sessions to use GTSM.","ccis":["CCI-002385"]},{"vulnId":"V-220144","ruleId":"SV-220144r604135_rule","severity":"low","ruleTitle":"The router must be configured to advertise a hop limit of at least 32 in Router Advertisement messages for IPv6 stateless auto-configuration deployments.","description":"The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message being used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached its destination.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if the hop limit has been configured for Router Advertisement messages. \n\nIf it has been configured and has not been set to at least 32, it is a finding.","fixText":"Configure the router to advertise a hop limit of at least 32 in Router Advertisement messages.","ccis":["CCI-000366"]},{"vulnId":"V-220145","ruleId":"SV-220145r604135_rule","severity":"medium","ruleTitle":"The router must not be configured to use IPv6 Site Local Unicast addresses.","description":"As currently defined, site local addresses are ambiguous and can be present in multiple sites. The address itself does not contain any indication of the site to which it belongs. The use of site-local addresses has the potential to adversely affect network security through leaks, ambiguity, and potential misrouting as documented in section 2 of RFC3879. RFC3879 formally deprecates the IPv6 site-local unicast prefix FEC0::/10 as defined in RFC3513.","checkContent":"Review the router configuration to ensure FEC0::/10 IP addresses are not defined. \n\nIf IPv6 Site Local Unicast addresses are defined, this is a finding.","fixText":"Configure the router using authorized IPv6 addresses.","ccis":["CCI-000366"]},{"vulnId":"V-220146","ruleId":"SV-220146r604135_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.","description":"Many of the known attacks in stateless autoconfiguration are defined in RFC 3756 were present in IPv4 ARP attacks. To mitigate these vulnerabilities, links that have no hosts connected such as the interface connecting to external gateways must be configured to suppress router advertisements.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to verify Router Advertisements are suppressed on all external IPv6-enabled interfaces.\n\nIf the router is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.","fixText":"Configure the router to suppress Router Advertisements on all external IPv6-enabled interfaces.","ccis":["CCI-000366"]},{"vulnId":"V-220147","ruleId":"SV-220147r950991_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 undetermined transport packets.","description":"One of the fragmentation weaknesses known in IPv6 is the undetermined transport packet. This packet contains an undetermined protocol due to fragmentation. Depending on the length of the IPv6 extension header chain, the initial fragment may not contain the layer four port information of the packet.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is configured to drop IPv6 undetermined transport packets.\n\nIf the router is not configured to drop IPv6 undetermined transport packets, this is a finding.","fixText":"Configure the router to drop IPv6 undetermined transport packets.","ccis":["CCI-002403"]},{"vulnId":"V-220148","ruleId":"SV-220148r856665_rule","severity":"medium","ruleTitle":"The perimeter router must be configured drop IPv6 packets with a Routing Header type 0, 1, or 3255.","description":"The routing header can be used maliciously to send a packet through a path where less robust security is in place, rather than through the presumably preferred path of routing protocols. Use of the routing extension header has few legitimate uses other than as implemented by Mobile IPv6. \n\nThe Type 0 Routing Header (RFC 5095) is dangerous because it allows attackers to spoof source addresses and obtain traffic in response, rather than the real owner of the address. Secondly, a packet with an allowed destination address could be sent through a Firewall using the Routing Header functionality, only to bounce to a different node once inside. The Type 1 Routing Header is defined by a specification called \"Nimrod Routing\", a discontinued project funded by DARPA. Assuming that most implementations will not recognize the Type 1 Routing Header, it must be dropped. The Type 3–255 Routing Header values in the routing type field are currently undefined and should be dropped inbound and outbound.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3–255.\n\nIf the router is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3–255, this is a finding.","fixText":"Configure the router to drop IPv6 packets with Routing Header of type 0, 1, or 3–255.","ccis":["CCI-002403"]},{"vulnId":"V-220149","ruleId":"SV-220149r856667_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values.","description":"These options are intended to be for the Destination Options header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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). \n\nNote: 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. \n\nIf the router is not configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values, this is a finding.","fixText":"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).","ccis":["CCI-002403"]},{"vulnId":"V-220150","ruleId":"SV-220150r856669_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 packets containing a Destination Option header with invalid option type values.","description":"These options are intended to be for the Hop-by-Hop header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize. Hence, this could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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). \n\nNote: 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. \n\nIf the router is not configured to drop IPv6 packets containing a Destination Option header with invalid option type values, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing a Destination Option header with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload).","ccis":["CCI-002403"]},{"vulnId":"V-220151","ruleId":"SV-220151r856671_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 packets containing an extension header with the Endpoint Identification option.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type is associated with the Nimrod Routing system and has no defining RFC document.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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. \n\nNote: 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. \n\nIf the router is not configured to drop IPv6 packets containing an extension header with the Endpoint Identification option, this is a finding.","fixText":"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.","ccis":["CCI-002403"]},{"vulnId":"V-220152","ruleId":"SV-220152r856673_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 packets containing the NSAP address option within Destination Option header.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type from RFC 1888 (OSI NSAPs and IPv6) has been deprecated by RFC 4048.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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). \n\n\nNote: 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. \n\nIf the router is not configured to drop IPv6 packets containing the NSAP address option within Destination Option header, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address).","ccis":["CCI-002403"]},{"vulnId":"V-220153","ruleId":"SV-220153r856675_rule","severity":"medium","ruleTitle":"The perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview 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.\n\nIf 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.","fixText":"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.","ccis":["CCI-002403"]},{"vulnId":"V-264309","ruleId":"SV-264309r984168_rule","severity":"medium","ruleTitle":"The router must employ organization-defined controls by type of denial of service (DoS) to achieve the DoS objective.","description":"DoS events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of DoS events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of DoS attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to DoS events.","checkContent":"Verify the router is configured to employ organization-defined controls by type of DoS to achieve the DoS objective.\n\nIf the router is not configured to employ organization-defined controls by type of DoS to achieve the DoS objective, this is a finding.","fixText":"Configure the router to employ organization-defined controls by type of DoS to achieve the DoS objective.","ccis":["CCI-004866"]},{"vulnId":"V-264310","ruleId":"SV-264310r1137936_rule","severity":"medium","ruleTitle":"The router must implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.","description":"Separating critical system components and functions from other noncritical system components and functions through separate subnetworks may be necessary to reduce susceptibility to a catastrophic or debilitating breach or compromise that results in system failure. For example, physically separating the command and control function from the in-flight entertainment function through separate subnetworks in a commercial aircraft provides an increased level of assurance in the trustworthiness of critical system functions.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.\n\nIf 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.","fixText":"Configure the router to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions.","ccis":["CCI-004891"]},{"vulnId":"V-264311","ruleId":"SV-264311r984174_rule","severity":"medium","ruleTitle":"The router must establish organization-defined alternate communications paths for system operations organizational command and control.","description":"An incident, whether adversarial- or nonadversarial-based, can disrupt established communications paths used for system operations and organizational command and control. Alternate communications paths reduce the risk of all communications paths being affected by the same incident. To compound the problem, the inability of organizational officials to obtain timely information about disruptions or to provide timely direction to operational elements after a communications path incident, can impact the ability of the organization to respond to such incidents in a timely manner. Establishing alternate communications paths for command and control purposes, including designating alternative decision makers if primary decision makers are unavailable and establishing the extent and limitations of their actions, can greatly facilitate the organization's ability to continue to operate and take appropriate actions during an incident.","checkContent":"Verify the router is configured to establish organization-defined alternate communications paths for system operations organizational command and control.\n\nIf the router is not configured to establish organization-defined alternate communications paths for system operations organizational command and control, this is a finding.","fixText":"Configure the router to establish organization-defined alternate communications paths for system operations organizational command and control.","ccis":["CCI-004931"]},{"vulnId":"V-278997","ruleId":"SV-278997r1137939_rule","severity":"medium","ruleTitle":"The router must dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined.","description":"If the router does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that the security attributes will not correctly reflect the data with which they are associated.\n\nSecurity attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified, CUI). Examples of security labels for packets include traffic flow (e.g., source, destination, and protocol combination); traffic classification based on QoS markings for preferred treatment; and VLAN identification.\n\nWhen data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. Dynamic association of security attributes is appropriate whenever the security characteristics of information changes over time. Security attributes may change, for example, due to information aggregation issues (i.e., the security characteristics of individual information elements are different from the combined elements), changes in individual access authorizations (i.e., privileges), and changes in the security category of information.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined.\n\nIf the router does not dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined., this is a finding.","fixText":"Configure the router to dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined.","ccis":["CCI-001424","CCI-000366"]},{"vulnId":"V-278998","ruleId":"SV-278998r1137942_rule","severity":"medium","ruleTitle":"The router must validate the integrity of transmitted security attributes.","description":"If security attributes are not associated with the information being transmitted between components, then access control policies and information flows that depend on these security attributes will not function and unauthorized access may result. When data is exchanged, the security attributes associated with this data must be validated to ensure the data has not been changed.\n\nSecurity attributes are values associated with data content/structure and source/destination objects. These attributes are bound to the user and data objects and may include information about the data's purpose, creator, origin, access restrictions, access permissions, or classification. Specific security attributes used depend on the application or technology context. However, these attributes are used in information systems to implement security policy for access control and flow control for users, data, and traffic. Security attributes may be explicitly or implicitly associated with the information contained within the information system. \n\nValidation checking can be performed by various means, such as using a cryptographic hash function, boundary checking of values, checksums, or message authentication code.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to validate the integrity of transmitted security attributes.\n\nIf the router does not validate the integrity of transmitted security attributes, this is a finding.","fixText":"Configure the router to validate the integrity of transmitted security attributes.","ccis":["CCI-001158"]},{"vulnId":"V-278999","ruleId":"SV-278999r1137945_rule","severity":"medium","ruleTitle":"The router must enforce information flow control based on organization-defined metadata.","description":"Enforcing allowed information flows based on metadata enables simpler and more effective flow control. Metadata is information used to describe the characteristics of data. Metadata can include structural metadata describing data structures (e.g., data format, syntax, and semantics) or descriptive metadata describing data contents (e.g., age, location, telephone number).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to enforce information flow control based on organization-defined metadata.\n\nIf the router does not enforce information flow control based on organization-defined metadata, this is a finding.","fixText":"Configure the router to enforce information flow control based on organization-defined metadata.","ccis":["CCI-000030","CCI-000366"]},{"vulnId":"V-279000","ruleId":"SV-279000r1137948_rule","severity":"medium","ruleTitle":"The router must use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions.","description":"A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. Security attributes may be used to manage information flow control. \n\nInformation flow enforcement mechanisms compare security attributes associated with information (data content and data structure) and source/destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not allowed by information flow policies. For example, an information object labeled Secret would be allowed to flow to a destination object labeled Secret, but an information object labeled Top Secret would not be allowed to flow to a destination object labeled Secret. Security attributes can also include, for example, source and destination addresses employed in traffic filter firewalls. Flow enforcement using security attributes can be used, for example, to control the release of certain types of information.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions.\n\nIf the router does not use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions, this is a finding.","fixText":"Configure the router to use organization-defined security attributes associated with organization-defined information, source, and destination objects to enforce organization-defined information flow control policies as a basis for flow control decisions.","ccis":["CCI-002190","CCI-000366"]},{"vulnId":"V-279001","ruleId":"SV-279001r1137951_rule","severity":"medium","ruleTitle":"When transferring information between different security domains, the router must use organization-defined data type identifiers to validate data essential for information flow decisions.","description":"Information flow decisions based on invalid data may allow unintended and unauthorized data flows, and therefore, risk the confidentiality of information. They may also result in the unauthorized release (spill) of information.\n\nData type identifiers include, for example, file names, file types, file signatures/tokens, and multiple internal file signatures/tokens. Information systems may allow transfer of data only if compliant with data type format specifications.\n\nThis requirement applies to routers that transfer information between different security domains (e.g., cross-domain solutions).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"When transferring information between different security domains, verify the router is configured to use organization-defined data type identifiers to validate data essential for information flow decisions.\n\nIf the router does not use organization-defined data type identifiers to validate data essential for information flow decisions, when transferring information between different security domains, this is a finding.","fixText":"Configure the router to use organization-defined data type identifiers to validate data essential for information flow decisions, when transferring information between different security domains.","ccis":["CCI-002201","CCI-000366"]},{"vulnId":"V-279002","ruleId":"SV-279002r1137954_rule","severity":"medium","ruleTitle":"The router must uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer.","description":"Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in information systems, allows the forensic reconstruction of events when required, and encourages policy compliance by attributing policy violations to specific organizations/individuals. Successful domain authentication requires that information system labels distinguish among systems, organizations, and individuals involved in preparing, sending, receiving, or disseminating information.\n\nThis requirement applies to routers that transfer information between different security domains (e.g., cross-domain solutions).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer.\n\nIf the router does not uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer, this is a finding.","fixText":"Configure the router to uniquely identify and authenticate source by organization, system, application, and/or individual for information transfer.","ccis":["CCI-002205","CCI-000366"]},{"vulnId":"V-279003","ruleId":"SV-279003r1137957_rule","severity":"medium","ruleTitle":"The router must uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer.","description":"Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in information systems, allows the forensic reconstruction of events when required, and encourages policy compliance by attributing policy violations to specific organizations/individuals. Successful domain authentication requires that information system labels distinguish among systems, organizations, and individuals involved in preparing, sending, receiving, or disseminating information.\n\nThis requirement applies to routers that transfer information between different security domains (e.g., cross-domain solutions).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer.\n\nIf the router does not uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer, this is a finding.","fixText":"Configure the router to uniquely identify and authenticate destination by organization, system, application, and/or individual for information transfer.","ccis":["CCI-002207","CCI-000366"]},{"vulnId":"V-279004","ruleId":"SV-279004r1137960_rule","severity":"medium","ruleTitle":"When transferring information between different security domains, the router must apply the same security policy filtering to metadata as it applies to data payloads.","description":"Subjecting metadata to the same filtering and inspection policies as payload data avoids the potential for data compromise through covert channels and the bypass of security policy filtering. \n\nThis requirement applies to routers that transfer information between different security domains (e.g., cross-domain solutions).\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"The router must apply the same security policy filtering to metadata as it applies to data payloads. Verify the router is configured to meet the requirements.\n\nIf the router does not meet the requirement, this is a finding.","fixText":"Configure the router to meet the requirement.","ccis":["CCI-002211","CCI-000366"]},{"vulnId":"V-279005","ruleId":"SV-279005r1137963_rule","severity":"medium","ruleTitle":"The router must use cryptographic algorithms approved by NSA to protect NSS when transporting classified traffic across an unclassified network.","description":"Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data.\n\nNIST cryptographic algorithms are approved by NSA to protect NSS. Based on an analysis of the impact of quantum computing, cryptographic algorithms specified by CNSSP-15 and approved for use in products in the CSfC program have been changed to more stringent protocols and configured with increased bit sizes and other secure characteristics to protect against quantum computing threats. The Commercial National Security Algorithm Suite (CNSA Suite) replaces Suite B.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Determine if the router uses cryptographic algorithms approved by NSA to protect NSS when transporting classified traffic across an unclassified network.   \n\nIf the router does not use cryptographic algorithms approved by NSA to protect NSS when transporting classified traffic across an unclassified network, this is a finding.","fixText":"Configure the router to use cryptographic algorithms approved by NSA to protect NSS when transporting classified traffic across an unclassified network.","ccis":["CCI-002450"]},{"vulnId":"V-279006","ruleId":"SV-279006r1137968_rule","severity":"medium","ruleTitle":"The router must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.","description":"Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. \n\nUse of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, routers need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPSEC.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.\n\nIf the router does not implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission, this is a finding.","fixText":"Configure the router to implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission.","ccis":["CCI-002421"]},{"vulnId":"V-279007","ruleId":"SV-279007r1137971_rule","severity":"medium","ruleTitle":"The router must use a FIPS-validated cryptographic module to generate cryptographic hashes.","description":"FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. \n\nThe cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the product being evaluated.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to use a FIPS-validated cryptographic module to generate cryptographic hashes.\n\nIf the router does not use a FIPS-validated cryptographic module to generate cryptographic hashes, this is a finding.","fixText":"Configure the router to use a FIPS-validated cryptographic module to generate cryptographic hashes.","ccis":["CCI-002450"]},{"vulnId":"V-279008","ruleId":"SV-279008r1137974_rule","severity":"medium","ruleTitle":"The router must dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined.","description":"If the router does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility the security attributes will not correctly reflect the data with which they are associated.\n\nSecurity attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, and files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified and CUI). Security labels for packets may include traffic flow information (e.g., source, destination, protocol combination); traffic classification based on QoS markings for preferred treatment; and VLAN identification.\n\nWhen data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. Dynamic association of security attributes is appropriate whenever the security characteristics of information changes over time. Security attributes may change due to information aggregation issues (i.e., the security characteristics of individual information elements are different from the combined elements); changes in individual access authorizations (i.e., privileges); or changes in the security category of information.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined.\n\nIf the router does not dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined, this is a finding.","fixText":"Configure the router to dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined.","ccis":["CCI-002272","CCI-000366"]},{"vulnId":"V-279009","ruleId":"SV-279009r1137977_rule","severity":"medium","ruleTitle":"The router must be configured to use cryptographic algorithms approved by NSA to protect NSS for remote access to a classified network.","description":"Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The router must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nNIST cryptographic algorithms are approved by NSA to protect NSS. Based on an analysis of the impact of quantum computing, cryptographic algorithms specified by CNSSP-15 and approved for use in products in the CSfC program have been changed to more stringent protocols configure with increased bit sizes and other secure characteristics to protect against quantum computing threats. The Commercial National Security Algorithm Suite (CNSA Suite) replaces Suite B.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Determine if the router is configured to use cryptographic algorithms approved by NSA to protect NSS for remote access to a classified network.\n\nIf the router is not configured to use cryptographic algorithms approved by NSA to protect NSS for remote access to a classified network, this is a finding.","fixText":"Configure the router to use cryptographic algorithms approved by NSA to protect NSS for remote access to a classified network.","ccis":["CCI-002450"]},{"vulnId":"V-279010","ruleId":"SV-279010r1137980_rule","severity":"medium","ruleTitle":"The router must use a FIPS-validated cryptographic module to provision digital signatures.","description":"FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard.\n\nThe cryptographic module used must have at least one validated digital signature function. This validated hashing algorithm must be used to generate digital signatures for all cryptographic security function within the product being evaluated. Federal Information Processing Standard (FIPS) 186-4, Digital Signature Standard (DSS), specifies three NIST-approved algorithms: DSA, RSA, and ECDSA. These algorithms are used to generate and verify digital signatures in conjunction with an approved hash function.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Determine if the router uses a FIPS-validated cryptographic module to provision digital signatures.   \n\nIf the router does not use a FIPS-validated cryptographic module to provision digital signatures, this is a finding.","fixText":"Configure the router to use a FIPS-validated cryptographic module to provision digital signatures.","ccis":["CCI-002450"]},{"vulnId":"V-279011","ruleId":"SV-279011r1137983_rule","severity":"medium","ruleTitle":"The router must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.","description":"FIPS 140-2/FIPS 140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plain text. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/FIPS 140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/FIPS 140-3 standard. \n\nThe cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the product being evaluated.\n\nThis requirement also applies to Zero Trust initiatives.","checkContent":"Verify the router is configured to use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.\n\nIf the router does not use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality, this is a finding.","fixText":"Configure the router to use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.","ccis":["CCI-002450"]}]}