acceptedThis Security Technical Implementation Guide is published as a tool to improve the security of Department of War (DoW) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 1 Benchmark Date: 28 Apr 20263.5.21.10.01<ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><ProfileDescription></ProfileDescription><GroupDescription></GroupDescription>NOKI-L2-000020<VulnDiscussion>Controlling local area network (LAN) access via 802.1x authentication can help prevent a malicious user from connecting an unauthorized personal computer to a switch port to inject or receive data from the network without detection. Satisfies: SRG-NET-000148-L2S-000015, SRG-NET-000343-L2S-000016</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000778CCI-001958Configure 802.1 x authentications on all host-facing access switch ports. To authenticate devices that do not support 802.1x, Media Access Control (MAC) Authentication Bypass must be configured. Configure dot1x radius policy: - exit all - configure system security dot1x radius-plcy <policy name> create - server <server index> address <server ip address> secret <secret key> - source-address <source address of the radius packet> - no shutdown Configure port dot1x authentication parameters: - configure port <port id> ethernet dot1x - radius-plcy <policy name> - port-control auto - per-host-authentication - allowed-source-macs <mac address> - no shutdownVerify Nokia router configuration has 802.1x authentication implemented for all access switch ports connecting to LAN outlets (i.e., RJ-45 wall plates) or devices not located in the telecom room, wiring closets, or equipment rooms. The 802.1x authentication is not required for switch ports connected to devices that do not support an 802.1x supplicant. For 7750 nodes, use the command below to verify dot1x "Authentication" status and list of "Allowed hosts" and "Disallowed hosts" is correct: - show system security dot1x Verify dot1x is enabled and configured for each port: - show port 1/1/c3/10 dot1x 802.1x Port Status Port control : auto Port status : authorized Authenticator PAE state : authenticated Backend state : idle Reauth enabled : no Reauth period : N/A Max auth requests : 2 Transmit period : 30 Supplicant timeout : 30 Server timeout : 30 Quiet period : 60 Radius policy : test Radius server plcy auth : N/A Radius server plcy acct : N/A Untagged tunneling : false Dot1q tunneling : true Qinq tunneling : true Per-host authentication : enabled MAC-based authentication: disabled Authenticator Initiation: true Allowed hosts : 1 (max 100) Disallowed hosts : 1 Admin-state : enabled If 802.1x authentication is not configured on all access switch ports connecting to LAN outlets or devices not located in the telecom room, wiring closets, or equipment rooms, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000040<VulnDiscussion>DoS is a condition when a resource is not available for legitimate users. Packet flooding distributed denial-of-service (DDoS) attacks are referred to as volumetric attacks and have the objective of overloading a network or circuit to deny or seriously degrade performance. This denies access to the services that normally traverse the network or circuit. Volumetric attacks have become relatively easy to launch by using readily available tools such as Low Orbit Ion Cannon or by using botnets. Measures must be taken to mitigate the effects of a successful volumetric attack to ensure sufficient capacity is available for mission-critical traffic. Managing capacity may include, for example, establishing selected network usage priorities or quotas and enforcing them using rate limiting, Quality of Service (QoS), or other resource reservation control methods. These measures may also mitigate the effects of sudden decreases in network capacity that are the result of accidental or intentional physical damage to telecommunications facilities (such as cable cuts or weather-related outages).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-001095Implement a QoS policy for traffic prioritization and bandwidth reservation. This policy must enforce the traffic priorities specified by the CC/S/As. Following is one of multiple ways to create a QoS policy. Configure sap-ingress and/or sap-egress QoS policies: - configure qos sap-ingress <id> create - configure qos sap-egress <id> create For each sap-ingress and sap-egress QoS policy, create as many policers as needed: - policer <policer id> create - percent-rate <value> cir <value> - mbs <value in kbytes> - cbs <value in kbytes> - back Create as many forwarding classes as needed. Forwarding classes can be created using ip-criteria, Differentiated Services Code Point (DSCP) bits in IP header, Precedence bits (IP header), and dot1p bits (Ethernet header). Because this is a layer 2 switch requirement, the example below is using dot1p bits: - fc <forwarding class> create - policer <policer id> - back - dot1p <dot1p value> fc <forwarding class> priority {low or high} - exit For network policy, copy the default network policy 1 into a new network policy and modify parameters as needed: - configure qos copy network 1 <network policy id> To list the entries in the network policy created: - configure qos network <network policy id> - info detail Modify the parameters as needed, or use the "no" form of the command to remove them from the configuration. Configure network QoS queues: - configure qos network-queue <network queue id> create - queue <queue id> <queue type> create - rate <pir percent> cir <cir percent> fir <fir percent> - mbs <percentage> - cbs <percentage> Configure as many queues as needed. Create as many forwarding classes as needed and assign a queue to them: - fc <name of forwarding class> create - multicast-queue <queue id> - queue <queue id> QoS policies are applied at the ingress or egress of the access and network ports. For access interfaces: - configure service <service id> sap <sap id> ingress qos <sap ingress qos policy id> - configure service <service id> sap <sap id> egress qos <sap egress qos policy id> For network interfaces: - configure router interface <interface name> qos <network qos policy id>Review the Nokia router configuration to verify QoS has been enabled to ensure sufficient capacity is available for mission-critical traffic such as voice and enforce the traffic priorities specified by the Combatant Commands/Services/Agencies (CC/S/As). Nokia routers have default QoS policy "1" applied to all ports and service access points (SAPs). Based on the network requirements, another QoS policy should be defined and applied to all ports. Use the commands below to verify the QoS policies defined and where the policies are applied: For sap-ingress policies: - show qos sap-ingress association Associations Service-Name : 10 Service-Id : 10 (VPLS) Customer-Id : 1 - SAP : 1/1/c3/10 For sap-egress policies: - show qos sap-egress association Associations Service-Name : 900 Service-Id : 900 (VPLS) Customer-Id : 1 - SAP : lag-4:900 For network policies: - queue <queue id> - show qos network <policy id> detail Interface Association Interface : to-sr-1-24d-a IP Addr. : 192.168.1.2/30 Port Id : 1/1/c9/1 IPv6 Addr. : 2001:400:0:3::2/64 Interface : to-sr-1-24d-b IP Addr. : 192.168.2.1/30 Port Id : 1/1/c10/1 - show qos network-queue association Port-id : 1/1/c3/1 Port-id : 1/1/c3/2 Port-id : 1/1/c3/3 Port-id : 1/1/c3/4 If the switch is not configured to implement a QoS policy, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000070<VulnDiscussion>Spanning Tree Protocol (STP) does not provide any means for the network administrator to securely enforce the topology of the switched network. Any switch can be the root bridge in a network. However, a more optimal forwarding topology places the root bridge at a specific predetermined location. With the standard STP, any bridge in the network with a lower bridge ID takes the role of the root bridge. The administrator cannot enforce the position of the root bridge but can set the root bridge priority to "0" in an effort to secure the root bridge position. The root guard feature provides a way to enforce the root bridge placement in the network. If the bridge receives superior STP Bridge Protocol Data Units (BPDUs) on a root guard-enabled port, root guard moves this port to a root-inconsistent STP state, and no traffic can be forwarded across this port while it is in this state. To enforce the position of the root bridge, it is imperative that root guard is enabled on all ports where the root bridge should never appear.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385Configure the virtual private local area network service (VPLS) to have Root Guard enabled on all switch ports connecting to access layer switches and hosts. Enable root guard for configured VPLS access ports where required using the command below: - configure service vpls <vpls service id> - sap <port id:vlan tag> - stp root-guardReview the switch topology and the configuration to verify Root Guard is enabled on all switch ports connecting to access layer switches and hosts. Use the command below for each port connecting to access layer switches and verify "Root Guard" is enabled: - show service id 10 sap 1/1/c3/10 stp | match "Root Guard" Root Guard : Enabled Active Protocol : N/A If the switch has not enabled Root Guard on all switch ports connecting to access layer switches and hosts, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000090<VulnDiscussion>The STP loop guard feature provides additional protection against STP loops. An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. In its operation, STP relies on continuous reception and transmission of Bridge Protocol Data Units (BPDUs) based on the port role. The designated port transmits BPDUs, and the nondesignated port receives BPDUs. When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes a designated port and moves to a forwarding state. This situation creates a loop. The loop guard feature makes additional checks. If BPDUs are not received on a nondesignated port and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state. Satisfies: SRG-NET-000362-L2S-000023, SRG-NET-000362-L2S-000022</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385Configure the Nokia router VPLS service to disable STP for untrusted ports: - configure service vpls <service id> sap <sap id> stp shutdownReview the router configuration to verify BPDU Guard is enabled on the virtual private local area network service (VPLS) for all user-facing or untrusted access switch ports. BPDUs received will be discarded on service access ports when STP on the VPLS is administratively enabled and the administrative state of STP is disabled. To verify STP is disabled on the service access ports, use the command below and verify "Stp Admin State" is set to "Down": - show service id 10 stp Stp port info Sap/Sdp/PIP Id Oper- Port- Port- Port- Oper- Link- Active State Role State Num Edge Type Prot. 1/1/c3/10 Down N/A Discard N/A N/A Pt-pt N/A If the switch has not disabled STP for untrusted user-facing ports, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000100<VulnDiscussion>Access layer switches use the Content Addressable Memory (CAM) table to direct traffic to specific ports based on the virtual local area network (VLAN) number and the destination Media Access Control (MAC) address of the frame. When a router has an Address Resolution Protocol (ARP) entry for a destination host and forwards it to the access layer switch and there is no entry corresponding to the frame's destination MAC address in the incoming VLAN, the frame will be sent to all forwarding ports within the respective VLAN, which causes flooding. Large amounts of flooded traffic can saturate low-bandwidth links, causing network performance issues or complete connectivity outage to the connected devices. Unknown unicast flooding has been a nagging problem in networks that have asymmetric routing and default timers. To mitigate the risk of a connectivity outage, the Unknown Unicast Flood Blocking (UUFB) feature must be implemented on all access layer switches. The UUFB feature will block unknown unicast traffic flooding and only permit egress traffic with MAC addresses that are known to exit on the port.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385Configure the Nokia router VPLS service to have Unknown discard enabled: - configure service vpls <service id> discard-unknownReview the router virtual private local area network service (VPLS) configuration and verify discard-unknown is enabled for VPLS service. The discard-unknown feature discards packets with unknown destination MAC addresses. Use the command below and verify "Discard Unknown" is enabled: - show service id 10 all | match "Discard Unknown" Mac Learning : Enabled Discard Unknown : Enabled If "Discard Unknown" is disabled, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000110<VulnDiscussion>In an enterprise network, devices under administrative control are trusted sources. These devices include the switches, routers, and servers in the network. Host ports and unknown DHCP servers are considered untrusted sources. An unknown DHCP server on the network on an untrusted port is called a spurious DHCP server. This includes any device (personal computer, wireless access point) that is loaded with DHCP server enabled. The DHCP snooping feature determines whether traffic sources are trusted or untrusted. The potential exists for a spurious DHCP server to respond to DHCPDISCOVER messages before the real server has time to respond. DHCP snooping allows switches on the network to trust the port a DHCP server is connected to and not trust the other ports. The DHCP snooping feature validates DHCP messages received from untrusted sources, filters out invalid messages, and rate-limits DHCP traffic from trusted and untrusted sources. The DHCP snooping feature builds and maintains a binding database, which contains information about untrusted hosts with leased IP addresses, and uses the database to validate subsequent requests from untrusted hosts. Other security features, such as IP Source Guard and Dynamic Address Resolution Protocol (ARP) Inspection (DAI), also use information stored in the DHCP snooping binding database. Therefore, it is imperative that the DHCP snooping feature is enabled on all VLANs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385Configure the switch to have DHCP snooping for all user VLANs to validate DHCP messages from untrusted sources. Configure DHCP snooping for all user service access points: - configure service vpls <vpls service id> sap <sap id> dhcp - snoop - no shutdownUse the command below for each virtual private local area network service (VPLS) and verify the status of DHCP for all user VLANs: - show service id 10 dhcp summary DHCP Summary, service 10 Sap/Sdp Snoop Used/ Arp Reply Info Admin Provided Agent Option State sap:1/1/c3/10 Yes 0/1 Yes Keep Up Number of Entries : 1 If the switch does not have DHCP snooping enabled for all user VLANs to validate DHCP messages from untrusted sources, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000120<VulnDiscussion>Source IP address filtering on a layer 2 port prevents a malicious host from impersonating a legitimate host by assuming the legitimate host's IP address. The feature uses Dynamic Host Configuration Protocol (DHCP) snooping and static IP source binding to match IP addresses to hosts on untrusted layer 2 access ports. Initially, all IP traffic on the protected port is blocked except for DHCP packets. After a client receives an IP address from the DHCP server, or after static IP source binding is configured by the administrator, all traffic with that IP source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host's ability to attack the network by claiming a neighbor host's IP address.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385Configure the Nokia router VPLS service to enable DHCP snooping at all points where DHCP messages requiring snooping enter the VPLS service: - configure service vpls <service id> sap <sap id> dhcp snoop Populate the DHCP lease state information extracted from snooped DHCP ACK messages. If the optional number "lease state table entries allowed" is omitted, only a single entry is allowed. Once the maximum number of entries has been reached, subsequent lease state entries are not allowed, and DHCP ACK messages are discarded. - configure service vpls <service id> sap <sap id> dhcp lease-populate <number of DHCP leases allowed> Enable anti-spoof filtering for untrusted VPLS service access points. Anti-spoof type can be ip, ip-mac, or mac. When type "ip" is used, only the source IP address is used in its lookup. The "ip-mac" type uses both the IP address and source MAC address in its lookup, while the "mac" type uses only the source MAC address in its lookup. If an entry does not match the ingress packet, the packet is silently discarded while incrementing the SAP discard counter. - configure service vpls <service id> sap <sap id> anti-spoof <anti-spoof type>Review the router virtual private local area network service (VPLS) configuration and verify an equivalent command for the Dynamic Address Resolution Protocol Inspection feature is enabled on all user virtual local area networks (VLANs). Verify both "DHCP snooping" and "lease populate" options under DHCP result for each service access point (SAP) configured within a VPLS service: - show service id 10 sap 1/1/c3/10 detail | match "Anti Spoofing" Anti Spoofing : Ip-Mac Dynamic Hosts : Enabled Using the same command, verify "Anti Spoofing" is enabled with type IP-MAC. If this is not enabled on all user VLANs, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000130<VulnDiscussion>DAI intercepts ARP requests and verifies that each of these packets has a valid IP-to-MAC address binding before updating the local ARP cache and forwarding the packet to the appropriate destination. Invalid ARP packets are dropped and logged. DAI determines the validity of an ARP packet based on valid IP-to-MAC address bindings stored in the Dynamic Host Configuration Protocol (DHCP) snooping binding database. If the ARP packet is received on a trusted interface, the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-002385The system evaluates ARP replies and requests received on a SAP with arp-reply-agent enabled against the anti-spoof filter entries associated with the ingress SAP. ARPs from unknown hosts on the SAP are discarded when anti-spoof filtering is enabled. Configure the Nokia router VPLS service to enable DHCP snooping at all points where DHCP messages requiring snooping enter the VPLS service: - configure service vpls <service id> sap <sap id> dhcp snoop Populate the DHCP lease state information extracted from snooped DHCP ACK messages. If the optional number "lease state table entries allowed" is omitted, only a single entry is allowed. Once the maximum number of entries has been reached, subsequent lease state entries are not allowed, and DHCP ACK messages are discarded. - configure service vpls <service id> sap <sap id> dhcp lease-populate <number of DHCP leases allowed> Enable anti-spoof filtering for untrusted VPLS service access points. Anti-spoof type can be ip, ip-mac, or mac. When type "ip" is used, only the source IP address is used in its lookup. The "ip-mac" type uses both IP address and the source MAC address in its lookup, while the "mac" type uses only the source MAC address in its lookup. If an entry does not match the ingress packet, the packet is silently discarded while incrementing the SAP discard counter. - configure service vpls <service id> sap <sap id> anti-spoof <anti-spoof type> Enable arp-reply-agent: - configure service vpls sap <sap id> arp-reply-agentReview the virtual private local area network service (VPLS) configuration and verify an equivalent command for the DAI feature is enabled on all user VLANs. Verify both "DHCP snooping" and "lease populate" options under DHCP result for each service access point (SAP) within a VPLS service: -show service id 10 sap 1/1/c3/10 detail | match "Anti Spoofing" Anti Spoofing : Ip-Mac Dynamic Hosts : Enabled - show service id 10 sap 1/1/c3/10 detail | match "ARP Reply Agent" ARP Reply Agent : Enabled Host Conn Verify : Disabled Using the same command, verify "Anti Spoofing" is enabled with type IP-MAC, and "ARP Reply Agent" is also enabled. If these are not enabled on all user VLANs, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000140<VulnDiscussion>A traffic storm occurs when packets flood a LAN, creating excessive traffic and degrading network performance. Traffic storm control prevents network disruption by suppressing ingress traffic when the number of packets reaches configured threshold levels. Traffic storm control monitors ingress traffic levels on a port and drops traffic when the number of packets reaches the configured threshold level during any one-second interval.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Configure storm control on each host-facing switch port. - configure port <port id> ethernet ingress-rate <value in mbps>Review the router configuration to verify traffic is rate limited on host-facing interfaces. Use the command below for each host-facing port and verify "Ingress Rate" is set to the required value: - show port 1/1/c3/1 | match "Ingress Rate" Egress Rate : Default Ingress Rate : 500 If storm control is not enabled on all host-facing switch ports, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000150<VulnDiscussion>IGMP and MLD snooping provides a way to constrain multicast traffic at layer 2. By monitoring the IGMP or MLD membership reports sent by hosts within a VLAN, the snooping application can set up layer 2 multicast forwarding tables to deliver specific multicast traffic only to interfaces connected to hosts interested in receiving the traffic. This significantly reduces the volume of multicast traffic that would otherwise flood the VLAN.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Configure IGMP or MLD snooping for IPv4 and IPv6 multicast traffic respectively for each VLAN. The igmp-snooping and mld-snooping can be configured at the VPLS service level or for each access point (VLAN). For VPLS service-level configuration: - configure service vpls <service id> igmp-snooping no shutdown - configure service vpls <service id> mld-snooping no shutdown For VPLS service access point-level configuration: - configure service vpls <service id> sap <sap id> igmp-snooping - configure service vpls <service id> sap <sap id> mld-snoopingReview the switch configuration to verify IGMP or MLD snooping has been configured for IPv4 and IPv6 multicast traffic respectively. Use the command below for each virtual private local area network service (VPLS) and verify the state of IGMP snooping and MLD snooping: - show service id 10 igmp-snooping base IGMP Snooping Base info for service 10 Admin State : Up Querier : No querier found SBD service : N/A Evpn-proxy : Disabled Port Oper MRtr Pim Send Max Max Max MVR Num Id Stat Port Port Qrys Grps Srcs Grp From-VPLS Grps Srcs sap:1/1/c3/10 Up No No No None None None Local 0 - show service id 10 mld-snooping base MLD Snooping Base info for service 10 Admin State : Up Querier : No querier found SBD service : N/A Evpn-proxy : Disabled Port Oper MRtr Send Max MVR Num Id Stat Port Qrys Grps From-VPLS Grps sap:1/1/c3/10 Up No No None Local 0 If the switch is not configured to implement IGMP or MLD snooping for each VLAN, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000160<VulnDiscussion>STP is implemented on bridges and switches to prevent layer 2 loops when a broadcast domain spans multiple bridges and switches and when redundant links are provisioned to provide high availability in case of link failures. Convergence time can be reduced significantly using RSTP (802.1w) instead of STP (802.1d), resulting in improved availability. RSTP should be deployed by implementing either Rapid Per-VLAN Spanning Tree (Rapid-PVST) or Multiple Spanning Tree Protocol (MSTP). The latter scales much better when there are many VLANs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Configure RSTP to be implemented at the access and distribution layers where VLANs span multiple switches. For VPLS services where RSTP should be implemented, use the command below to enable RSTP for an already-created VPLS service: - configure service vpls <vpls id> - stp mode rstp - no shutdownIn 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, review the router virtual private local area network service (VPLS) configuration to verify RSTP has been implemented. Use the command below and verify STP mode is set to RSTP for VPLS, where RSTP should be implemented. - show service id 10 stp | match Mode Mode : Rstp Last Top. Change : 0d 00:00:00 If RSTP has not been implemented where STP is required, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000170<VulnDiscussion>In topologies where fiber optic interconnections are used, physical misconnections can occur that allow a link to appear to be up when there is a mismatched set of transmit/receive pairs. When such a physical misconfiguration occurs, protocols such as Spanning Tree Protocol (STP) can cause network instability. Enabling ETH-CFM is the standard and most effective way to protect a layer 2 service against one-way (unidirectional) connections on a Nokia 7750 SR. The constant, bidirectional exchange of Continuity Check Messages (CCMs) provides an "always-on" monitoring system. It ensures that connectivity is healthy in both directions, detecting silent failures that would be missed by on-demand tests such as a loopback (ping).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Configure the ETH-CFM maintenance domain and bind the Maintenance Endpoint (MEP) to the SAP to be monitored. Use the CCMs to detect possible unidirectional issues. Configure ETH-CFM domain information: - configure eth-cfm domain <domain id> format none level <level> - association 1 format icc-based name <name> - bridge-identifier bridge-name <vpls service name> - back - remote-mepid <mep id> Apply to the SAP within VPLS: - configure service vpls <id> - sap <sap id> eth-cfm mep <mep id> domain <domain id> association <index> - ccm-enable - no shutdownVerify the ETH-CFM configuration for the service access point (SAP) in the virtual private local area network service (VPLS) appears as shown in the example below. - show service id 10 sap 1/1/c3/10 detail Eth-Cfm MEP Configuration Information Md-index : 3 Direction : Down Ma-index : 1 Admin : Enabled MepId : 10 CCM-Enable : Enabled If ETH-CFM is not configured to protect against one-way connections, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000190<VulnDiscussion>A disabled port assigned to a user or management VLAN could be enabled accidentally or by an attacker. As a result, the attacker could gain access to that VLAN as a member. Satisfies: SRG-NET-000512-L2S-000007, SRG-NET-000512-L2S-000009, SRG-NET-000512-L2S-000010, SRG-NET-000512-L2S-000011, SRG-NET-000512-L2S-000012, SRG-NET-000512-L2S-000013</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Note: Switch ports configured for 802.1x are exempt from this requirement. Assign all VPLS service ports not in use to an inactive VLAN. Configure VPLS service access ports with either dot1q or qinq encapsulation: - configure port <port id> ethernet encap-type <dot1q or qinq> Configure unused SAPs with inactive VLAN tag in VPLS SAP configurations: - configure service vpls <service id> - sap <port id:vlan tag> createNote: Switch ports configured for 802.1x are exempt from this requirement. Review Nokia router configurations and examine all access switch ports. Each access switch port not in use should have membership to an inactive VLAN that is not used for any purpose. For any port to be part of a VPLS service, the port must be configured for that service. Just enabling a port does not give the port access to a bridge domain. VLAN configuration is also part of configuring a port for a VPLS service. Use the command below to verify all VLAN tags used for all VPLS services. Pay attention to wildcard "*" usage in the VLAN tag portion of the service access point (SAP) ID configuration. When the wild card "*" is configured in the VLAN tag portion of the SAP, it allows all VLAN tags. - show service sap-using Service Access Points PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr 1/1/c1/1:200 200 1 none 1 none Up Up 1/1/c1/1:300 300 1 none 1 none Up Up If a port is configured with null encapsulation, it will allow all VLAN tags. Verify access ports are configured with "Port Encp" set to "dotq" or "qinq": - show port Ports on Slot 1 Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX 1/1/c1/1 Up Yes Up 1518 1518 - accs dotq cgige 1/1/c2 Up Link Up conn 100G CWDM4 M* If any access switch ports are not in use and not in an inactive VLAN, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000200<VulnDiscussion>In a VLAN-based network, switches use the default VLAN (i.e., VLAN 1) for in-band management and to communicate with other networking devices using Spanning Tree Protocol (STP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP), which is all untagged traffic. As a consequence, the default VLAN may unwisely span the entire network if not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-000366Remove the assignment of the default VLAN from all access switch ports. Remove the access VPLS service ports using the default VLAN or wildcard VLAN tag "*" in VPLS SAP configurations: - configure service vpls <service id> - sap <port id:vlan tag> shutdown - no sap <port id:vlan tag>Review the switch configurations and verify no access switch ports have been assigned membership to the default VLAN (i.e., VLAN 1). The service access points (SAPs) are configured to allow specific VLANs. Use the command below and verify the VLAN tag used for all SAPs. When wild card "*" is configured in the VLAN tag portion of the SAP, it allows all VLAN tags, including VLAN 1. For any port to be part of a virtual private local area network service (VPLS), the port must be configured for that service. Just enabling a port does not give the port access to a bridge domain. VLAN configuration is also part of configuring a port for a VPLS service. - show service sap-using Service Access Points PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr 1/1/c1/1:200 200 1 none 1 none Up Up 1/1/c1/1:300 300 1 none 1 none Up Up If a port is configured with null encapsulation, it will allow all VLAN tags. Verify access ports are configured with "Port Encp" set to "dotq" or "qinq": - show port Ports on Slot 1 Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX 1/1/c1/1 Up Yes Up 1518 1518 - accs dotq cgige 1/1/c2 Up Link Up conn 100G CWDM4 M* If access ports are assigned to the default VLAN, this is a finding.<GroupDescription></GroupDescription>NOKI-L2-000270<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Nokia SR OS 25.x L2SDISADPMS TargetNokia SR OS 25.x L2S5743CCI-004891Configure the layer 2 switch to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. A layer 2 switch VPLS service is a logically separate subnetwork. Configure a VPLS service using the following commands: - configure service vpls <vpls service id> customer <customer id> create - sap <port id:vlan tag if needed> create - back Add as many service access point (SAP) access ports as needed. If connection to a remote site is needed, add a service distribution point (SDP) tunnel to the remote endpoint: - spoke-sdp: <sdp id>:<vc id> create - back - no shutdownVerify the layer 2 switch is configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions. Logical layer 2 switch separation is configured using separate virtual private local area network services (VPLS). Verify VPLS services created and access ports configured for each VPLS service using the commands below. To view all the VPLS services created, use the following command: - show service service-using vpls Services [vpls] =============================================================================== ServiceId Type Adm Opr CustomerId Service Name ------------------------------------------------------------------------------- 200 VPLS Up Up 1 200 300 VPLS Up Up 1 300 Use the command below to view all the access points that are part of each VPLS service: - show service id 200 base | match sap sap:1/1/c1/1:200 q-tag 1518 1518 Up Up If the layer 2 switch is not configured to implement physically or logically separate subnetworks to isolate organization-defined critical system components and functions, this is a finding.