RADIUS-based NAC vs Sensor-based NAC
This article will focus on some of the Pros and Cons of central versus distributed architectures with respect to Network Access Control (NAC) solutions. During the decision making process when purchasing or implementing NAC solutions, the question of architecture is always at the forefront.
Many factors come into consideration when looking at central versus distributed architecture. Cost, complexity implementation, ongoing management, redundancy, connectivity, routing, location of directory or other servers, the list goes on and on. To highlight some of the specific factors and how they translate to real-world considerations, we will compare and contrast a generic RADIUS-based central NAC architecture to a Genian NAC distributed Sensor architecture.
Central RADIUS Architecture
Pros
With a typical centralized RADIUS server architecture, a RADIUS server will be deployed in the data center. Various network devices such as switches, wireless controllers and/or wireless access points will be integrated with the central RADIUS server. Upon initial glance, it is relatively easy to highlight some of the more common Pros of this architecture. Below are a few examples:
- Only one NAC device / RADIUS server to deploy
- Only one NAC device / RADIUS server to manage over time
- Less hardware cost if hardware is deployed
- Potentially less ongoing maintenance cost depending on licensing
If we peel back the onion and dig deeper, this central architecture model does however introduce several Cons as well. Due to the nature of RADIUS and the centrally deployed architecture, there are now requirements, caveats and limitations that must be taken into account.
Cons
A central RADIUS server introduces a Single Point of Failure for network access
- HA typically then becomes a requirement
- HA introduces additional cost
- HA introduces additional complexity
- Additional complexity means longer implementation
RADIUS requires integration with every network device
- Every switch, controller or access point requires configuration
- Every switch, controller or access point must be configured in the RADIUS server
- Although there are less NAC/RADIUS servers to configure/manage, that is offset by the requirement to configure so many network devices
WAN connectivity creates additional configuration and challenges
- Bi-directional communication for RADIUS traffic must be allowed
- Firewalls/ACLs must permit authentications from every network device to the RADIUS server
- Unsolicited RADIUS Change of Authorization (CoA) packets must be permitted through Firewalls/ACLs to all remote network devices
- In the event of a WAN failure, network devices will not be able to reach the central RADIUS server
- Some network devices support critical VLAN or RADIUS failure options but not all. Either way this means additional configuration and complexity
- To overcome the WAN challenges, distributed RADIUS servers would need to be deployed which negates the original central architecture design
Genian NAC Distributed Sensor Architecture – An Alternative Approach
Since Genian NAC Sensors and Policy Servers are not part of the network architecture, this eliminates many of the challenges involved with a RADIUS architecture and implementation. Additionally, since the Sensors are centrally managed by a Policy Server, all of the benefits of a central architecture are present without the drawbacks.
Below is a list of some of the benefits provided by the Genian NAC architecture:
- No Single Point of Failure for network access
- Policy Servers and Sensors are not part of the network infrastructure
- This negates the requirement for HA to ensure network availability
- No HA reduces cost
- No HA reduces complexity
- Less complexity means faster implementation
- Does not require any integration with network devices
- No switch, controller or access point configuration required
- Network access devices do not need to be aware of or point traffic to Sensors
- Although multiple sensors may be present, no integration means easy installation
- WAN connectivity does not create additional challenges
- Sensors communicate to Cloud Policy Servers to download policies
- For On-Prem Policy Servers, Sensors communicate via keepalives
- No unsolicited RADIUS Change of Authorization (CoA) packets must be permitted through Firewalls/ACLs
- In the event of a WAN failure, Sensors operate in Fail Safe mode by default
- No network access is blocked while in Fail Safe mode
- Fail Closed option is available if desire is to block new devices from network
- Ease of Sensor Provisioning
- Zero Touch Provisioning to Cloud Policy Server
- Low Touch Provisioning to On-Prem Policy Server
- Distributed Architecture = Low Cost? – Yes!
- Sensors can be installed as Virtual Machines
- Sensors can be installed on almost any Intel physical machine
- Even an endpoint node with an Agent can act as a Sensor
- Sensor deployment options offset cost of a typical distributed architecture
- Licensing not tied to number of Sensors further offsetting cost
In conclusion, the Genian NAC architecture provides a solution that is centrally managed, yet can be deployed in a distributed fashion. With no requirement for HA, no requirement to integrate with network infrastructure, concerns regarding remote site WAN connectivity negated and the ability to rapidly deploy, Genian NAC’s architecture means low overhead for IT and Security teams. Less planning, less design, less caveats, ease of provisioning, faster implementation.