Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Any connection to an internet service provider (ISP) must be approved by the Office of the DoD CIO before a connection is made to the ISP. Specifically, DoD Instruction 8010.01, DEPARTMENT OF DEFENSE INFORMATION NETWORK (DODIN) TRANSPORT, Sept 10, 2018 states: Para 4.4 “a. Commercial transport services procured as an alternative to the DISN-provided transport requires compliance with this issuance or DoD CIO review and approval.” Based on the use cases below, verify written approval has been obtained from the Office of the DoD CIO or verify a renewal request has been appropriately submitted. There are three basic use cases for an ISP connection. Use case (1): An ISP connection that originates from an approved DISN infrastructure source (includes IAP connections at the DECCs). A DoDIN Waiver is required for a CC/S/A to connect the unclassified DISN to an ISP. These connection requests must come to the Waiver Panel with a Component CIO endorsement of the requirement. These connections should not be provisioned and put into use until waived. Expired waivers pending renewal from the OSD DoDIN Waiver Panel may be downgraded to a Severity 3 category, if proof of a requested renewal can be verified. A DISN enclave that cannot prove DoDIN Waiver approval for the ISP connection is a Severity 1 category. Note: If discovered during a CCRI assessment, the review team lead will immediately report the unapproved ISP connection to the USCYBERCOM (301-688-3585) and the Connection Approval Office (301-225-2900/2901). USCYBERCOM will direct the connection be immediately disconnected. Use Case (2): An ISP connection to a Stand Alone Enclave (physically and logically separated from any DISN connection) requires DoDIN Waiver approval prior to connection. The Stand Alone Enclave must have an AO issued ATO and the connection must be logically and physically separated from the DISN. An unapproved ISP connection in this use case will be assigned a Severity 3 category. Use Case (3): An ISP connection to a non-DoD network (such as a contractor-owned infrastructure) co-located on the same premises as the DoD network. The non-DoD network is physically and logically separated from any DoD IP network. Furthermore, it is not connected to any DoD IP network. The non-DoD network infrastructure is not DoD funded nor is it operated or administered by DoD military or civilian personnel. In addition, the non-DoD network with the ISP connection is not storing, processing, or transmitting any DoD data. For such a network as defined herein, a DoDIN Waiver approval is not required for deploying a connection to an ISP. However, the AO must perform and have on file a risk assessment endorsed by the facility or installation command. If any of the above use cases are applicable, and written approval has been not been obtained from the Office of the DoD CIO or a renewal request has not been submitted, this is a finding.
Written mission justification approval must be obtained from the Office of the DoD CIO prior to establishing a direct connection to the Internet via commercial service provider outside DoD CIO approved Internet access points (e.g. DISA IAP, Cloud Access Point, NIPRnet Federated Gateway, DREN IAP, etc.).
Review the network topology to determine external connections and inspect location where CSU/DSUs and data service jacks reside. If these components are not in a secured environment, this is a finding.
Move all critical communications to controlled access areas. Controlled access areas in this case means controlled restriction to authorize site personnel, i.e., dedicated communications rooms or locked cabinets. This is an area afforded entry control at a security level commensurate with the operational requirement. This protection will be sufficient to protect the network from unauthorized personnel. The keys to the locked cabinets and dedicated communications rooms will be controlled and only provided to authorized network/network security individuals.
Review the DMZ topology and verify public servers are being monitored by an IDPS. If an IDPS sensor is not deployed to monitor all DMZ segments housing public servers, this is a finding.
Place an IDPS sensor in the enclave to monitor public servers.
Review topology of the network segment hosting the web, application, and database servers. If this segment is not being monitored by an IDPS sensor, this is a finding.
Implement an IDPS strategy to monitor the network segment hosting web, application, and database servers.
Review the management network topology and verify network security management servers are being monitored by an IDPS. If an IDPS sensor is not deployed to monitor all segments housing network security management servers, this is a finding.
Install an IDPS to monitor and protect the Management Network (management subnet or OOB network).
Review the network topology to ensure the enclave has the IDPS positioned to monitor all traffic to and from the enclave. Review any type of report that was recently produced from information provided by the sensor showing any recent alerts, an escalation activity and any type of log or configuration changes. This will show the sensor is being actively monitored and alerts are being acted upon. If the enclave's CNDSP requires continuous monitoring of the IDPS, the CNDSPs management team (e.g. sensor grid management team at DISA) will verify the operational status by providing information about the enclave's IDPS such as a network diagram, MOA, current alert information, or other information to validate its operational status. Note: If the authorized Cybersecurity Service Provider (CSSP) can utilize security tools and services that ensures the network (can include perimeter connection and enclave) is monitored in a manner that would satisfy CJCSI 6510.01F, Enclosure A-5, Paragraph 8, an IDSP is not required to be part of the security solution. If there is no IDPS positioned and enabled to monitor all ingress and egress traffic, this is a finding. Exception: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.
Install an IDPS inline or passively, behind the enclave firewall to monitor all unencrypted traffic, inbound and outbound.
Review the network topology diagram and interview the ISSO to determine how the IDS sensor data is transported between sites. If it is not transported across an OOB network or an encrypted tunnel, this is a finding.
Design a communications path for OOB traffic or create an encrypted tunnel using a FIPS 140-2 validated encryption algorithm to protect data.
Review the network topology diagram and interview the ISSO to determine how the IDPS traffic between the sensor and the security management or sensor data collection servers is transported. If the IDPS traffic does not traverse a dedicated VLAN logically separating IDPS traffic from all other enclave traffic, this is a finding.
Design a communications path for OOB traffic or create a VLAN for IDPS traffic to protect the data.
Interview the IDPS administrator and determine if anomaly-based detection is deployed in the network. If implemented, ensure that any products collecting baselines for anomaly-based detection have their baselines rebuilt periodically to support accurate detection. If the collection products do not have their baselines rebuilt periodically, this is a finding.
Establish procedures to update anomaly-based sensors.
If the signatures are located on a server, verify that the directories on which the signature packs are placed are protected by read-only access. If the directories are not set for read-only access, this is a finding.
Modify the access restrictions to prevent the signatures from being updated.
Review the file server accounts and determine if the accounts with read access to the IDPS signatures are provided only to the IDPS sensors. If there are accounts other than those allocated for the IDPS sensors providing access to the signatures, this is a finding.
Secure the signatures from access to accounts for IDS updates.
Interview the SA to determine the IDPS maintenance procedures as well as have SA display the backup files saved on the file server. If the IDPS configuration is not backed up prior to applying software or signature updates, or when making changes to the configuration, this is a finding.
Establish backup procedures and define directories to store the configuration settings and operating system versions.
Interview the SA and determine the process of software and signature validation. If file checksums provided by the vendor are not compared and verified with checksums computed from CD or downloaded files, this is a finding.
Establish change control procedures that include file validation and integrity.
Interview the SA to determine the IDPS backup procedures as well as have SA display the backup files saved on the file server. If the IDPS data is not backed up on a weekly basis, this is a finding.
The organization must establish weekly backup procedures for the network IDS/IPS data.
Interview the ISSO and the IDPS administrator. Have the IDPS administrator display update notifications that have been received, the build number or patch level, then search the vendor's vulnerability database for current release and patch level. If software and signatures are not updated when updates are provided by the vendor, this is a finding.
Have the IDPS administrator subscribe to the X-press notification or similar service offered by the vendor. Ensure the IDPS software is updated when software is available either by DISA or the vendor for security related distributions.
Review network device configurations and topology diagrams to validate encapsulated traffic received from other enclaves terminate at the perimeter for filtering and content inspection. If the tunnel is terminated on a VPN gateway, validate the traffic is inspected by a firewall and IDPS before gaining access to the private network. If the tunnel is being provided by the perimeter router with a direct connection to the tenant's perimeter router, then the perimeter router (of the enclave providing the transient service) must be configured (examples: policy based routing or VRF bound to this interface with only a default route pointing out) to insure all traffic received by this connecting interface is forwarded directly to the NIPR/SIPR interface regardless of destination. If this isn't being done then the connecting interface will have to be treated as an external interface with all the applicable checks. Secured connections such as SSL or TLS which are used for remote access, secure web access, etc. is also applicable to this rule. These types of connections like the other types above must terminate at the enclave perimeter, enclave DMZ, or an enclave service network for filtering and content inspection before passing into the enclave's private network. If the tunnels do not meet any of the criteria above and bypass the enclave's perimeter without filtering and inspection, this is a finding. Note: This vulnerability is not applicable for any VPN connectivity between multiple sites of the same enclave, nor is it applicable for VPN remote access to the enclave. For theses deployments, the implementation must be compliant with all requirements specified within the VPN SRG.
Move tunnel decapsulation to a secure end-point at the enclave's perimeter for filtering and inspection.
Review the enclave's security authorization package and the ATC or Interim ATC amending the connection approval received. If the tunneling of classified traffic is not documented in the security authorization package and an ATC or Interim ATC, this is a finding.
Document the tunneling of classified traffic in the security authorization package and the ATC or Interim ATC.
Review the network topology diagram. If there is a connection between the classified network and the unclassified network for the purpose of tunneling classified traffic across a non-DISN or OCONUS DISN unclassified IP network, verify there is approval by the DSAWG. If there is no document stating DSAWG approval, this is a finding.
Remove the connection between the classified and unclassified network. Obtain approval from the DSAWG for the purpose of tunneling classified traffic across a non-DISN or OCONUS DISN unclassified IP network.
Review the configuration of the IPsec VPN gateway and verify that the tunnel provisioned for transporting classified traffic across an unclassified IP transport network is using cryptographic algorithms in accordance with CNSS Policy No. 15. If cryptographic algorithms used for tunneling classified traffic across an unclassified network are not in accordance with CNSS Policy No. 15, this is a finding.
Configure the tunnel used for transporting classified traffic across an unclassified IP transport network to negotiate with the remote end point to employ cryptographic algorithms in accordance with CNSS Policy No. 15.
Inspect switches and associated cross-connect hardware are kept in a secured IDF. If the hardware is located in an open area, verify all hardware is located in a secured and locked cabinet. If switches and associated cross-connect hardware are not kept in secured IDFs or locked cabinet, this is a finding.
Place switches and associated cross-connect hardware in a secured IDF. If the hardware is located in an open area, ensure the hardware is located in a secured and locked cabinet.
Validate the network diagram by correlating the information with all routers, multi-layer switches, and firewall configurations. Validate all subnets have been documented accordingly. Validate any connectivity documented on the diagram by physically examining the cable connections for the downstream and upstream links, as well as connections for major network components (Routers, Switches, Firewalls, IDS/IPS, etc.). If the site has not maintained network topology diagrams for the enclave, this is a finding.
Update the enclave's network topology diagram to represent the current state of the network and its connectivity.
Review the network topology and interview the ISSO to verify that each external connection to the site's network has been validated and approved by the AO and CAO and that CAP requirements have been met. If there are any external connections that have not been validated and approved, this is a finding.
All external connections will be validated and approved prior to connection. Interview the ISSM to verify that all connections have a mission requirement and that the AO is aware of the requirement.
Review the network topology and interview the ISSO to verify that each external connection to the site's network has been validated and approved by the AO and CAO and that CAP requirements have been met. If there are any external connections that have not been validated and approved, this is a finding.
All external connections will be validated and approved prior to connection. Interview the ISSM to verify that all connections have a mission requirement and that the AO is aware of the requirement.
Review the network topology and interview the ISSO to verify that external connections to the network are reviewed and documented on a semi-annual basis. If there are any external connections that have not been documented, or if the connections are not reviewed on a semi-annual basis, this is a finding.
Implement a semi-annual review process to document and account for external connections to the organization.
Inspect the network topology and physical connectivity to verify compliance. If the site has a non-DoD external connection and does not have an IDPS located between the site's Approved Gateway and the perimeter router, this is a finding. Note: An Approved Gateway (AG) is any external connection from a DoD NIPRNet enclave to an Internet Service Provider, or network owned by a contractor, or non-DoD federal agency that has been approved by either the DoD CIO or the DoD Component CIO. This AG requirement does not apply to commercial cloud connections when the Cloud Service Provider (CSP) network is connected via the NIPRNet Boundary Cloud Access Point (BCAP).
Install and configure an IDPS between the site's Approved Gateway and the premise router.
Review the network topology diagram and verify that ingress and egress traffic via external connections to the enclave do not bypass the enclave's perimeter security. If there are external connections to the enclave that bypass the enclaves' perimeter security, this is a finding.
Disconnect any external network connections not routed through the organization's perimeter security or validated and approved by the AO.
Validate global IP addresses in use on unclassified or classified networks registered through the DoD Network Information Center. For NIPRNet, go to the website https://www.nic.mil. For SIPRNet, go to the web portal at http://www.ssc.smil.mil. If the site is using an address space that has not been registered and allocated to the site, this is a finding.
Submit any unregistered and/or unauthorized global IP addresses to the DoD Network Information Center (NIC) for registration.
Review network diagrams, enterprise sensor reports, and network scans submitted to the Connection Approval Office. Determine that only global IP addresses assigned by the NIC are in use within the organization's SIPRNet enclave. NOTE: This requirement also applies to IPv6 ULA addresses. The IPv6 ULA is unauthorized on SIPR without approval. Determine whether NAT and unauthorized IP address space is in use in the organization's SIPRNet enclave. Exceptions to this requirement are listed below: 1. Closed classified networks logically transiting SIPRNet for enclave-to-enclave VPN transport only. 2. Out-of-Band management networks, where the NATd nodes do not access SIPRNet base enterprise services. 3. Thin client deployments where the hosting thin client server serves as the SIPRNet access point for its thin clients and that the organization maintains detailed thin client service usage audit logs. 4. Valid operational mission need or implementation constraints. All exceptions must have approval by the SIPRNet DISN accreditation official, DISA AO. If NAT and unauthorized IP address space is in use on the organization's SIPRNet infrastructure, this is a finding.
Remove the NAT configurations and private address space from the organization's SIPRNet enclave. Configure the SIPRNet enclave with SSC authorized .smil.mil or .sgov.gov addresses. If NAT or private address space is required, as per one of the stated exceptions or for valid mission requirements, then submit a detailed approval request to use private addressing through the DSAWG Secretariat to the DISN accreditation official, DISA AO.
Verify the DHCP audit and event logs include hostnames and MAC addresses of all clients, in addition to IP address and date/time. Also, validate logs are kept online for thirty days and offline for one year. If the logs do not include hostnames and MAC addresses along with the IP address and date/time, or if the logs are not kept online for thirty days and offline for one year, this is a finding.
Configure the DHCP audit and event logs to log hostname and MAC addresses, in addition to IP address and date/time. Store the logs for a minimum of thirty days online and then offline for one year.
Review the configuration of SIPRNet DHCP servers to verify that the lease duration is set to a minimum of thirty days. If the lease duration is less than thirty days, this is a finding.
Configure any DHCP server used on the SIPRNet with a minimum lease duration of thirty days.
Inspect the site to validate physical network components are in a secure environment with limited access. If there are any network components not located in a secure environment, this is a finding.
Move all critical communications into controlled access areas. Controlled access area in this case means controlled restriction to authorize site personnel, i.e., dedicated communications rooms or locked cabinets. This is an area afforded entry control at a security level commensurate with the operational requirement. This protection will be sufficient to protect the network from unauthorized personnel. The keys to the locked cabinets and dedicated communications rooms will be controlled and only provided to authorized network/network security individuals.
Review the network topology diagram and interview the ISSO to verify that all NIPRNet-only applications are located in a local enclave DMZ. If there are any NIPRNet-only applications not hosted in the enclave's DMZ, this is a finding.
Implement and move NIPRNet-only applications to a local enclave DMZ.
Review the network topology diagram and interview the ISSO to verify that all Internet-facing applications are hosted in a DoD DMZ Extension. If there are any Internet-facing applications hosted in the enclave's DMZ or private network, this is a finding.
Implement and move internet facing applications logically to a DoD DMZ Extension.
Review the network topology diagrams and visually inspect the firewall location to validate correct position on the network. If the firewall is not positioned between the perimeter router and the private network and between the perimeter router and the DMZ, this is a finding. Exception: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.
Move the firewall into the prescribed location to allow for enforcement of the Enclave Security Policy and allow for all traffic to be screened.
Determine which type of solution is used for deep packet inspection at the enclave boundary. Acceptable solutions for meeting this requirement are a deep packet inspection firewall, or a stateful packet inspection firewall in conjunction with any combination of application firewalls or application layer gateways. If the organization does not have any implementation of deep packet inspection protecting their network perimeter boundaries, this is a finding. Exception: If the perimeter security for the enclave or B/C/P/S is provisioned via the JRSS, then this requirement is not applicable.
Implement a deep packet inspection solution at the enclave boundaries. Verify any IA appliances used for deep packet inspection are connected, properly configured, and actively inspecting all ingress and egress network traffic.
Determine if a deny-by-default security posture has been implemented for both inbound and outbound traffic on the perimeter router or firewall. If a deny-by-default security posture has not been implemented at the network perimeter, this is a finding.
Implement a deny-by-default security posture on either the enclave perimeter router or firewall.
Review all network element configurations to ensure that an authentication server is being used. Then verify that a two-factor authentication method has been implemented. The RADIUS or TACACS server referenced in the configurations will call a two-factor authentication server. If two-factor authentication is not being used to access all network elements, this is a finding.
The network administrator must ensure strong two-factor authentication is being incorporated in the access scheme.
Review the network topology to determine that there are two NTP servers and what network they are connected to. Verify that they are both online according to the documented IP address. Where possible, deploy multiple gateways with diverse paths to the NTP servers. An alternative design is to have one server connected to a reference clock and the other server reference an external stratum-1 server. With this scenario, the NTP clients should be configured to prefer the stratum-1 server over the stratum-2 server. The NTP servers should be configured to easily scale by creating a hierarchy of lower level (stratum-2 to stratum-15) servers to accommodate the workload. The width and depth of the hierarchy is dependent on the number of NTP clients as well as the amount of redundancy that is required. If two NTP servers have not been deployed in the management network, this is a finding.
Deploy and implement at least two NTP servers in the management network.
Review the Bogon/Martian maintenance policy to validate plans and procedures are in place to protect the enclave from illegitimate network traffic with up to date Bogon/Martian rulesets. If the site does not have a policy to keep Bogon/Martian rulesets up to date, this is a finding.
Implement a Bogon/Martian maintenance policy to protect the enclave from illegitimate network traffic.
Review the network topology diagram to determine if a management network has been implemented. Validate the IP address space documented for this network by verifying the IP addresses referenced for management access (SSH, NTP, AAA, SNMP manager, Syslog server, etc.) to the managed network elements. If a management network has not been implemented, this is a finding.
Define a large enough address block that will enable the management network to scale in proportion to the managed network.
Review the network topology and verify that at least two syslog servers are located within the management network. Note the IP addresses as documented on the management network topology and verify that this is what is configured on the network elements as the host devices for sending syslog data. If a minimum of two syslog servers have not been deployed in the management network, this is a finding.
Stand up at least two syslog servers and connect them to the management network. Configure all managed network elements to send syslog data to the syslog servers.
Examine the syslog server to verify that it is configured to store messages for at least 30 days. Have the administrator show you the syslog files stored offline for one year. If the syslog messages are not kept online for thirty days and offline for one year, this is a finding.
Configure the syslog server to store messages for at least 30 days on-line. The administrator must establish a strategy for storing the logs off-line for minimum of 1 year.
At a minimum, a copy of the current and previous network element configurations must be saved. Storage can take place on a classified network, OOB network, or offline. If the current and previous network element configurations are not stored in a secured location, this is a finding.
The network administrator will store the current and previous router and switch configurations in a secure location. Storage can take place on a classified network, OOB network, or offline. Configurations can only be accessed by server or network admin.
Inspect the network element configurations that have been stored offline. If the configurations are not encrypted, this is a finding.
Encrypt all network device configurations stored offline.
Review the network topology and verify that an OOB network provides connectivity from the management network to all of the managed network elements. If an OOB network has not been deployed, verify that the network administrators have management access via the console to the managed network elements. If there is no OOB network or if network administrators do not have management access via the console to the managed network elements, this is a finding.
The network administrator will manage devices via direct connection or access via OOB management network.
Interview the ISSM and review the SSAA. GRE tunnels found on a premise or edge SIPRNet router that have an endpoint within the REL IP address space must be documented in the SSAA. If the REL LAN has not been documented in the SSAA, this is a finding.
The ISSM will document GRE tunnels defined on a premise or edge SIPRNet router that have an endpoint within the REL IP address space.
Have the ISSM disclose documentation that a REL LAN review has been performed annually. If annual reviews are not being performed, this is a finding.
The ISSM will document REL LAN reviews being performed annually.
Review the topology diagram of the classified network. If there are any leased circuits connecting to DoD Vendor, Foreign, or Federal Mission Partner enclave or network without a signed DoD CIO-approved sponsorship memo, this is a finding. If classified connectivity is not to a DSS-approved contractor facility or DoD Component-approved foreign government facility, this is a finding.
Terminate all leased circuits connecting to DoD Vendor, Foreign, or Federal Mission Partner enclave or network without a signed DoD CIO-approved sponsorship memo. Terminate all leased circuits for a classified network that is not connecting to a DSS-approved contractor facility or DoD Component-approved foreign government facility.
Review SIPRNet accreditation package and an Interim Authority to Connect/Authority to Connect (IATC/ATC) amending the connection approval received. If C2 and non-C2 exceptions are not documented, this is a finding.
Document all SIPRNet connections.
Review the network topology diagram. If there is a connection between the classified network and the unclassified network for the purpose of tunneling classified traffic across the unclassified IP network, verify that the IPsec VPN gateway used to provision the tunnel is compliant with appropriate physical security protection standards for processing classified information. If appropriate physical security protection has not been enforced, this is a finding.
Employ the necessary physical security protection for the VPN gateway devices used for tunneling classified traffic across the unclassified IP network.
Review the router configuration to determine if LDP and RSVP messages are being authenticated as shown in the examples below. If authentication is not being used for these protocols using a secured hashing algorithm for message authentication, this is a finding. An LDP session is secured by configuring a password for each LDP peer as shown in the example below: mpls ip mpls label protocol ldp mpls ldp neighbor 10.1.1.1 password xzxxxxxxxxxxx mpls ldp neighbor 10.3.3.3 password xxxxxzzzzxxxz The IP address 10.1.1.1 and 10.3.3.3 in this example are the router IDs of the neighbors for which this router has an LDP session requiring MD5 authentication. To specify that the router ID 10.1.1.1 is to be found in VPN routing/forwarding instance (VRF) named VPN1 instead of the global route table, the "vrf" keyword is used in the command as shown in the following example: mpls ldp neighbor vrf VPN1 10.1.1.1 password xxxxxxxxxxxxxxxxx A group of peers using the same MD5 password can be configured as shown in the example below: mpls ldp password for 10 xxxxxxxxxxxxxxx mpls ldp password required for 10 ! access-list 10 permit 10.1.1.1 access-list 10 permit 10.3.3.3 access-list 10 permit 10.4.4.4 The access list specifies a password is mandatory for LDP sessions with neighbors whose LDP router IDs are permitted by the access list. To configure MD5 or SHA-1 authentication for RSVP, both ip rsvp authentication key and ip rsvp authentication commands must be configured as shown in the example below. The latter command simply enables authentication. interface Ethernet0/0 ip address 192.168.101.2 255.255.255.0 ip rsvp bandwidth 7500 7500 ip rsvp authentication type sha-1 ip rsvp authentication key xxxxxxxx ip rsvp authentication Note: If SHA-1 is not specified using the ip rsvp authentication type command, MD5 will be utilized.
Implement neighbor authentication using a secured hashing algorithm for all signaling protocols deployed to build LSP tunnels.
Review the DISN-facing interfaces of the enclave perimeter routers to verify that LDP or RSVP is not enabled. If any of these interfaces are LDP or RSVP enabled, this is a finding.
Disable LDP and RSVP on DISN-facing interfaces on all perimeter routers.
Review the router configuration and verify that the "mpls ldp sync" command is configured on the IS-IS or OSPF configuration as shown in the following example: mpls ip mpls label protocol ldp ! interface POS0/3 ip router isis mpls ip ... ... ... router isis mpls ldp sync If not all MPLS routers synchronize IGP and LDP, this is a finding. Note: If the LDP peer is reachable, the IGP waits indefinitely (by default) for synchronization to be achieved. To limit the length of time the IGP session must wait, enter the "mpls ldp igp sync holddown" command. If the LDP peer is not reachable, the IGP establishes the adjacency to enable the LDP session to be established.
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.
In cases where VLANs do not span multiple switches it is a best practice to not implement STP. Avoiding the use of STP will provide the most deterministic and highly available network topology. If STP is required, then review the switch configuration to verify that RSTP or MSTP has been implemented. Following are example configurations: RSTP spanning-tree mode rapid-pvst MST spanning-tree mode mst spanning-tree mst configuration name Region1 revision 1 instance 1 vlan 10, 11, 12 instance 2 vlan 13, 14 If RSTP or MSTP has not been implemented where STP is required, this is a finding. Note: Note: Cisco has implemented RSTP as part of MSTP and Rapid-PVST+.
Configure Rapid STP be implemented at the access and distribution layers where VLANs span multiple switches.
Review each router and verify that a QoS policy has been configured to provide preferred treatment for control plane traffic and C2 real-time services. Step 1: Verify that the class-maps are configured to match on DSCP values that have been set at the edges as shown in the configuration example below: class-map match-all CONTROL_PLANE match ip dscp 48 class-map match-all C2_VOICE match ip dscp 47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af4 class-map match-all PREFERRED_DATA match ip dscp af3 Step 2: Verify that the policy map applied to the core-layer-facing interface reserves the bandwidth for each traffic type as shown in the following example: policy-map QOS_POLICY class CONTROL_PLANE priority percent 10 class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to the core-layer-facing interface as shown in the configuration example below: interface GigabitEthernet1/1 ip address 10.2.0.2 255.255.255.252 service-policy output QOS_POLICY If a QoS policy has not been implemented within the JIE WAN infrastructure to provide assured services for control plane traffic and C2 real-time services, this is a finding.
Configure a QoS policy on each router to provide assured services for control plane traffic and C2 real-time services.
By default, multicast is disabled globally as well as on all interfaces. Multicast routing is enabled on a router with the global command ip multicast-routing. PIM is enabled on an interface with either of the following commands: ip pim sparse-mode, ip pim dense-mode, ip pim sparse-dense-mode. If the global command ip multicast-routing is defined, review all interface configurations and verify that only the required interfaces are enabled for PIM. The following is a sample configuration with multicast routing enabled and PIM enabled on an interface. ip multicast-routing ! interface FastEthernet0/0 ip pim sparse-mode If PIM is not disabled on interfaces that are not supporting multicast, this is a finding.
The router administrator will disable PIM on all router interfaces that are not required to support multicast routing.
Step 1: Verify that an ACL is configured that will specify the allowable PIM neighbors similar to the following example. ip access-list standard pim-neighbors permit 192.0.2.1 permit 192.0.2.3 Step 2: Verify that a pim neighbor-filter command is configured on all PIM enabled interfaces that is referencing the PIM neighbor ACL similar to the following example: interface GigabitEthernet0/3 ip address 192.0.2.2 255.255.255.0 pim neighbor-filter pim-neighbors If PIM neighbor filter is not bound to interfaces that have PIM enabled, this is a finding.
The router administrator configures and binds a PIM neighbor filter to those interfaces that have PIM enabled.
The administratively-scoped IPv4 multicast address space is 239.0.0.0 through 239.255.255.255. Packets addressed to administratively-scoped multicast addresses must not cross administrative boundaries. This can be accomplished by applying a multicast boundary statement to all COI-facing interfaces as shown in the following example: ip multicast-routing ! interface FastEthernet0/0 ip address 199.36.92.1 255.255.255.252 ip pim sparse-mode ip multicast boundary 1 ! access-list 1 deny 239.0.0.0 0.255.255.255 access-list 1 permit any If inbound and outbound administratively-scoped multicast traffic is not blocked, this is a finding.
Configure a multicast boundary statement at all COI-facing interfaces that has PIM enabled to block inbound and outbound administratively-scoped multicast traffic.
To prevent Auto-RP messages from entering or leaving the PIM domain, the ip multicast boundary command must be configured on a COI-facing PIM-enabled interface. Verify that the referenced ACL denies multicast addresses 224.0.1.39 and 224.0.1.40, as shown in the example below: ip multicast-routing ! interface FastEthernet0/0 ip address 199.36.92.1 255.255.255.252 ip pim sparse-mode ip multicast boundary 1 ! access-list 1 deny 224.0.1.39 access-list 1 deny 224.0.1.40 If COI-facing interfaces do not block inbound and outbound Auto-RP discovery and announcement messages, this is a finding.
Block inbound and outbound Auto-RP discovery and announcement messages at external-facing PIM-enabled interfaces.
Verify that the RP router is configured to filter PIM register messages using the ip pim accept-register global command as shown in the example below. This command can reference either an ACL or a route-map to identify and prevent unauthorized sources or groups from registering with the RP. ip pim accept-register list PIM_REGISTER_FILTER ! ip access-list extended PIM_REGISTER_FILTER deny ip any 224.0.0.0 0.0.0.255 deny ip 0.0.0.0 0.255.255.255 any deny ip 1.0.0.0 0.255.255.255 any deny ip 2.0.0.0 0.255.255.255 any deny ip 5.0.0.0 0.255.255.255 any deny ip 7.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 23.0.0.0 0.255.255.255 any deny ip 27.0.0.0 0.255.255.255 any ... ... ... deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny ip 197.0.0.0 0.255.255.255 any deny ip 223.0.0.0 0.255.255.255 any deny ip 224.0.0.0 224.255.255.255 any permit ip any any If the RP router peering with customer PIM-SM routers is not configured with a PIM import policy to block registration messages for reserved multicast groups, this is a finding.
Configure RP routers to filter PIM register messages received from a tenant multicast DR for any reserved or any other undesirable multicast groups.
Verify that the RP router is configured to filter PIM join messages for any reserved multicast groups using the ip pim accept-rp global command as shown in the example below. The ip pim accept-rp global command causes the router to accept only (*, G) join messages destined for the specified RP address as allowed by the referenced access-list. ip pim accept-rp 10.10.2.1 PIM_JOIN_FILTER ! ip access-list standard PIM_JOIN_FILTER deny 224.0.1.2 deny 224.0.1.3 deny 224.0.1.8 deny 224.0.1.22 deny 224.0.1.24 deny 224.0.1.25 ... ... ... deny 225.1.2.3 deny 229.55.150.208 deny 234.42.42.42 255.255.255.252 deny 239.0.0.0 0.255.255.255 permit any Note: IOS 12.4T extends the ip multicast-routing command with a group-range or access-list argument that can be used to filter multicast control (PIM, IGMP) and data packets for unauthorized groups. If the RP router peering with customer PIM-SM routers is not configured with a PIM import policy to block join messages for reserved and any undesirable multicast groups, this is a finding.
RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block join messages for reserved and any undesirable multicast groups.
Review the configuration of the DR to verify that it is rate limiting the number of multicast register messages. If the DR is not limiting multicast register messages, this is a finding. The following is a PIM sparse mode configuration example that limits the number of register messages for each (S, G) multicast entry to 10 per second. ip multicast-routing ! interface FastEthernet 0/0 description link to core ip address 192.168.123.2 255.255.255.0 ip pim sparse-mode ! interface FastEthernet 0/1 description User LAN ip address 192.168.122.1 255.255.255.0 ip pim sparse-mode ! ip pim rp-address 1.1.1.1 ip pim register-rate 10
Configure the Designated Router (DR) to rate limit the number of multicast register messages it will allow for each (S, G) entry.
Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages allowing hosts to only join those groups that have been approved by the organization. If the DR is not filtering IGMP or MLD report messages, this is a finding. The following is a PIM sparse mode configuration example filtering specific multicast groups as defined in access-list 11 on the LAN-facing interface. ip multicast-routing ! interface FastEthernet 0/0 description link to core ip address 192.168.123.2 255.255.255.0 ip pim sparse-mode ! interface FastEthernet 0/1 description User LAN ip address 192.168.122.1 255.255.255.0 ip pim sparse-mode ip igmp access-group 11 ! access-list 11 permit 224.10.10.0 0.0.0.255 access-list 11 permit 224.11.11.0 0.0.0.255 access-list 11 permit 224.20.20.0 0.0.0.255
Configure the Designated Router (DR) to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) report messages to allow tenant hosts to join only those multicast groups that have been approved by the organization.
Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. If the DR is not limiting multicast join requests via IGMP or MLD, this is a finding. The following is a PIM sparse mode DR configuration example that limits the number of IGMP join requests on both a global and a per-interface basis ip multicast-routing ip igmp limit 80 ! interface FastEthernet 0/1 description User LAN121 ip address 192.168.122.1 255.255.255.0 ip pim sparse-mode ip igmp limit 50 ! interface FastEthernet 0/2 description User LAN122 ip address 192.168.122.1 255.255.255.0 ip pim sparse-mode ip igmp limit 50 Note: If both global and per interface state limiters are configured, the limits configured for per interface state limiters are still enforced but are constrained by the global limit.
Configure the Designated Router (DR) on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.
Review the multicast last-hop router configuration to verify that the SPT switchover threshold is increased (default is 0) or set to infinity (never switch over). The following is a PIM sparse mode last-hop router configuration example that will disable the SPT switchover for all multicast groups: ip multicast-routing ip pim spt-threshold infinity If any multicast router is not configured to increase the SPT threshold or set it to infinity to minimalize (S,G) state, this is a finding.
Configure the multicast router to increase the SPT threshold or set it to infinity to minimalize (S,G) state within the multicast topology where Any Source Multicast (ASM) is deployed.
Review the access switches connected to multicast last-hop routers to determine if IGMP snooping is enabled. The following are switch configuration examples with IGMP snooping enabled globally and on a per-VLAN basis: Enable IGMP Snooping globally: ip igmp snooping Enable IGMP Snooping for VLAN: ip igmp snooping vlan 7 If any switches within the ICAN access layer do not have IGMP or MLD snooping enabled, this is a finding.
Configure the switch to implement IGMP or MLD snooping, ensuring multicast traffic for any given multicast group is forwarded to only those hosts that have joined the group.
All routers or multilayer switches providing first-hop redundancy services must be configured to delay preemption to provide enough time for the IGP to stabilize. Review the router or multilayer switch providing first-hop redundancy services and verify that the preemption delay is configured. If preemption delay is not configured, this is a finding. Following is an HSRP configuration example that delays the preemption by 30 seconds. interface GigabitEthernet 0/0/0 ip address 10.11.0.2 255.255.255.0 standby 1 priority 110 standby 1 ip 10.21.0.1 standby 1 preempt standby 1 preempt delay minimum 30 Following is a VRRP configuration example that delays the preemption by 30 seconds. interface GigabitEthernet 0/0/0 ip address 10.11.0.2 255.255.255.0 vrrp 1 priority 110 vrrp 1 ip 10.21.0.1 vrrp 1 preempt delay minimum 30 For VRRP implementations, a preemptive scheme is enabled by default. If preemption is disabled using the no vrrp preempt command, the virtual router backup that is elected to become virtual router master remains the master until the original virtual router master recovers and becomes master again.
Configure each router and multilayer switch providing first-hop redundancy services to be configured to delay the preempt to provide enough time for the IGP to stabilize. Note: The amount of delay will be based on the number of IGP routes.