9.2.2. Network Devices Requirements

In each of the use cases that we can implement with OpenNAC, there are a series of requirements that the network devices must meet.

These requirements will ensure the proper functioning of the use cases.

For this we are going to divide the requirements by use case:

9.2.2.1. Visibility

If visibility is required through the res devices, there are different requirements based on the source of information used:

9.2.2.1.1. Visibility through network traffic

The requirements to realize visibility through network traffic are:

  • Support of SPAN, RSPAN and ERSPAN (for L3 switches)

9.2.2.1.2. Visibility through RADIUS Accounting

The requirements to realize visibility through RADIUS Accounting are:

  • Compatibility with RFC2866

    • Accounting must be possible without the need for prior authentication.

    • To have complete accounting information, it is necessary that the packets sent by the switch contain the IP of the discovered device.

9.2.2.1.3. Visibility via SNMP Traps

The requirements to perform visibility through SNMP Traps are:

  • Support for sending SNMP Traps that contain information about the MAC and the Port to which the devices are connecting. This information must be included in the same SNMP Trap message. You must also specify if the MAC is connecting, disconnecting or moving port (MAC Change SNMP Trap).

The use of SNMP v3 is recommended.

9.2.2.2. UNAC

The main requirements for the UNAC use case are the ability to perform port authentication based on the following RFCs:

  • RADIUS (RFC 2865) (Indispensable Requirement)

  • 802.1x (RFC 3580) (Indispensable Requirement)

The 802.1x requirements will depend on the type of authentication required for the use case, these can be:

  • 8021.x User Authentication

  • 8021.x Host Authentication

  • 802.1x Authentication by Certificate (User or Machine).

  • MAC Address Authentication

  • Default VLAN (Indispensable Requirement)

In the case of UNAC, network segmentation is not contemplated since it is part of the Segmentation use case. That is why network devices must be able to assign the relevant network or VLAN to the devices after authentication is done.

For this, the requirement is to have a Default VLAN.

  • Critical VLAN (Indispensable Requirement)

An essential point in the case of UNAC is the scenario where for some reason the NAC system is not accessible to network devices. In this scenario, it is essential and a requirement of great importance that the network devices have a critical VLAN system which they assign to the users in this scenario.

  • Reject VLAN or Guest VLAN (Optional Requirement)

It is possible that in the event of an authentication error we want to assign the devices to a certain VLAN, for this it will be necessary to have the rejection VLAN or Guest VLAN configuration.

  • Pre-Auth Control Direction (Optional Requirement)

This option allows us to configure the data flow prior to the authentication of a user device. Sometimes it is possible to allow traffic from inside to outside of the switch prior to user authentication.

9.2.2.3. Segmentation

The Segmentation use case requires network devices to accept information about how to assign network permissions to user devices in the authorization phase.

These requirements are:

  • Dynamic VLAN assignment (Optional if segmentation by VLAN is not used)

In order to segment user devices based on the VLANs defined in the network devices, it is necessary:

  • VLAN support (802.1Q)

  • Possibility of assigning VLANs to sessions through RADIUS attributes (as standard, RFC 2868)

  • Assignment of ACLs (Optional if ACL segmentation is not used)

In order to segment user devices based on ACLs we have two options:

  • Assigning static ACLs

    Network devices must allow some type of identifier of an ACL previously defined on the network device itself to be sent to them so that it can be applied to the authorized session.

  • Assignment of dynamic ACLs

    Network devices must allow a full ACL that is not previously defined on the network device to be sent to it for the network device to apply to the authorized session.

As a standard, RFC4849 is usually followed, but it is possible that some manufacturers use proprietary RADIUS attributes.

  • Toggle Port

In the event that there is a possibility that the user devices need a re-evaluation of their session and that this implies a change in their segmentation state, it will be necessary for the network devices to have one of the two TogglePort mechanisms:

  • SNMP

Management through SNMP protocol (Enable/Disable interface), SNMP v3 is recommended.

  • CoA

Compliant with RFC5176 or RFC3576.

9.2.2.4. User Device Compliance

The User Device Compliance use case is primarily based on the uses of UNAC and Segmentation.

The analysis of the level of compliance of a device allows us to control whether or not it can access the network (UNAC) and with what level of privileges it can do so (Segmentation).

That is why the requirements of this use case will be based mainly on the requirements of the mentioned use cases depending on the scope of the project to be implemented.

9.2.2.5. BYOD & Guest Management

The BYOD and Guest use cases are primarily based on the use of captive portals for network access.

There are currently two types of methods for creating captive portal flows with their respective requirements:

  • Method via webauth

This method is based on the realization of the flow through HTTP/HTTPS calls towards the network devices. To do this, these network devices must support this webauth method.

  • Method via TogglePort

The TogglePort method is primarily based on having the network segmented and performing a segment change after the captive portal flow is complete. For this, the necessary requirements are similar to those of the segmentation use case:

  • Dynamic VLAN assignment (Optional if segmentation by VLAN is not used)

  • Assignment of ACLs (Optional if ACL segmentation is not used)

  • Toggle Port (CoA or SNMP)

9.2.2.6. Network Device Compliance

In the case of Network Device Compliance, the following three OpenNAC modules are mainly used:

  • NetBackup

  • NetConf

  • Network Device Compliance

For all of these modules, the prerequisite is the ability to connect and manage the device via SSH.

9.2.2.7. Optional

  • Syslog Analytics

If the network electronics is compatible with syslog, it is possible to send the logs of these network devices to be stored in ON Analytics and to be able to trace the logs of the network devices in OpenNAC.