What changed in Cisco IOS Switch RTR STIG V3R4V3R4 changes

Cisco IOS Switch RTR STIG V3R4 (2026-09-30) replaced V3R3 (2026-04-01): 13 checks updated. It has 53 checks, against 53 in V3R3.

  • 0 added
  • 0 removed
  • 13 updated

Updated fields: Check text 12Fix text 2Discussion 2Title 1

Updated in V3R4 (13)

V-220423CAT IIThe Cisco switch must be configured to enable routing protocol authentication using FIPS 198-1 algorithms with keys not exceeding 180 days of lifetime.Check text

Check text

Review the switch configuration using the configuration examples below for BGP and OSPF. EIGRP, RIP, and IS-IS only support MD5 and will incur a permanent finding for those protocols. Note: The 180-day key lifetime is Not Applicable for the DODINDOWIN Backbone. The remainder of the requirement still applies. Verify that neighbor router authentication is enabled for all routing protocols. If neighbor authentication is not enabled this is a finding. Verify that authentication is configured to use FIPS 198-1 message authentication algorithms. If the routing protocol authentication is not configured to use FIPS 198-1 algorithms this is a finding. Verify that the protocol key lifetime is configured to not exceed 180 days. If any protocol key lifetime is configured to exceed 180 days this is a finding. BGP Example: key chain &ltKEY-CHAIN-NAME> tcp key &ltKEY-ID> send-id &ltID> recv-id &ltID> cryptographic-algorithm hmac-sha256 key-string &ltKEY> accept-lifetime 00:00:00 Jan 1 2022 duration 180 send-lifetime 00:00:00 Jan 1 2022 duration 180 ! ! router bgp &ltASN> no synchronization bgp log-neighbor-changes neighbor x.x.x.x remote-as &ltASN> neighbor x.x.x.x ao &ltKEY-CHAIN-NAME> Note: TCP-AO is used to replace MD5 in BGP authentication. OSPF Example: key chain OSPF_KEY_CHAIN key 1 key-string xxxxxxx send-lifetime 00:00:00 Jan 1 2018 23:59:59 Mar 31 2018 accept-lifetime 00:00:00 Jan 1 2018 01:05:00 Apr 1 2018 cryptographic-algorithm hmac-sha-256 key 2 key-string yyyyyyy send-lifetime 00:00:00 Apr 1 2018 23:59:59 Jun 30 2018 accept-lifetime 23:55:00 Mar 31 2018 01:05:00 Jul 1 2018 cryptographic-algorithm hmac-sha-256 … … … interface GigabitEthernet0/1 ip address x.x.x.x 255.255.255.0 ip ospf authentication key-chain OSPF_KEY_CHAIN

V-220433CAT IIThe Cisco switch must be configured to have Internet Control Message Protocol (ICMP) unreachable messages disabled on all external interfaces.Check text, Fix text

Check text

Review the configuration to verify the no ip unreachables command has been configured on all external interfaces as shown in the configuration example below: interface GigabitEthernet0/1 ip address x.x.x.x 255.255.255.0 no ip unreachables If ICMP unreachable notifications are sent from any external or null0 interface, this is a finding. Alternative - DODINDOWIN Backbone: Verify that the PE switch is configured to rate limit ICMP unreachable messages as shown in the example below: ip icmp rate-limit unreachable 60000 ip icmp rate-limit unreachable DF 1000 Note: In the example above, packet-too-big message (ICMP Type 3 Code 4) can be sent once every second, while all other destination unreachable messages can be sent once every minute. This will avoid disrupting Path MTU Discovery for traffic traversing the backbone while mitigating the risk of an ICMP unreachable DoS attack. If the PE switch is not configured to rate limit ICMP unreachable messages, this is a finding.

Fix text

Step 1: Disable ip unreachables on all external interfaces. SW1(config)#int g0/1 SW1(config-if)#no ip unreachables Step 2: Disable ip unreachables on the Null0 interface if it is used to backhole packets. SW1(config-if)#int null 0 SW1(config-if)#no ip unreachables Alternative - DODINDOWIN Backbone: Configure the PE switch to rate limit ICMP unreachable messages as shown in the example below: SW1(config)#ip icmp rate-limit unreachable df 100 SW1(config)#ip icmp rate-limit unreachable 100000 SW1(config)#end Alternative - Non-DODINDOWIN Backbone: An alternative for non-backbone networks (e.g., enclave, base, camp, etc.) is to filter messages generated by the switch and silently drop ICMP Administratively Prohibited and Host Unreachable messages using the following configuration steps: Step 1: Configure ACL to include ICMP Type 3 Code 1 (Host Unreachable) and Code 13 (Administratively Prohibited) as shown in the example below: SW1(config)#ip access-list ext ICMP_T3C1C13 SW1(config-ext-nacl)#permit icmp any any host-unreachable SW1(config-ext-nacl)#permit icmp any any administratively-prohibited SW1(config-ext-nacl)#exit Step 2: Create a route-map to forward these ICMP messages to the Null0 interface. SW1(config)#route-map LOCAL_POLICY SW1(config-route-map)#match ip address ICMP_T3C1C13 SW1(config-route-map)#set interface Null0 SW1(config-route-map)#exit Step 3: Configure no ip unreachables on the Null0 interface. SW1(config)#int null 0 SW1(config-if)#no ip unreachables SW1(config-if)#exit Step 4: Apply the policy to filter messages generated by the switch. SW1(config)#ip local policy route-map LOCAL_POLICY SW1(config)#end

V-220445CAT IIThe Cisco perimeter switch must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoW Instruction 8551.1.Title, Check text, Fix text, Discussion

Title

The Cisco perimeter switch must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoDW Instruction 8551.1.

Check text

Review the switch configuration to verify that the ingress ACL is in accordance with DoDDoW 8551.1. Step 1: Verify that an inbound ACL is configured on all external interfaces. interface GigabitEthernet0/2 ip address x.11.1.2 255.255.255.254 ip access-group EXTERNAL_ACL_INBOUND in Step 2. Review the inbound ACL to verify that it is filtering traffic in accordance with DoDDoW 8551.1. ip access-list extended EXTERNAL_ACL_INBOUND permit tcp any any established permit icmp host x.11.1.1 host x.11.1.2 echo permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … &lt must be in accordance with DoDDoW Instruction 8551.1> … deny ip any any log-input If the switch does not filter traffic in accordance with the guidelines contained in DoDDoW 8551.1, this is a finding.

Fix text

Configure the switch to use an inbound ACL on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DoDDoW Instruction 8551.1. SW1(config)#ip access-list extended EXTERNAL_ACL_INBOUND SW1(config-ext-nacl)#permit tcp any any established SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo SW1(config-ext-nacl)#permit icmp host x.11.1.1 host x.11.1.2 echo-reply … … &lt must be in accordance with DoDDoW Instruction 8551.1> … SW1(config-ext-nacl)#deny ip any any log-input SW1(config-ext-nacl)#exit SW1(config)#int g0/2 SW1(config-if)#ip access-group EXTERNAL_ACL_INBOUND in

Discussion

Vulnerability assessments must be reviewed by the System Administrator, and protocols must be approved by the Information Assurance (IA) staff before entering the enclave. Access 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 that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation. If the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with DoDDoW 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.

V-220458CAT IIIThe Cisco PE switch must be configured to enforce a Quality-of-Service (QoS) policy to provide preferred treatment for mission-critical applications.Check text

Check text

Review the switch configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications. Step 1: Verify that the class-maps are configured to match on DSCP values as shown in the configuration example below: class-map match-all C2_VOICE match ip dscp af47 class-map match-all VOICE match ip dscp ef class-map match-all VIDEO match ip dscp af41 class-map match-all CONTROL_PLANE match ip dscp cs6 class-map match-all PREFERRED_DATA match ip dscp af33 Step 2: Verify that the policy map reserves the bandwidth for each traffic type as shown in the example below: policy-map QOS_POLICY class C2_VOICE priority percent 10 class VOICE priority percent 15 class VIDEO bandwidth percent 25 class CONTROL_PLANE priority percent 10 class PREFERRED_DATA bandwidth percent 25 class class-default bandwidth percent 15 Step 3: Verify that an output service policy is bound to all interfaces as shown in the configuration example below: interface GigabitEthernet1/1 no switchport ip address 10.1.15.1 255.255.255.252 service-policy output QOS_POLICY ! interface GigabitEthernet1/2 no switchport ip address 10.1.15.4 255.255.255.252 service-policy output QOS_POLICY Note: Enclaves must mark or re-mark their traffic to be consistent with the DODINDOWIN backbone admission criteria to gain the appropriate level of service. A general DiffServ principle is to mark or trust traffic as close to the source as administratively and technically possible. However, certain traffic types might need to be re-marked before handoff to the DODINDOWIN backbone to gain admission to the correct class. If such re-marking is required, it is recommended that the re-marking be performed at the CE egress edge. Note: The GTP QOS document (GTP-0009) can be downloaded via the following link: https://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List If the switch is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.

V-220461CAT IIThe Cisco multicast switch must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.Discussion

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 DoDDoW 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 switches and passing through some switches to include only some of their interfaces." Therefore, it is imperative that the network engineers have documented their multicast topology and know which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.

V-237758CAT IIThe Cisco perimeter switch must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to verify that Router Advertisements are suppressed on all external IPv6-enabled interfaces as shown in the example below. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 nd ra suppress If the switch is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.

V-237761CAT IIThe Cisco perimeter switch must be configured to drop IPv6 undetermined transport packets.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is configured to drop IPv6 undetermined transport packets. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops undetermined transport packets as shown in the example below. ipv6 access-list FILTER_IPV6 deny ipv6 any any log undetermined-transport permit ipv6 … … … … deny ipv6 any any log If the switch is not configured to drop IPv6 undetermined transport packets, this is a finding.

V-237763CAT IIThe Cisco perimeter switch must be configured drop IPv6 packets with a Routing Header type 0, 1, or 3-255.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets with a Routing Header type 0, 1, or 3-255 as shown in the example below. ipv6 access-list FILTER_IPV6 permit ipv6 any host 2001:DB8::1:1:1234 routing-type 2 deny ipv6 any any log routing permit ipv6 … … … … deny ipv6 any any log Note: The example above allows routing-type 2 in the event Mobility IPv6 is deployed. If the switch is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255, this is a finding.

V-237765CAT IIThe Cisco perimeter switch must be configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops 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) as shown in the example below. ipv6 access-list FILTER_IPV6 deny hbh any any dest-option log permit ipv6 … … … … deny ipv6 any any log Note: Cisco has deprecated the dest-option-type command used to filter by option type within Hop-by-Hop header. Therefore, all packets with the Hop-by-Hop header option types must be dropped. If the switch is not configured to drop IPv6 packets containing a Hop-by-Hop header with destination options, this is a finding.

V-237771CAT IIThe Cisco perimeter switch must be configured to drop IPv6 packets containing a Destination Option header with invalid option type values.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Destination Option header with option type values of 0x05 (Switch Alert) or 0xC2 (Jumbo Payload) as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option log permit ipv6 … … … … deny ipv6 any any log Note: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped. If the switch is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.

V-237773CAT IIThe Cisco perimeter switch must be configured to drop IPv6 packets containing an extension header with the Endpoint Identification option.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Destination Option header as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option log permit ipv6 … … … … deny ipv6 any any log Note: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped. If the switch is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.

V-237775CAT IIThe Cisco perimeter switch must be configured to drop IPv6 packets containing the NSAP address option within Destination Option header.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch 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). Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Destination Option header as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option log permit ipv6 … … … … deny ipv6 any any log Note: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option header. Therefore, all packets with the Destination Option header must be dropped. If the switch is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.

V-237777CAT IIThe Cisco perimeter switch must be configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type.Check text

Check text

This requirement is not applicable for the DODINDOWIN Backbone. Review the switch configuration to determine if it is compliant with this requirement. Step 1: Verify that an inbound IPv6 ACL has been configured on the external interface. interface gigabitethernet1/0 ipv6 address 2001::1:0:22/64 ipv6 traffic-filter FILTER_IPV6 in Step 2: Verify that the ACL drops IPv6 packets containing a Destination Option header as shown in the example below. ipv6 access-list FILTER_IPV6 deny 60 any any dest-option log deny hbh any any dest-option log permit ipv6 … … … … deny ipv6 any any log Note: Cisco has deprecated the dest-option-type command used to filter by option type within the Destination Option and Hop-by-Hop header. Therefore, all packets with the Destination Option header and Hop-by-Hop options must be dropped. If the switch is not configured to drop IPv6 packets containing a Destination Option header, this is a finding.

How these changes are found

Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V3R4 no longer has.

Comparing other releases, or this one against an older release? Pick any two in STIG Compare.