Control Plane Policing (CoPP)

Overview

CoPP is a QoS feature used in security that rate-limits the traffic handled by the route processor (RP) thereby protecting the control plane of devices such as routers and switches from excessive traffic that could lead to CPU exhaustion, denial of service, , or instability.

CoPP uses Modular QoS CLI (MQC) to rate-limit, drop and granularly permit traffic to or from the RP. The RP handles traffic that is categorized into three planes:

• Data plane
• Management plane
• Control plane

The control plane is a collection of processes that run at the process level on the route processor (RP). These processes collectively provide high-level control over most IOS functions. All packets destined for the control plane pass through the central switch engine before they are forwarded to the process level. The control-plane and central switch engine are part of the RP.

Majority of traffic managed by the RP is handled by way of the control and management planes. Such traffic includes:

• Routing protocol updates (IGP, BGP)
• Management traffic such as SNMP, SSH, Telnet, NTP, HTTP(S), etc.
• Traffic destined for a local IP address of the switch/router i.e., the local router or switch is the destination of the traffic.

Control Plane Traffic Types

Control plane protection categorizes control plane traffic into three types:

• Local (self generated): traffic originated by the local device and destined for its own control plane e.g. routing protocol updates
• Transit: traffic that transits the router and is punted to the CP for processing e.g. ICMP unreachable messages not unknown destinations, packets with expired TTL.
• Host: traffic destined for one of the router's interfaces (physical or logical) for management purposes e.g. SSH, HTTP, SNMP

Why protect the CPU

The CPU is a finite resouce, which when overwhelmed leads to:

• Network instability: Dropping of legitimate traffic
• Operational Outage: failure to respond to management updates
• DoS: if the two aforementioned problems intensify, a DoS may be the result

Control-plane Policing (CoPP) provides rate-limiting and filtering capabilites to control the number of packets that have to be processed by the RP of a router or switch. This helps in reducing the load on a router�s RP at any given point in time. It helps protect the RP from denial-of-service (DoS) attacks, and other flooding attacks, reconnaisance attacks.

When implementing CoPP, it is important to rate-limit traffic on all interfaces destined for the local router. A logical interface exists on all routers called the control plane interface. Rate-limiting packets on this interface applies the rate-limit to all the physical interfaces. Quality of Service (QoS) and policing on the control plane interface rate-limits packets entering any interface to protect the RP.

Control Plane Attack Vectors

The performance of the control plane can be degraded in the following ways:

• Resource Exhaustion: High CPU usage due to unnecessary traffic e.g. broadcast storms.
• Direct Attacks: malicius traffic sent to the device e.g. TCP SYN flood attacks to port 22
• Indirect Attacks: excessive legitimate traffic e.g. OSPF LSA updates due to link flapping

Configuring CoPP

To implement CoPP, the following sequence of steps should be followed:

1. Categorize network traffic into classes using Access Control List (ACLs).
2. Create a Class Map (CM) to define traffic types.
3. Create a Policy Map (PM) to define the action to take on identified traffic by implementing a defined policy (policing actions) e.g. drop, transmit, rate-limit.
4. Create a Service Policy which specifies how to apply the policy map to the control plane

CoPP is hardware-accelerated if the command mls qos is applied.

Categorize Network Traffic using ACLs

Traffic to be rate-limited needs to first be identified and categorized into different classes based on importance, function or protocol type.

ACLs are used to identify and classify traffic to be rate-limited. These classes include:

• BGP
• IGP
• Critical applications
• File management
• Interactive management
• Monitoring
• STP and other layer 2 protocols
• Default

A separate ACL should be configured for each of these traffic categories. Each ACL should permit all known protocols in its class. Traffic for the default class should be configured to permit any other type of traffic e.g permit ip any any.

Extended ACLs are usually used for classifying traffic as they can be configured to match the traffic port/protocol numbers.

During categorization of traffic, it is important to note that traffic for certain classes such as SNMP, (T)FTP, GRE, is originated from known sources. In such cases, the ACE entries in these ACLs should explicitly define the source IP address. If the ports for these traffic sources is known, then the ACEs should be configured to permit traffic from these specific port numbers as well.

The different traffic categories include:

• BGP: For maintaining BGP operations such as neighbor formation and maintenance, prefix exchange. BGP uses TCP port source port 179; when configuring ACE entries, the BGP port number or keyword bgp are valid high-level protocols for matching against.
  R1(config)#ip access-list extended ACL_COPP_BGP
R1(config-ext-nacl)#remark BGP traffic
R1(config-ext-nacl)#10 permit tcp any gt 1024 any eq bgp
R1(config-ext-nacl)#20 permit tcp any gt 1024 any eq bgp established


• IGP: traffic for formation and maintenance of IGP protocols such as EIGRP, OSPF, RIP. OSPF uses IP protocol number 89 and IPv4 multicast addresses 224.0.0.5 and 224.0.0.6 or IPv6 multicast address FF02::5 and FF02::6. EIGRP uses IP protocol number 88 and IPv4 multicast address 224.0.0.10 IPv6 multicast address FF02::A. The IP protocols can also be matched using the keywords eigrp or ospf.
  R1(config)#ip access-list extended ACL_COPP_IGP
R1(config-ext-nacl)#10 permit ospf any host 224.0.0.5
R1(config-ext-nacl)#20 permit ospf any host 224.0.0.6
R1(config-ext-nacl)#30 permit ospf host 224.0.0.5 any
R1(config-ext-nacl)#50 permit eigrp any host 224.0.0.10
R1(config-ext-nacl)#60 permit eigrp host 224.0.0.10 any


• Monitoring and Reporting: traffic for monitoring the switch or router such as ICMP, IP SLA.
  R1(config)#ip access-list extended ACL_COPP_MONITOR
R1(config-ext-nacl)#10 permit icmp any any
R1(config-ext-nacl)#10 permit icmp any any echo
R1(config-ext-nacl)#20 permit icmp any any echo-reply
R1(config-ext-nacl)#30 permit icmp any any unreachable
R1(config-ext-nacl)#40 permit icmp any any port-unreachable


• Interactive Management: traffic that is interactive in nature and is required for routine network operations such as SSH, Telnet, SNMP, NTP, TACACS. This type of traffic is usually low-volume.
  R1(config)#ip access-list extended ACL_COPP_INT_MGMT
R1(config-ext-nacl)#remark Interactive file management
R1(config-ext-nacl)#10 permit tcp host 10.20.2.1 host 10.1.10.1 eq 22
R1(config-ext-nacl)#20 permit udp host 10.1.10.1 host 10.30.5.1 eq 161
R1(config-ext-nacl)#30 permit udp host 10.1.10.1 host 10.30.5.1 eq 162
R1(config-ext-nacl)#50 permit udp host 10.1.10.1 host 10.80.1.1 eq ntp


• File Management: this type of traffic is used to transfer files. Protocols in this category include: TFTP, FTP. This type of traffic is usually high-volume.
  R1(config)#ip access-list ACL_COPP_FILE_MGMT
R1(config-ext-nacl)#10 permit tcp any host 10.1.10.1 eq ftp
R1(config-ext-nacl)#20 permit tcp host 10.1.10.1 eq ftp any
R1(config-ext-nacl)#30 permit tcp any host 10.1.10.1 eq ftp-data established
R1(config-ext-nacl)#40 permit tcp host 10.1.10.1 eq ftp-data any established


• Critical applications: protocols in this category include GRE, HSRP, GLBP, DHCP, IPsec, VRRP, IGMP, multicast traffic.
  R1(config)#ip access-list extended ACL_COPP_CRITICAL_APPLICATIONS
R1(config-ext-nacl)#remark Critical applications
R1(config-ext-nacl)#10 permit udp host 0.0.0.0 host 255.255.255.255 eq bootpc
R1(config-ext-nacl)#20 permit udp host 10.10.1.20 eq bootps any eq bootps
R1(config-ext-nacl)#30 permit ip any host 22.0.0.2


  bootpc and bootps are the keywords for DHCP.

• Undesirable: malicious traffic that should not be allowed to be processed by the RP. Such traffic may be generated by malware. The port numbers, transport protocol used etc of malware can only be known if the malware has has been profiled .
• Default: traffic that does not fit into any of the above categories. This traffic should be rate-limited until some specific types within this category can be classified and grouped into newer groups or classified under existing (above) listed groups.

Create Class Maps to Define Traffic Class

Class maps are used to define classes of the traffic to be rate-limited. A class map may reference an ACL, protocol, IP Prec or IP DSCP values in a packet.

A separate class-map should be created for each of the configured ACLs for each traffic category. Class-maps have a default class-map that deals with traffic that is not explicitly defined. A separate class-map should be explicitly configured for the default traffic ACL.

1. Define the class map name: using the command class-map <match-any | match-all> <class-map-name>. The matching instruction is match-any or match-all
   • match-any: traffic must match only one of the commands to be classified as part of the traffic class.
   • match-all: traffic must match all the match commands to be part of the traffic class. Care must be taken with match-all keyword as the traffic will have to match all characteristics in all the match commands.
2. Specify how the traffic will be matched: using the command match [access-group [<acl-number> | name <acl>] | protocol | ip prec | ip dscp]
   • Access-group: reference the previously configured access control list match statement. ACL names are case sensitive.
   • Protocol: You can match by protocol instead of ACL; for example to match ARP packets; match protocol arp
   • IP Prec | IP dscp: to match against an IP packet's Precedence or DSCP fields

R1(config)#class-map match-all CM_COPP_BGP
R1(config-cmap)#match access-group name ACL_COPP_BGP
R1(config)#class-map match-all CM_COPP_CRITICAL_APPLICATIONS
R1(config-cmap)#match access-group name ACL_COPP_CRITICAL_APPLICATIONS
R1(config-cmap)#exit
R1(config)#class-map match-all CM_COPP_FILE_MGMT
R1(config-cmap)#match access-group name ACL_COPP_FILE_MGMT
R1(config-cmap)#exit
R1(config)#class-map match-all CM_COPP_IGP
R1(config-cmap)#match access-group name ACL_COPP_IGP
R1(config-cmap)#class-map match-all CM_COPP_INT_MGMT
R1(config-cmap)#match access-group name ACL_COPP_MGMT
R1(config-cmap)#class-map match-all CM_COPP_MONITOR
R1(config-cmap)#match access-group name ACL_COPP_MONITOR
R1(config-cmap)#class-map match-all CM_COPP_DEFAULT
R1(config-cmap)#match access-group name ACL_COPP_DEFAULT


Verification

R1#show class-map
Class Map match-all CM_COPP_INT_MGMT (id 5)
   Match access-group name  ACL_COPP_MGMT
                              
Class Map match-any class-default (id 0)
   Match any                  
                              
Class Map match-all CM_COPP_FILE_MGMT (id 3)
   Match access-group name  ACL_COPP_FILE_MGMT
                              
Class Map match-all CM_COPP_DEFAULT (id 7)
   Match access-group name  ACL_COPP_DEFAULT
                              
Class Map match-all CM_COPP_MONITOR (id 6)
   Match access-group name  ACL_COPP_MONITOR
                              
Class Map match-all CM_COPP_BGP (id 1)
   Match access-group name  ACL_COPP_BGP
                              
Class Map match-all CM_COPP_IGP (id 4)
   Match access-group name  ACL_COPP_IGP
                              
Class Map match-all CM_COPP_CRITICAL_APPLICATIONS (id 2)
   Match access-group name  ACL_COPP_CRITICAL_APPLICATIONS


Create Policy Maps to Define a Service Policy

Policy maps are used to define the rate-limit parameters of the classified traffic. Policy maps are used to associate the traffic class (defined with a class map) with one or more policies resulting in a service policy. To configure a policy map:

1. Define the policy map name: using the command policy-map <service-policy-name>
2. Reference a configured class map: using the command class <traffic-class-name>
3. Define the rate-limit threshold and action: at which traffic will be rate-limited, and action to take for conformal traffic, and rate-limit violation using the command police <cir | rate> conform-action <transmit | drop> exceed-action <transmit | drop> violate-action <transmit | drop> The police command allows the following policing actions:
   • Committed Information Rate (CIR): the guaranteed rate of traffic allowed.
   • Committed Burst (Bc): the maximum amount of traffic allowed to exceed the CIR for a short duration.
   • Excess Burst (Be): An additional burst size that can be configured for two-rate policing.

Each class-map should be associated with a policy map that permits all traffic. The policy for each class should be set as conform-action transmit exceed-action transmit.

Some control-plane policing rates along with recommended actions:

Class	Rate(pps)	Rate(bps)	Conform action	Exceed action
BGP	500	4000000	Transmit	Drop
IGP	50	300000	Transmit	Drop
Monitoring and reporting	125	900000	Transmit	Drop
Interactive management	100	500000	Transmit	Drop
File management	500	6000000	Transmit	Drop
Critical applications	125	900000	Transmit	Drop
Undesirable	100	0	Drop	Drop
Default	100	1000000	Transmit	Drop

R1(config)#policy-map PM_COPP
R1(config-pmap)#class CM_COPP_BGP
R1(config-pmap-c-police)#police cir 4000000 bc 4000000 be 4000000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_IGP
R1(config-pmap-c)#police cir 300000 bc 60000 be 60000 c conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_CRITICAL_APPLICATIONS
R1(config-pmap-c)#cir 900000 bc 180000 be 180000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_MONITOR
R1(config-pmap-c)#police cir 900000 bc 180000 be 180000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_FILE_MGMT
R1(config-pmap-c)#police cir 6000000 bc 1200000 be 1200000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_INT_MGMT
R1(config-pmap-c)#police cir 500000 bc 100000 be 100000 conform-action transmit exceed-action drop


Verification

R1#show policy-map
  Policy Map PM_COPP
    Class CM_COPP_IGP
     police cir 300000 bc 60000 be 60000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_INT_MGMT
     police cir 500000 bc 100000 be 100000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_BGP
     police cir 4000000 bc 800000 be 800000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_FILE_MGMT
     police cir 6000000 bc 1200000 be 1200000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_CRITICAL_APPLICATIONS
     police cir 900000 bc 180000 be 180000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop
R1#

The policy map configuration will protect a device's RP from being overwhelmed by control-plane traffic. For illustrative purposes, the following CIR rate for ICMP traffic will be made artificially low.

R1#show policy-map
  Policy Map PM_COPP
  !Output omitted for brevity
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop

R1#

Apply the Policy Map

A policy map can be applied to a single interface or all interfaces. Depending on your security model, you may wish to apply different policy-maps with different rates to all interfaces and other policies to specific interfaces for instance, the interface pointing to the Internet may have a more restrictive policing than that connected to the internal network.

Apply policy map to all interfaces

A router has a single control-plane interface. To apply the policy-map to all interfaces, enter the control-plane configuration mode and apply the policy-map;

R1(config)#control-plane
R1(config-cp)#service-policy input PM_COPP

The input keyword enforces the policy on ingress traffic.

Apply the policy-map to a single interface

To apply the policy-map to a single interface, enter the specific interface and configure the policy map using the service-policy interface command;

R1(config)#interface g0/0
R1(config-if)#service-policy input PM_COPP

Test and Verify Configuration

On a second device (another router or host device such as PC), you can test the control-plane policing by pinging.

R1#show policy-map control-plane
Control Plane
              
  Service-policy input: PM_COPP
              
    Class-map: CM_COPP_IGP (match-all)
      18 packets, 2312 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_IGP
      police:
          cir 300000 bps, bc 60000 bytes, be 60000 bytes
        conformed 18 packets, 2312 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_INT_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MGMT
      police:
          cir 500000 bps, bc 100000 bytes, be 100000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_BGP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_BGP
      police:
          cir 4000000 bps, bc 800000 bytes, be 800000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_FILE_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_FILE_MGMT
      police:
          cir 6000000 bps, bc 1200000 bytes, be 1200000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_CRITICAL_APPLICATIONS (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_CRITICAL_APPLICATIONS
      police:
          cir 900000 bps, bc 180000 bytes, be 180000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_MONITOR (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MONITOR
      police:
          cir 90000 bps, bc 18000 bytes, be 10800 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: class-default (match-any)
      56 packets, 6556 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
              
R1#show policy-map
  Policy Map PM_COPP
    Class CM_COPP_IGP
     police cir 300000 bc 60000 be 60000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_INT_MGMT
     police cir 500000 bc 100000 be 100000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_BGP
     police cir 4000000 bc 800000 be 800000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_FILE_MGMT
     police cir 6000000 bc 1200000 be 1200000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_CRITICAL_APPLICATIONS
     police cir 900000 bc 180000 be 180000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop
              


Pinging from another Host

R2#ping 30.255.1.1 repeat 500 size 1500
Type escape sequence to abort.
Sending 500, 1500-byte ICMP Echos to 30.255.1.1, timeout is 2 seconds:
!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.
!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!
.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!
!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!
Success rate is 93 percent (465/500), round-trip min/avg/max = 1/17/48 ms


CoPP rate-limiting can be observed to have taken effect.

R1#show policy-map control-plane
Control Plane  
                
  Service-policy input: PM_COPP
                
    Class-map: CM_COPP_IGP (match-all)
      40 packets, 4380 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_IGP
      police:    
          cir 300000 bps, bc 60000 bytes, be 60000 bytes
        conformed 40 packets, 4380 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_INT_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MGMT
      police:    
          cir 500000 bps, bc 100000 bytes, be 100000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_BGP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_BGP
      police:    
          cir 4000000 bps, bc 800000 bytes, be 800000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_FILE_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_FILE_MGMT
      police:    
          cir 6000000 bps, bc 1200000 bytes, be 1200000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_CRITICAL_APPLICATIONS (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_CRITICAL_APPLICATIONS
      police:    
          cir 900000 bps, bc 180000 bytes, be 180000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_MONITOR (match-all)
      500 packets, 757000 bytes
      5 minute offered rate 11000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MONITOR
      police:    
          cir 90000 bps, bc 18000 bytes, be 10800 bytes
        conformed 465 packets, 704010 bytes; actions:
          transmit
        exceeded 35 packets, 52990 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 10000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: class-default (match-any)
      135 packets, 13264 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
R1#

Advanced CoPP Techniques

Control Plane Protection (CPPr)

Control plane protection categorizes control plane traffic into three types:

• Local (self generated): traffic originated by the local device and destined for its own control plane e.g. routing protocol updates
• Transit: traffic that transits the router and is punted to the CP for processing e.g. ICMP unreachable messages not unknown destinations, packets with expired TTL.
• Host: traffic destined for one of the router's interfaces (physical or logical) for management purposes e.g. SSH, HTTP, SNMP

CPPr subdivides control plane into three queues:

• Routing(OSPF, BGP, EIGRP)
• Management (SSH, SNMP)
• Transit (TTL-expired, ARP)

control plane
   service-policy input COPP-POLICY
   management-interface allow ssh snmp

Hierarchical CoPP (H-CoPP)

H-CoPP is supported on platforms such as ASR/Nexus and uses nested policies for granular control.

policy-map COPP-CHILD
  class BGP
   police 10000 conform transmit exceed drop

policy-map COPP-PARENT
  class routing
    police cir 20m
    service-policy COPP-CHILD


Troubleshooting

Troubleshooting control plane policing requires troubleshooting of the various components of CoPP i.e., access control lists, class maps, policy maps and service policies. When troubleshooting CoPP, consider;

ACLs

When troubleshooting ACLs for CoPP, focus on the following;

• Verify correct source and destination addresses, protocols, port number, action (permit | deny): show access-list
• Grouping: if grouping traffic types, ensure that they are grouped based on function; e.g. routing protocols (BGP, OSPF, EIGRP), management protocols (SSH, TELNET, HTTP(S), TFTP, SNMP, DNS, NTP).
• Action: with CoPP, a permit action in an ACL means match the traffic and apply the policy. Deny means exclude the traffic from the class and move on to the next class.
• Protocol: If the wrong protocol is specified in the ACL, the wrong type of traffic will be matched.
• Source and destination: the correct source and destination ACLs should be applied. During troubleshooting, change IP address to any to see the effect.
• Operators and Ports: Ensure correct ACL operator and port numbers are defined.
• Avoid log and log-input ACL keywords for CoPP due to unexpected results in CoPP functionality.

Class Maps

• Watch-out for the match-all and match-any commands.
• Verify that the class-map is configured correctly show class-map. Verify correct instructions (match-any, match-all), correct ACL, protocol,IP prec, DSCP.

Policy Maps

When troubleshooting policy maps, consider;

• Verify that the service policy is applied in the correct direction: show policy-map control-plane all.
• Verify that the policy-map is correctly configured; show policy-map
• Check the correct class-map, rate or CIR, conform-action, exceed-action,correct order.
• Order of operations: classes defined are processed from top to down.
• Class-map: has the correct class-map been configured correctly.
• Policy: Ensure the correct CIR in bps and rate in pps have been configured. In some IOS versions, if traffic that matches a class is to be dropped, replace police command with drop keyword.
• Default-class: if traffic does not match any defined class, it will be subjected to conditions laid out in the default class.
• Case: class names are case sensitive.

Service Policy

When troubleshooting the application of a service policy;

• Correct interface: service policy can be applied only to one interface, the control-plane. If applying to a physical interface, ensure that the service policy is configured on the correct interface. Confirm with show policy-map interface <interface-name>
• Direction: input for incoming packets. Confirm direction with; show policy-map control-plane. Not all IOS versions support output. For routing protocols, output CoPP would be for replies to queries / requests or ACKs. For ICMP; error or informational reply, for telnet, SSH, HTTP, SNMP replies or traps. Ensure the ACL and class-map are configured appropriately for replies.
• Case: Policy maps are case-sensitive; verify with show policy-map control-plane
• Verification: show platform hardware qos queue stats control-plane

Common Issues

• Too restrictive policing may result in legitimate traffic being dropped e.g. OSP updates due to flapping links.
• Too permissive policing may result in CPU exhaustion when traffic increases
• Missing class-default in a class map may result in unclassified traffic bypassing restrictions.

Best Practices

The following are some recommended best practices to consider when setting up CoPP:

• Baseline: monitor normal operational status before configuration of CoPP using the following:
  • show process cpu sorted
  • show control-plane stats
  • show interface <type> rate
  • NetFlow data
• Differentiate traffic types: recognize different control plane traffic types (local, transit, host) and their expected behaviour.
• Implement granular and specific class maps: Avoid catch all policies, use extended ACLs. Also consider routing protocol peering where a class map match specific traffic to and from known neighbor IP addresses. This can protect against rogue or misconfigured devices injecting excessive routing updates.
• Design adaptive policy maps: consider set-cos or set-dscp to mark traffic for further QoS treatment in the data plane.
• Consider two-rate policiing where a sustained rate is maintained (cir) and a peak rate (PIR) with corresponding burst sizes offering more flexibility in handling temporary bursts of legitimate traffic. Use the command police cir bc pir be
• Log exceed traffic: addthe exceed-action drop log to monitor attacks.
• Comine with control plane protection (CPP/CPPr): for granular control implement separate queues for management, routing etc.
• Start with Cisco's recommended CoPP templates (Aggressive, Moderate, Lenient).

Device Security using AAA (TACACS+, RADIUS and Local Database)

Authentication Authorization and Accounting

Authentication refers to the verification of the users accessing a device; it seeks answers to the question "Who are you?". Authorization defines what resources the user is allowed to access and which operations the user is allowed to perform. Accounting logs all user actions on the system.

AAA is usually used for device access and network access. Device access may require privileged access for administrative purposes.

Application of AAA in network access can be used to segregate users between employee access and guest access. Additionally, employee access can be further refined such that some employees can access some departmental resources and others should be unable to access network resources in other departments.

Authentication of a user can be performed using a username and password combination. Certificates (PKI) can also be used to authenticate users. The user may be a network device.

Authorization defines what resources the user has access to. It can also be defined as what actions the user is permitted to perform on a device.

AAA Components

AAA consists of three components: supplicant, authenticator and authentication server.

1. Supplicant: device requesting access; this may be a laptop, printer, smartphone. The supplicant is either requesting for network access or device access. Supplicant may also refer to the software on the laptop that is used to authenticate the end user.
2. Authenticator: this is the device being accessed; it is the device that is enforcing authentication (NAD). With device access, this device can be any network-connected device such as router, switch, wireless LAN controller. If the access request is for network access, the device is usually a wireless LAN controller or switch for wireless and wired network access respectively.
3. Authentication server: validates the identity of the client and notifies the authenticator if the client is authorized to access the network or device. This authentication uses username/password combination or certificates (PKI) to authenticate users. RADIUS is an example of an authentication service.

   Cisco systems offers Identity Services Engine (ISE) and Access Control System (ACS) to provide AAA services for a network.

Protocols

AAA can be used to authenticate users for device administration or network access:

1. Device administration: device access is done using console, SSH, Telnet and HTTP(S). The network device then uses RADIUS or TACACS+ to authenticate the user's network access with the authentication server.
2. Network access: users can be authenticated using protocols such as EAPoL, HTTP(S), SSL, IKEv1 and IKEv2. RADIUS, TACACS+ are used between NAD and authentication server.

Privileges

Privileges are the list of commands that a user is authorized to execute. IOS defines different privilege levels with level 0, 1 and 15 defined by default. Privilege levels 2-14 are open for customization. The following table displays the different levels of privileges in Cisco IOS:

Privilege Level	Origin	Accessibility
0	Built-in	No access. Few commands are available.
1	Built-in	User mode, very limited access. It is the default exec user level and provides some show commands.
15	Built-in	Privilege exec / enable mode, verification and full access.
2 - 14	User-defined	Granular control over commands users are authorised to use

Custom Privileges

These custom privilege levels are defined in the range 2 – 14. Users can then be assigned these privileges based on the level of configuration depth that you would like them to make on the devices. The default privilege for remote access (SSH, Telnet) is 1(one) while console is 15. If a privilege level is not assigned to a line or user, then the default privilege is used.

When configuring allowable commands to privilege levels, higher privilege levels inherit commands allowed in lower privilege levels. For example assigning a privilege level of 7 to a user grants the user privileges to run commands that have been defined in privilege levels 0 – 6 in addition to level 7.

The following example configuration sets the commands that the custom privilege level 2 is permitted to run. Here, the user is permitted to access the configuration mode and shutdown or enable interfaces only. Privilege level 2 is then assigned to a user account on the local database.

R1(config)#privilege exec level 2 configure terminal
R1(config)#privilege configure level 2 interface
R1(config)#privilege interface level 2 shutdown
R1(config)#privilege interface level 2 no shutdown
R1(config)#privilege exec level 2 show privilege
R1(config)#username bob privilege 2 secret alice
R1(config)#privilege interface level 3 ip address
R1(config)#privilege configure level 3 ip domain-name
R1(config)#username user3 privilege 3 secret cisco3


When the privilege level is defined on the router as in the case above, by default, the router will use the local database for commands.

The use of role-based access control(RBAC) provides granular control over commands and privileges from a centralized point.

Line Privilege

Privilege level can be configured for a line rather than a user (see Local Database section). This can be accomplished using the line command privilege level <level>. Here, all users who login into the device through the configured line will be granted the same privilege level.

R1(config)#line vty 0 4
R1(config-line)#privilege level 10

If a user has a privilege configured in the local database and the user logs into the device through a VTY line that has a configured privilege, the user's local database configured-privilege supersedes the configured line privilege.

Verification

To verify privileges of the login session, use the command show privilege.

R2#192.168.1.1
Trying 192.168.1.1 ... Open

User Access Verification

Username: bob
Password:
R1#show privilege
Current privilege level is 2


From the output above, the VTY line was configured with a privilege level of 10. However, the user bob's session privilege is 2(two) which is the privilege level configured in the local database.

Local Database

The local database is a list of user accounts configured on the local device. The local database contains records of the username, password and configured privilege levels for users. The local database supports authentication and authorization features. However, it does not support accounting functionality. Authorization is supported through the configuration of privilege levels. This database can be used to authenticate many types of sessions such as login sessions.

A local user database is created using the global config command username <username> privilege <level> secret <password>. Use of the keyword secret is preferred to password because it encrypts the secret key in the configuration file. If password is used, then the secret key has to be encrypted in the configuration file using the command service password encryption.

R1(config)#username bob privilege 1 secret alice
R1(config)#username alice privilege 1 secret bob
R1(config)#username rasta privilege 1 password reggae
R1(config)#do show run | in username
username bob privilege 2 secret 5 $1$WHSh$PYERWv2eq6ud0txH8G4id.
username alice privilege 3 secret 5 $1$HxyA$IHet6l6lilvR7A2z7bYme.
username rasta password 0 reggae


Local Database for Authentication

If the local database is to be used for authenticating remote users through VTY lines or local console connections, then the following commands can be used.

R1(config)#ip domain-name emmanueltoko.blogspot.com
R1(config)#crypto key generate rsa modulus 2048
The name for the keys will be: R1.emmanueltoko.blogspot.com

% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 33 seconds)

R1(config)#
*Feb 22 13:29:06.599: %SSH-5-ENABLED: SSH 1.99 has been enabled
R1(config)#ip ssh version 2
R1(config)#do show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2ErQIRNGA/SVNcDfgoGZs2KTF3nNPXPC19zUVakD9
NGKyb88AhWu1kVJeOSBarZzivfezJY5E2QLzFw6FjZ6Tla41NOTduziwzHht2dvO3kDTCli61wW9bF5Q
ekjXc8HOwOXd2f0kslx8Il9QxELY1Sq01tPk/Q4Pgza3NOqC+oLHVLkJt5JBDn84AybjYn56OgXk1ETb
Mjj2VKy7M7WdNlhful17LHX/mkVVZSavpMfMhpjaz/Z+yHbgGsNu5r5wNS29+rMpjB4OCAbpATy/Ee1V
GsEEiQU8XChJk9kwM8ADxFJZKz5bHHlmbyiI9LS/jN3SaEtZbU2pKpQwMaKN
R1(config)#line vty 0 4
R1(config-line)#login local
R1(config-line)#transport input ssh telnet

The above command enables authentication using the local database on vty lines 0 to 4 (5 simultaneous remote logins). In this snippet, SSH has been enabled as the primary remote access method with telnet as backup if SSH fails.

Note: It is recommended that remote access using telnet be disabled as it sends the authentication credentials and commands to the remote device in clear text.

Device Security With AAA

AAA refers to authentication, authorization and accounting. It is a refined approach to authenticating users, authorizing their activities and logging (accounting) for all their activities and commands issued on a network device. AAA supports the use of the local database, RADIUS and TACACS+ for authenticating and authorization, and only RADIUS and TACACS+ for accounting.

AAA features are not available until enabled globally using the global config mode command aaa new-model.

Local Database

When implementing AAA using the local database, the router authenticates the username and password using the local database and the user is authorized to access the network device based on the information in the local database. Local authentication is used on small networks and is not scalable.

Authentication with Local Database

1. Turn on AAA services;
   R1(config)#aaa new-model

2. Create a local user:
   R1(config)#username user secret pass

3. Set the enable password:
   R1(config)#enable secret pass

4. Configure login authentication to use the enable password as the default method:
   R1(config)#aaa authentication login default enable

   OR

   Create a login authentication method named local_auth and set it to authenticate users against the local database:

   R1(config)#aaa authentication login local_auth local

5. Apply AAA authentication to the VTY lines;

   If using the default method:

   R1(config)#line vty 0 15
R1(config-line)#login authentication default

   If using a configured authentication method:

   R1(config)#line vty 0 15
R1(config-line)#login authentication local_auth

6. SSH to above router: It uses the local database to authenticate;
   R1#ssh -l user7 192.168.1.1

Authorization using Local Database

If authorization is enabled for a line, and enable secret is configured, the enable secret is superseded by the aaa authorization. If authorization is not enabled for an authenticated user, the privilege level for a remote user (SSH) is set to 15. The user's configured privilege level is only enforced after enabling authorization.

To enable authorization,

1. Create a user:
   R1(config)#username user secret pass
   Login to the above router from the remote host: What is the privilege level?
2. Create an exec-authorization method: Create method list local-author. Configure authorization to be performed against the local router’s database
   R1(config)#aaa authorization exec local-author local

3. Apply local-author as an authorization method for the vty lines
   R1(config)#line vty 0 4
R1(config-line)#authorization exec local-author

4. Configure local authorization for specific intefaces
   R1(config-if)#aaa authorization exec <interface-type> <interface-number>

5. Configure local authorization for specific commands:
   R1(config)#aaa authorization commands <privilege-level> <command> local
   Replace privilege-level and command with the appropriate privilege level and command permitted respectively.

6. Telnet to router and authenticate.

The main drawbacks of local user authentication are:

• User credentials are stored locally i.e., on the device
• Solution is not scalable if the network grows to hundreds of devices
• More administrative overhead
• No centralized control over authentication services

It is therefore recommended to deploy the services of external server-based authentication such as ISE, ACS, or any other platform that supports RADIUS or TACACS+ for network access control.

Verification

AAA operational state can be varied by the various sub-commands under the show aaa command.

R1#show aaa ?
  acct-stop-cache   Show Acct Session IDs of poisoned sessions
  attributes        Show attributes supported by AAA subsystem
  cache             Show contents of AAA caches
  clients           Show AAA Client statistics
  command           Show AAA command infomation
  dead-criteria     Show what criteria will be applied to mark the specified
                    server dead
  local             Show AAA local method options
  memory            Memory usage information
  method-lists      Show method lists defined in the AAA subsystem
  servers           Show All AAA Servers as seen by the AAA Server MIB
  service-profiles  Show AAA service profiles downloaded and stored
  sessions          Show AAA Sessions as seen by AAA Session MIB
  user              Show users active in the AAA subsyste


R1#show aaa sessions
Total sessions since last reload: 8
Session Id: 8
  Unique Id: 23
  User Name: etoko3
  IP Address: 192.168.2.2
  Idle Time: 0
  CT Call Handle: 0
R1#

RADIUS

RADIUS (Remote Authentication Dial-In User Service) is a standards-based protocol for implementing AAA (RFC 2865). It combines authentication and authorization into a single resource. It offers robust accounting features. Previously (RFC 2138), the default ports for RADIUS servers are 1645 for authentication and 1646 for accounting. RFC 2138 sets the RADIUS ports on UDP to 1812 for authentication and 1813 for accounting. RADIUS uses both TCP and UDP as the transport protocol; however UDP is more commonly used. With RADIUS, only the password is encrypted. RADIUS combines authentication and authorization features. It offers robust accounting features.

The RADIUS server may be located in the same subnet or remote network. All that is required is for the local device to have IP connectivity to the RADIUS server.

Authentication

When configuring authentication of user credentials against a RADIUS server, the local device sends the authentication credentials entered by the user to the specificed IP address of the RADIUS server connecting to the port number 1812.

When configuring RADIUS authentication, ensure that a backup authentication method is configured to avoid being unable to access the device due to misconfiguration of the RADIUS authentication. Usually, this backup authentication method is the local database. When authenticating a user login session against a RADIUS server, IOS will attempt to connect to the RADIUS server up to five times by default, to make an access request. If the connection attempt fails all these five times, then the backup authentication method is used. A RADIUS server will not respond to an access request if the requester is not configured as a client. This happens regardless of whether IP connectivity between the client and the server exists.

RADIUS uses MD5 to generate a digest of the user's password by default.

If the RADIUS server does respond with an access denied message to an authentication request, then the IOS will deny access and not use the configured backup authentication method.

Configuration

1. Enable AAA with aaa new-model command;
   R1(config)#aaa new-model

2. Define the source of authentication: use local database as last resort; The default RADIUS authentication port is 1812 and accounting port 1813.
   R1(config)#radius-server host 192.168.1.2 auth-port 1812 acc-port 1813
R1(config)#radius-server host 192.168.1.2 key password

   OR

   R1(config)#radius server RADIUS_SERVER01
R1(config-radius-server)#address ipv4 192.168.1.2 auth-port 1812 acct-port 1813
R1(config-radius-server)#key complexpassword
R1(config)#radius server RADIUS_SERVER02
R1(config-radius-server)#address ipv4 192.168.1.5 auth-port 1812 acct-port 1813
R1(config-radius-server)#key complexkey

   Additional interaction with the RADIUS servers can be configured using the following options:

   • timeout <1-1000>: the time to wait(in seconds) for the server to respond when requesting for an authentication attempt. If access to the first server times out, an attempt to connect to the second server is initiated.
   • retransmit <0-100>: number of retries to active server after every failure. The default number of retransmit attempts is five times.

3. Server groups
   1. Default Radius group:

      When configuring a server, it is automatically added to a group radius. If a server group is explicitly configured (step below), then the server will be added to this group. This can be verified using the command show radius server-group all:

      R1#show radius server-group all
Server group radius                    
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1      
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0
    Server_auto_test_enabled: FALSE    
     Keywrap enabled: FALSE            
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0
    Server_auto_test_enabled: FALSE    
     Keywrap enabled: FALSE            
R1#

   2. Custom Server Group:
      1. Define a group name that will contain the list of servers: aaa group server radius <group-name>.
         R1(config)#aaa group server radius RADIUS_SERVERS

      2. Define each server in the group server <ip-address>
         R1(config-sg-radius)#server name RADIUS_SERVER01
R1(config-sg-radius)#server name RADIUS_SERVER02

         Alternatively, IP address or server name (requires DNS server to be configured) of the RADIUS servers can be defined in place of the server names using the command server <ip-address|hostname>. The timeout and retransmit settings can also be configured for each server in this group.

         R1(config-sg-radius)#do show radius server-group all
Server group radius                      
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1        
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
Server group RADIUS_SERVERS              
    Sharecount = 1  sg_unconfigured = FALSE
    Type = standard  Memlocks = 1        
    Server(192.168.1.2:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
    Server(192.168.1.5:1812,1813) Transactions:
    Authen: 0   Author: 0       Acct: 0  
    Server_auto_test_enabled: FALSE      
     Keywrap enabled: FALSE              
                                          
R1(config-sg-radius)#

         If configuring a server as private, using server-private instead of server, it does not get added to the group radius but is only available in the group can it is defined in.

         R1(config)#aaa group server radius RADIUS_SERVERS
R1(config-sg-radius)#server-private 192.168.1.7 auth-port 1645 acct-port 1646 key cisco

4. Configure the purpose of the authentication and method of authentication:
   1. Purpose of authentication: authentication can be enabled for a list of services such as the following:
      • login: login to the device.
      • enable: executing the enable command to move into privileged mode. The authentication prompt for enable appears regardless of connection type i.e., console, SSH, telnet.
      • dot1x: End user network access.
   2. Authentication list: You can list authentication methods by giving the method a descriptive name or using the unnamed ‘default’ method; aaa authentication login <default | list-name method1, method2, method3>.
      1. default list: the default authentication list uses the keyword default to define the list;
         R1(config)#aaa authentication login default

         It is recommended to use the named list over the default list. The default list keyword gets attached to console, vty lines automatically; it is common to all the lines. This increases the possibilities of getting locked out due to misconfiguration. With the named lists, the different lines such as console, vty will require explicit configuration.

      2. Using a named list: here, the named list AAA_AUTHENTICATION is used:
         R1(config)#aaa authentication login AAA_AUTHENTICATION

   3. Define the authentication method(s):

      More than one method can be configured. The methods refer to the following;

      • tacacs+: each tacacs+ server is tried in configuration order
      • radius: each radius server is tried in configuration order
      • local: the local user database containing the username commands configured on the switch
      • local-case: use the local database with case sensitivity.
      • enable: use of the enable password for authentication.
      • line: line passwords authenticate any connected user. No usernames can be used.

      The following configuration uses the enable authentication as a backup for RADIUS authentication.

      R1(config)#aaa authentication login AAA_AUTHENTICATION group radius local enable

      The keyword group has the options RADIUS or TACACS and the authentication request will be forwarded to the configured RADIUS groups first, the next 'local' will be used if the RADIUS servers are unavailable/unreachable. Lastly, the enable password will be used for authentication. Note: Add the local, line and/or enable methods at the end of the list as a last resort authentication method.

      If the authentication using RADIUS fails, the next authentication method is not used. RADIUS authentication failure happens when a user account is not available in the RADIUS server or when a user's password is not correct. The second authentication method is only used if the RADIUS server is not reachable.

      However, if the local or local-case authentication method is configured as first authentication method and RADIUS as second, if an authentication request fails for the local method, then RADIUS authentication is attempted next. This fact can be used to ensure that some users are authenticated using the local database and others use RADIUS only.

5. Apply a method list to a line (Console, VTY): To enable AAA authentication on VTY lines 0 to 4 (5 simultaneous connections).
   R1(config)#line vty 0 4
R1(config-line)#login authentication AAA_AUTHENTICATION

Instead the default unnamed method list can be used if method list was not defined in Step 4.

Verification

RADIUS authentication can be verified using the command debug radius authentication. The following output shows an attempt to login remotely using telnet. The RADIUS servers in the server group are unreachable, so the backup authentication method, local-case is used and is successful:

!!On R1

R1#debug radius authentication


!--------------------------

!!On R2

R2#192.168.1.1
Trying 192.168.1.1 ... Open

User Access Verification

Username: bob
Password:

R1#

!!! Debug messages on R1
!---------------
*Apr 17 22:47:31.367: RADIUS/ENCODE(00000024): ask "Username: "
*Apr 17 22:47:31.367: RADIUS/ENCODE(00000024): send packet; GET_USER
R1(config)#
*Apr 17 22:47:37.479: RADIUS/ENCODE(00000024): ask "Password: "
*Apr 17 22:47:37.483: RADIUS/ENCODE(00000024): send packet; GET_PASSWORD
R1(config)#
*Apr 17 22:47:41.855: RADIUS/ENCODE(00000024):Orig. component type = Exec
*Apr 17 22:47:41.859: RADIUS: AAA Unsupported Attr: interface [221] 4 1797168952
*Apr 17 22:47:41.859: RADIUS/ENCODE(00000024): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
*Apr 17 22:47:41.859: RADIUS(00000024): Config NAS IP: 0.0.0.0
*Apr 17 22:47:41.859: RADIUS(00000024): Config NAS IPv6: ::
*Apr 17 22:47:41.863: RADIUS/ENCODE(00000024): acct_session_id: 19
*Apr 17 22:47:41.863: RADIUS(00000024): sending
*Apr 17 22:47:41.867: RADIUS/ENCODE: Best Local IP-Address 192.168.1.1 for Radius-Server 192.168.1.2
*Apr 17 22:47:41.867: RADIUS(00000024): Send Access-Request to 192.168.1.2:1812 id 1645/2, len 67
*Apr 17 22:47:41.867: RADIUS: authenticator 83 1D 62 A3 6C FD D2 D4 - A2 59 29 65 B0 96 39 3D
*Apr 17 22:47:41.867: RADIUS: User-Name [1] 5 "bob"
*Apr 17 22:47:41.867: RADIUS: User-Password [2] 18 *
*Apr 17 22:47:41.867: RADIUS: NAS
R1(config)#-Port [5] 6 2
*Apr 17 22:47:41.867: RADIUS: NAS-Port-Id [87] 6 "tty2"
*Apr 17 22:47:41.867: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
*Apr 17 22:47:41.867: RADIUS: NAS-IP-Address [4] 6 192.168.1.1
*Apr 17 22:47:41.867: RADIUS(00000024): Sending a IPv4 Radius Packet
*Apr 17 22:47:41.867: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:46.875: RADIUS(00000024): Request timed out!
*Apr 17 22:47:46.875: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:46.879: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:51.923: RADIUS(00000024): Request timed out!
*Apr 17 22:47:51.923: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:51.927: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:47:56.959: RADIUS(00000024): Request timed out!
*Apr 17 22:47:56.959: RADIUS: Retransmit to (192.168.1.2:1812,1813) for id 1645/2
*Apr 17 22:47:56.963: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:01.979: RADIUS(00000024): Request timed out!
*Apr 17 22:48:01.979: RADIUS: Fail-over to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:01.983: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:07.019: RADIUS(00000024): Request timed out!
*Apr 17 22:48:07.019: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:07.019: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:12.047: RADIUS(00000024): Request timed out!
*Apr 17 22:48:12.047: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:12.051: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:17.083: RADIUS(00000024): Request timed out!
*Apr 17 22:48:17.083: RADIUS: Retransmit to (192.168.1.5:1812,1813) for id 1645/2
*Apr 17 22:48:17.087: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:22.111: RADIUS(00000024): Request timed out!
*Apr 17 22:48:22.111: RADIUS: Fail-over to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:22.115: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:27.135: RADIUS(00000024): Request timed out!
*Apr 17 22:48:27.135: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:27.139: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:32.175: RADIUS(00000024): Request timed out!
*Apr 17 22:48:32.179: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:32.183: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:37.215: RADIUS(00000024): Request timed out!
*Apr 17 22:48:37.215: RADIUS: Retransmit to (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:37.219: RADIUS(00000024): Started 5 sec timeout
R1(config)#
*Apr 17 22:48:42.243: RADIUS(00000024): Request timed out!
*Apr 17 22:48:42.243: RADIUS: No response from (192.168.1.7:1645,1646) for id 1645/2
*Apr 17 22:48:42.247: RADIUS/DECODE: No response from radius-server; parse response; FAIL
*Apr 17 22:48:42.247: RADIUS/DECODE: Case error(no response/ bad packet/ op decode);parse response; FAIL
R1(config)#

Authorization

AAA authorization determines what commands an authenticated user is permitted to issue to the network device. Authenticated users are by default put at EXEC level. Command authorization involves configuring the commands that an authenticated user is permitted to use. Here, an authorization request is sent to the RADIUS server each time that the user types a command. Authorization can be configured to set the login session to a configured privilege. If privileges have not been configured, then the default privilege is set (one for remote session and fifteen for a console session).

Configuring a privilege at the line level is not recommended as all users will have the same privilege. It is recommended to set the privilege for each user.

1. Configure authorization by defining any RADIUS or TACACS+ servers. Follow steps 1 -3 of RADIUS and/or TACACS+ configurations above.
2. Define a method list of authorization that will be tried in sequence using; aaa authorization <commands | config-commands | configuration | exec | network| reverse-access> <default | list-name> method1, method2, method3 …. methodn .

   Specify the function or service needing authorization with one of the following keywords;

   • commands: the server must return permission to use any command at any privilege level
   • config-commands: the server must return permission to use any configuration command.
   • configuration: The server must return permission to enter configuration mode.
   • exec: server must return permission for the user to run an EXEC session. The server can also return the privilege level for the user so that the user immediately can be put into privileged EXEC (enabled) mode without typing ‘enable’.
   • network: the server must return permission to use network-related services.
   • reverse-access: the server must return permission for the user to access a reverse telnet session.

   You can identify the method with a descriptive name (list-name) or use the single unnamed list (default). Each authorization method will be listed in the order it will be tried;

   • group <group-name>: requests are sent to servers in a group.
   • group <radius|tacacs+: requests are sent to all servers of this type.
   • if-authenticated: requests are granted if the user is already authenticated.
   • none: no external authorization is used; every user is authorised successfully.

   Only TACACS+ servers can authorise users with permission to use specific commands. RADIUS servers offer more of an all or nothing approach.

3. Apply an authorization method list to a specific line; authorization <commands level | exec | reverse-access> <default | list-name>. If this command is not entered, the default group is used for all lines. To configure a switch / router to use AAA authorization for all lines using configured TACACS+ group, with the local user database as backup authorization.
   R1(config)#aaa authorization exec aaa-exec group tacacs+ local

   Another example:

   R1(config)#aaa authorization exec VTY group radius local

   Here authorization is attempted using configured RADIUS servers; if this fails, then the local database is used as backup.

4. Apply the authorization to the line:
   1. For remote sessions(vty):
      R1(config)#line vty 0 98
R1(config-line)#authorization exec VTY

   2. For console sessions:

      Authorization is not enabled on console by default. It should be explicitly enabled first.

      R1(config)#aaa authorization console

      R1(config)#line console 0
R1(config-line)#authorization exec CON


autocommand logout

Given a user, bob, if we want to ensure that this account is authenticated for some purposes but not for login, one option available is not to use the aaa authentication for login. Another option is to use username bob autocommand logout. Under authorization, aaa authorization exec default local group MYRADIUS.

Accounting

AAA accounting logs all actions including configurations and show commands issued on the network device. To configure accounting, the following sequence of commands needs to be configured;

Enable AAA and configure RADIUS and TACACS+ server groups as described in steps 1 -3 of RADIUS and TACACS+ authentication procedures. Define a method list giving a sequence of accounting methods; aaa accounting [system | exec | commands <level>] [default | <list-name>] [start | stop | stop-only | wait-start | none] [method1 method2 method3 ..methodn] .

The function triggering the accounting can be one of the following;

• system: major events such as reloading are recorded.
• exec: user authentication into an EXEC session is recorded along with the user’s address, time, duration.
• commands level: information about any command running at a specific privilege level is recorded, along with the user who issued the command.

You can specify that certain types of accounting records to be sent to the accounting server using;

• start-stop: events are recorded when they start and stop-only
• stop-only: event are recorded only when they stop.
• none: no events are recorded.

Apply an accounting method list to a specific line; accounting <commands level | connection | exec> <default | list-name>. If the above command is not used, default group will be used for all lines. User EXEC sessions will be recorded as they start and stop along with user information. Any commands that are entered while a user is in privilege 15 (enable mode) will also b recorded.

Example:

R1(config)#aaa accounting exec default start-stop group myauthserver
R1(config)#aaa accounting commands 15 default start-stop group myauthserver

RADIUS Server Configuration

The RADIUS server will have to configured to authorize users based on their authentication credentials. Some popular RADIUS servers include FreeRADIUS, daloRADIUS. The following is an example configuration of daloRADIUS:

# Define the RADIUS server server {
  # Set the server IP address and port
  ipaddr = 192.168.1.100
  port = 1812

  # Set the authentication protocol
  auth_protocol = PAP

  # Set the authentication server
  auth_server = mysql

  # Set the authorization server
  authz_server = mysql
}

# Define the MySQL database
mysql {
  # Set the MySQL server IP address and port
  ipaddr = 192.168.1.200
  port = 3306

  # Set the MySQL database name
  database = "radius"

  # Set the MySQL username
  username = "radius"

  # Set the MySQL password
  password = "password"
}

# Define the user database
users {
  # Define a user
  user {
  # Set the username
  username = "cisco"

  # Set the password
  password = "cisco123"

  # Set the service type
  service_type = Exec-User

  # Set the Cisco AVPair
  Cisco-AVPair = "shell:priv-lvl=15"
  }
}



TACACS+

Developed by Cisco systems, it is mainly used for device administration using ACS servers. It uses TCP port 49 for both the client and server. TACACS+ does not support EAPoL.

In networks supporting TACACS+ and RADIUS, it is common for TACACS+ to be used for device administration and RADIUS for network access.

Authentication using TACACS+

TACACS+ (Terminal Access Controller Access Control System) is Cisco-proprietary and uses port 49 on TCP (but also UDP). It provides separate services for authentication, authorization and accounting. TACACS+ offers basic accounting features. Unlike RADIUS where only the password is encrypted, with TACACS+, the entire packet is encrypted.

Configuration

1. Enable AAA:
   R1(config)#aaa new-model

2. Configure TACACS+ server settings on the client:
   R1(config)#tacacs server TACACS+_SERVER01
R1(config-tacacs-server)#address ipv4 192.168.1.2
R1(config-tacacs-server)#key complexpassword
R1(config)#tacacs server TACACS+_SERVER02
R1(config-tacacs-server)#address ipv4 192.168.1.5
R1(config-tacacs-server)#key complexkey


   The TACACS+ port does not need to be explicitly configured as the default port of 49 is used. However, it can be explicitly configured if the TACACS+ server is listening on a port that is not the default TCP port 49.

   R1(config-tacacs-server)#port 65000

   Some prefer to configure TACACS+ server settings using the command tacacs-server host <server-ip-address>.

   R1(config)#tacacs-server host 192.168.1.2
R1(config)#tacacs-server key complexpassword

3. Configure TACACS+ server groups;
   R1(config)#aaa group server tacacs+ TACACS+_SERVER_GROUP
R1(config-sg-tacacs)#server name TACACS+_SERVER01
R1(config-sg-tacacs)#server name TACACS+_SERVER02


4. Create a login authentication method named ‘AAA_AUTHENTICATION’ and configure it to authenticate against a TACACS+ server. The local user database should be the backup authentication method.
   R1(config)#aaa authentication login AAA_AUTHENTICATION group tacacs+ local

5. Apply ‘AAA_AUTHENTICATION’ method to vty lines
   R1(config)#line vty 0 4
R1(config-line)#login authentication AAA_AUTHENTICATION

6. Telnet above router. What credentials were used and why?

Cisco Authentication Servers

Cisco offers access control system (ACS) and Identity Services Engine(ISE) servers as physical hardware or virtual images to implement access authentication. ACS and ISE support RADIUS and TACACS+:

• Access Control System (ACS):
  • Used for both device access and network access
  • Supports both RADIUS and TACACS+ with TACACS+ particularly used for device access.
• Identity Services Engine (ISE):
  • Mainly used for network access.
  • Mainly uses RADIUS. However, starting ISE 2.0, TACACS+ support has been added.
  • Supports RADIUS with Change of authorization (CoA).
  • Supports additional features such as profiling such as granting access to specific devices only, security posture assessment of the end-user device (device must meet certain minimum requirements), web portal services such as for guest user access.