What is the methodology for Implementing 802.1x on your LAN

How to implement 802.1x on your wired network?

Although next generation LANs should be based on SD-Access technology, there are still many companies securing their wired network with an interim solution. This means implementing a combination of 802.1x or MAC Authentication Bypass (MAB). Those methods allow you to authenticate and authorize the endpoints that connect to the access layer. Many other blogs focus on providing the configuration for the access switches or Cisco Identity Services Engine (ISE). Instead, we want to explain our engineering approach and things that you need to consider.

There are many very skilled engineers that know every feature on ISE and can explain packet level details for various flows. They often concentrate on discussing those advanced features and forget about the bigger picture. The end goal is often improving the network security across a vast number of switches in a short amount of time. The next stage could be to further enhance it but it doesn’t make sense to try and move from zero 802.1x or MAB straight to the most complex deployment.

Prepare and design before you implement wired 802.1x

What is often missing is a structured approach to prepare, design and implement the solution. Each project should always start with the network assesment where you can understand the current setup. This first critical phase should be followed by the network design where you can demonstrate the concepts to the customer. Don’t be tempted to bypass those stages and move straight into the solution implementation because it will come to bite you in the long run. Lack of planning will never save time but on the contrary it will cause delays and unexpected outages.

The documentation will help you spot many challenges on paper instead of during the change window. It will help you provide the solution that is flexible enough to add more complex features later. Nobody likes backing out the change or re-implementing large parts of the solution. You need this detailed planning before scheduling any changes. Finally, great documentation will provide a strong foundation for training and handover at the end of the project. Embrace it because it will save you from many headaches.

Monitor, Low Impact or Secure Mode

There are plenty of articles on the Internet talking about three main stages of wired 802.1x implementation. Those phases are:

Monitor Mode – Configure your access switches with mab and 802.1x but ignore RADIUS (ISE) response and allow connectivity regardless of the Authentication result
Low Impact Mode – Only allow basic DNS / DHCP / AD traffic but any extra connectivity will require succesful authentication from ISE
Secure Mode – only allow EAPoL and deny all other traffic from the endpoint until it is succesfully authenticated

Configuring the switch in Monitor Mode essentially means you need an extra command “authentication open” on each port. The main difference between Low Impact and Secure Mode is an access list on the interface and is required to support devices that are authenticated via MAB. Implementing Low Impact mode can lead to problems when ISE becomes unreachable and an ACL is in place. This condition would require custom EEM scripts to remove the ACL and allow a critical VLAN when ISE is unreachable. What is the rationale behind running with all those stages for wired authentication rollouts? Is it always required to configure all switches at least twice to achieve the same end goal?

You can control deployment stages from ISE

At the end of the day the most simplistic form ISE would send a RADIUS Access-Accept or Access-Reject message to the switch. If the switch is in Monitor Mode it will simply ignore it and allow full access regardless of the authentication result. If your environment is very large with hundrends of switches you can use alternative approach. Instead of configuring “authentication open” on all ports in the monitor phase you could lock the port down but configure ISE to allow all traffic.

In the past if ISE was already pre-configured and used for wireless it was possible but difficult to provide a policy that allows all wired traffic to begin with. Fortunately, ISE now supports Policy Sets that allow very granular configuration and splitting all wireless and wired policies much easier. You can now group all your wired devices under multiple policy sets and later lock them down in stages. This doesn’t mean that implementing monitor mode with “authentication open” on the switches is no longer a valid approach. We just want to show an alternative method that could be considered.

Start the wired 802.1x implementation on a small group of switches

In order to define your ISE policy for wired endpoints you need to start the discovery phase on a smaller scale. It is best to select a number of switches that should be representative for the whole estate. The approach to select those switches would vary but should include the following:

various switch models
different types of endpoints connected to the switches
software versions if applicable

Once you start your implementation on those switches you will receive a great deal of information about the devices connected to your network. This Proof of Concept will allow you to test the solution on a smaller scale and make sure it all works as expected. You will also uncover any potential software defects that may determine the best software version for the mass rollout. In the end of this POC phase you should have a much better understanding on how you need to structure your future policies. It is extremely likely you will have more than one configuration template that may include multi-domain or multi-auth options.

Draft your wired security policy during POC and adjust it throughout the project

Just imagine skipping this crucial POC stage and attempting a mass rollout of Monitor Mode everywhere. ISE will be flooded with hundreds or thousands of new authentications and it would be extremely difficult to work with a large number of endpoints to define precise security policies. Any problems with the original template would have to be re-implemented across the estate. As long as POC devices provide a representative snapshot of your environment you may find the following mix of endpoints:

Wireless Access Points
Workstations and Laptops
Wired Phones
CCTV cameras
Printers
Barcode Scanners
Sensors
Access Control
Etc

Those endpoints could authenticate to the network with wired 802.1x or the switch could use MAB as a mechanism to authenticate them. For any devices that require MAB it is critical to purchase ISE Plus licensing that allows automatic endpoint profiling. All endpoint profiles can be further abstracted into logical groups that in turn would be used in your Authorization rules. Your corporate policy may require 2-factor authentication for laptops and workstations. This means that a wired 802.1x supplicant rollout and configuration will run in parallel if not already implemented. You can draft your policy during the POC stage and later adjust it in the mass rollout as required. Over time, you should see all legitimate endpoints and users hitting specific rules inside a specific policy set. The goal is to make sure nothing hits default catch-all rule. This is because at the end of the project it should deny any traffic and the switches should enforce it.

Implementing wired authentication on your LAN is a great step towards SD-Access

Many organizations planning to implement SD-Access will at face the challenge of identifying the endpoints connecting to their LAN. There are some fundamental differences in policy enforcement between the traditional wired authentication described here and SD-Access. In traditional networking the access switch allows, denies or restricts access for each endpoint based on the ISE authentication result. In Software Defined Access it works differently because ISE provides Scalable Group Tags (SGTs) based on authentication result. Those SGTs are used to enforce the policy in the dataplane based on a connectivity matrix that is also defined on ISE and passed to the edge nodes. Bottom line is that you need to authenticate your endpoints in order to provide the correct SGT in any SD-Access design. Starting reconnaissance and implementing a traditional wired authentication on your LAN today will bring you one step closer to the future SDA dream.