Cisco ISE Secured Wired Access

ISE Deployment Components

A typical ISE-based network access control solution comprises four components, endpoints, network devices, Cisco ISE, and external services.

Endpoints need network access, and the network devices provide network access to endpoints, based on instructions from ISE. ISE can optionally leverage external services to understand more about the corresponding endpoints for policy decisions. When it comes to rolling out an identity-based network, because these four parts of the network are involved, various teams and individuals need to be engaged. Various ISE use cases, such as Guest access, BYOD, Posture, and so on require endpoints communicating to ISE via network devices.

• Endpoint, which connect to network
• Network Device, which will get access to your network
• Cisco ISE, which will determine who should get access and what level of access
• External Services, which resolved the user identity from external identity source

Endpoint Supplicants

Popular Supplicants are:

• Windows Native supplicant
• MAC OS Native Supplicant
• Android/iOS Native Supplicant
• Cisco AnyConnect Secure Mobility NAM Client
• Linux Native Supplicant (wpa_supplicant) 

Endpoint Onboarding Overview

Users and Endpoints Authentication
With valid credentials, endpoints get controlled access.

• Before ISE authenticate any endpoint, ISE need to identify the endpoint and their valid credentials, like certificates, MAC-ID, passwords, Token/OTP.
• For this Cisco ISE should be firstly integrated with External identity stores which includes Active Directory, SQL Server, LDAP Server.
• The user/endpoints credential reach ISE through process called Authentication, which means validating the credential, and as part of the authentication process there are various authentication protocols that users/endpoint can use.
• Basically, through the process of Authentication we tell ISE who you are

Users and Endpoints Authorization

• Every Authentication ends with an Authorization.
• So, with the revealed user/endpoint identity, ISE determines what level of access should be granted to that user/endpoint.
• The wired access or remote vpn access are basically secured from Day-1, due to the nature of their connectivity, so most of the enterprise networks are moving towards the Secured wired access.

Benefits of Wired Access:

• Asset Visibility: Provides greater visibility into the network due to authentication process which is useful for security audits, network use statistics, etc.
• Security: Allows network administrator to control network access at the access edge.
• Identity-Based Services: Authorize endpoints into a specific VLAN or assign a unique access list that grants appropriate access for that user.
• Transparency: Transparent to End users
• User and device authentication: Can authenticate both devices and users

Authentication and Authorization

Authentication basically identified the user identity. In simple term, validating user/endpoint credentials. On other side, authorization mean, what your entitled to, and the user in question have the permission to access the requested resources.
So, you can see both authentication and authorization work together.
As in figure you can see both employee and contractor have been authenticated, but the employee has all the access, but the contractor have limited access.

Authentication Options
Active Identity
IEEE 802.1X

• The 802.1x standard defines a client/server-based access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated. 
• The authentication server authenticates each client connected to a switch port before making available the services offered by the switch or the LAN.  
• The supplicants on the endpoints use Extensible Authentication Protocol (EAP) to pass credentials, such as passwords or certificates, to ISE. 
• EAP payloads are typically transported over 802.1X in Ethernet networks (EAP over LAN or simply EAPoL) and over RADIUS in IP networks. 
• ISE evaluates an endpoint’s identity and instructs the corresponding network device about whether to open the port or not, the VLAN or ACL or both VLAN and ACL that are to be applied for that endpoint’s access session.

Web Authentication

• Web authentications are typically used to onboard guest users for internet access. Cisco platforms provide a couple of options, Local Web Authentication (LWA) and Central Web Authentication (CWA). 
• In the former, web pages are hosted in network devices such as a switch or a wireless LAN controller, and in the latter, all web portals are hosted centrally on ISE. 
• CWA, which is the preferred method, is typically a MAB session with URL-redirect authorization on the switch port. 
• Until the corresponding endpoint is authenticated successfully, web traffic from the endpoint is redirected to ISE via a login portal for end users to enter their credentials.  
• Upon successful authentication, ISE initiates a Change-of-Authorization (CoA) to permit additional access.

Passive Identity
MAC Authentication Bypass (MAB)

• MAB enables port-based access control using the MAC address of an endpoint. 
• A MAB-enabled port on the switch can be dynamically enabled or disabled based on the MAC address of the device that connects to it. 
• The MAC addresses of endpoints must be whitelisted in a database that is present in ISE or in an external location to grant network access to known endpoints. 
• MAB is not truly an authentication method; it functions more as an authentication bypass when an endpoint is unable to perform 802.1X authentication. 
• While MAB can protect networks from unauthorized access, it is not a secure alternative to 802.1X because MAC addresses can be spoofed easily.

Easy Connect

• The Cisco ISE EasyConnect feature enables enterprises to implement identity-based network access without the need for 802.1X. No supplicants or supplicant configurations are needed on endpoints. 
• An EasyConnect session, which is like the CWA flow, starts with a MAC authentication bypass. 
• ISE learns about an endpoint’s location, MAC address, and IP addresses via an initial MAB session. 
• This initial MAB session is authorized with limited access from ISE to enable a Windows Active Directory-managed endpoint to perform a Windows domain login. 
• Upon successful domain login, the user ID to IP address mapping from the Active Directory (AD) domain controller is retrieved to ISE and merged with the initial MAB session. 
• After the user ID and its AD group membership is resolved, ISE changes the authorization to permit additional access.

Note:

• Of the various authentication options discussed until now, IEEE 802.1X is the most secure and flexible authentication method. 
• There are several EAP methods that allow a variety of credential types to be handled, depending on the endpoint and the environment type. 
• Although the Web Authentication and EasyConnect options provide the necessary user ID context for visibility and access control, they are constrained to specific types of endpoints, for example, Web Authentication requires user interaction and a device with a compatible web browser and EasyConnect works only for Windows Active Directory-managed endpoints. 
• Finally, MAB is less secure authentication method and fall-back mechanism for IEEE 802.1X, but is the easiest option to configure basic level of controlled access.

Authorization Options

• The ISE Authorization Policy is composed of authorization rules
• Authorization rule is composed of three main elements: name, attributes/conditions, and permissions (authorization results)
• Authorization results consists of authorization profiles and Security groups.
• Authorization result is used to specify the permission to be granted when attribute(s)/condition(s) of an authorization rule is/are matched.
• Profile, or Security Group, or both can be used to specify the permission to be granted when an authorization rule is matched.
• An authorization profile acts as a container where several specific permissions allow access to a set of network services.
• The authorization profile is where you define a set of permissions to be granted for a network access request and can include ACL (Filter-ID), DACL, VLAN, etc.

An ISE authorization policy is composed of authorization rules defined for a specific users and group of users to permit, deny, or provide limited access to network resources. Authorization profiles let you choose the attributes to be returned when a RADIUS request is accepted or rejected with RADIUS ACCESS-ACCEPT and ACCESS-REJECT access type commands. Limited access authorization may vary from environment to environment. The question to be asked is, what should be limited, and how?

Dynamic VLAN Assignment

• One of the traditional means of limiting network access is by placing endpoints in different VLANs based on their role. 
• Endpoints in specific VLANs can be access controlled by policies that are defined at Layer 3 boundaries, such as on routers or firewalls. 
• ISE can authorize endpoints to specific VLANs using a VLAN name or a VLAN number. 
• Also, in platforms such as Cisco Catalyst 2960X, 3650 Series, 3850 Series, and 9300 Series, VLANs can be applied on a per-MAC address basis.
• Best Practice: When doing dynamic VLAN assignment, we recommend using VLAN names rather than numbers. This will make your ISE authorization easier to read, understand and maintain. When you have a large switch, it is better to let the switch locally determine the actual VLAN number assigned with a name.

IP Access Control Lists (ACLs)

• ACLs can be used to control network access at the port level. They can either be downloaded to the network from ISE or be configured locally on a switch and be referenced by ISE during authorization. 
• Named ACL authorization can be carried out with a RADIUS-standard attribute called Filter-ID, using the ACL name. 
• For ACL downloads, either a Per-User ACL or a Downloadable ACL (dACL) can be used. 
• Both these ACL download options use Cisco custom RADIUS Attribute Value Pairs (AVPs). 
• While Per-User ACLs have a 4000-character limit, dACLs do not. However, the practical recommendation for dACLs is 64 Access Control Entries (ACEs).

Security Group Tags (SGTs)

• SGTs offer an efficient alternative to VLAN-based segmentation. 
• Just like VLAN authorization, assigning an SGT alone to an endpoint does not control access. Instead, after SGT assignments, endpoints must be subject to egress enforcement policies based on SGTs. 
• Note that although in most cases, identity-based access is necessary for SGT-based segmentation.

URL Redirection

• An access switch can redirect endpoints to specific URLs that are authorized by ISE for redirection. 
• Typically, URL redirection is towards the ISE nodes so that the endpoints can carry out web authentication with ISE. 
• However, endpoints can be subject to custom URLs as part of RADIUS authorization from ISE. Custom AVPs are used for URL redirection in an identity-based network.

Session-Aware Networking

• ISE along with Cisco Catalyst switches implement session-aware networking which offers consistent way to configure features across technologies, easy deployment and features customization along with robust policy control engine. 
• Under this, a session identifier is attached to an endpoint’s network access session (wired or wireless), and session ID is used for all reporting purposes such as show commands, MIBs, and RADIUS messages and allows users to distinguish messages for one session to other sessions. 
• This common session ID is used consistently across all authentication methods and features applied to a session.

• When an endpoint connects to network, the network device generates a unique session identifier that is a combination of the network device IP address, the session count on the network device, and the timestamp of the corresponding endpoint’s initial connection.

• ISE can invoke the network device to enforce specific policies for the endpoint using the Session ID. 
• After the initial authorization, ISE issues a CoA by referencing the same Session ID. Distinct access policies for the endpoints on the same port are applied because of the separation maintained by the Session ID.

Other Authorization Options for Access Control

• Voice Domain Permission – Enables vsa of “cisco-av-pair”. Endpoint placed on a voice domain after authorization.
• Web Redirection (CWA, MDM, CPP) – Allows network administrator to control network access at the access edge.
• Auto Smart Ports – Enables vsa of “cisco-av-pair” to attach a Device-specific built-in/User-Defined Macros
• Reauthentication – Maintain connectivity during reauthentication process
• MACSec Policy – Enable MACSec encryption policy whenever a MACSec-enabled client connects to Cisco ISE
• NEAT - Enables vsa of “cisco-av-pair” to extend secure access in areas outside the wiring closet.
• Interface Template - Enables vsa of “cisco-av-pair” to use interface template for authentication
• Web authentication – Enables Local Web Authentication for its authorization profile
• ASA VPN – Enables ASA VPN group policy

Policy Set

A policy set is a hierarchical container that is used to logically group authentication and authorization policies.

• Policy set can be configured based on network access use cases, location of network access device, type of network access device, and so on.
• For example, you can have a policy set for wired 802.1x use case, another policy set for wireless 802.1x, another policy set for guest users, another policy set for endpoints requesting network access from a particular location or connecting through a particular network device and so on.
• That means, authentication and authorization rules for wired 802.1x will be contained in wired 802.1x policy set. Authentication and authorization rule for wireless 802.1x will be contained in wireless 802.1x policy set and so on.
• Policy set is evaluated using a top-down approach, and it is the first match policy set that will be applied. If the attributes of a RADIUS request match a policy set, the request will be subjected to the authentication and authorization rules of that policy set.
• If ISE receive a request for authentication or network access, it evaluates the attributes of the received request against the condition(s) of the first policy set, if there's no match, it proceeds to the second policy set and so on, until it finds a matching policy set.
• If no configured policy set is matched, the default policy set will be applied.
• If a policy set is matched, the request will be evaluated against the authentication rules contained in the policy set, using top-down approach.
• If no authentication is matched, the default authentication rule will be applied.
• If an authentication rule is matched, and authentication is successful, the request will be further evaluated against the authorization policies contained in the policy set, starting from Local Exceptions to Global Exceptions, all the way to authorization policy.
• If an authorization rule is matched, the authorization profile of the rule will be applied to the session, but if no authorization rule is matched, the default authorization rule will be applied.

Network Device

“Network device” or “Network Access Device (NAD)” indicates a Cisco Catalyst switch that runs on Cisco IOS software. There are three major configurations to perform on Catalyst switch for it to work with ISE.

• The global AAA and RADIUS server configurations govern how a switch talks to ISE, how RADIUS transactions are load balanced, how frequently accounting updates are sent, how the switch handles failure scenarios when ISE is not reachable.
• The endpoint side configuration includes interface level commands to handle specific authentication methods such as 802.1X or MAC authentication bypass in a particular order.
• ISE might authorize an endpoint with a VLAN, ACL, SGT configuration or URL redirection. Note that some authorization-related configurations must be done locally on the switch.
• The port configurations can be done using IBNS 1.0 or 2.0 methods.

Switchport Host Modes
On All Cisco Catalyst switches there are 4 modes which can be configured as:

• Single Host Mode: Only one client or mac address is allowed on the network
• Multi-Host Mode: Basically, you can authenticate on of those users behind or maybe hub and all other endpoints or hosts which are connected behind that hub will be piggybacks on primary authentication.
• Multi-Domain Mode: Basically, allowed one client, which may be a wired client, and we also allow one client under voice side. So, one voice client and once Data client independently authenticates to ISE. Use any authentication method, but they both need to be authenticate.
• Multi-Auth Mode: This is the default mode. It is basically the extension of multi-domain mode. Voice domain authenticates one MAC address/client. Data domains authenticate multiple clients. dACL or single vlan assignment for all devices are supported.

Phased Deployments

• Enabling 802.1X on switch ports can be disruptive. The need for endpoints to prove their identity with some sort of authentication and then get network access, may not work well for all device types. 
• With wireless, this is a norm because the endpoints do not plug to the network; rather, they must be configured (for SSIDs) to connect to the network. The notion of configure and connect is built ground up in the wireless world, while the same is not the case with the wired side of networks. 
• For decades, the expectation is that the endpoint must get IP address the moment they plug in to the wired Ethernet port.
• We recommend a phased deployment model that has limited impact on network access while gradually introducing authentication and authorization on the wired network. 
• The three deployment modes are:

Monitor Mode (Open Mode)

• This Mode enables authentication across Wired infrastructure, while authorization is kept open. 
• This means that irrespective of the endpoint’s authentication status (success or failure), the port is always open. 
• When a user plugs in a device after monitor mode is enabled in the network, there is no impact to the end user irrespective of the authentication status. 
• Such a setting provides adequate visibility centrally to the security operator to know how many endpoints authenticate successfully, how many fail, why they fail, where they are located, and so on. After most of the failures are fixed, one of the below two enforcement modes can be enabled. 
• Note, Monitor Mode is not for validating enforcement of more advanced authorization results such as Scalable Group Tags (SGT’s), Scalable Group ACL’s (SGACL’s), downloadable ACL’s(dACL’s) or even dynamic Vlan Assignment.
• We simply want the authentication server to send back a basic RADIUS access accept or access reject to the authenticator (access switch).
• Configuration:

Enable 802.1X and MAB
Enable Open Access – All traffic in addition to EAP is allowed, like not having 802.1X enabled except authentication still occur
Enable Multi-Auth host mode
Authorization Honoured (Access-Reject-Ignored)

Low-Impact Mode

• This mode builds on the monitor mode.
• With open access in place, IP ACLs are used to control pre-authentication and post-authentication network access. A Pre-Auth ACL on the switch port controls network access before an endpoint can successfully authenticate.
• A named or downloadable ACL that is received from ISE grants specific level of access upon successful authentication.
• The Low-Impact mode is ideal for a Preboot Execution Environment (PXE) boot environments where thin clients must download the operating system from the network before attempting network authentication.
• Since devices get IP address immediately after they connect to the network, and authentication may take place in parallel or later, we recommend that you do not make VLAN changes in the Low-Impact mode.
• Configuration:

Start from Monitor mode
Configure Pre-Auth port ACLs on switch and attach to interface
Create dACL on ISE for both Data and Voice Vlans.
Reference these dACL in the authorization policy to override PORT ACL once authenticated.
Note: VLAN assignment not recommended as part of Auth result.

Restricted Mode (Closed Mode)

• In this mode, the port is closed by default.
• Only EAPoL payloads are allowed for 802.1X authentication.
• Upon successful authentication, the endpoints can have access to network services.
• Since endpoints do not acquire dynamic IP addresses without authentication, this mode is ideal for VLAN authorizations.
• Configuration:

Return to default “Closed” Access
Timers or Authentication order changes
Implement Identity-based VLAN Assignment

Preparing Switch for Identity-Based Network Access

Identity Configuration

Identity-Based Networking Services (IBNS)
Legacy Style

• IBNS is distinct from IEEE 802.1x but it has the same 802.1x functionality. IBNS is a systems security framework that delivers network authentication methods, and a part of it uses IEEE 802.1x.
• IEEE 802.1x is a standard defined by IEEE 802.1x working group for addressing port-based access control using authentication. 
• It defines a standard link-layer protocol that is used for transporting higher-level authentication protocols, and the actual enforcement is via MAC-based filtering and port state monitoring.

Limitations of IBNS 1.0

• Critical Authorization – Need feature to locally activate an IP ACL during RADIUS server outage
• Differentiated Authentication – Authentication request to specific RADIUS server for specific methods
• Flexible Authorization – Need more flexibility in moving between authorization for various authentication methods
• Configuration Bloat – per port configuration grows making it difficult to manage system configuration.

Identity-Based Networking Services (IBNS) 2.0

• The advanced access session manager, a core component of the Cisco Policy Aware IBNS architecture, provides a policy- and identity-based framework for flexible and scalable services to secure-access clients (Figure). 
• This framework enables provisioning for any authentication with any authorization on any media: wired or wireless. 
• The enhanced policy engine is equipped with a new set of capabilities, and a flexible configuration option, Cisco Common Classification Policy Language (referred to as C3PL), is provisioned, giving administrators more power to define enterprise-wide secure access policy

• Configuring the C3PL policy from the foundation may seem challenging given the various options with which the command set is equipped. 
• To ease this effort, Cisco IOS® Software provides a conversion tool that migrates the existing identity configuration commands on the port to the new policy-mode configurations (Figure)

Service Templates
A service template contains a set of service-related attributes or features, such as access control lists (ACLs) and VLAN assignments, which can be activated for one or more subscriber sessions in response to session lifecycle events. Templates simplify the provisioning and maintenance of network session policies in which policies are divided into distinct groups or are role based (Figure)

IBNS 2.0 supports CoA requests to initiate:

• Activation and deactivation of service templates for sessions
• Port bounce
• Port shutdown
• Session querying
• Session reauthentication
• Session termination

CoA for Local Web Authentication - The access session manager can now facilitate CoA for web authentication sessions. All CoA commands that can be run for any authentication session are also applicable for web authentication

Features

• C3PL-based identity configuration
• Concurrent authentication methods for a single session, including IEEE 802.1X (dot1X), MAC authentication bypass (MAB), and web authentication
• Locally defined & downloadable identity service templates
• Interface templates & Autoconf
• Extended RADIUS change of authorization (CoA) support for session querying, reauthentication, and termination; port shutdown and port bounce; and identity service template activation and deactivation
• Local authentication using Lightweight Directory Access Protocol (LDAP)
• Per-user inactivity handling across methods
• Web authentication support for common session ID
• Web authentication support for IPv6

Identity-Based Networking Services (IBNS) 1.0 vs. 2.0

• When it comes to the switch configurations required for ISE deployment, one of the most important considerations is whether to go with IBNS 1.0 or IBNS 2.0 MQC-style commands. 
• IBNS are the identity-based session management services on Cisco IOS, which are meant to handle access services for endpoints connecting to a network. 
• The policy functions on a switch determine how to facilitate an endpoint’s network authentication with a centralized AAA server, how to treat the endpoint when there are authentication failures or how to handle AAA server unreachability. 
• IBNS can be implemented in two ways, depending on the platform support and policy needs.

• Apart from significant changes in the Cisco IOS components that handle identity-based services, from an administration and operations perspective, there are considerable differences between IBNS 1.0 and IBNS 2.0. 
• As the figure above depicts, in case of IBNS 1.0, which is sometimes referred to as legacy mode in CLI, a switch’s local policy for handling an endpoint’s identity-based network access is all contained within interface configurations (a list of interface commands applied to a switch port). 
• On the other hand, in case of IBNS 2.0, the configurations take the structure of a Cisco Modular Quality of Service CLI (MQC). 
• One or more subscriber policies are used; these policies are defined by the policy-map command, which classifies various endpoint events into classes that are defined by the <class-map> command arguments. 
• The various endpoint event classifications are subject to specific actions, some of which are local and some of which are enforced on instructions from ISE. 
• The use of templates provides modularity, flexibility, and reusability of certain policy objects within the switch platform.

Cisco ISE Deployments

• ISE can be deployed as a standalone service or a cluster of multiple ISE nodes. 
• While the former is a good option for small-sized networks, the latter is the choice for medium and large environments. 
• Both standalone and multi-node ISE deployments can be done on bare metal servers (Cisco Secure Network Server [SNS]) or on supported Hypervisors.
• Choose the deployment type and install option depending on your requirements.
• Access switches need to talk to ISE servers for AAA. Typically, two or more RADIUS servers are defined on the switches for AAA and CoA. 
• For large networks involving multiple PSNs per site, we recommend that use of Load Balancers. 
• When Load Balancers are used, the virtual IP addresses of these Load Balancers must be configured as RADIUS server IP addresses on the switches.
• The following table summarizes the configuration practice that should be followed, depending upon the type of deployment and whether Load Balancers are used or not.

Switch-Side Configuration	2-Node Standalone ISE	Multi-Node ISE	Multi-Node ISE with Load Balancers
RADIUS Server configuration for AAA	IP address of the either ISE nodes	IP address of the PSNs	IP address of the Virtual IP address of the Load Balancers
RADIUS Server configuration for CoA	IP addresses of the either ISE nodes	IP addresses of the PSNs and PANs	IP addresses of the Load Balancer VIP, PSNs, and PANs

High-Level Functional Operation Sequence Overview of 802.1X
Below Figure shows how the components and protocols of 802.1x work together.

The message exchange as shown in Figure is divided into four stages:
Session initiation

• An 802.1X authentication can be initiated by either the switch or the supplicant. 
• From the perspective of the switch, the authentication session begins when the switch detects a link up on a port. 
• The switch initiates authentication by sending an EAP-Request-Identity message to the supplicant. If the switch does not receive a response, the switch retransmits the request at periodic intervals.
• The supplicant can initiate authentication by sending an EAPoL-Start frame. 
• The EAPoL-Start message enables supplicants to speed up the authenticate process without waiting for the next periodic EAP-Request-Identity from the switch. 
• EAPoL-Start messages are required in situations where the supplicant is not ready to process an EAP-Request from the switch (for example, because the operating system is still booting); or where there is no physical link state change on the switch (for example, because the supplicant is indirectly connected via an IP phone or hub).

Session authentication

• During this stage, the switch relays EAP messages between the supplicant and the authentication server, copying the EAP message in the EAPoL frame to an AV-pair inside a RADIUS packet and vice versa. 
• In the first part of the exchange, the supplicant and the authentication server agree on an EAP method.
• The rest of the exchange is defined by the specific EAP method. 
• The EAP method defines the type of credential to be used to validate the identity of the supplicant and how the credential is submitted. 
• Depending on the method, the supplicant may submit a password, certificate, token, or other credential. That credential can then be passed inside a TLS-encrypted tunnel, as a hash or in some other protected form.

 
Session authorization

• If the supplicant submits a valid credential, the authentication server returns a RADIUS Access-Accept message with an encapsulated EAP-Success message. 
• This indicates to the switch that the supplicant should be allowed access to the port. 
• Optionally, the authentication server may include dynamic network access policy instructions (for example, a dynamic VLAN or ACL) in the Access-Accept message. In the absence of dynamic policy instructions, the switch simply opens the port. 
• If the supplicant submits an invalid credential or is not allowed to access the network for policy reasons, the authentication server returns a RADIUS Access-Reject message with an encapsulated EAP-Failure message. 
• This indicates to the switch that the supplicant should not be allowed access to the port. 
• Depending on how the switch is configured, it may retry authentication, deploy the port into the Auth-Fail VLAN, or try an alternative authentication method.

 
Session accounting

• If the switch can successfully apply the authorization policy, the switch can send a RADIUS Accounting-Request message to the authentication server with details about the authorized session. 
• Accounting-Request messages are sent for both dynamically authorized sessions as well as locally authorized sessions; for example, Guest VLAN and Auth-Fail VLAN.

 
A fifth stage, session termination, is not shown in Figure.

• Session termination is an important part of the 802.1X authentication process. 
• To ensure the integrity of the authenticated session, sessions must be cleared when the authenticated endpoint disconnects from the network. 
• Sessions that are not terminated immediately can lead to security violations and security holes. 
• Ideally, session termination happens as soon as the endpoint physically unplugs, but this is not always possible if the endpoint is connected indirectly, for example, via an IP phone or hub. 
• Multiple termination mechanisms may be needed to address all use cases as below:

Link down

• The most direct way to terminate an 802.1X session is to unplug the endpoint. When the link state of the port goes down, the switch completely clears the session. 
• If the original endpoint or a new endpoint plugs in, the switch restarts authentication from the beginning.

EAPoL Logoff/proxy EAPoL Logoff

• The EAPoL-Logoff message was designed to allow the supplicant to tell the switch to terminate the existing session. 
• On receipt of an EAPoL-Logoff message, the switch terminates the existing session. 
• However, there are not many practical applications of this message and many supplicants do not send EAPoL-Logoff messages.

CDP Enhancement for Second Port Disconnect

• For IP telephony deployments with Cisco IP phones, the best way to ensure that all 802.1X sessions are properly terminated is using Cisco Discovery Protocol (CDP). 
• Cisco IP phones can send a CDP message to the switch indicating that the link state for the port of the data endpoint is down, which allows the switch to immediately clear the authenticated session of the data endpoint.

Inactivity Timer

• When the inactivity timer is enabled, the switch monitors the activity from authenticated endpoints. 
• When the inactivity timer expires, the switch removes the authenticated session. 
• The inactivity timer for 802.1X can be statically configured on the switch port or it can be dynamically assigned using the RADIUS Idle-Timeout Attribute [28]. 
• Cisco recommends setting the timer via the RADIUS attribute because this provides control over which endpoints are subject to this timer and the length of the timer for each class of endpoints. 
• For example, if your phones are capable of Proxy-EAPoL-Logoff, there might be no need to assign an inactivity timer for 802.1X-authenticated sessions. 
• Likewise, endpoints that are known to be quiet for long periods of time can be assigned a longer inactivity timer than endpoints in greater use.