What changed in Router Security Requirements Guide V5R2V5R2 changes

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the router configuration to verify that access control lists (ACLs) and filters are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. These filters should be applied inbound or outbound on the appropriate external and internal interfaces. If the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure ACLs and filters to allow or deny traffic for specific source and destination addresses as well as ports and protocols. Apply the filters inbound or outbound on the appropriate external and internal interfaces. Policy-based routing can also be implemented if needed.

Discussion

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. Enforcement 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). This requirement also applies to Zero Trust initiatives.

V-207097 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207098 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207099 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207100 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207101 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207102 in V5R2

Check text

Review the router configuration to determine if there is an import policy to block source-active multicast advertisements for any undesirable multicast groups, as well as any (S, G) states with undesirable source addresses. Step 1: Verify that an inbound source-active filter is bound to each MSDP peer. Step 2: Review the access lists referenced by the source-active filter to verify that undesirable multicast groups, auto-RP, single source multicast (SSM) groups, and advertisements from undesirable sources are blocked. If the router is not configured with an import policy to block undesirable SA multicast advertisements, this is a finding.

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207103 in V5R2

Check text

Review the router configuration to determine if there is export policy to block local source-active multicast advertisements. Verify that an outbound source-active filter is bound to each MSDP peer. Review the access lists referenced by the source-active filters and verify that MSDP source-active messages being sent to MSDP peers do not leak advertisements that are local. If the router is not configured with an export policy to block local source-active multicast advertisements, this is a finding.

Discussion

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). Allowing 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. This requirement also applies to Zero Trust initiatives.

V-207104 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207105 in V5R2

Check text

This requirement is not applicable for the DODIN Backbone. Review the router configuration to verify the router is configured to deny updates received from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer. Step 1: Review router configuration and verify that there is an as-path access-list statement defined to only accept routes from a CE router whose AS did not originate the route. Step 2: Verify that the as-path access list is referenced by the filter-list inbound for the appropriate BGP neighbors. If the router is not configured to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207106 in V5R2

Discussion

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. Secured 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. This requirement also applies to Zero Trust initiatives.

V-207107 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207108 in V5R2

Discussion

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. A 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. As stated in the DoDDOD 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. This requirement also applies to Zero Trust initiatives.

V-207109 in V5R2

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the multicast topology diagram and determine if router interfaces are enabled for IPv4 or IPv6 multicast routing. If the router is enabled for multicast routing, verify all interfaces enabled for PIM have a neighbor filter bound to the interface. The neighbor filter must only accept PIM control plane traffic from the documented PIM neighbors. If PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM enabled interfaces.

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207110 in V5R2

Discussion

If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Administrative 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. Admin-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. This requirement also applies to Zero Trust initiatives.

V-207111 in V5R2

Discussion

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. If 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. This requirement also applies to Zero Trust initiatives.

V-207112 in V5R2

Title

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 sitessite's address space.

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the configuration of each router interface connecting to an alternate gateway. Verify each permit statement of the ingress filter only permits packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider. If the ingress filter permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure the ingress filter of the perimeter router connected to an alternate gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider.

Discussion

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 DoDDOD 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 DoDDOD enclave's address block. This requirement also applies to Zero Trust initiatives.

V-207113 in V5R2

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the configuration of the router connecting to the alternate gateway. Verify there are no BGP neighbors configured to the remote AS that belongs to the alternate gateway service provider. If there are BGP neighbors connecting the remote AS of the alternate gateway service provider, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure a static route on the perimeter router to reach the AS of a router connecting to an alternate gateway.

Discussion

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 Internetinternet to the NIPRnet. This requirement also applies to Zero Trust initiatives.

V-207114 in V5R2

Title

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.

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the configuration of the router connecting to the alternate gateway and verify that redistribution of static routes to the alternate gateway is not occurring. If the static routes to the alternate gateway are being redistributed into BGP or any IGP peering with a NIPRNet gateway or another autonomous system, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure the router so that static routes are not redistributed to an alternate gateway into either an Exterior Gateway Protocol or InteriorIGP Gateway Protocol to the NIPRNet or to other autonomous systems.

Discussion

If the static routes to the alternate gateway are being redistributed into an Exterior Gateway Protocol or InteriorIGP Gateway Protocol 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. This requirement also applies to Zero Trust initiatives.

V-207115 in V5R2

Title

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.

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Verify that the OOBM interface is an adjacency in the InteriorIGP Gateway Protocol routing domain for the management network. If the router does not enforce that InteriorIGP Gateway Protocol instances configured on the OOBM gateway router peer only with their own routing domain, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure the router to enforce that InteriorIGP Gateway Protocol instances configured on the OOBM gateway router peer only with their own routing domain.

Discussion

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 InteriorIGP Gateway Protocol routing instances is critical on the router to segregate traffic from each network. This requirement also applies to Zero Trust initiatives.

V-207116 in V5R2

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Verify the InteriorIGP Gateway Protocol instance used for the managed network does not redistribute routes into the InteriorIGP Gateway Protocol instance used for the management network, and vice versa. If the InteriorIGP Gateway Protocol instance used for the managed network redistributes routes into the InteriorIGP Gateway Protocol instance used for the management network, or vice versa, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure the InteriorIGP Gateway Protocol instance used for the managed network to prohibit redistribution of routes into the InteriorIGP Gateway Protocol instance used for the management network, and vice versa.

Discussion

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. Since 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. This requirement also applies to Zero Trust initiatives.

V-207117 in V5R2

Check text

Verify that the RP router is configured to filter PIM register messages. If the RP router peering with PIM-SM routers is not configured with a PIM import policy to block registration messages for any undesirable multicast groups and sources, this is a finding.

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207118 in V5R2

Check text

Verify that the RP router is configured to filter PIM register messages. Note: Alternative is to configure all designated routers to filter IGMP Membership Report (a.k.a join) messages received from hosts. If the RP router peering with PIM-SM routers is not configured with a PIM import policy to block registration messages for any undesirable multicast groups and Bogon sources, this is a finding.

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-207119 in V5R2

Check text

This requirement is not applicable for the DoDINDODIN Backbone. Review the router configuration to verify that the access control list (ACL) or filter is configured to allow specific ports and protocols and deny all other traffic. The filter must be configured inbound on all external interfaces. If the ACL or filter is not configured to allow specific ports and protocols and deny all other traffic, this is a finding. If the filter is not configured inbound on all external interfaces, this is a finding.

Fix text

This requirement is not applicable for the DoDINDODIN Backbone. Configure the perimeter router to deny network traffic by default and allow network traffic by exception.

Discussion

A deny-all, permit-by-exception network communications traffic policy ensures that only connections that are essential and approved are allowed. This 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 that is 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. This requirement also applies to Zero Trust initiatives.

V-207132 in V5R2

Check text

Review the documentation of the router or interview the Systemsystem Administratoradministrator. Verify that the router fails securely in the event of an operational failure. If it cannot fail securely, this is a finding.

Discussion

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. If 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. This requirement also applies to Zero Trust initiatives.

V-207171 in V5R2

Discussion

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. This requirement also applies to Zero Trust initiatives.

V-264310 in V5R2