Access Control Lists (ACLs)

Contents

1. Introduction and Overview
2. Standard ACLs
3. Extended ACLs
4. Time-based ACLs
5. Infrastructure ACLs
6. Reflexive ACLs
7. Dynamic ACLs
8. Other ACL Features
9. IPv6

Introduction and Overview

An Access Control List (ACL) is a sequential list of rules containing permit or deny statements, that are used to match packets. When applied to interfaces, ACLs are used to perform a network control service. Each rule in the ACL is known as an Access Control Entry (ACE); sometimes referred to as ACL statements. Each ACE can permit or deny specific traffic. Depending on the type of ACL, each ACE contains match criteria that packets transiting the device are subjected to such as:

• Source and destination IP address
• IP protocols such as TCP, UDP, ICMP, OSPF, EIGRP etc
• TCP/UDP source and destination port numbers

The original intent when introducing ACLs was packet filtering. ACLs have since been deployed to provide multiple network functions such as:

• Quality of Service (QoS) operations such as queueing, traffic classification for policing
• Policy-based routing (PBR)
• Route maps
• Network identification in routing protocols
• Route modification/filtering
• Management plane restrictions
• Object tracking

Processing of ACLs

The following description of ACLs applies to ACLs in packet filtering. Reference may be made to the application of ACLs in other features supported by routers or multi-layer switches.

The most common application of ACLs, in enterprise networks, is in packet filtering. By default, routers do not filter traffic; they examine the destination IP address of an IPv4/IPv6 packet and refer to the routing table to determine the egress interface. When an ACL is applied to a router interface:

1. It evaluates all transiting packets
2. Determines if a packet is permitted or denied based on the ACEs.

A router processing an ACL checks the header of each packet to determine whether it matches the criteria specified in any ACE of an ACL. If a match is found, the packet is forwarded or dropped as specified in the ACE (permit or deny) and further processing of the ACL ends:

• A permit action allows the packet through.
• A deny action results in a dropped packet.

Sequence numbers have a default increment of 10; with the first ACE having a sequence number of 10, 2^nd 20, 3^rd 30 and so on. ACL entries are processed sequentially from top to bottom of the list. By default, ACLs have an implicit deny added at the bottom of the ACL and these ACLs are used for through-the-box access rules. Management ACLs control to-the-box traffic; these ACLs do not have the implicit deny at the end of the ACL.

ACLs can be applied in the inbound or outbound directions from the perspective of the router. An inbound ACL filters packets coming into an interface but before any route processing takes place. An outbound ACL filters packets after route processing. If a packet matches any of the ACEs in an ACL, the action (permit or deny) is applied and the router immediately stops processing the ACL. The first match ends the processing of an ACL regardless of whether subsequent ACEs in the ACL match the packet. Because of this, when configuring ACLs, the ordering of the ACEs is extremely important.

Note: ACLs for traffic filtering do not block local router generated traffic in the egress direction.

Ordering of ACEs

When defining network ranges to be permitted or denied by an ACL, the more specific address entries should be configured before the general entries. The most specific network address entry is that defining a specific interface IP address using the keyword host or wildcard bit 0.0.0.0. These should then be followed by the more general wildcard bits. An illustrative example is:

• deny host 192.168.1.1
• permit 192.168.1.0 0.0.0.127
• deny 192.168.1.0 0.0.0.255

If the more specific addresses are entered after the more general addresses which overlap the more specific address i.e., the more specific address is a subset of the more general address, IOS will display an error message.

R2(config-std-nacl)#5 deny 192.168.3.0 0.0.0.255
% Access rule can't be configured at lower sequence num as Host at sequence 10 is part of the given address block

Wildcard Bits

ACLs use wildcard bits and not subnet masks to match binary 0s and 1s of the IP address. Unlike subnet masks, wildcard masks use 0 = match, 1 = ignore. Wildcard bits allow for more specific matching of traffic compared to subnet masks. The bits that are set to zero in a wildcard bit must match. For example; 172.16.1.1 0.15.255.255 matches addresses in the range 172.16.1.1 172.31.255.255. Wildcard bits use the following rules to match binary 0s and 1s:

• Wildcard bit 0: Match the corresponding bit value in the address.
• Wildcard bit 1: Ignore the corresponding bit value in the address (do not care).

Unlike wildcard masks used in OSPF, EIGRP, wildcard bits do not have to be contiguous; they can be on or off anywhere to represent sections of the IP address that have to match and sections that do not have to match. To determine the wildcard bits to use when configuring an ACL, subtract the subnet mask value (in dotted decimal notation) from the broadcast subnet mask i.e., 255.255.255.255 (/24).

Matching Subnets

Example 1

If an IP address 192.168.1.0 has a subnet mask of 255.255.255.0, then the wildcard bits can be determined as follows:

Logging, Debugging, Timestamps, Sequence Numbers

Introduction and Overview

Logging aims to answer the three questions: what, when, who? Log messages are generated by the various services and protocols running on a network device. By default, output from system messages and debug commands is sent to a logging process. The logging process controls the distribution of logging messages to various destinations, such as the logging buffer, terminal lines, syslog server. Messages are also sent to the console. These are then viewed using syslog, local logging, debugs, conditional debugs.

Logging can be used for fault identification, security auditing and network forensics; for monitoring the network and performance of network devices. Additional purposes include regulatory compliance.

Log messages include a timestamp that indicates the time when the log was generated. It is important to note that the time must be accurate. This can be done by configuring NTP to provide accurate datetime values. The time must be consistent across all network devices; troubleshooting can be difficult if you cannot correlate timestamps across devices.

Logging Messages

Syslog messages can be output to the console, local buffer or remote syslog server. The messages follow this format:

%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: message text

Where:

• FACILITY-SUBFACILITY: protocol, module or process that generated the message.
• SEVERITY: This is a level from 0 - 7 that specifies how important the message is. The following table displays all the logging severity levels available:

  Level Number	Severity	Description	Syslog Definition
  0	Emergencies	System is unusable	LOG_EMERG
  1	Alerts	Action must be taken immediately	LOG_ALERT
  2	Critical	Critical conditions	LOG_CRIT
  3	Errors	Error conditions	LOG_ERR
  4	Warnings	Warning conditions	LOG_WARNING
  5	Notifications	Normal but significant conditions	LOG_NOTICE
  6	Informational	Informational messages	LOG_INFO
  7	Debugging	Debug-level messages	LOG_DEBUG

  When you enable logging for a specific level, it also enables all levels above it. For example, if you enable level 4(warnings), it also will enable levels 0 - 3.

• MNEMONIC: a code that identifies the action reported
• Message text: A plain text description of the event

Local Logging

By default, logging on the console includes all severity levels 7 - 0. Logging on the console can be disabled using the command no logging. By default, monitor and buffer logging display messages with severity levels of debugging and lower.

Logging Console

To enable logging to console, use the command logging console. By default, the logging severity level for console is debugging. To control the logging options, use the command logging console <level>.

Logging Buffer

For local logging, Cisco IOS can save syslog messages to an internal buffer i.e., all the logs are saved on the device itself. You can display these messages by using the show logging command.

These messages are lost when the device is rebooted. The default buffer size is 8192 bytes. When the buffer is full, the older logs get overwritten by the newer ones. The size of the buffer can be increased using the command: logging buffered <size>.

Logging Monitor

By default, the log messages do not appear in the login session of a remote connection through SSH or telnet. To enable logging to remote logins via SSH or telnet, use the command terminal monitor. The default logging severity for the command terminal monitor is debugging. To change the logging severity level of a remote login session, use the command logging monitor <level>.

Logging messages can be disabled from a vty login session using the command terminal no monitor.

Logging Synchronous

By default, logging messages in a login session are displayed in the console session or VTY session as soon as they are generated. This can be a nuisance as the log messages distract a user who is typing at the command line from a console or VTY session as the log messages get displayed inline. The command logging synchronous [level <severity-level>|all] | limit <0-2147483647> enables synchronous logging of messages; where log messages are displayed at the login session but a new line is created for the logging messages so the logging messages do not appear in the middle of a typing session; the command being typed is placed into a new line below the displayed log message. The optional values:

• level: indicates that messages with a severity level equal to or lower are printed asynchronously. The default is 2.
• limit: specifies the number of buffers to be queued for the terminal after which new messages are dropped. The default is 20.

Logging Flash

Logs can be stored as files on flash memory. This is accomplished using the command logging file flash:<file-name> <max-file-size> <min-file-size> <severity-level> where:

• The maximum file size is in the range 4096 - 2147483647 bytes.
• The default size is 4096.
• The minimum file-size is in the range 1024 - 2147483647 bytes.
• The severity-level is in the range 0 - 7.

The command logging file flash:log_message.txt 40960 4096 3 stores log messages in a file in a flash memory.

Debug

Debugging is a powerful tool for troubleshooting complex network issues. It displays detailed information about all events in real-time. Use the debug command with caution on production networks as it is a resource intensive tool and may impact operations. Debugging can disrupt operations under high-CPU load conditions because it is processed by the CPU.

Best practices when using debugging include the following:

• show process cpu sorted: helps understand current CPU utilization. If the router is already loaded, debugging may impact the router.
• Consider output volume and time before enabling debug. If output is voluminous, this may impact router performance.
• Excessive console logging can cause the network device to hang as its CPU prioritizes this output. Use vty terminal monitor or logging buffered instead.
• Disable debug commands after troubleshooting using no debug all or undebug all.

Debugging messages can be enabled using the command debug <command>. The debugging messages can then be sent to a logging service, in this case the console using the command logging console.

Debug using IP Access Lists

Debugging by referencing an IP ACL allows debugging information that matches a configured IP access control list.

access-list 100 permit ip any 192.168.1.1 0.0.0.0
debug ip packet 100

Any debugs that do not match the access control list are not logged.

Conditional Debugs

Conditional debugs generate detailed information about a specific object such as matching a specific interface, username, MAC address, VLAN, etc. Conditional debugs limit the number of debugging messages punted to the CPU. Conditional debugs are configured using the command debug condition <interface>. Conditional debugs can be stacked as such that the debugging messages that are displayed match all conditions in the stack.

debug condition gigabitethernet1/0
debug condition ip 192.168.1.1
debug ip ospf hello

The above configuration will generate debug messages if they match all three commands.

To log debug messages for packets matching an ACL and specific interface: debug interface <interface-id>. Verify with show debug.

With conditional debugs, you can attach an access-list to filter debug traffic to permitted traffic in the access-list.

Verification

show debug

To view the debugging messages, use the command show debug. After disabling the debug, ensure that the debug condition is disabled as well.

Syslog

Logs generated by a device can be sent to the logging buffer whose size can be modified, or an off-box syslog collector. Syslog listens for log messages on UDP port 514. Syslog is the standard for computer message logging. It allows the separation of software which generates messages from the systems that store it and the software that analyzes and reports it. It can be used for the security auditing and system management, debugging messages and analysis. The syslog is supported by a wide range of devices, including routers and receivers over multiple platforms. The syslog is used to integrate the log data from many various types of systems into the central repository.

A rate-limit can be configured for syslogs to limit the rate of messages per second.

The syslogs can be forwarded to a syslog server using the following process

1. Specify the syslog server: logging host <ip-address>.
2. Specify the type of messages: the message type to be logged is specified using the command logging trap <severity>.

Filtering Logs

Logging Discriminator

A logging discriminator can be used to filter generated logs based on the text in the log. Log discriminators can be used to filter out specific logs that are repeatedly generated consuming the device log buffer. Some logs have a high severity level but are not so consequential such as up-down messages. It can be applied to the console, monitor, buffer or syslog server.

When creating a log discriminator, be as specific as possible and test the discriminator extensively before deploying it in a production environment. This will minimize the risk of filtering important messages.

To configure a logging discriminator:

1. Configure the logging discriminator name and filtering options using the command logging discriminator <discriminator-name> <facility> <mnemonics> <message-body> <includes> <severity> <rate-limit> where:
   • facility: (Optional) Message sub-filter for the facility pattern in an event message.
   • mnemonics: (Optional) Message subifilter for the mnemonic pattern in an event message.
   • msg-body: (Optional) Message sub-filter for the msg-body pattern in an event message.
   • drops: Drops messages that match the pattern, including the specified regular expression.
   • includes: Delivers messages that match the pattern, including the specified regular expression string.
   • string: (Optional) Expression used for message filtering.
   • severity: (Optional) Message sub-filter by severity level or group.
   • sev-num: (Optional) Integer that identifies the severity level or multiple levels. Multiple levels must be separated with a comma (,)/
   • rate-limit: (Optional) Specifies a number of messages to be processed within a unit of time.
   • msglimit: (Optional) Integer in the range of 1 to 10000 that identifies the number of messages not to be exceeded.
   logging discriminator msg-body drops Configured from console by console

2. Application:
   • To apply the logging discriminator to the console, use the command logging console discriminator <discriminator-name>
   • To apply the logging discriminator to the monitor, use the command logging monitor discriminator <discriminator>.

Verification

Configured logging settings can be viewed using the command show logging.

Timestamps

Timestamps are controlled by the service timestamps command. This command by itself enables the adding of timestamps to debug messages and, by default, sets the timestamps to uptime.

Having logs and debug messages timestamped is extremely important when troubleshooting particularly across different devices. To enable timestamps on logging and debug messages:

• Debugging messages: the command service timestamps debug datetime msec adds timestamps to debug messages including milliseconds. The datetime option includes the date and the time.
• Log messages: the command service timestamps log datetime msec adds the timestamps to logging messages. Options include:
  • datetime: This option alone enables the date (day of month and month) and time(hours, minutes and seconds). Additional options include:
    • localtime: use the local timezone for timestamps.
    • msec: include milliseconds in the timestamp.
    • show-timezone: add timezone information to the timestamp.
    • year: include the current year in the timestamp.
  • uptime: does not include additional options as does datetime.

Sequence Numbers

Sequence numbers can be added to log messages based on the time that they were generated. The sequence numbers increment from 1, 2, onwards. If there is more than one log message with the same time stamp, you can display messages with sequence numbers to view these messages. By default, sequence numbers are not added to log messages. Sequence numbers can be added to log messages using the command service sequence-numbers. When enabled, they are prepended to the log message appearing at the start of a log message.

IPv6 First Hop Security

Introduction and Overview

As IPv4 public addresses get depleted, the number of IPv6 deployments has increased exponentially. This exponential increase in the adoption of IPv6 can also be attributed to introduction of Internet of Things (IoT).

With all these devices gaining access to networks, security concerns are growing in IPv6 deployments. It is important that these IPv6 deployments are secured for optimum operation of these networks. A critical part of the network that needs to be considered when implementing security mechanisms is at the local links (Layer 2) where hosts are connected to the network.

First hop is the network segment between the end hosts and their default gateway i.e., the access layer. Security at the first hop aims to prevent against internal threats at the access layer such as a man-in-the-middle(MiM) attack. In IPv4, security at the access layer is implemented through DHCP snooping, IP source guard and dynamic ARP inspection. Most IPv6 first-hop security features are implemented on a layer 2 device(switch).

In IPv6, ICMPv6 ND/NDP replaces IPv4 ARP. ARP uses two messages: request and reply. With ICMPv6 ND uses four messages:

1. Neighbor Solicitation (NS): a device requests for information about a neighbor.
2. Neighbor Advertisement (NA): a device advertises its information to other neighbors.
3. Router Solicitation (RS): a device requests for information about local routers i.e., routers in the network segment.
4. Router Advertisement (RA): a device advertises itself as an active router.

When a host is added to a network:

1. The host chooses a link-local address; usually FE80::/10 for the network segment of the address. The host segment of the address is generated using EUI-64.
2. The host then checks to confirm that the link-local address is unique by sending an NS on the local link to the solicited node multicast address (FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits from the EUI-64). If no response is received for the NS, then the link-local address is confirmed as unique.
3. The host then sends a NA to the "all hosts multicast address" FF02::1 (similar to 255.255.255.255 in IPv4) announcing itself as a host.
4. Router discovery is then attempted by sending RS messages to FF02::2 (all routers multicast address).
5. A local router replies with RA that contains the router's IPv6 address and MAC address along with prefix information for SLAAC.
6. The host chooses a global prefix for SLAAC where the address is generated using the RA advertised prefix and EUI-64 for the host part of the address. The host performs DAD to verify that the global prefix address is unique. If unique, the host sends a NA for the global prefix.

IPv6 First Hop Attack Surface

IPv6 features such as ICMPv6 Neighbor Discovery’s Neighbor Solicitation (NS), Neighbor Advertisement (NA) messages and Router Discovery Router Solicitation (RS) and Router Advertisement (RA) introduce attack options that were previously not possible in IPv4. IPv6 first hop security concerns on the local links are usually associated with router discovery, neighbor discovery, duplicate address detection(DAD), stateless address autoconfiguration(SLAAC) and DHCPv6.

This process presents several attack surfaces that can be exploited in some of the following ways:

• Spoof the router: a rogue device can send gratuitous RA to announce itself as the router. Spoofing the router is a MiM attack or a basic DoS attack
• Spoof DHCPv6 server: a rogue device can respond with bogus DHCPv6 messages. Spoofing the DHCPv6 server is a form of DoS attack or MiM if it is combined with RA spoofing.
• Poison the router's ND cache: a rogue device can send gratuitous NA messages with other device's addresses. Poisoning the router's ND cache is a MiM or DoS attack.
• Overload the router's ND cache: a rogue device sends packets to the entire /64 prefix range. This results in the DoS attack as router is overwhelmed trying to respond with NS messages.

RA Guard

Router discovery is a means for hosts to locate routers that reside on a local link. Security concerns with router discovery include attacks on ICMPv6 Router Discovery (RD) and host address allocation using SLAAC (Stateless Address Autoconfiguration). RD attacks are categorized as man-in-the-middle attacks.

Attack

One of the several ways that an RD attack may take place follows this sequence:

Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.

A legitimate router R1 responds with a Router Advertisement (RA) with lifetime X to the RS from Host A. Host A installs R1 as its default gateway for duration X.

An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.

When duration X is about to elapse, Host A request a renewal of the prefix lease.

Rx then sends new RA messages with lifetime Z. Host A will receive these RA messages and install Rx as its default gateway.

Host A starts to direct traffic to remote networks through Rx as its gateway. Rx can then monitor traffic from Host A.

The above sequence of events is an example of a man-in-the-middle (MiTM) attack on IPv6 local links.

IPv6 RA Guard

Router advertisements should enter a network through an authorized switchport and from an authorized source. RA Guard protects against router spoofing and prefix spoofing on the segment. This is accomplished by blocking or rejection of rogue or unwanted router advertisements that are received on certain ports.

Deploying RA Guard involves configuration of a policy and attaching the policy to a specific VLAN or switchport. Traffic is permitted on the ports that comply with the policy and blocked/dropped on non-compliant ports.

Configuration

When configuring RA Guard policies, device roles are specified for each of the ports that the policy will be applied. The configurable device roles include:

• host: attached device is a end-user host device. In host mode, all RA redirect messages are disallowed on the port.
• router: attached device is a router. RA and RS messages are to be expected from this port. Additionally, switchports with routers can be configured as trusted ports.
• monitor: for attached devices that have network monitoring features or are network sniffers.
• switch: attached device is a switch.

When configuring RA Guard, two policies are usually configured; one policy for ports where routers are attached and a separate policy for ports where hosts are attached.

1. Configure the RA Guard Policy:

   Defining a policy for hosts:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy HOSTS

   2. Specify the device role: The device role can be host or router: device-role host.
      SW1(config-nd-raguard)#device-role host

   Creating a second policy for routers:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy ROUTERS

   2. Specify the device role: The device role is router: device-role router.
      SW1(config-nd-raguard)#device-role router

   3. Configure the port as trusted: trusted-port
      SW1(config-nd-raguard)#trusted-port

   4. Enable of O flag/bit: other-config-flag on. The O bit indicates to the client additional information is to be extracted from another source such as a DHCP or DNS server.
      SW1(config-nd-raguard)#other-config-flag on

   5. All optional features are bypassed if not configured. They include:
      • hop limit <maximum | minimum> <number>: (Optional) Enable verification of advertised hop count limit.
      • managed-config-flag <on | off>: (Optional) Enable verification that the advertised managed address configuration flag is on.
      • match ipv6 access-list alc
      • match ra prefix-list ipv6_prefix_list: (Optional) Verification of the advertised prefixes in inspected messages from configured prefix-list.
      • other-config-flag <on | off> : (Optional) Verification of advertised other-config parameter
      • router-preference maximum < high | low | medium > : (Optional) Verification that the advertised default router preference parameter value is lower than or equal to a specified limit
      • match ipv6 access-list <acl>: (Optional) Enable verification of the sender’s IPv6 address in inspected messages from the configured authorized device source access-list

2. Apply the RA Guard policy to the switchport or VLAN:
   • VLAN:
     SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 nd raguard attach-policy HOSTS


   • interface: Apply IPv6 RAGuard feature to a specified interface using the command ipv6 nd raguard attach-policy <policy-name> [vlan <add|except|none|remove|all> vlan <vlan1, vlan2 … vlan n>]
     SW1(config)#interface g0/0
SW1(config-if)#ipv6 nd raguard attach-policy ROUTERS


Verification

The following commands verify RA Guard configuration and operation:

• show ipv6 snooping policies: RA guard will appear as one of the snooping policies configured
• show ipv6 nd raguard policy <policy-name>
• debug ipv6 snooping raguard <filter | interface | vlanID>
• show ipv6 snooping capture-policy interface <interface-id>: for configured interfaces

Restrictions for IPv6 RA guard

• IPv6 RA guard does not offer protection when IPv6 traffic is tunneled.
• RA guard is supported on hardware when the TCAM is programmed.
• RA Guard can be configured on a switchport interface in the ingress direction.
• Supports host and router mode.
• Not supported in etherchannel and etherchannel port members.
• Not supported on trunk ports with merge mode.
• Is supported on auxiliary VLANs and private VLANs (PvLANs). Primary VLAN features are inherited and merged with port features.
• Packets dropped by IPv6 RA guard can be spanned.
• RA guard cannot be configured if the following command is configured platform ipv6 acl icmp optimize neighbor-discovery

SLAAC

SLAAC is a mechanism that enables an IPv6 host to obtain an IPv6 address prefix from its local router through one of its local links without the use of all DHCPv6 features. Unlike DHCPv6, due to the stateless nature of SLAAC, address assignments are not verified before addresses are issued.

Steps involved in a SLAAC attack:

1. Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.
2. A legitimate router R1 responds with a Router Advertisement (RA) that provides the IPv6 prefix. 2001:DB8:C0FF:EE::/64 with lifetime X.
3. Host A configures the address 2001:DB8:COFF:EE::2/128 and checks the availability of the address using Duplicate Address Detection (DAD) and begins using this address.
4. An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.
5. Host A’s IPv6 address will then expire at the lapse of duration Y.
6. Rx can then send a new RA with a new prefix 2001:DB9:COFF:EA::/64.
7. Upon receiving the new prefix, Host A will configure the address 2001:DB9:COFF:EA::09/128 with R1 still being retained as the default gateway. R1 may block Host A’s network traffic due to the fact that it is from an unknown network.
8. R1 may drop Host A’s traffic resulting in black-holing all network traffic from Host A.

DHCPv6 Guard

DHCPv6 assigns hosts IPv6 prefixes and other configuration options. DHCPv6 is both a stateful and stateless protocol. A rogue DHCPv6 server could be inserted into a network. The attackers can then deploy man-in-the-middle attacks ,traffic interception or blackhole traffic.

DHCPV6 Attacks

DHCPv6 does not assign a default router like DHCP in IPv4 environments. Th default router is learned through SLAAC from RA messages.

DHCPv6 Guard prevents the spoofing of the DHCPv6 server by blocking DHCPv6 messages that come from unauthorized / rogue DHCPv6 servers and relay agents. Client messages or messages sent by replay agents from clients are not blocked. When implementing DHCPv6 Guard, devices are categorized as server and client. DHCPv6 server messages are only processed if the device role is set to server.

Configuration

The configuration of the DHCPv6 Guard is similar to that of the RA Guard. A DHCPv6 Guard policy is configured for the DHCPv6 clients and a separate policy for the servers. The policy is then applied to a VLAN or interface.

1. Configure the DHCPv6 policy:

   Policy for servers:

   1. SW1(config)#ipv6 dhcp guard policy SERVERS
SW1(config)#device-role server
SW1(config)#trusted-port

      Additional configuration options exist for attached DHCPv6 servers:

      • Authorized DHCPv6 servers: DHCPv6 messages can be permitted to be transmitted if they originate from authorized DHCPv6 servers. To enable this feature:
        1. Configure an IPv6 access control list with the IPv6 addresses of the authorized DHCPv6 servers: ipv6 access-list <acl-name> permit host <ipv6-address> 128.
        2. Enable verification of the advertised DHCP server and relay address in inspected messages from the configured authorized server ACL. An empty ACL is treated as a permit. match server access-list <acl-name>.
      • IPv6 Addresses in Authorized Range: DHCPv6 Guard can be configured to permit DHCPv6 advertised prefixes are in the permitted IPv6 range:
        1. Create an entry in an IPv6 prefix-list; ipv6 prefix-list <prefix_list_name> permit <ipv6_prefix> 128.
        2. Enable verification of advertised prefixes in DHCP reply messages from the configured authorized prefix-list. An empty ACL is treated as a permit.

   Policy for clients:

   1. SW1(config)#ipv6 dhcp guard policy CLIENTS
SW1(config)#device-role client

   Other optional DHCPv6 features include:

   • preference min limit : Enable verification that the advertised preference (in preference option) is greater than the specified limit
   • preference max limit : Enable verification that the advertised preference is less than the specified limit

2. Apply the DHCPv6 Guard policy:
   1. Interface:
      SW1(config)#interface g0/0
SW1(config-if)#ipv6 dhcp guard attach-policy SERVERS


   2. VLAN:
      SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 dhcp guard attach-policy CLIENTS

Verification

The operational state of DHCPv6 Guard can be verified using these commands:

• show ipv6 dhcp guard policy <policy-name>.
• show ipv6 snooping policies.

Restrictions

DHCPv6Guard is not supported on etherchannel ports.

Binding Table

The binding table is a database of IPv6 neighbors connected to a device and is created from informational sources such as ND snooping, DHCP gleaning. It contains information such as the link-layer address, the IPv4 or IPv6 address, and the prefix binding i.e., it can be considered to be a mapping of layer 2 addresses to IPv6 addresses. It is used by various IPv6 guard features to prevent spoofing and redirect attacks.

The binding table supports features that can be leveraged to provide first hop security:

• Limits can be set for the number of IPv6 addresses that a MAC address can have.
• The binding table recovery mechanism feature enables the binding table to recover in the event of a device reboot. The recovery mechanism will block any data traffic sourced from an unknown source (a source that is not in the binding table).
• The binding table introduces the capacity to provide a prefix-list that is matched before the recovery is attempted for both DHCP and NDP. If an address does not match the prefix-list associated with the protocol, the recovery of the binding table entry will not be attempted with that protocol.

IPv6 Snooping

IPv6 snooping bundles several IPv6 first-hop security features such as ND inspection, IPv6 device tracking, IPv6 address glean, IPv6 binding table recovery. IPv6 ND inspection operates at Layer 2 or between Layer 2 and Layer 3. IPv6 snooping mitigates vulnerabilities in the ICMPv6 ND mechanisms for example attacks on DAD, address resolution, device discovery and neighbor cache/table. IPv6 snooping learns and secures binding for SLAAC addresses in Layer 2 neighbor tables and analyses ND messages in order to build a trust binding table. An ND message is considered trustworthy if its IPv6-to-MAC mapping is verifiable. The IPv6 first-hop security binding table recovery mechanism enables the binding table to recover in the event of a device reboot.

The binding table is a database of IPv6 neighbors connected to the device and is created from sources such as ND snooping. It is used by various IPv6 guard features to validate link-layer addresses, IPv4 or IPv6 addresses prefix-binding of neighbors to prevent spoofing and redirect attacks.

Configuration

To configure an IPv6 snooping policy;

1. Configure the snooping policy:
   SW(config)#ipv6 snooping policy SNOOP_POLICY


2. Attach the snooping policy to an interface:
   SW(config)#interface g0/0
SW(config-if)#ipv6 snooping attach-policy SNOOP_POLICY


Verification

• show ipv6 snooping capture-policy interface <interface_number>: To display snooping ND messages and capture policies
• show ipv6 snooping counter interface <interface_name_number> : To display information about the packets counted by the interface counter
• show ipv6 snooping features : To display information about snooping features configured on a device
• show ipv6 snooping policies : To display information about configured policies and interfaces that they are attached to
• debug ipv6 snooping : Debugging of IPv6 snooping information

Restriction

IPv6 snooping is not supported on etherchannels.

Source Guard

If a device starts transmitting on a network segment without IPv6 host discovery messages such as NS, NA, DHCPv6 message exchange, source guard enables the switch to drop such traffic from an unfamiliar IPv6 source address.

IPv6 source guard relies on IPv6 snooping cache to create the IPv6 neighbor binding table. It creates an automatic IPv6 port ACL(PACL) to filter sources based on neighbor binding table.

Configuration

1. Configure the source guard policy:
   SW(config)#ipv6 source-guard policy SG_POLICY
SW(config-sisf-sourceguard)#permit link-local
SW(config-sisf-sourceguard)#deny global-autoconf
SW(config-sisf-sourceguard)#trusted

2. Apply the configured source guard policy to the VLAN or interface:
   • On the VLAN:
     SW(config)#vlan configuration 1
SW(config-vlan-config)#ipv6 source-guard attach-policy SG_POLICY

   • On the interface:
     SW(config)#interface g0/0
SW(config-if)#ipv6 source-guard attach-policy SG_POLICY

Verification of Source Guard

The following command is used to verify IPv6 source guard: show ipv6 snooping policies.

Neighbor Discovery Attacks

Similar to RA messages ND messages are used to discover other hosts on the local link. It replaces ARP in IPv6. ND performs DAD and address resolution, neighbor unreachability and redirection. Neighbor discovery messages are mainly Neighbor Solicitation (NS) and Neighbor Advertisement (NA). ND Attacks usually involve Address Resolution, Duplicate Address Detection and Neighbor Cache attacks.

Address Resolution Attacks

Address resolution is the process that a host (Host A) follows when it wants to send network traffic to another host (Host B) on the local link when it does not know its Layer 2 address (MAC address in Ethernet networks). Host A resolves the IPv6 address of Host B into a MAC address and forwards the packet with Host B’s MAC address as the destination address of the Layer 2 frame.

Stages in IPv6 address resolution attacks include the following;

1. Host A sends a Neighbor Solicitation message on the local link requesting for Host B’s link local address. Host B sends a Neighbor Advertisement (NA) message on the local link containing its MAC address which Host A stores in its neighbor table binding the MAC address with the IPv6 address.
2. If a malicious Host X inserts itself into the local network, it can masquerade as Host B and intercept all packets sent to Host B. Without effective IPv6 first-hop security, Host X can perform a Man-in-the-Middle (MiTM) attack.
3. Host A will attempt to send packets destined to Host B but using Host X’s link-layer address.

Duplicate Address Detection Attacks

Duplicate Address Detection (DAD) is an IPv6 protocol that enables a host to detect a duplicate address on the local network. DAD attacks are usually aimed at preventing hosts from having IPv6 addresses. Steps involved in deploying a DAD attack;

1. Host A wants to use the address 2001:DB8:C0FF:EE::1. So it sends an NS message on its local link to determine if any other host is using this address. If no NA response is received from other hosts on the local link, Host A will go ahead to use this address.
2. However, malicious host Host X which has inserted itself on the local link receives this NS message. It responds with an NA claiming that it is currently using that same address 2001:DB8:C0FF:EE::1 yet it does not actually use this address.
3. Host A sends another NS message requesting to use another IPv6 address 2001:DB8:C0FF:EE::A. Host X again claims that this address is already taken. Host X essentially claims all addresses that Host A requests to use thereby preventing Host A from having a valid IPv6 address.

Neighbor Cache Attacks

When performing address resolution after receiving IPv6 an NA response to an NS request, a host stores the MAC address to IPv6 address binding in its neighbor table/cache. If many hosts reside on the local link, the neighbor table can grow large in size. In IPv6, the interface identifier is 64-bits long. There could be as many as 264 potential number of hosts on the link resulting in potentially 264 neighbor table entries. With IoT devices prevalent these possibilities become close to reality.

A malicious host (Host X) can attempt to fill up the neighbor cache / table of another host or router resulting in a DoS condition.

Step 1: Malicious Host X sends packets to all potential addresses in its local link. The local router R1 will attempt to resolve the IPv6 addresses in order to forward the frames to them. For hosts whose addresses are not yet resolved, R1 will create an incomplete cache entry for a few seconds as it awaits a response that is never received. This entry eventually times out.

However, if Host X sends many such packets fast, it could fill up the R1 neighbor table resulting in a DoS condition.